Over the past few months, we moved most of our development and product work to agents, and the number of PRs and CI runs keeps growing. Every week we see room to double our output again, either by letting each agent run longer or by running more agents at once.
Running a single agent longer has a ceiling. Every agent has a range in which its context stays effective. Beyond that range, quality drops as the context grows, often called context rot. So running more agents, rather than longer ones, could be the way to scale.
Running more agents has a clear upside. Each agent works on a task small enough to stay within its effective context window, and since inference speed is fixed, running agents in parallel is how we get more done at the same time. The downside is just as clear: once many agents are running, managing their scope, boundaries and communication becomes the problem.
Small team vs. big team
Say a project takes about 100 PRs. What is the difference between 4 people running 100 agents, and a team of 20 people who split the scope and each run 5 agents?
The real difference is how much guidance and feedback the agents get. More people means more chances to give clear scope and boundaries, catch misunderstandings and stop agents from drifting. But we found that when an agent has enough context, it can do much of that control work itself.
So we wrote that guidance down. The plan is the essential part. Before any agent starts, we plan the scope, the boundaries, the reporting structure and the feedback loops, and put them in a shared project plan that every agent works from.
The project plan
The project plan has four parts:
- Acceptance criteria. Define the overall scope and a clear way to test whether the final deliverable is accepted.
- Task decomposition. A clear task list, with the dependencies between tasks.
- Guardrails. Set up as much as possible ahead of time: working folder, isolated workspace (git worktree), shared docs, where to give feedback, where to write new findings, and a clear list of reports and resources.
- Feedback loops. Capture new findings and use them to update the shared context as work moves on.
The task spec
Every task spec states:
- the task
- the expected result
- the resources it can use
- where to report
No plan is perfect
The plan will be wrong somewhere. What matters is that every agent already knows where to write when it is.
As the work moves forward, agents find things the plan did not know about, hit new blockers and run into cases nobody planned for. If each of these comes back to a person as a question, we are back to the attention problem. So next to its task spec, every agent is pre-assigned three places to write:
- Progress log. A shared log of what agents learn while they work: new findings, small decisions made inside their own scope, and anything other agents should know.
- Review feedback. Feedback on a task goes to that task's own feedback file, so the next iteration works from real results.
- Escalation. When an agent hits a blocker or a case outside the plan, it does not quietly work around it. It writes a blocker report and moves on to work that is still safe to do. The orchestration agent and the master monitoring file are where I actually pay attention.
This is the project plan's feedback loop in practice. Each round of work also leaves useful notes for the next round of iteration.
Why this works
Each agent only codes and experiments inside its own scope. It stays focused and needs less context, which frees the orchestrator to take on a bigger scope.
Most of the open decisions are made up front, and reporting and guardrails are in place before work starts. That is what makes the later integration, testing and validation doable.
This is how a large team already works. The difference is that a team keeps all of this in tools like Jira or Linear, while we keep it in markdown files that every agent can read.
How this differs from subagents
It doesn’t, really. It is the same idea: an orchestrator starts and controls the agents. The difference is timing. We decide each agent’s scope, prompt and feedback loop before the run, not during it. That is why we can start many agents at once.
Running it in practice
As we tested and refined this method, we built Agent Canvas. It shows the dependency map, feedback loops and progress, and a local orchestrator runs all the work and collects the reports.
Once the plan is ready, the orchestrator kicks things off, and the worker agents all start in a controlled way. Depending on the project's scope, managing 50 agents feels about the same as managing a few orchestrators.
This also works for smaller projects, and it scales to bigger projects with more agents.
Our largest run so far was an overnight product review: six review lanes, 61 task specs and 60 handoffs, all from one Agent Canvas project in isolated worktrees. No agent pushed code or opened a PR on its own. The night ended with one combined branch and a validation report for people to review.
The numbers moved too. Across our GitHub organization, we merged 331 pull requests from September 1 to 29. Over the same days in October, as more of our projects ran this way, we merged 905, about 2.7 times as many.
Where it still breaks
Running agents in parallel doesn’t make every project fast. In one UI regression project, we split the work into 14 tasks and ran up to six agents at once. The list grew to 17 as the agents found new issues along the way. After almost seven hours, only nine tasks were integrated. The isolated ones finished in under an hour. The slow ones were stuck waiting: on a shared test environment, on other tasks’ pages, or on a decision from us.