When Agents Talk to Agents: Coordination Is Not Authorization

A marketing agent proposes a promotion. A stock agent reports availability. A finance agent estimates margin. Their conversation produces an attractive recommendation. None of that establishes that the promotion is authorized, the inventory is still available, or the price may be published.

Multi-agent systems can divide useful analytical work. They also create coordination problems that a single assistant does not have. The architecture needs explicit contracts for evidence, shared state, authority, and recovery.

Add a role only when it solves a problem

Separate agents can be useful when tasks require different evidence, tools, or evaluation criteria. An independent review role can help challenge an analysis, while a retrieval role gathers relevant material under its own access boundary.

But several agents reading the same flawed source do not provide independent confirmation. Additional conversations can increase latency, consumption, and opportunities for misunderstanding. Compare the design with a simpler workflow that uses one model and well-defined tools.

The AutoGen research paper demonstrates an architecture for programmed multi-agent conversation. It does not establish that adding agents always improves accuracy, speed, or economics. Those outcomes need testing for the actual task.

An illustrative replenishment proposal

Imagine a distributor preparing a replenishment recommendation for a seasonal product. One component retrieves current stock and open orders. Another prepares a demand analysis. A third reviews the supplier's current lead-time evidence.

Each contribution identifies its source, timestamp, assumptions, and unresolved questions. The system of record retains the actual inventory and purchasing state. The agents do not negotiate a new version of stock availability by agreeing with one another.

The workflow assembles a proposal for an authorized buyer. Approved rules check budget, supplier eligibility, quantities, and approval requirements. If the proposal exceeds the buyer's authority or relies on stale information, the action is rejected or refreshed.

No agent message saying “finance approved” is sufficient unless it corresponds to a genuine, verifiable approval in the control system. A conversational role name is not a financial authority.

Make handoffs explicit

A useful message contract states the task identifier, requested contribution, permitted data scope, relevant record versions, evidence references, result status, and unresolved conditions. Define what the receiver may assume and what it must verify.

Distinguish a proposal from an accepted decision and a completed write. If an agent reports a recommendation as “done,” the receiving system should not interpret that as a purchase order already issued.

Avoid passing large, unfiltered conversations between every participant. Give each role the minimum relevant evidence. This reduces confusion and helps preserve access boundaries, but it does not replace authorization checks at the tools themselves.

Design disagreement as a normal state

The demand analysis may suggest buying more while current cash constraints suggest waiting. That disagreement is not necessarily a system failure. It may be the business decision the workflow exists to reveal.

Preserve the competing evidence and the actual tradeoff. Do not force agents to converge merely to produce a clean answer. Assign the decision to the authorized person or policy and record the result.

Stop circular conversations. Set task limits, clear completion conditions, and an owned escalation when evidence remains insufficient. A team of agents repeatedly asking each other for clarification can consume resources without advancing the work.

Protect writes from stale or duplicate work

Parallel work can produce two proposals for the same record. A retry can repeat an external action after the original response was lost. A delayed result can arrive after a person has already changed the plan.

Use operation identifiers, state checks, and authoritative readback. Idempotent API guidance explains how a service can recognize a repeated request without repeating the effect, within its defined contract. Merely attaching a key does not make every downstream system exactly-once.

The action service must validate the current state and reject conflicting or expired approvals. The models may prepare and request an operation; they should not be the only mechanism deciding whether it is permitted.

Test a deliberately late contribution. If the buyer changes the replenishment plan while the demand agent is still working, the returned analysis should be marked against its original source version rather than applied to the new plan. This makes concurrency concrete: useful work can arrive too late to authorize the action it originally supported.

Evaluate the whole arrangement

Measure accepted outcomes, coordination overhead, contradictory results, repeated work, unresolved tasks, and cost. Test unavailable participants and partial completion, not only an ideal conversation in which every role responds correctly.

A multi-agent enterprise should not be a collection of digital personalities improvising business authority. It should be a coordinated operating system whose participants contribute useful work inside explicit boundaries. The conversation can be flexible. The account of what happened must remain dependable.