Multi-agent architecture: set operational limits before automating

A multi-agent architecture is not a more advanced automation just because it has several roles. It becomes operable when the team can say, for each delegation: which task is entrusted, which data and tools are accessible, which decision remains human, how the workflow stops and who handles a deviation. Before adding agents, set this operational scope.

In short

• Add a specialised agent when it carries a distinct responsibility, context or interface. Do not add roles only to split a prompt.
• Define six limits before automating: task, data, rights, delegation, external effect and stop condition.
• Escalate ambiguous, out-of-scope or impactful cases to a human decision rather than silently widening autonomy.
• Evaluate the whole chain: context hand-offs, tool calls, refusals, traces and recovery after an error.

Multi-agent systems coordinate specialised components. This organisation can clarify some responsibilities, but it adds context hand-offs, routing decisions and interactions that must be made readable. Microsoft presents several collaboration patterns between agents, including sequential chains, dialogues and orchestrators, each with its own coordination trade-offs.[2]

Which problem should a multi-agent architecture really solve?

The right starting point is not "how many agents do we need?". It is a task that cannot be handled reliably by a single workflow with clear responsibilities.

Splitting can help when a step requires:

• a distinct document context;
• a different business tool or authorisation;
• its own verification method;
• a validation decision at a specific moment;
• a structured output that serves as controlled input to another step.

Conversely, creating a research agent, a summary agent and a control agent for a simple task may only multiply transitions without improving the decision. Each transition adds an operational question: which information is passed on, with what status, in which scope and with what possibility of rollback?

NIST's GenAI profile proposes risk management adapted to the context, the organisation's role and the system's impacts. This approach is useful here: the split between agents must be justified by a responsibility and an expected piece of evidence, not by a framework convention.[1]

Which limits should you write down before connecting the agents?

The operational scope is a decision sheet per workflow, then per agent that acts or accesses a resource. It makes explicit what the system may prepare, check, execute or refuse.

Limit	Question to write down	Expected evidence
Task	What concrete result does this agent produce?	Input, output and criterion for when it is not needed
Data	Which sources may it read or pass on?	Document scope and access rule
Rights	Which identity and authorisations does it use?	User context or documented delegation
Delegation	To which agents or tools may it pass a request?	List of destinations and exchange contract
External effect	What can it change, send or trigger?	Scope, validation and rollback capability
Stop	When must it finish, refuse or escalate?	Terminal condition, owner and trace

This table is not decorative documentation. It distinguishes a work proposal from an execution. An agent can prepare a search or a draft without being able to write to a business system. It can request a validation without being able to choose to bypass it.

OWASP's LLM06:2025 entry links the risk of damaging actions to excessive functionality, permissions or autonomy. Among other measures, it recommends reducing extensions, functionality and permissions, and requiring human approval for high-impact actions.[3]

How do you limit delegation between agents?

A delegation must be treated as an interface, not as a free-form message between two roles. The calling agent formulates a request. The called agent receives a limited context, applies its controls, then returns an output with a clear status.

For each link between two agents, define:

1. The reason for the call. Which sub-task justifies this delegation?
2. The data passed on. Which context is needed, and what must stay out of the exchange?
3. The capability requested. Does the called agent read, propose, execute, or can it only classify?
4. The expected answer. Is it a sourced fact, a proposal, a refusal or a request for clarification?
5. The continuation rule. Who decides the next step when the answer is incomplete, contradictory or out of scope?

This discipline prevents the orchestrator from turning an intermediate answer into an executable order without control. It also avoids passing sensitive context to a generalist agent that does not need it to do its task.

OWASP's guide on agentic applications stresses that agents can interact with users, tools and other agents. Controls must therefore cover interfaces and interactions, not just the model in isolation.[4]

For rights propagation, see our article on authorisation error patterns in a multi-agent architecture. This guide addresses another question: how to keep the delegation itself within a known operational scope.

When should you isolate an agent rather than add it to the general pool?

An agent that accesses sensitive data, triggers an impactful operation or uses a particular technical identity should not be available as a generic capability by default. Its access must be tied to a specific workflow, an authorisation rule and a business owner.

Isolation is often preferable when:

• the agent handles a corpus or tool reserved for one business area;
• it performs a write that is hard to undo;
• it requires a distinct validation;
• its behaviour must be evaluated against a specialised rule;
• an error could leave the nominal context without the orchestrator seeing it.

This rule does not mean that an isolated agent is automatically safe. It simply reduces the number of paths through which a sensitive capability can be discovered or called. The team must still check identity, permissions, inputs, outputs and traces at the level of the system that holds the resource.

Our guide on human approvals for an agent connected to business tools helps decide when an action should stop in front of an authorised person rather than continue automatically.

How do you define a useful stop condition?

A multi-agent workflow without a clear stop condition tends to turn uncertainty into new delegations. The agent looks for one more source, rephrases the same request or tries an adjacent tool. This persistence can look useful in a demo, but it makes operations hard to predict.

Define explicit terminal outputs:

Situation	Expected output
Sufficient evidence and result within scope	Return a sourced answer or proposal
Missing or contradictory data	Report the limit and ask for clarification or a review
Insufficient right or unexpected scope	Refuse or escalate without trying to bypass the rule
Impactful external effect	Prepare an approval request with target, scope and consequence
Technical error or unavailable dependency	Stop, log the error and route to the recovery procedure
Planned number of delegations or duration exceeded	End the workflow in a readable state, then have the deviation handled

The stop condition is not a system failure. It is the mechanism that prevents open-ended autonomy from hiding missing information, an absent authorisation or a failing dependency.

How do you evaluate a multi-agent architecture as a chain?

Testing each agent separately is not enough. The operational decision also depends on the hand-offs between them: does the right information reach the right role, with the right status and the right limits?

Prepare scenarios that observe the whole chain:

1. a nominal task with the expected data and rights;
2. an ambiguous request that should trigger a clarification;
3. a contradictory or outdated source;
4. an agent called with incomplete context;
5. an attempt to delegate to an out-of-scope capability;
6. an impactful action that requires human approval;
7. a tool failure, followed by the planned recovery or escalation.

For each scenario, keep the input, the agents or tools called, the controls applied, the output of each step, the final decision and the reason for stopping. AI agent traceability details the events that link a request, a control, an authorisation and a result without copying business data without limit.

What should you decide before automating further?

Before expanding a multi-agent workflow, gather this evidence in a short review:

1. each agent has a responsibility that justifies its existence;
2. the data and tools accessible to each role are known;
3. rights follow the user's context or the authorised delegation;
4. inter-agent exchanges have a defined input, output and status;
5. impactful actions have an approval point and an owner;
6. stop, error and escalation conditions are observable;
7. refusal and recovery scenarios have been tested;
8. a person or team can restrict the workflow if its behaviour leaves the scope.

If any of this evidence is missing, reduce the automation. Keep a single agent, limit the available tools, shorten the chain, make a step read-only or submit an action for approval. A smaller, understandable scope is a better base than a set of agents whose interactions cannot be explained.

Our go/no-go method between an LLM prototype and production helps tie this decision to criteria, tests and owners before opening up to more users.

FAQ

• Do you always need an orchestrator in a multi-agent architecture?

  No. An explicit chain can be simpler when a process is known in advance. An orchestrator becomes useful when the system must choose between distinct responsibilities, while remaining subject to documented routing, rights and stop rules.

• How many agents should you start with?

  There is no universal number. Start with the smallest split that makes responsibilities and controls clearer. Add an agent only if its role, data, rights and output can be usefully distinguished.

• Is a human approval enough to limit a multi-agent workflow?

  No. An approval replaces neither permissions, nor scope limits, nor the controls of downstream systems. It must be tied to a specific action and complement a technical scope that stays limited even after approval.

• What should you trace in a delegation between agents?

  Keep a workflow identifier, the calling and called roles, the type of request, the relevant authorisation context, the control decision, the result and the reason for any stop or escalation. The level of detail must stay proportionate to the data and the applicable rules.

Methodology and sources

• [1] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), July 2024, consulted on 22 September 2026.
• [2] Microsoft Learn, Multi-agent patterns, consulted on 22 September 2026.
• [3] OWASP, LLM06:2025 Excessive Agency, consulted on 22 September 2026.
• [4] OWASP, Securing Agentic Applications Guide 1.0, consulted on 22 September 2026.

This page offers an editorial scoping method for multi-agent systems. It contains no client data, no mission statistics and no promise of security, compliance or results. The autonomy limits and controls required depend on the use case, the tools and the organisation's responsibilities.

---

Do you need to decide which agents, tools and approvals to keep within a workflow's scope before automating? Describe your context to IgnitionAI. A first conversation can help define the responsibilities, delegation limits and operational evidence to gather before the build.