Agentic AI Architecture Patterns

Key takeaways

• Ask “who decides what happens next?”, not “how many agents can we connect?” In a workflow the application controls the route; in an autonomous system a model chooses steps within defined limits.
• Enforce permissions in tools and systems, not in routing or handoffs. Choosing a destination or receiving a conversation is not authorisation.
• Choose the smallest design that passes the test. More agents are an architectural cost to justify, not a maturity target.

A support assistant does not need a committee of agents to check a service status and prepare a ticket. A discovery exercise may need several specialists because the next question depends on what the previous investigation uncovers. The architecture should reflect that difference.

The useful design question is not “How many agents can we connect?” It is “Who decides what happens next?” In a workflow, the application controls the route. In a more autonomous system, a model chooses steps and tools within defined limits. Both approaches have a place. [1, 3]

The eight patterns below are a practical selection, not a universal taxonomy or eight separate Agent Framework features. They overlap and can be combined. The examples are illustrative designs, not claims about deployed customer systems. [1, 2, 3]

Read the control flow before choosing the framework

Diagram key: blue = agent; grey = input or workflow step; amber = decision or validation; green = tool or result; plum = human intervention or escalation. Arrows show information and control flow, not a deployment topology.

01 Single agent with tools

One agent owns the task and chooses which tools to call. Each result informs its next step: investigate further, answer, or stop. The tools execute actions; the model does not bypass their permissions. [1, 3]

In practice An employee reports an unavailable application. The support agent checks service health, searches the runbook and, if needed, prepares a ticket containing the evidence already gathered.

Use it when The task stays within one domain and the toolset is manageable. Do not introduce separate agents merely because the solution uses several APIs.

Design it carefully Keep read and write tools distinct. Enforce permissions in the tools, cap execution time and calls, and return a useful explanation when the budget runs out. [1, 3]

02 Sequential workflow

The application fixes the order of work. AI can interpret an unstructured input, while conventional code checks exact conditions before the next stage runs. Not every box needs to be an agent. [3]

In practice Supplier onboarding starts with document extraction. Code checks mandatory fields and registration rules. Only a validated payload progresses to approval; missing data returns for correction.

Use it when The steps and their dependencies are known in advance. If a conventional workflow can handle the process, retain it and add AI only where interpretation helps.

Design it carefully Define a schema for every stage and retain the source evidence. Stop invalid outputs at the gate rather than asking later stages to repair them silently. [1, 3]

03 Routing to specialists

A classifier selects a destination. It may use explicit rules, a conventional classifier or a model. The destination can be an agent, a workflow or a service; routing does not require a multi-agent conversation. [3]

In practice An employee assistant sends payslip questions to HR, device incidents to IT and supplier invoice queries to finance. An unclear request triggers clarification rather than a confident guess.

Use it when Requests fall into distinct categories with different knowledge, tools or service owners.

Design it carefully Test ambiguous and out-of-scope requests as well as obvious categories. The receiving capability must enforce authorisation independently: choosing finance is not permission to read finance data. [1, 3]

04 Concurrent processing

Independent reviews run at the same time. A collector combines their outputs and identifies contradictions or missing results. The reviewers do not need to discuss their findings with one another. [1, 3]

In practice A proposal receives technical, commercial and delivery reviews in parallel. Each returns evidence, assumptions and risks using the same output structure. The final assessment preserves material disagreements.

Use it when The subtasks can genuinely proceed independently and the benefit in elapsed time or coverage justifies the extra consumption.

Design it carefully Define timeouts, partial-result handling and conflict resolution before fan-out. Avoid parallel writes to shared records unless the application handles concurrency safely. [1]

05 Orchestrator-worker coordination

A lead agent decides what work is needed, assigns scoped tasks and revises the plan as evidence arrives. Unlike a fixed parallel review, the task breakdown depends on the request and intermediate findings. [3, 4]

In practice An architecture discovery agent commissions source-system, security and platform assessments. If the evidence exposes an undocumented dependency, it adds a focused investigation rather than repeating the whole exercise.

Use it when The goal is clear but the required subtasks cannot be fully specified upfront.

Design it carefully Give each worker a question, permitted sources, output format and budget. Persist the plan and progress outside the conversation. Set explicit stop conditions for stalled or repeated investigation. [1, 4]

06 Handoff between agents

The active owner changes during execution. The receiving specialist gets enough context to continue, rather than merely returning a subtask result to a lead agent. Only one agent owns the conversation at a time in this pattern. [1]

In practice A service agent investigates an order enquiry. When the customer asks for a return, it transfers the relevant order details, checks already completed and outstanding actions to the returns specialist.

Use it when The right owner becomes clear during the conversation. If the destination is obvious from the initial request, a simpler router may be enough.

Design it carefully Record the transfer of ownership, minimise shared context and limit repeat handoffs. Permissions must be evaluated for the receiving agent, not inherited merely because another agent transferred the conversation. [1]

07 Evaluator-optimiser

A generator creates an output; an evaluator checks it against explicit criteria and returns actionable feedback. The loop ends on acceptance, a revision limit or escalation. It is useful only when feedback can measurably improve the result. [1, 3]

In practice An agent drafts a source-to-target mapping. Automated checks verify field coverage and types; a model reviewer examines ambiguous transformation descriptions. Failed checks return specific corrections.

Use it when There is a defensible quality rubric, and defects can be identified and corrected before release.

Design it carefully Use code for exact checks and calibrate model judgements against expert review. A second agent agreeing with the first is not proof of correctness. Retain unresolved issues when the revision budget ends. [3, 5]

08 Group collaboration

Specialists contribute to a shared discussion and can challenge one another. A coordinator controls participation and stopping. That interaction, not simply having several reviewers, distinguishes this pattern from concurrent processing. [1]

In practice Security, data and operations agents examine a Fabric design. Security challenges the proposed network boundary; operations raises support implications; data proposes an alternative. The architect receives the trade-offs and evidence, including unresolved objections.

Use it when Cross-examination can change the recommendation. Use independent reviews instead when discussion adds little.

Design it carefully Keep the group small, limit rounds and name the human decision owner. Prefer read-only tools during deliberation; agreement must not automatically trigger a production change. [1]

Oversight and production controls

Human approval belongs before execution

An agent may investigate a production incident and propose a configuration change without having authority to apply it. Pause before the write operation and show the reviewer the exact target, proposed change, supporting evidence and expected impact. Approval should cover that action, not a vague plan. Agent Framework supports approval-required tools and requests for additional information. [2]

Design the failure path as carefully as the success path

For each pattern, specify what happens after a timeout, unavailable tool, invalid output or exhausted budget. Persist enough state to resume safely, and make retries safe for actions that modify records. A repeated request must not create a second ticket or apply the same change twice. [1, 4]

Measure the completed outcome

A fluent response is not a successful transaction. Check whether the intended record was created, the right evidence was retrieved and unauthorised actions were blocked. Track completion, tool errors, latency and cost, using deterministic checks where possible and calibrated model or human review where judgement is needed. [5]

Choose the smallest design that passes the test

Start with a direct model call or a single agent where possible. Add coordination only when evaluation exposes a specific limitation: tool overload, missing expertise, independent work or a genuine need for discussion. More agents are an architectural cost to justify, not a maturity target. [1, 3]

Sources reviewed 20 October 2026. Diagrams and scenarios are original illustrations informed by these sources. Pattern names vary between publications.