Four engineering patterns that separate multi-agent from prompt chains
An AWS design exercise for agent workflows: bounded MCP tools, durable events, shared fallback validation and cost-aware routing, with a failure rehearsal and human approval before production changes.
A diagram with five agent names does not tell me whether a system has five independently useful responsibilities. Before adding another agent, I want to know who owns the state, which steps can proceed independently, and what happens when the same request arrives twice.
Sergio Villani's September 2 review of the Google for Startups AI Agents Challenge provides a useful starting point: bounded tool interfaces, event-driven concurrency, shared validation for fallback models, and inexpensive routing before expensive inference. Read the original review .
This article translates those ideas into an AWS design exercise. The architecture below is a proposal to evaluate, not a benchmark or a report of a deployed customer system. The central question is operational: can we explain, replay and safely stop the work when a model, tool or consumer fails?
A concrete workload: propose a remediation change
Consider an assistant that receives an infrastructure finding and prepares a proposed change for review. It retrieves resource metadata, assesses policy constraints and builds an explanation. It must not grant itself permissions or apply production changes.
The useful output is a review package: finding identifiers, supporting evidence, an IaC diff, validation results, affected resources, estimated operational impact and a rollback proposal. A polished paragraph without that evidence is incomplete work.
I would start with one coordinator and ordinary functions. A second agent earns its place only when it needs a distinct tool boundary, independent execution, a separate evaluation strategy or its own lifecycle. Splitting one reasoning task into several prompts can still be useful; it does not automatically justify distributed infrastructure.
Pattern 1: make tools bounded capabilities
Instead of exposing a generic database connection, define a narrow operation such as get_resource_configuration(resource_id). Its response contract should specify permitted fields, maximum records, provenance, freshness and a clear not-found result. Pagination needs an explicit bound rather than an invitation to retrieve the entire estate.
These limits belong in executable code. Asking the model to avoid sensitive fields does not make those fields inaccessible. Authorize the operation using the caller and tenant context, validate the resource identifier, and return only what the current decision needs. Tool output remains untrusted input for the reasoning layer.
For an external protected HTTP MCP server, the referenced MCP authorization specification describes audience-bound tokens and prohibits forwarding the received token unchanged to another resource. The downstream service needs its own appropriate credentials. A signed token for the wrong recipient is not authorization to use this tool. MCP authorization .
Amazon Bedrock AgentCore Gateway can expose Lambda functions and APIs as MCP-compatible tools, with inbound and outbound authentication and tool discovery. That can reduce integration work; it does not decide which business action a caller is entitled to perform. Keep that decision in the tool boundary and test it. AgentCore Gateway .
My acceptance tests would include an unauthorized tenant, an excessive result request, an expired token and an instruction embedded in a tool result. The expected behavior is bounded rejection or a safe response, never broader access to finish the task.
Pattern 2: distribute work only where independence exists
In the remediation example, metadata collection and a policy lookup may run concurrently. A change proposal that depends on both must wait. An event bus does not remove that dependency; it makes us responsible for representing it explicitly.
I would publish a versioned work item with an event ID, workflow ID, resource reference, deadline and schema version. Avoid putting secrets or large evidence payloads in the event. Store evidence separately and pass an access-controlled reference. Consumers report completion against the same workflow so the coordinator can distinguish complete, incomplete, expired and failed work.
EventBridge can route events to consumers, but event delivery and successful business processing are different outcomes. Its documented default for retriable target-delivery failures is up to 185 attempts over 24 hours. Configure a dead-letter queue for undelivered events; without one, exhausted delivery attempts can end in a dropped event. These settings do not validate an agent's answer. EventBridge retry policy .
With SQS Standard, design for a message being delivered again. An idempotency record should represent the business operation, not merely the current network attempt. A retry of the same proposed notification must not send a second notification. SQS at-least-once delivery .
For this design, I would reserve an idempotency key before creating a side effect and record its result. The record needs expiry and recovery semantics: a worker can crash after reserving the key. Blindly skipping every existing key can turn duplicate protection into silent work loss. Replaying a dead-letter message should therefore be a reviewed recovery action with the original operation identity preserved.
Architecture: separate evidence from authority
The diagram groups the four patterns around one control boundary. Parallel workers can gather evidence, but only a validated proposal proceeds to review. The deployment path consumes an approved change through its existing controls.
This is deliberately a logical view. It is not a promise that a single Gateway configuration implements routing, authorization, validation and deployment. Each box has an owner and an independently testable contract.
Pattern 3: give every model the same exit check
A fallback protects availability only if its answer is still fit for the task. Keep a shared validation stage after both the primary and fallback paths. If neither passes, return an incomplete result or escalate; a successful HTTP response is not a reason to approve an invalid change.
For a remediation proposal, I would check the output schema, the allowed resource scope, the link between findings and proposed changes, and whether the requested evidence actually exists. Then run the applicable IaC checks in the controlled build environment. Do not treat generated code or a model's assertion that a plan is safe as the result of executing those checks.
Both models should receive only the tool permissions required for the task. The fallback is not a reason to add a general-purpose shell, widen an IAM policy or skip human review. Tests should include a plausible proposal with the wrong resource ID, a valid-looking answer with missing evidence and a timeout after a partial tool action.
Bedrock cross-Region inference profiles can route requests among Regions in a geography or globally, depending on the profile. They do not replace application deadlines, bounded retries or evaluation. Before adopting one, review the destination Regions and residency requirements. CloudTrail's inferenceRegion information helps identify where processing occurred. Cross-Region inference .
I would record the model or profile used, validation outcome, attempt count and end-to-end deadline. A fallback-rate alarm is useful only when paired with a failure policy: who is paged, what work pauses, and whether affected proposals need re-evaluation. Select the threshold from observed traffic rather than copying a percentage from another workload.
Pattern 4: route cheaply, but measure incorrect shortcuts
Some requests do not need inference. A request for the status of an existing review can be handled by an authenticated state lookup. A narrowly specified help action can return a maintained answer. Start with explicit intent rules and a test set rather than a growing collection of permissive regexes.
The cost equation I would track is total workflow cost divided by successfully validated outcomes. Include tool calls, retries, storage, orchestration and human review time. Reducing model tokens while doubling rework is not a useful optimization.
Separate routing confidence from authorization. Recognizing the phrase “approve this change” does not grant permission to approve it. Authorization is checked even for a deterministic route. For an ambiguous request, ask a clarifying question or escalate to the reasoning path.
Bedrock intelligent prompt routing offers a managed way to select between two models in the same family using predicted response quality. The current documentation notes English optimization and that application-specific performance data does not adapt the router. Evaluate Portuguese and domain-specific requests explicitly before choosing it. This is a model-selection layer, not a replacement for the deterministic actions above. Intelligent prompt routing .
The failure rehearsal I would run before launch
Take one synthetic finding and walk it through five deliberate failures:
- Deliver the same work item twice. Verify that there is one business outcome and a traceable duplicate decision.
- Stop a worker after it reserves its idempotency key. Confirm that recovery is possible without creating the side effect twice.
- Make the primary model unavailable. Verify that the fallback reaches the identical validation stage and obeys the same deadline.
- Return a tool result containing a request to change permissions. Confirm that the result cannot change the worker's authority.
- Produce an invalid proposal while the model request itself succeeds. Confirm that no deployment is triggered and that the reviewer sees why the proposal failed.
Save the test inputs, expected behavior and resulting traces. A demo that only exercises the happy path cannot establish whether this design is recoverable.
Well-Architected review: six questions, six owners
- Operational excellence: can an operator find the workflow, inspect its current state and replay failed work using a documented procedure?
- Security: can each tool prove that the current caller may perform this specific operation on this resource?
- Reliability: can the workflow survive duplicate messages, partial completion and unavailable models without silently approving bad work?
- Performance efficiency: which steps genuinely benefit from concurrency, and where do dependencies or shared quotas dominate latency?
- Cost optimization: what is the cost per validated outcome, and how much is spent on retries and rejected proposals?
- Sustainability: can we avoid unnecessary inference, repeated retrieval and unbounded retention while keeping the evidence required for review?
These are design questions to assign to the team, not a claim that the architecture has passed an AWS review. A checklist becomes useful when a failed answer has an owner and a concrete next action.
When I would keep the simpler design
If the workflow has two short dependent steps, one model and no need for independent recovery, a single process may be the better choice. Persist the work where necessary, bound its execution and test it before introducing a bus and several independently deployed workers.
The strongest reason to split a component is an operational boundary that matters: separate permissions, a distinct failure domain, independent scaling or a different lifecycle. “We want more agents” is not such a boundary.
My starting sequence would be: define the useful outcome, write the shared validator, narrow the tools, measure the baseline, then add concurrency and routing only where the evidence justifies them. That sequence leaves us with something inspectable even if the final design still has one agent.
Practical checklist
- Define the proposal and its required evidence before selecting models.
- Version event and tool contracts; keep sensitive payloads out of routine logs.
- Set a workflow deadline, attempt budget and clear incomplete state.
- Test tenant boundaries and token audience validation.
- Make side effects idempotent and document interrupted-work recovery.
- Run both model paths through one tested validation stage.
- Preserve human approval for identity changes and production deployment.
- Evaluate routing quality in the languages the application actually serves.
- Track validated outcomes and rework, not just token savings.
- Rehearse failure and rollback before exposing the workflow to real traffic.
Which of these boundaries is hardest in your own agent workflow: tool permissions, duplicate work, fallback validation or routing quality? A concrete failure case would make a useful next article.
References and original version
- Google Developers Blog: four engineering patterns
- MCP authorization specification, version 2025-06-18
- Amazon Bedrock AgentCore Gateway
- EventBridge delivery retries
- SQS at-least-once delivery
- Bedrock cross-Region inference
- Bedrock intelligent prompt routing
Adapted and updated for AWS Builder Center from my original English article , with a Portuguese version and interactive diagrams on the site. I am Fernando Azevedo, AWS Community Builder, writing about architecture, AWS and applied AI.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article