Don't Build an Agent Company for a Form Field: Why One Main Agent Beats a Full Roster

Recently I've been watching some AI Coding workflows and keep getting a familiar feeling: product, architecture, development, testing—each role gets an Agent, then a supervisor coordinates. Role definitions, message bus, shared memory, all in place, like a fully staffed little company.

Looking at this lineup, adding a field to a form almost feels embarrassing to ask for.

Image AI-assisted.

If a single Agent already understands requirements, reads code, modifies, and tests, why break it apart first and then let several Agents explain things to each other again?

Anthropic's recent article When to fold subagents into your main agent loop is precisely about which subagents can be folded back into the main loop. That is, let the same Agent retain working context, continuously call tools, check, and fix, until the task is done.

They observed that some enterprises, after switching to one main Agent that loads Skills and tools on demand, often get better quality, and cost and latency may also drop. One customer's time roughly halved.

These experiences come mainly from enterprise business Agents and can't be directly extrapolated to all development tasks. But one phenomenon the article points out is worth pondering: Agent architecture is copying enterprise organizational structure.

Handoffs—Agents can't escape them either

Human teams have product, development, testing, and that exists for a reason: people have limited time and different experience and expertise. But those reasons don't transfer intact to several Agents using the same model.

Giving them titles like "senior architect" or "senior developer" doesn't mean you've hired two people with different experience. Different instructions and contexts might help, but the result still depends on the outcome.

In everyday development, much of the division of labor is just different stages of the same thing. For example, adding a filter condition to an interface: the Agent discovers that empty strings and missing parameters have different meanings in the old logic, so it keeps the compatibility handling and adds a test. The detail it just looked up can be used in the next step.

If implementation and testing are each given to a different Agent, the latter has to figure out again: where did this compatibility handling come from? Is it a product requirement or historical baggage? If the handoff didn't write it down, it can only look it up again, or add a test based on its own understanding.

Of course you can ask the previous Agent to write down all the details. But judging which exploration results are worth keeping is itself work. Too little in the handoff and things get missed; too much and it has to be digested again. We've already suffered enough handoff cost in human teams; there's no reason to assume handoffs between Agents are free just because Agents don't complain.

Anthropic's another architecture article also suggests dividing along contexts that can be isolated; implementation and testing of the same feature often belong together. That's closer to the problem itself than seating people according to development roles.

Settle the process into the flow, no need to switch Agents at every step

Reading repo docs, reusing request wrappers, running checks after changes, attaching verification results on delivery—these requirements can all be written into Skills, with scripts and tools, and the main Agent loads them as needed. The conventions are reused, and the context of requirements and decisions already made stays.

The easiest confusion here is between "needs to follow a different way of doing things" and "needs another Agent to do it." For example, analyze the impact scope before modifying code; write that analysis step into a Skill and it can take over, without necessarily calling in an analyst and waiting for its report.

Codex's Skills documentation introduces this on-demand loading approach. Business knowledge can be maintained separately; it doesn't all have to be stuffed into the initial prompt, nor does every new capability require a new session.

For bug fixes, interaction tweaks, interface changes, and module refactoring, I would first let one main Agent complete the full loop, and divide work only when there's a clear bottleneck. Microservices and domain modeling experience can apply to tool interfaces, data ownership, and business rules, without turning every module into a thinking character.

Of course, a Skill carries the way of doing things. State saving across days, failure recovery, approval and permission checks still need to be guaranteed by a program or platform. If a Skill says "must pass checks before release," the release interface has to actually check that condition, otherwise it's just a strictly worded manual.

Which tasks deserve separate hands?

Development waits on design, testing waits on development; splitting into three Agents doesn't change the dependency. Meanwhile, a single main Agent can call independent tools in parallel; reading files and looking up references don't require forming a team first.

What's worth splitting is work that can run independently for a stretch and then bring back results. For instance, if a failure has several possible causes, you can separately check logs, recent changes, and dependent services; unrelated modules in a large repo can also be explored in parallel.

Independent review also has value. Having another Agent check the requirements against the final artifact has a chance of catching problems the implementer missed along their original line of thinking. It doesn't have to take over every implementation detail; the review scope and delivery result are fairly clear.

For this kind of collaboration, I would first use the built-in subagents in Codex and Claude Code. Dispatch, wait, and collect results are already handled; there's no need to maintain a role and message system for a few bounded divisions of labor.

But built-in also has overhead. Claude Code's Agent Teams documentation explicitly states that team mode uses more tokens; sequential tasks, same-file edits, and work with many dependencies are better suited to a single session or subagent. Several terminals refreshing logs at once doesn't directly count as improved efficiency.

I'd look at one practical thing: after handing off a subtask, can the main Agent keep doing useful work? If it can only wait for the report, and then has to reread the code when the report comes back, the added division of labor probably doesn't save much time.

The value of platforms also needs to be counted separately

A representative product like Multica, from its official introduction, drives existing coding agents and provides task assignment, run logs, review, and usage statistics. A team needs to know who's doing what, where it's stuck, and how much it costs—these all have practical use.

But managing a hundred tasks and splitting one task into ten Agents are two different things. The former solves management and visibility; whether the latter improves execution efficiency needs separate proof. Just because we need a dashboard doesn't mean we should also accept the whole role-switching mechanism behind it.

Keeping the dashboard, approvals, and run logs, while having individual tasks completed by a main Agent plus Skills, calling subagents when necessary, can still form a complete development workflow. What I don't endorse is first arranging a full set of roles, then making every small change go through rounds of requirement restatement, plan generation, and phase summaries.

Whether a specific product is slower or more expensive can't be concluded from a single usage impression. Model selection, caching, retries, and platform queueing all affect the result. The more complex the solution, the more it should be compared on actual tasks.

You can take the same batch of real tasks and compare: native Agent plus Skills, built-in subagents, and external orchestration. Keep the model, permissions, and acceptance criteria as consistent as possible; compare pass rate, total time, manual rework, and actual cost, including failures and retries.

Anthropic's migration toolkit also replaces items one by one and compares before and after; it doesn't presuppose that a single Agent necessarily wins.

My inclination is clear: for routine development, first use one Agent well. If adding people solves a problem, add them; but if it's just a few extra boxes and a few more handoff documents, I'd rather save the money. After all, when hiring people we all know to confirm the workload first; when it comes to Agents billed per token, people suddenly get generous.