Multi-agent systems can improve separation of concerns when a request requires several specialized activities. They can also multiply model calls, introduce contradictory decisions, and make failures harder to reconstruct. AI-103 includes orchestrated multi-agent solutions, but the exam does not require a developer to prefer them over an ordinary application pipeline. Begin with a single-agent baseline and name the defect that delegation is intended to solve: slow sequential research, inconsistent source checking, overloaded tool permissions, or an unmanageable context window.<\/p>\n
Use an internal procurement scenario. An employee asks whether a requested device complies with security policy, whether the supplier is approved, and whether the purchase fits the departmental budget. These are different evidence systems with different access constraints. A coordinator might ask a policy researcher for the security requirement, an inventory specialist for device facts, and a financial validator for current limits. A final component then composes a supported response, but only a trusted ordering service may create a purchase request.<\/p>\n
This makes a stronger applied test than a generic conversation among assistants. The organization can measure whether parallel research reduces latency, whether restricted budget data is exposed, whether conflicting results are disclosed, and whether the final proposal remains idempotent. The bounded agent<\/a> architecture establishes tool permissions before delegation. Without those contracts, adding more agents just spreads the same security failure across multiple components.<\/p>\n Give each specialist a narrowly scoped input and output contract. A policy researcher accepts a request ID, policy topic, and permitted document scope; it returns source IDs, applicable rule text, effective date, confidence limits, and retrieval errors. An inventory component accepts a product identifier and returns a validated catalog record. A finance component receives the minimum needed budget context and returns a recommendation, not a transfer or payment instruction.<\/p>\n Schemas must distinguish a definitive value from an assumption. A budget tool returning “unknown” because a backend timed out should not be translated into “no funding exists.” Use explicit statuses such as completed, missing evidence, rejected by authorization, temporarily unavailable, and human review required. A coordinator should never fabricate missing fields to satisfy a schema when a specialist failed. Treat all specialist responses as less trusted than the system’s authorization rules.<\/p>\n Version each contract independently of the prompt. When a downstream service changes an enum or removes a field, a model can produce plausible text that silently fails integration. Use schema validation and contract tests to catch compatibility breaks. An agent handoff should carry a correlation ID and stable task ID so the parent process can reconcile late or duplicated responses rather than relying on a conversation transcript.<\/p>\n Parallel execution works when branches are independent. The security researcher and catalog researcher can proceed together if both receive only authorized information. The final procurement eligibility decision cannot run correctly until the relevant policy and product details are available. Draw a dependency graph rather than placing agents in a single chain because a diagram looks orderly.<\/p>\n Some tasks should be sequential. A user may first need to authenticate and select a project before a specialist can access scoped data. A planning component can propose branches, but its output must pass an allowlist of permitted tasks and destinations. If the planner requests a financial dataset for a caller who lacks permission, the orchestrator should reject the branch before launch. The model does not get to redefine the graph’s security assumptions.<\/p>\n Routing is appropriate when the user’s request belongs to one specialist. A general question about device specifications should not invoke a costly finance analysis. Use simple deterministic rules for known cases where possible; reserve model-based routing for ambiguous requests and evaluate misroutes as a distinct quality issue. Compare latency, token consumption, correct specialist selection, and recovery on the same test corpus.<\/p>\nDefine specialist roles and typed contracts<\/h2>\n
Choose fan-out, sequence, or routing based on dependencies<\/h2>\n