Prototype · closed beta
unOpen.AI
In closed beta: Roxy, a private AI assistant with permanent memory running on infrastructure the user owns. Brand, site, product, backend and conversational design.
Technology
Multi-agent systems.
One outcome.
Multi-agent system architecture splits an AI task across several cooperating agents, coordinated by a supervisor or by handoffs. It is the default answer to a hard agent problem and usually the wrong one. This page is for teams deciding whether to split: when multiple agents genuinely help, the patterns that hold in production, and the cheaper fix to try first.
All Technology & Model Stack →Introduction transcript. Qubi: Splitting a hard job between many agents is tempting, but every handoff loses detail. So we try one agent first, with better context and fewer tools. When the work truly splits, a supervisor hands parts to workers running side by side. Retries are counted and capped, results come back, and the supervisor writes one answer.
The unpopular opening
Most problems people reach for multi-agent to solve are single-agent problems with bad context engineering.
The reasoning usually goes: the agent is failing at a complex task, so decompose the task and give each part its own agent. It is intuitive, it maps onto how we organise humans, and it frequently makes things worse — because the original failure was not insufficient specialisation. It was that the agent lacked the right information at the right step, or had twelve tools where three would do, or was being asked to hold too much in one context window.
Splitting into agents does not fix any of that. It adds coordination overhead, multiplies token cost, introduces handoff points where context is silently dropped, and makes debugging dramatically harder — a failure is now somewhere in a graph rather than in a trace you can read top to bottom.
Try first: better retrieval so the agent has what it needs; fewer, better-described tools; explicit intermediate steps in one context; a stronger model for the hard step only. In our experience that resolves the majority of "we need multi-agent" situations, at a fraction of the complexity.
When it genuinely helps
01
Genuinely parallel work
Researching forty accounts, or analysing thirty documents independently. There is no coordination problem because the units do not interact — this is parallelism, and it is the clearest win available.
02
Hard trust boundaries
One agent may read customer PII, another may write to a public channel, and they must never be the same context. Separation here is a security control, not an optimisation, and it is the strongest architectural justification there is.
03
Adversarial review
A generator and a critic with genuinely different instructions catch errors a single pass does not. This works when the critic has a real basis for disagreement — a rubric, a test, a policy — and degrades into theatre when it is the same model asked to "check your work".
04
Context that will not fit
When the work genuinely exceeds a usable context window even after retrieval and compaction. Note that this bar has moved a long way: much of the multi-agent literature predates the context lengths now routinely available.
The two patterns
-
Supervisor.
One agent owns the goal and delegates sub-tasks to workers, each returning a result. Control is centralised, so the trace is readable and the stopping condition is unambiguous. The supervisor's context is the bottleneck — everything flows through it. -
Handoff.
Agents transfer control to one another, each fully owning the interaction while it holds it. This suits routing — triage hands to billing hands to a specialist — and mirrors how support organisations work. The risk is context loss at each hop and, without a supervisor, loops that no one terminates.
In practice supervisor is the safer default. Handoff earns its place where a conversation genuinely changes owner and the previous agent has nothing further to contribute.
SUPERVISOR PATTERN
-
01Request
goal + constraints
-
02Supervisor
plans, delegates
-
03Workers
parallel, isolated
-
04Collect
results + failures
-
05 · Branch / escalationRetry
bounded attempts
-
06Synthesise
supervisor decides
Lower box = bounded retry pathMarker = one request
Where they break
01
Cost multiplication
Five agents on a task is not five times the tokens — coordination messages, repeated context and retries can push it well beyond five times. Model this before building, not after the first invoice.
02
Context loss at handoff
Each transfer summarises, and each summary loses the detail that mattered. Failures appear far downstream of the hop that caused them, which makes them expensive to diagnose.
03
Unbounded loops
Two agents can pass work back and forth indefinitely, each convinced the other should handle it. Hard iteration caps and a terminal fallback are not optional.
Questions
Questions about Multi-Agent Systems.
How do we know if we need multi-agent?
Build the single-agent version first and instrument where it fails. If failures cluster on a specific sub-task that would benefit from different tools or a different model, that is a signal. If they are spread across context problems — the agent not knowing something it should have known — multi-agent will not help, and the fix is retrieval.
Which framework should we use?
For simple supervisor patterns, plain code with a loop and a tool router is often clearer than a framework and much easier to debug. LangGraph is reasonable when the graph is genuinely complex and you want the state machine made explicit. Where reliability and retries across long-running steps matter, a durable execution engine like Temporal contributes more than an agent framework does.
How do we debug a multi-agent system?
Trace everything, with a correlation ID across the whole graph, and store every prompt and response. Without full traces, debugging is guesswork — this is the single largest practical cost of multi-agent architectures and the reason we push back on them by default.
Do agents need shared memory?
Usually less than people expect. Shared mutable state between agents reintroduces every concurrency problem you know from distributed systems, now with a non-deterministic actor. Passing explicit results, and keeping durable state in a normal database with normal transactions, is simpler and more reliable than a shared memory abstraction.
Further reading
When agents cross platform boundaries.
For work owned by another system, our A2A interoperability guide explains task contracts, identity and failure handling. For the execution loop within one application, explore managed agent runtimes and the September 2026 Agents API release.
