Multi-Agent Systems

A multi-agent system is exactly what the name says: more than one agent, working on a shared task, with some way of coordinating them. The most common and most useful shape for design work is a team of specialists under a coordinator. Each agent is given a narrow role and a focused set of instructions and tools - a researcher agent that only gathers and synthesises information, a drafter agent that only turns a structured input into a draft, a checker agent that only critiques a draft against the brief and the rules. Above them sits a coordinator (also called an orchestrator or supervisor) whose job is to break the overall goal into pieces, decide which agent gets which piece and in what order, pass the output of one along as the input of the next, and assemble the final result. Crucially, the coordinator is often not another AI at all - for many studio workflows it is a plain, deterministic script, which is more predictable and cheaper than a coordinating agent and is usually the right starting point.

The reason to split roles rather than ask one agent to do everything is that focus improves quality. An agent given one clear job, a tailored instruction and only the tools it needs tends to do that job better than a generalist juggling several roles in a single crowded context. It is the same logic that makes a studio hire specialists rather than expecting one person to be an expert researcher, a fast drafter and a sharp critic simultaneously. The independent checker is the standout benefit: an agent that did not write the draft, and is prompted specifically to find problems with it, catches errors the drafter is blind to - much as a second designer reviewing your drawing sees the mistake you have stopped noticing.

There are other patterns beyond the specialist team - agents that debate a question and converge, a pool of workers running the same task in parallel on different inputs, a hierarchy of coordinators for a large job - but they are variations on the same two ideas: give each agent a focused role, and coordinate them deliberately. And through every pattern runs the same non-negotiable: the multi-agent system is a more elaborate instrument, not a more responsible one. You remain the lead, and the team's output is a draft for you to verify and sign, not an answer to trust because several agents agreed on it.

A team of agents is worth its overhead only when the job genuinely divides into separable, specialisable parts - and a surprising amount of the time, it does not. Reach for multiple agents when four things are true. First, the task is big and mixed - a long job spanning research, synthesis, drafting and checking, where a single agent's context would get crowded and its focus would blur across the roles. Second, the parts are genuinely separable - you can hand the researcher a clean sub-goal and the drafter a clean input, without every agent needing the whole picture at once. Third, an independent check adds real value - the work is error-prone or consequential enough that a dedicated critic, blind to how the draft was made, will catch things the maker misses. Fourth, parallelism pays - several sub-tasks can run at the same time and the wall-clock saving matters.

A good design-world example: producing a set of room data sheets from a schedule. A researcher agent pulls the relevant standards and product data; a drafter agent generates each sheet in the studio's format; a checker agent verifies each sheet against the schedule and flags gaps - all coordinated by a script, all surfaced to you for sign-off. The roles are clean, the check is valuable, and the sheets can be drafted in parallel. This is a job a team does better than one agent grinding through it in a single thread.

But hold the line against the more common temptation: using a team because it sounds sophisticated. For most tasks a single well-instructed agent is simpler, cheaper, faster and easier to trust - and simplicity is a feature, not a limitation, when you are the one accountable for the output. If the job is small, if the parts are not cleanly separable, if one agent already does it well, a multi-agent system just adds cost, latency and failure modes for no gain. The professional instinct is the opposite of the hype: start with one agent, and add a second role only when you can name the specific benefit it buys. As a rule, do not build a team you cannot debug, and do not add an agent whose contribution you cannot articulate in a sentence.

Every agent you add to a system brings a bill, and being honest about it is what separates a useful team from an expensive tangle. The first cost is plain overhead: more agents mean more model calls, more tokens, more money and more latency - a chain of three agents passing work along is slower and dearer than one agent doing the job, and for a small task the overhead can dwarf the work itself. In an Indian small-studio context, where tool budgets are tight and ROI has to be visible, this matters concretely: a five-agent pipeline that costs more than the hour it saves is a net loss, however clever it looks.

The second cost is more insidious: compounding error. When one agent's output becomes another's input, a mistake early in the chain does not stay put - the researcher misreads a clause, the drafter faithfully builds on the misreading, and the checker, if it trusts the draft's framing, may wave it through. Errors propagate and can amplify, and because no single agent saw the whole path, the failure is easy to miss and hard to locate. This is why an independent checker must be genuinely independent - prompted to distrust the draft and go back to sources - rather than a rubber stamp that inherits the same blind spots.

The third cost is loss of transparency. A single agent's reasoning is hard enough to inspect; a system of several agents handing work back and forth is far harder to trace when it goes wrong. You get a final output but a murky account of how the pieces produced it, which makes debugging slow and trust fragile. And there is a subtler failure - emergent behaviour, where the interaction of agents produces something none was individually asked for: two agents ping-ponging without converging, a coordinator looping, costs spiralling. Guard against all of this with the same discipline you would apply to any system you are responsible for: keep it as simple as the job allows, log what each agent did so you can trace the path, cap iterations and spend, make the checker truly independent, and remember that the output of a five-agent system carries exactly as much of your professional responsibility as one you typed yourself.

Building a multi-agent system for real work is an exercise in restraint and clear contracts, not in maximal cleverness. Start by writing down the goal and the roles in plain language before you build anything: what is the whole job, what are the two or three genuinely distinct sub-jobs, and - the test that saves you - could you explain to a colleague in one sentence what each agent contributes and why a single agent would not do. If you cannot, you do not need that agent. Keep the team as small as the job allows; two or three focused agents plus a deterministic coordinator handles most studio workflows, and every additional role must earn its place.

Next, define the contract at each hand-off - the shape of what one agent passes to the next. Vague hand-offs are where multi-agent systems rot; a clean, structured hand-off (a defined list, a filled template, a specific format) keeps each agent's job well-posed and makes errors visible at the seam. Give each agent only the tools and context it needs for its role - the researcher gets search and file-reading, the drafter gets the template and the researcher's findings, the checker gets the draft, the brief and the sources to verify against, and nothing more. Prefer a deterministic coordinator - a script that routes and merges - over a coordinating agent unless the routing genuinely needs judgement, because a predictable coordinator is easier to trust, cheaper and simpler to debug.

Finally, and above all, place yourself as the lead of the team, not a bystander to it. The independent checker agent is a helper, not a substitute for your review - it reduces error, it does not remove your accountability. Put a human checkpoint where the work becomes consequential, always before anything binding leaves the studio, and treat the whole system's output as a draft you verify and sign. Build in limits - a cap on iterations, a cap on spend, logging of each agent's actions so you can trace what happened - so the team cannot run away with your time or money. A well-designed agent team is one you understand end to end, can debug when it fails, and stand behind when it succeeds. If it is none of those things, it is too big; cut it back until it is.