Splitting work between agents can make a complex process easier to maintain, but it does not make the process safer automatically. A researcher agent may retrieve information, a planner may propose steps, and an executor may call APIs. If their handoffs lose source evidence or blur permissions, the multi-agent design increases risk instead of reducing it. The engineering question is which responsibilities deserve separate components and what state or authority may cross between them.
Microsoft AI-103 includes orchestrated multi-agent solutions, tool use, conversation memory and safeguards. A suitable case study is a document-intake workflow: one component interprets a form, another checks an enterprise policy, and a third proposes a case update. Each step must be individually testable, with explicit ownership for records and failures.
Decide whether multiple agents are justified
Begin with the simplest workflow that can fulfill the task. A single agent with two read-only tools might already retrieve a policy and summarize a customer request. Adding three agents in that scenario introduces extra model calls, state transfer, latency and possible inconsistencies without improving the result. Separate agents when tasks have different knowledge, tool privileges, evaluation criteria or operating characteristics that benefit from isolation.
For example, a retrieval specialist may be able to search manuals but must never create invoices. A drafting specialist may format a proposed response but cannot issue a refund. A service component with tightly controlled write privileges executes only an approved command. The separation is useful because authority follows the role, not because the system can claim to be “multi-agent.”
Express handoffs as typed, evidence-bearing contracts
A handoff should include the specific task, validated identifiers, source references, uncertainty and permitted next actions. Passing “the first agent said the customer qualifies” as plain text is fragile because the recipient cannot distinguish an authorized policy rule from a guess. Instead, pass the customer ID, policy document version, relevant clause identifier, factual findings and unresolved questions in a structured format that downstream code can validate.
Do not pass full conversation histories by default. They may contain irrelevant personal data, stale instructions and adversarial content. A bounded record of facts and sources is easier to inspect and less expensive to process. When a receiving agent needs additional detail, it should retrieve the approved source through an authorized tool rather than treating a previous agent’s paraphrase as immutable truth.
Separate transient context, durable memory and system state
Transient context helps an agent respond in the current exchange. Durable memory stores approved facts or preferences across requests. System state tracks authoritative business objects such as orders and approvals. These categories should not be stored or trusted in the same way. A user can change a conversation preference, but that does not change the payment system’s current invoice balance.
For memory, define what may be retained, who may access it, when it expires, and how it is corrected. For business state, always consult the source of truth before acting. An agent recalling yesterday’s asset owner must recheck ownership if it intends to change that asset today. When memory conflicts with a fresh API result, the authoritative data should win. This is an application-design decision, not a model-prompt trick.
Control routing to prevent runaway agent loops
A model-driven router can decide whether a question needs retrieval, drafting or action. It should still operate under an explicit task budget: maximum hops, total model calls, tool concurrency, timeouts, and a stopping condition. A poorly defined “review your answer until satisfied” loop can spend resources indefinitely without introducing new evidence.
Track why each handoff occurs. If two agents repeatedly pass the same unresolved question back and forth, terminate with a clear explanation or human escalation. Use a deterministic state machine for workflows with known steps, reserving model judgment for classification, interpretation or bounded planning where it adds value. Complex architecture is justified only when it improves accuracy, controllability or capability.
Design approvals at the boundary of side effects
In a case-processing workflow, an extraction agent can identify a refund amount and a policy agent can evaluate eligibility; neither should finalize a payment. The application should build an approval proposal containing the amount, customer identity, source documents and policy check. A reviewer with actual authority approves that exact proposal. Only then may a transaction tool execute it.
Binding approval to immutable parameters prevents a subtle failure: the agent obtains approval for a small action, then changes the target or amount during continued reasoning. Preserve the approved request and reject any later mismatch. Use idempotent execution and record the final transaction state. A human approval click alone is not sufficient unless the right person reviewed the right operation.
Prepare for partial failures and compensation
Multi-step operations fail partway through. A case record may be created even though a notification call times out. The next run must know whether to retry, query status or undo an incomplete action. Design workflow checkpoints that record which steps committed and which did not. Use idempotency for repeatable writes and an explicit compensation or manual-resolution path for operations that cannot be reversed automatically.
Do not allow an agent to infer successful completion from a tool request that returned an error. If the state is uncertain, verify it at the downstream system. A workflow that sends a notification twice is inconvenient; one that issues a duplicate refund is financially serious. Distinguish retry safety by the consequences of the action, not merely by whether the API supports retries.
A procurement assistant may require three agents: one to extract purchase-order information, one to validate policy and another to prepare a supplier notification. In a single run, extraction succeeds, policy review rejects the order and the notification agent is already waiting. If the system streams tasks directly between agents without a durable decision point, the supplier might receive a message about an order the organization explicitly rejected.
Treat the workflow as a state machine with traceable transitions. Extraction yields a typed evidence package containing document IDs and values; policy review returns an approved, rejected or needs-human-review decision with reasons; notification is eligible only when a committed approval record exists. Agent messages alone do not constitute that record. The dispatcher should validate the schema and policy result before making the next state transition, and each stage should have a clear deadline and retry policy.
Some steps can be retried harmlessly, but others need compensation. Re-running a classifier changes no business state; resending an email cannot reliably be “undone.” For irreversible effects, create a draft first, require approval where consequences warrant it, and use a deduplication key on the commit. If a later stage fails, the recovery action may be to create an incident or cancel an authorized reservation rather than pretending every operation is reversible. Document what compensation means for each external service rather than assuming a generic rollback.
Finally, test the workflow with stale evidence, conflicting approvals and an unavailable subagent. A resilient design routes uncertainty to a bounded human review path and exposes partial completion to operators. The value of multiple agents is in separating genuine responsibilities; extra agents that merely pass paraphrased text between themselves add latency and failure points without improving the business result.
Evaluate the trajectory, not only the final answer
An agent can produce a perfectly worded final message after accessing the wrong document or making an unnecessary external call. Evaluate the sequence of decisions: which role received the task, what evidence was passed, whether tool access stayed within bounds, how many model calls were made, whether approvals occurred, and where the workflow stopped. Final-answer quality alone misses these hazards.
Create test scenarios with conflicting policy versions, missing permissions, stale memory and an injected instruction in a retrieved file. Compare tool and agent traces to expected behavior. Microsoft’s Foundry Agent Service documentation describes supported agent types, runtime and observability, but the application’s own success criteria determine whether a particular orchestration is acceptable.
Keep security boundaries explicit across agent roles
A multi-agent system should not share one broad service credential simply because deployment is easier. Restrict each agent or tool execution identity to what its work requires. If an agent needs to act on behalf of a user, verify the supported delegation pattern and pass authorization context through trusted code. A planner’s instruction cannot elevate a retrieval agent into an administrator.
Tool output remains untrusted even when it comes from another agent. One compromised or confused step should not be able to rewrite the others’ operating rules. Validate handoff schema, source references and allowed operations. Record which component introduced every claim or request so a reviewer can locate the original evidence during an incident.
Practice a three-stage workflow with a deliberate failure
For an AI-103 lab, build an intake agent that extracts a case identifier, a policy agent that retrieves authorized clauses, and a deterministic service component that creates only a draft. Test a valid case, a missing contract, a malicious instruction embedded in a document and a timeout after draft creation. A durable workflow should avoid duplicate drafts, cite the exact policy version and route uncertain outcomes to review.
Then ask whether the separate intake and policy agents genuinely outperform a simpler single-agent workflow. Compare groundedness, latency, cost and failure clarity on the same tests. If the extra agents provide no meaningful benefit, simplify. Knowing when not to orchestrate is part of engineering judgment: the purpose is a maintainable, safe system, not a more elaborate diagram.