Multi‑agent organisations: when one agent is not enough

If you search for “multi‑agent systems”, you get papers, frameworks and primers. Little recipe for coordinating different agents in production. Even less traceable proof on how to stop them stepping on each other, burning tokens, or losing the goal.

That gap shows when a single agent starts to fail. At first it replies. Then it bogs down on long tasks, repeats work, and mixes styles. It does not prioritise. It does not know when to ask for help or when to stop. It loops.

That is where I use multi‑agent organisations. Not to “play” at roles. To assign responsibilities, contracts and limits. Coordination matters more than model size.

What a practical multi‑agent organisation is

I mean several specialised agents working to a shared goal. Each has a clear scope, well‑defined inputs and validated outputs. This is not window dressing with titles. It is designing interfaces between agents: what they receive, what they produce, and when they hand over.

The heart is orchestration. An agent should not “know everything”. It should know when to decide and when to pass the baton. A planner defines the plan. An executor runs tools. A critic audits results. An integrator delivers a unified output. Names do not matter. Boundaries do.

Stopping rules matter too. Each agent has a budget of steps and tokens. If it cannot reach an acceptable result, it returns a structured failure. Another agent decides whether to retry, simplify, or escalate.

When one agent is not enough

I see it in four situations.

Long haul. Work that spans days, has many dependencies and interim deliverables. A single agent forgets useful context, mixes versions, and fails to consolidate.

Diverse tools. Integrations with several APIs, long documents and noisy data. One agent tries to touch everything and ends up doing everything and nothing well.

Control and traceability. You need to explain why it chose A and not B. In a single flow, the decision blurs. With split roles, each step leaves an auditable trail.

Risk and compliance. You must filter, anonymise and validate. Separating the one who searches from the one who publishes reduces error surface and data leakage.

In one scenario, a team that spends twenty hours per month on manual reviews can cut that effort if an automated critic flags inconsistencies and drafts verification summaries. No magic. Just structure.

Orchestration: contracts, memory and quality control

I start with contracts. Each agent speaks in a format the next one understands. I do not improvise fields. I define what counts as a “fact”, an “assumption”, a “citation” and a “requirement”. When the executor cannot verify, it marks it. The critic does not invent. It points out gaps and asks for data.

Memory sits in three layers. A brief, ephemeral layer for the current turn. A working layer for the case thread. And a documentary layer for what deserves to persist. A custodian agent decides what persists. Not whoever happens to pass by.

Quality control is not a final pass. It is a function with the authority to block deliveries. It evaluates against formal criteria, not “I like it”. If evidence is missing, it sends the package back to the searcher. If there is waffle, it asks for synthesis.

Cost, latency and budget

More agents do not mean more cost by default. They mean visible cost. When you split tasks, you see where time and tokens burn. That lets you tune precisely.

In one scenario, moving from one agent to three raises end‑to‑end latency two or three times if you do not parallelise. When you parallelise what does not depend on other steps, you recover part of the time. The flow sets the balance: clarity first, then speed.

Set budgets per agent and per case. Limit steps, limit calls, and limit tokens. If the plan exceeds budget, the planner trims scope or proposes phases. I prefer an explicit “I cannot meet this budget” over an opaque “I tried”.

Start small and grow with care

I start with a narrow vertical and an operational success metric. I do not promise to “fix the whole process”. I promise to move one measurable needle. With that, I design two or three roles we truly need and a test set that covers the critical cases.

If the function is commercial, I split research, drafting and validation. Here a model of AI agents for selling fits. It isolates prospecting from negotiation and from follow‑up. Each step needs different data and criteria. Orchestration stops one agent shifting voice and goals without warning.

When the basic loop performs, I add safe parallelism. I research several sources at once, but I integrate under one criterion. Conflicts are not hidden. They are raised and resolved with clear rules.

Signals the design is on track

Agent‑to‑agent talk gets shorter and more informative. There are fewer empty spins. Outputs hold style and structure. If I ask to redo a part, the system does not break what was already right.

Another sign: the decision log is readable. I can follow the thread from the goal to each piece of evidence. If another operator takes over, they grasp what is missing and why, fast.

It also shows in failures. When something falls over, it falls with an explanation. I do not get an “unknown error”. The system states what it tried, where it got stuck, and what it proposes next.

Risks and mitigation

Agents can influence each other badly. “Prompt infection” is not just on the web. One agent could pass a misleading instruction to another. I cut that with message sanitisation and validators that ignore out‑of‑protocol orders.

Another risk is echo. If all agents use the same source, they reinforce a wrong assumption. So I mark source diversity and ask for explicit contradictions. The integrator arbitrates and documents the criterion.

There is also tool abuse. An executor with broad permissions can expose credentials or over‑query. I limit scopes, sign each action, and log traces. If there is doubt, I can reproduce the step.

Lastly, misalignment. If the goal changes and no one updates the plan, agents follow an old north. I keep a living, versioned goal artefact. The planner checks it before each cycle.

Why it is worth it

A single agent is fine for short, low‑variance tasks. When reality gets complex, multi‑agent systems bring order, expose trade‑offs, and sustain quality. This is not a fad. It is process engineering applied to generative models.

The key is not the number of agents. It is their coordination. Clear roles, simple contracts, memory with judgement, and evaluations that bite. With that, scaling stops being improvisation and becomes design.

I post working automations on @WhatsMarketing_es.

If you want me to look at your case, get in touch. I work from Buenos Aires, originally from Málaga, with clients in Mexico City, Argentina, the rest of Latin America and Spain.