# The Project Agents Starter Kit From "Applied AI for Marketing Ops" (appliedaiformops.com) by Lily Luo. Structure for running more than one agent at once: one agent per project, a coordinator that only routes, model routing, scaled review, and a board. **Two ways to use this file:** - **By hand.** Read it top to bottom and build each piece with your AI agent's help. - **Give it to your agent.** Paste this whole file to your AI agent and say "set this up for me." The last section is instructions for the agent. --- At some point one agent working from one set of files stops being enough, not because the files are wrong, but because you are running more than one kind of work and loading all of it for every task dilutes the parts that matter. This is the kit for that point. It assumes you already have files that persist (if not, start with The Files-First Starter Kit, lilyluo.ai/starter-kits/files-first) and a way to keep them current (if not, The Context Capture Starter Kit, lilyluo.ai/starter-kits/context-capture). What is left is structure: one agent per project instead of one agent for everything, a coordinator that routes between them, model routing so cost matches the work, review that runs only where being wrong is expensive, and a board that shows you all of it at once. This needs a platform you can configure: something that supports more than one running context, a way to pass instructions between them, and a place to persist records outside of any single conversation. ## The five pieces | Piece | What it does | |---|---| | One agent per project | Each project gets its own memory, its own task records, its own states, so work on one project never bleeds into another | | A coordinator | Routes a request to the right project and never does the work itself | | Model routing | Matches the cost and capability of the model to what the task actually needs | | Independent review, scaled | A second pass that checks the first, run only where being wrong is expensive: code and anything going outside | | The board | One view across every project, so you can see what is moving without opening each one | ## Why this is the last kit, not the first Everything here assumes discipline you already have at the file level. A coordinator routing between five agents that each have stale, conflicting, or missing files just produces five times the confusion instead of one. Build the structure after the content is already solid. --- ## `01-one-agent-per-project.md` (One agent per project) Each project gets its own memory, its own task records, and its own states, because mixing them produces an agent that is mediocre at everything instead of good at the one thing in front of it. --- ### What each project needs | Part | What it holds | |---|---| | Its own memory | The facts, standards, and decisions specific to that project, not the whole system's | | Task records | A specific record per request: the objective, what counts as done, what files it needs, what it is allowed to touch | | States | Where each task actually is: ready, working, in review, blocked, done | ### Why states matter more than they sound like they should A task without an explicit state is a task an agent can forget, skip, or quietly drop, and nothing tells you it happened. States are the mechanism that makes "did this actually get reviewed" an answerable question instead of a guess. ### Scoping a project A project is a bounded piece of work with its own facts and its own standards, not every topic you touch: a newsletter has different rules than a code change, and a code change for one codebase has different context than a code change for another. If two things need different files to do well, they are different projects, even if the same person is doing both. ### Simple at first Start with memory and task records. Add explicit states once you have caught yourself asking "wait, did that actually happen" more than once. The structure earns its complexity; it should not arrive all at once. ### A real example I run one agent per project I track, each with its own folder, its own brief, and its own record of what it is allowed to do. The complexity is not even across them. A fantasy football league is a single file and a short brief: who is on my roster, who is on a bye. This website is the opposite end: a brief, a task record, and a review step for every piece of work, because the project itself keeps growing and a single flat file stopped being enough to hold it. Both are the same pattern at different scales. Neither works by stuffing one into the other's context. --- ## `02-coordinator.md` (The coordinator) One layer whose only job is to route a request to the right project agent. The coordinator never writes the draft, never writes the code, and never makes the judgment call. It decides where the work goes and keeps track of what is moving. --- ### What it does 1. Takes a request in plain terms, not a command syntax you have to remember. 2. Turns it into a bounded task: an objective, what counts as done, which project it belongs to. 3. Starts the work in that project's own context, not its own. 4. Tracks status across every project so you can ask "what is everyone doing" and get a real answer. 5. Opens review when work is submitted, in whichever project needs it. ### The rule that keeps it a coordinator and not just another worker If the coordinator is ever the one producing the output, something has gone wrong. Its context should stay about routing and status, never about the content of any single project. The moment it starts drafting instead of dispatching, it has become just another project with no one left to coordinate it. ### What it should ask before acting Not everything should launch itself. A coordinator should check before starting sensitive, outward-facing, or costly work, and before starting a second simultaneous worker on the same thing. Routine internal work can proceed on its own. The line between the two is a judgment call worth writing down once, not re-deciding every time. ### A real example Mine runs as a persistent session I talk to in plain language, and it is the thing that turns "can someone check my week's lineup" into an actual bounded task in the right project, with the right agent picking it up. I can also go straight to a project's own agent when I want to, and often do. The coordinator is there for when I do not want to remember which project owns which kind of request. When I catch it drifting toward doing the work itself, that is a signal something in the routing needs fixing. --- ## `03-model-routing.md` (Model routing) Not every task needs your most expensive model, and not every task should run on your cheapest one. Model routing is the rule that matches the two on purpose instead of by habit. --- ### What decides the route | Factor | What it changes | |---|---| | Risk | Anything outward-facing, sensitive, or hard to reverse adds required review passes and needs your yes before it starts, even if the task looks small | | Complexity | A quick lookup and a multi-step build are not the same task wearing different clothes | | Category | Drafting, coding, and research pull on different strengths; route to the model suited to the category, not just its general reputation | ### Keep it deterministic where you can A fixed rule, applied the same way every time, beats a judgment call you make freshly for every task. Write the rule once: this category, at this risk level, gets this model at this effort. Then let the coordinator apply it without asking you each time, except for the cases you deliberately carved out as needing your yes first. ### Where review effort should go Routing the model correctly is half the cost control. The other half is not re-running a full model on a task that only needed a lighter one to begin with, and not under-provisioning a task where being wrong is expensive. Both mistakes cost you, in different directions. ### A real example My own router scores a task on category and complexity, then assigns a specific model and effort level, logged alongside the task record so the choice is visible. Routine internal work gets a lighter route. Anything outward-facing or sensitive always gets at least one independent review pass, even when the task is small enough that it would otherwise get none, and it needs my yes before the work starts. Being wrong in public costs more than being wrong in a draft only I will see. --- ## `04-independent-review.md` (Independent review, scaled) A second pass, run by something that did not write the first draft, checking it against what actually matters. The mistake most setups make is running this on everything, which makes it too slow to keep using, or on nothing, which means the first mistake that matters goes straight out. --- ### Where it earns its cost **Code.** A second pass catches what the first pass was too close to the problem to see, and the cost of a bug reaching something that runs is higher than the cost of a few extra minutes. **Anything going outside.** A draft headed anywhere outward-facing gets a check against your boundaries and your standards before a person signs off on it. Skipping review here lets a risk through unnoticed, which costs far more than the few minutes it saves. ### Where it does not need to run Logging a quick idea, an internal note, a task that gets looked at and fixed in the same minute it is written. Review that runs on everything trains you to skip reading it, which defeats the purpose more completely than not having it at all. ### How to structure a pass Give the reviewer the acceptance criteria and the actual artifact, not a vague "check this over." A reviewer asked to verify specific claims against specific evidence catches real problems. A reviewer asked to generally assess quality produces opinions instead. ### A real example My setup scales review by risk: routine internal work gets zero passes and is marked done on its own evidence, balanced work gets one independent pass from a different model than the one that wrote it, and anything outward-facing or sensitive gets a focused pass no matter how small the task looks. The review step is not free, so it only runs where being wrong actually costs something: a line of code that ships, a sentence that goes out under my name. Everything else just gets done. --- ## `05-the-board.md` (The board) One view across every project, so "what is everyone doing" has a real answer instead of requiring you to open five places and ask. --- ### What belongs on it | Column | What it shows | |---|---| | Project | Which agent owns this | | Task | What is actually in motion | | State | Ready, working, in review, blocked, or done | | Needs you | Anything stuck on your decision, flagged so it cannot hide | ### What the board is not A dashboard of vanity activity. If a row does not tell you something you would act on, cut it. The point is to surface what needs a decision, not to produce a satisfying wall of status. ### What needs your decision first Whatever is blocked on you. A board that buries the two things waiting on your yes under twenty things quietly in progress has failed at its one job. Sort for that, or flag it separately so it cannot get lost in volume. ### A real example Mine is a single view across every project I track, with each task's state and a flag for anything that needs my decision pulled to the top. It once caught a task where the worker had finished and the review step never actually ran: the review sat unrun for six weeks before the board surfaced it, because nothing on a board like this stays hidden once you are actually looking at it instead of trusting it is fine. --- ## For your AI agent If your user pasted this whole file and asked you to set it up, do this: 1. Confirm the user already has persistent files per project (from The Files-First Starter Kit or equivalent) and a way to keep them current. If not, point them there first; this kit is structure built on top of that content. 2. Set up one agent, memory file, and task-record format per project first. Keep states simple: ready, working, in review, blocked, done. 3. Build the coordinator next. Write down explicitly what it is never allowed to do: produce the actual output. Its job is routing and status only. 4. Add model routing as a written rule: which category and complexity level gets which model and effort, and which risk level adds review passes and requires the user's yes before starting. Apply it the same way every time rather than re-deciding per task. 5. Add independent review scaled to risk: zero passes for routine internal work, one pass for balanced work, and a focused pass for anything outward-facing or sensitive, whatever the tier. 6. Build the board last, once there is more than one project actually running. Sort or flag it so whatever needs the user's decision cannot get buried. 7. Ask before starting sensitive, outward-facing, costly, or simultaneous work. Routine internal work can proceed without asking each time.