AI can now write a surprising amount of code from a short request. That does not automatically make the change right, easy to support or aligned with what the business needed.
The question I keep coming back to is not simply, “Should we use one agent or many?” It is: Where does this piece of work most need a second look—and what will that review cost us?
A small, well-understood change may benefit from one agent keeping the whole task in view. A feature with unresolved design choices may need a written plan and a fresh reviewer. A long build may need a repeated cycle of implementation, real testing and correction. Those are different problems, so they should not be forced into one architecture.
First, what do we mean by “one agent”?
For this comparison, a single-context agent is one primary AI session that understands the request, explores the code, plans the change, writes it and checks its own work. It may run tests and use tools. The distinguishing feature is that there is no independent role or fresh-context hand-off to challenge its assumptions.
That can be a sensible way to work. There is less orchestration, fewer documents to maintain and less time spent transferring context. When the request is small and the code change is local, a simple workflow can be faster and easier to supervise than a team of agents.
The weakness is that the same session that made an assumption is also asked to find the assumption’s flaws. A conversation can accumulate guesses and partial decisions. As it grows, important detail may become harder to track. And a model that has just written a feature may be too ready to accept its own explanation that the feature is finished.
A single agent is not necessarily a single prompt or a single pass. It can plan, edit and run tests in a loop. The comparison is about whether important work is reviewed independently, not whether the agent is allowed to think twice.
Google’s Elephant–Goldfish Model: design first, then read it cold
Google’s Elephant–Goldfish Model, or EGM, tackles the point before code is written. The “Elephant” is a long-running, context-rich session that works with the developer to understand the system, explore choices and write down the intended design. Its job is not to rush into implementation. The “Goldfish” is a fresh-context reviewer. It sees the design and its referenced material, but not the earlier conversation that produced it. [1] [2]
That fresh start is deliberate. If a reviewer cannot understand the plan from the document alone, the document is not yet clear enough to hand to another person—or to a coding agent. EGM’s review process then asks fresh reviewers to challenge the design, find missing assumptions and check whether the implementation instructions are ready to use. A person resolves the trade-offs and approves the design before implementation begins. [2] [3]
This is not simply “add more agents.” The core idea is to make the thinking durable. The design becomes an artifact the team can review, store with the code and revisit later. The model is especially useful when a change crosses system boundaries, affects a business rule, or has decisions that would be expensive to unwind once coding has started.
There is a cost. The team must spend time discussing the problem and maintaining the design. Reviewers can also raise findings that are irrelevant or mistaken, so people still need to judge which ones matter. And the design can drift from the code if nobody maintains it. EGM’s own guide says the full design-first process need not be used for a simple bug fix; teams can use the parts that address their immediate bottleneck. [3]
Anthropic’s planner–builder–evaluator loop: build in slices, test the result
I read “Anthropic’s loop” as the planner–generator–evaluator approach described in Anthropic’s 2026 article on building long-running applications. It is a published experiment, not a universal SDLC standard. Its aim is different from EGM’s: instead of mainly testing whether the design is clear before coding, it tries to keep a long build on track through small implementation steps and repeated evaluation. [4]
The planner turns a short request into a product specification. The generator works through one feature at a time. Before a sprint begins, the generator and evaluator agree on a contract for that slice: what will be built and what evidence will show it is done. The evaluator then exercises the running application—including its interface, API and stored data—and sends specific findings back to the generator. The generator fixes the issues and moves to the next slice. [4]
That feedback is more useful than asking the coding agent to say whether its own work looks good. In Anthropic’s example, the evaluator used browser automation to interact with the application as a user would. But the author also found that the evaluator did not perform well automatically. It needed tuning to stop overlooking issues, and even after tuning it missed some defects and usability problems. [4]
The example makes the trade-off concrete. For one retro-game-maker request, Anthropic reported a solo run taking about 20 minutes and costing US$9. Its full harness ran for six hours and cost US$200. The author judged the full-harness output noticeably stronger, but this was a single illustrative comparison, not a repeated benchmark proving that the more expensive approach will deliver the same return on another codebase. [4]
Anthropic’s earlier long-running-agent work offers a related, lighter pattern: use an initializer to set up the project and feature list, then start fresh coding sessions that take one item at a time and leave progress notes and a clean working state for the next session. That approach shows that a role hand-off does not have to mean a complex swarm. A clear feature list, version history and progress file can carry a lot of the needed context. [5]
What the evidence does—and does not—say
There is no credible basis for saying that more agents are always better. A 2026 study from Google Research tested 260 agent configurations across six benchmarks, five architectures and three model families. It found that results depended on the shape of the task. Compared with a single-agent baseline, multi-agent coordination improved one decomposable financial-reasoning benchmark by about 81%, but reduced performance on one sequential-planning benchmark by as much as 70%. The study also found that tool-heavy tasks can carry extra coordination costs. These results support matching the architecture to the work; they do not directly compare EGM with Anthropic’s coding harness, and the financial and planning figures should not be treated as software-delivery results. [6]
Anthropic’s general agent guidance points in the same direction: start with the simplest approach that meets the need, then add workflow or agent complexity where it provides a measurable benefit. More steps can improve quality, but they can also add delay, cost and failure points. [7]
So I would not frame the choice as “monolithic is old” versus “multi-agent is the future.” A staged workflow is another operating cost. It earns its place when independent review, repeated testing or context hand-offs prevent more waste than they create.
Where I would use each approach
For a small, low-risk change with clear acceptance criteria, I would begin with one agent. Let it inspect the repository, make the change and run the relevant tests. Keep a human review before merging, especially if the change touches production behavior. The aim is not to add ceremony where a straightforward check will do.
For a feature where the main risk is misunderstanding the problem or making the wrong system-level choice, I would use EGM—or a lighter version of it. Ask the agent to clarify the need and write down the proposed behavior, important alternatives and affected systems. Have a fresh session read that proposal without the conversation history. If it cannot explain the proposal or identify how it will be tested, fix the document before coding.
For a longer feature whose success can be observed in a working system, I would trial the planner–generator–evaluator loop. Break the work into vertical slices that each leave the application in a usable state. Agree on what “done” means before each slice, then have a separate evaluator run the acceptance checks and report evidence, not just a score.
For a high-impact feature, I would combine the two selectively: use EGM to clarify and challenge the design, then have an implementation agent work through small slices with a separate evaluator. A human should approve the design and review the final change. I would avoid adding several agents that all edit the same tightly connected code at once. Parallel work helps when tasks are genuinely separable; otherwise, it creates integration and coordination work.
How I would trial one or both
I would start with a small pilot, not a company-wide process change. Pick a handful of real but non-critical changes that represent the team’s normal work. Include some straightforward tickets and some that involve multiple services, unclear requirements or end-to-end behavior. Use the existing single-agent workflow as the baseline, then compare it with EGM, the planner–generator–evaluator loop, or both where they fit.
Keep the comparison fair. Use the same repository snapshot, acceptance criteria, model and tool access where practical. Rotate or match similar tasks across the approaches so the result is not driven by one unusually easy or difficult ticket. Record every agent call and human hand-off. If the model, prompt, test environment or task changes materially, note it; otherwise, a “better” result may just reflect a different starting point.
Before the trial, agree what success means. I would measure the time from request to an acceptable change—not just the time until code first appears. I would also track how many changes pass review without substantial rework, defects found in testing, issues discovered after merge, human time spent correcting or coordinating the agents, and the total cost of model calls and evaluation tools. Ask reviewers whether the resulting code and design are understandable enough to maintain. Token counts and lines of code are not business outcomes.
A workflow should earn its place if it improves outcomes that matter to the team without creating a larger burden elsewhere. If the single agent consistently delivers small changes with low rework, keep it for that class of work. If EGM prevents repeated requirement or design gaps, reserve it for changes where those gaps are costly. If the evaluator catches meaningful end-to-end defects that ordinary checks miss, use the loop where those checks can be made reliable. If the review agents mostly produce noise, narrow their remit or remove them.
The pattern I would take forward
These approaches are not mutually exclusive, and neither one should become a ritual. EGM helps make intent and design clear before implementation. Anthropic’s loop adds structured, repeated feedback while a feature is being built. A single-context agent can remain the fastest option for contained work. The same team can use all three, depending on what is uncertain and what failure would cost.
For me, the goal is not to maximise the number of agents. It is to find the shortest trustworthy path from a business need to a change that works, can be explained and can be supported after the AI session ends.
References
- [1] Google Open Source Blog — Introducing the Elephant-Goldfish Model plugin: scaling design-driven AI software development
- [2] Google Open Source — Google Elephant-Goldfish Model repository
- [3] Google Open Source — Elephant-Goldfish Model setup and workflow guide
- [4] Anthropic — Harness design for long-running application development
- [5] Anthropic — Effective harnesses for long-running agents
- [6] Google Research authors, arXiv — Towards a Science of Scaling Agent Systems
- [7] Anthropic — Building effective agents