Blog
One agent or many? How we think about AI orchestration for software development
When we first started building Damilah’s multi-agent platform, one of the earliest questions we had to answer was: why not just use one very good agent and give it everything?
One-man bands exist, albeit as a gimmick rather than the norm. But one person acting as an electrician, a structural engineer and an architect when building a house already doesn’t sound so good. One truly talented person might well be competent at all three, but they’re unlikely to be excellent.
The same logic applies to AI agents in software development. A single, powerful AI model with the right context and tools might handle all assigned tasks adequately in isolation. But when it’s doing all of them simultaneously, context gets muddled, corners get cut and there is nobody to check the work. This won’t result in a collapsed building, but damage to a business could still be significant.
Multi-agent systems solve this by giving each agent a specific job.
Three reasons for splitting it up
Reason one: Specialisation and context isolation. A planning agent focuses on breaking down requirements, a developer agent writes code and a testing agent finds problems. Each one does what it was built to do and can be given the tools, context and instructions that match exactly what it needs. Splitting the work means each agent only carries what is relevant to its task.
Reason two: Practical speed. Frontend and backend development do not always have to wait for each other, they can run in parallel, which cuts time significantly on anything complex.
Reason three: Cost. Not every task needs your most powerful model. Routine work can be routed to a smaller, cheaper model, and complex reasoning goes to the stronger one. This is something we built directly into DMAP: real-time visibility of what each LLM call costs, with automatic routing that puts the right model on the right task. Without it, token costs grow faster than most teams expect.
But what about the trade-offs?
Trade-off one: Handoffs. They need to be designed very carefully to protect consistency and predictability. Anything one agent knew implicitly needs to be written down and passed to the next. A downstream agent making a locally reasonable decision can produce something that is globally inconsistent with what came before it.
Trade-off two: Orchestration overhead. The coordination layer (including state management, message passing, retries and error handling) does not exist with a single agent. With a multi-agent system, you have to build it, test it and maintain it.
Trade-off three: Cost and latency. Both have a tendency to go up. Each handoff is a full model call, and you pay for the context you re-pass, the summaries and the system prompts at every stage.
How we got here with DMAP
Before moving to a fully formed multi-agent architecture, we started with a single use case: building a new feature for an existing product. That required three agents: a requirements analyst, a developer and an orchestrator to coordinate them. That worked well.
But then we thought about what else teams might need in a real-life situation. Building a new product from scratch, for example, requires a product manager agent, an architect and a designer who can produce a prototype. Replatforming an existing system, on the other hand, needs a different set. Each use case we looked at required agents we had not needed before and therefore, didn’t have.
That surfaced the other real advantage of multi-agent systems that we haven’t mentioned yet: modularity. You can add or replace an individual agent without rebuilding everything around it.
Now, with DMAP’s workflow orchestration, teams can choose which agents they need, define how these agents hand off work, what gets logged at each stage and where human review sits in the loop, without wiring it all together from scratch.
The bottom line
Multi-agent systems are more powerful and more complex than a single agent. The specialisation, parallel execution and cost routing are their genuine advantages. Three specialists doing their jobs well and in parallel, can be more effective than one generalist doing it all. But only if they’re well-coordinated, otherwise you just have three people getting in each other’s way.
“When you work in product, you spend a lot of time making sure the right person is doing the right job. Building DMAP taught us that AI agents need exactly the same discipline.”
– Andrea Stankovikj, Principal Product Owner at Damilah
Orchestration overhead is an important consideration. Poorly designed handoffs can cause problems and drive up costs. To make the multi-agent approach work, you need to make sure the architecture has been thought through carefully.
If you are thinking about how to structure AI agents for your own development workflow, book a meeting with us first to ensure success.