Connecting Multiple AI Agents Inside a Business Application

One agent reads a customer request, another checks internal records, and a third drafts a response. The demonstration looks collaborative, but the system still needs an answer to basic questions: which result is authoritative, who may request an external action, and what happens if one agent works from an older version of the case?

Connecting multiple agents is an orchestration problem inside a business application. The potential benefit is specialised work with clearer context or parallel investigation. The cost is additional communication, coordination, evaluation, and recovery. More agents do not automatically produce better decisions.

This article uses an illustrative service-proposal workflow with evidence gathering, eligibility checking, and response preparation. It explains when separation can help and how to keep shared state and execution authority under application control.

Confirm that multiple agents solve a real problem

Begin with a simpler design: a fixed workflow or one agent with a small tool set. Measure where it struggles. The issue may be unclear task instructions, poor retrieval, or missing validation rather than a need for more agents.

Separate work when the roles have meaningfully different evidence, tools, or evaluation criteria. An evidence collector and a proposal writer may benefit from different inputs; two agents given the same broad task may simply repeat one another's mistakes.

Consider whether ordinary functions or services would provide the same separation more predictably. A deterministic eligibility check does not need an agent persona to enforce a known rule.

The Anthropic guide to effective agents discusses workflows and adaptive agents as different designs. Use that distinction to choose the least complex arrangement that meets the task rather than treating agent count as a capability measure.

Define role contracts around outputs

Give each role a specific input, permitted tools, expected output, and stopping condition. The evidence role might return source-linked facts and unresolved gaps; the drafting role might return a proposal using only those facts.

Avoid vague roles such as expert or supervisor without an operational contract. A title does not establish authority or tell the runtime how to validate the result.

Keep outputs structured enough for the next stage to inspect. Include task identity, source versions, findings, and uncertainty rather than passing an unbounded conversation transcript between roles.

Specify what a role must not decide. A drafting agent should not approve its own external message, and an evidence agent should not change the account record merely because it found a discrepancy.

Keep the application as the coordinator

The application should own task state, permitted transitions, budgets, and execution. Agents can propose work or choose bounded investigative steps, but they should not privately redefine the process through messages to one another.

Use a coordinator that validates outputs and determines the next permitted stage. It may include model-based interpretation where justified, but its access and state rules should remain enforceable outside generated text.

Record why a task moves forward, waits, or stops. A missing source, denied permission, and exhausted budget require different responses. The coordinator should preserve these distinctions.

Do not allow a peer agent's request to create new authority. A message asking another agent to send data or invoke a broader tool is still untrusted task input unless the application validates it.

Store shared case state durably

Maintain a case record with the business object, initiating actor, source context, current version, proposals, decisions, and confirmed operations. This gives every role a stable reference independent of its local conversation.

Version the evidence snapshot or source references used by each stage. If the account changes while agents work, the coordinator should identify stale results rather than combine them as though they describe one moment.

Keep shared facts separate from suggestions. A model's interpretation should not silently become an authoritative field that other agents then cite as source truth.

Persist important state before handing off work. A process restart should not require agents to reconstruct approvals or completed actions from memory.

Choose sequential or parallel work deliberately

Parallel investigation can help when subtasks are independent, such as retrieving separate permitted source sets. It can also increase cost and create conflicting snapshots if the subtasks depend on one another.

Keep dependent steps sequential. A proposal writer should not finalise a response before the required evidence is available if that would encourage assumptions or repeated regeneration.

Define how partial results are handled. The coordinator may wait for all required sources, proceed with a clearly limited draft, or stop for clarification. The choice should follow the task contract.

Measure whether parallelism improves the end-to-end outcome. Faster individual responses do not necessarily reduce review or completion time when the merge step becomes more complicated.

Merge evidence without erasing disagreement

Two roles may return conflicting findings because they used different sources or interpretations. Preserve the source references and make the conflict visible to the coordinator or reviewer.

Use authoritative-source rules where the business has them. A current order record may take precedence over an older note, but the integration should not invent precedence merely to produce a complete answer.

Do not resolve disagreement by counting how many agents repeat a claim. Similar models with similar inputs can make correlated errors. Agreement is not independent verification.

Route unresolved questions to a person or a defined additional lookup. The useful output may be a concise conflict report rather than a single confident conclusion.

Keep permissions narrow for every role

Assign tools and data access according to the role's actual need. An evidence collector may need read access, while a writer needs only the approved evidence package. Neither automatically needs transactional authority.

Preserve the initiating actor and tenant context across handoffs. A role running under a broad service identity should not expose information the user is not authorised to receive.

The OWASP AI agent security guidance covers risks from untrusted instructions, tool use, and excessive access. Apply those controls at every handoff, including messages produced by another agent.

Keep credentials in the runtime or adapters, not in role prompts or shared messages. The application should execute permitted requests without revealing reusable secrets to the models.

Treat agent messages as proposals, not commands

A message from one agent may contain incorrect facts, malformed data, or instructions outside the recipient's role. Validate it against the handoff schema and current task state.

Distinguish supplied evidence from requested action. A source excerpt can inform a decision without authorising the next tool call. The receiving role should not inherit broader authority from the sender's wording.

Use bounded message sizes and relevant context. Passing every previous transcript can increase cost, expose unnecessary information, and make it harder to identify the actual task.

Record the validated handoff and configuration versions. This allows the team to investigate whether a failure originated in source gathering, interpretation, merge logic, or execution.

Use reviewers to check evidence, not to create an illusion of certainty

A separate review agent can identify possible omissions or inconsistencies, but its approval is not equivalent to verified correctness. It may share the same assumptions and weaknesses as the producing agent.

Give the reviewer explicit criteria and access to the underlying evidence where permitted. Asking whether the answer looks good invites a superficial judgement rather than a useful check.

Keep deterministic validations outside the review model. Required fields, allowed identifiers, permissions, and business constraints should be enforced by application code.

Evaluate whether the review stage catches meaningful errors at an acceptable cost. If it mostly rewrites phrasing or agrees with the draft, a simpler check or better source presentation may be more useful.

Centralise consequential execution

Use one controlled execution boundary for writes and external communication. Several agents should not independently update the same record or send competing messages because each believes its subtask is complete.

Require a validated proposal and any necessary human approval before execution. Bind that decision to exact values, destination, and version.

Recheck current business state and authority at the boundary. A proposal assembled from several stages may be older than it appears by the time it reaches execution.

Record the destination's confirmed result. Agents can explain the outcome afterward, but their own statements should not be the source of truth about whether the action happened.

Prevent duplicate work and uncertain writes

Assign stable task and operation identities across retries and handoffs. A restarted role should not create a new business operation merely because its local run identifier changed.

Use concurrency-safe claims or equivalent coordination for work items. Two workers receiving the same stage should not both execute a consequential action.

For remote writes, use supported idempotency and reconciliation. If a response is lost, determine the outcome before repeating the action. The coordinator should preserve uncertainty rather than let another agent guess.

Track partial completion. Evidence collection may be complete while drafting failed, or a record update may succeed while notification remains pending. Recovery should target the unfinished stage without repeating confirmed effects.

Put budgets and stop conditions around the whole task

Per-agent limits are useful, but the workflow also needs an overall budget for calls, time, and cost. Otherwise, several bounded agents can still create an excessive combined workload.

Detect repeated delegation or review loops that add no new evidence. The coordinator should stop and report the unresolved issue rather than let agents continue debating indefinitely.

Distinguish waiting for a human or external event from active processing. Persist the waiting state and resume when appropriate instead of keeping unnecessary model work running.

Expose budget exhaustion as an operational result with useful partial evidence. A task can stop responsibly without pretending it reached the requested conclusion.

Evaluate the system and its components

Test each role against its contract, then test complete cases through the coordinator. Include missing sources, conflicting evidence, stale state, denied actions, repeated messages, and a failed stage.

Measure accepted outcomes, unsupported claims, tool use, review effort, latency, and cost. A specialised role can improve its local score while making the overall workflow less useful.

Compare with the simpler baseline. The multi-agent design should justify its coordination overhead through measured benefits for the actual task.

Use traces to identify where an error was introduced and propagated. A final wrong answer alone does not reveal whether the source was bad, a role misread it, or the coordinator merged incompatible results.

Maintain the workflow as one product

Version role prompts, tool schemas, handoff contracts, and coordinator rules together in a reviewable release process. A small change to one role can alter assumptions made by the next.

Assign ownership for the complete business outcome. Individual teams can maintain components, but someone must decide whether the combined workflow remains useful and safe to operate.

Keep a pause mechanism and manual fallback. Operators should be able to disable a stage or the whole task without losing recorded work or repeating completed actions later.

Review access whenever a new role or tool is added. Shared infrastructure should not result in every agent receiving the union of all permissions.

Make a case trace readable across agent boundaries

A multi-agent application needs a record of the handoffs that actually occurred. For the service-proposal workflow, capture which role received the case, the input version, the evidence references and the structured output. Link these records to the coordinator's state transitions. This gives support staff a way to locate the first incorrect assumption without reconstructing an entire conversation manually.

Record outcomes rather than treating hidden model reasoning as an audit mechanism. A concise explanation tied to source facts is more useful for review than a long speculative narrative. The system should be able to show that a pricing proposal used a particular rate schedule and that execution used the approved proposal version, regardless of how many intermediate model calls occurred.

When one role fails, distinguish its failure from the coordinator's response. An unavailable research source might correctly lead to a request for clarification. That is different from the coordinator ignoring the missing evidence and publishing a confident proposal. Evaluating the handoff makes those two behaviours visible and helps teams improve the relevant component.

Give business reviewers an appropriate view of this trace. They may need the sources, disagreements and final proposed commitments, while engineers need request timing and error details. Both views should refer to the same durable case. Avoid scattering essential decisions across separate agent dashboards that nobody can reconcile during an incident.

Use a small set of representative case traces during release review. Compare the full path after a role prompt, tool schema or routing rule changes. A component can produce better-looking text while causing additional loops or bypassing a useful check elsewhere. Reviewing the coordinated outcome protects the application from that local optimisation.

Add another agent only when the boundary earns its cost

Start with a clear task and a simple implementation. Introduce a specialised role when its distinct evidence, tools, or evaluation needs provide a measurable benefit that ordinary modular code does not already supply.

Keep shared state, authorisation, and execution under application control. Make disagreements visible, preserve operation identities, and test recovery across the handoffs.

A useful multi-agent system is a coordinated workflow with explicit contracts and confirmed outcomes. Its strength comes from well-chosen boundaries and evidence of better work, not from the number of model conversations happening behind the interface.

---