Splitting agents by profession recreates the handover problems that slow human teams down; splitting by feature lets each agent finish what it starts.
The more people involved in a project, a task or an initiative, the more opportunities we create for mistakes, misinterpretations and missing context. That is not a controversial claim. It is roughly why standups, handover documents and alignment meetings exist in the first place.
I am starting to think the same is true for AI agents.
What ten years of Flash taught me about handovers
For the first ten years of my career I worked extensively with Flash. Flash let you design, animate and code inside the same environment, and as a generalist I often built smaller websites and applications almost entirely on my own.
That was frequently faster than having three people coordinate the same work. Not because one person was better at every discipline. They rarely are. It was faster because there were fewer handovers, and fewer meetings.
No translation from designer to developer. No explanation from developer to animator. No morning alignment to reconnect decisions that had drifted apart the day before.
The animation was baked into the design. The design reflected what was technically possible. The code was written with respect for the intended experience. Everything stayed inside the same mental model.
We are rebuilding the org chart in agents
When people build teams of agents, they tend to copy the organisational structure they already know. One agent for design. One for architecture. One for development. One for QA. One for integration. One for deployment. And an orchestrator on top, coordinating the handovers.
It looks sophisticated on a diagram. It also recreates every translation layer that slows human teams down.
A small implementation detail disappears before it reaches QA. A design decision loses its reasoning on the way to development. The deployment agent hits an error with no understanding of the architectural choice that produced it.
Split the application, not the profession
So perhaps we should cut the work along a different axis.
Horizontally, divide the application into features, components or clearly isolated areas of responsibility. Feature teams, essentially. One agent owns the checkout flow, another owns account management, another owns search, another owns the content pipeline.
That split is practical before it is philosophical. Agents working in separate areas are not constantly touching the same files, components and branches.
Vertically, though, each agent should own much more of the delivery than we usually allow. The checkout agent should not only write checkout code. It should understand the user need, design the interaction, weigh the architecture, implement the feature, test it, resolve the integration problems it causes and get it ready for deployment.
Horizontally separated. Vertically whole. Almost the exact inverse of the traditional model, where work travels down through design, development, QA and operations, losing a little context at every step.
Human specialisation is a constraint we do not have to inherit
We built those organisational layers partly because humans specialise, and for good reasons. A strong designer may not naturally think like a backend architect. A backend engineer may not be good at interaction design. A QA specialist notices things the person who wrote the implementation is blind to, precisely because they did not write it.
Those differences are real and valuable. They are also human. Different kinds of intelligence, different depths of knowledge, different biases — that is what separates designers from backend engineers today, and none of it transfers to a model.
An agent does not experience the same distance between creative thinking, systems thinking, implementation and testing. It can reason about the experience while holding the architecture in mind. It can write the code while remembering the design intention. It can run the tests while still carrying the implementation decisions in context.
Being able to connect those disciplines may be one of its greatest strengths.
So why break that context apart on purpose?
The best Flash work I saw was rarely made by treating animation, design and code as unrelated production stages. The animation was considered while the interface was designed. The design respected how the experience would actually be built. The implementation preserved the character and intention of the design. The result felt coherent because the same context travelled through the entire piece of work.
Agentic development can benefit from the same principle. Give agents separate horizontal areas so they do not interfere with each other, and enough vertical responsibility to finish what they start.
Where fragmentation still earns its place
Independent review is the exception, and it matters.
My current setup usually has Claude doing the development and ChatGPT reviewing the result. That gives me a genuinely different set of eyes without fragmenting the implementation across five agents. The split is deliberate, because a review is worth less when it comes from the same context that produced the work.
That is the test I now apply to any new agent in a setup: is this split here because the work genuinely needs isolation, or because an org chart in my head says it belongs to a different job title?
Separate the work. Not the understanding.
Use as many agents as the horizontal architecture requires, and as few vertical handovers as you can get away with. Save fragmentation for the places where it does real work, like QA and review.
The most effective agent organisation probably does not resemble a large corporate org chart. It looks more like a small group of highly capable generalists, each owning a complete feature from intention to implementation.
37 views