Agentic Architecture Patterns without Unnecessary Complexity

The Agentic Leap — Part 3: Agentic Architecture Patterns

Architecture diagrams can make agent systems look more mysterious than they are. Let us slow the discussion down. An agent architecture is simply a set of responsibilities, boundaries and hand-offs. Your experience with ASP.NET Core services, Azure messaging and domain design already gives you most of the instincts you need.

Use the smallest architecture that can meet the goal safely, clearly and measurably.

For BuildEstate Pro, the first release has one user identity, one project boundary and one objective: review planning evidence and prepare a proposal. That points to one bounded agent backed by ordinary C# services. We add a router or specialist only when a real difference in policy, ownership or evaluation requires it.

Once tools exist, it is tempting to add more agents. That usually increases latency, cost and failure modes before it increases value. Architecture should follow the shape of the work and the trust boundaries—not a desire to draw an impressive diagram.

This module compares the main patterns using the same BuildEstate Pro planning-support goal.

1. Start with one bounded agent

A single agent loop is the default:

User goal -> policy/context -> model -> permitted tool -> observation
                                 ^                         |
                                 +-------------------------+

It has one state record, one instruction hierarchy and one place to enforce budgets. This works when tools share the same user, data boundary and objective.

public sealed class PlanningSupportAgent(
    IAgentDecisionModel model,
    IToolRegistry tools,
    IAgentPolicy policy,
    IExecutionStore store)
{
    public Task<AgentResult> RunAsync(AgentGoal goal, CancellationToken ct)
        => AgentLoop.RunAsync(goal, model, tools, policy, store, ct);
}

Do not split “search agent”, “summary agent” and “formatting agent” merely because those are separate prompt steps. Ordinary functions are clearer.

2. Router pattern

A router classifies a request and sends it to a specialised deterministic flow or agent. It is useful when domains have different tools, instructions or evaluation criteria.

Request -> router -> planning support
                  -> finance explanation
                  -> legal-policy answer
                  -> unsupported / human queue

The router should produce a typed route plus confidence and rationale evidence. Low-confidence or multi-domain requests should not be forced into one branch. Test routing separately from branch quality.

3. Planner–executor pattern

A planner proposes a sequence; an executor validates and performs one step at a time. Replanning occurs after material observations.

public sealed record Plan(
    string Goal,
    IReadOnlyList<PlannedStep> Steps,
    string CompletionCondition);

public sealed record PlannedStep(
    int Number,
    string Capability,
    string Purpose,
    bool RequiresApproval);

Plans are hypotheses, not authority. The executor must check every step against current policy. Avoid executing an entire model-generated plan blindly; conditions may change after step one.

This pattern helps when users need a preview, tasks are long-running or support teams need to inspect progress. It adds plan drift, replanning cost and a new object that must be versioned.

4. Supervisor–worker pattern

A supervisor delegates bounded tasks to workers and combines their outputs. Use it when work genuinely benefits from parallel, independently evaluated specialisms.

For example, a planning review might ask a policy worker and project-evidence worker to operate concurrently. Neither may alter business state. The supervisor receives structured findings, resolves no hidden authority conflicts, and prepares one proposal.

Risks include duplicated retrieval, conflicting conclusions, context loss, circular delegation and unclear ownership. Enforce:

• a shared execution ID and parent task;
• worker-specific tool allow-lists;
• depth, fan-out and total-cost budgets;
• typed deliverables and deadlines;
• one component responsible for the final decision.

5. Critic or reviewer pattern

A second model pass reviews a draft against a rubric. It may identify unsupported claims, missing evidence or policy violations. It must not be treated as proof: two models can share the same blind spot.

{
  "verdict": "revise",
  "findings": [
    {
      "code": "MISSING_EVIDENCE",
      "claim": "Ecology survey is current",
      "requiredAction": "Cite the survey date or remove the claim"
    }
  ]
}

Prefer deterministic validators for properties code can know: citation existence, permission, schema validity, totals and state transitions. Use a model reviewer for semantic qualities that are hard to encode.

6. Human-in-the-loop pattern

Human review is not a decorative confirmation box. It is a state transition that pauses execution, persists the exact proposal, explains consequence and records the decision.

Approval is appropriate for external communication, financial commitments, legal or planning submissions, destructive changes and actions outside routine policy. The approver needs sufficient evidence and must possess authority independently of the initiating user.

7. Multi-agent systems

Separate agents become defensible when they have genuinely independent ownership, deployment, context or security boundaries. Examples include another organisation’s planning agent exposed through A2A, or an internal compliance agent governed by a separate team.

Inside one codebase, multiple services or components do not automatically require agent-to-agent communication. A typed service call, message queue or workflow engine remains simpler when the interaction contract is known.

8. Pattern comparison

9. Composition for BuildEstate Pro

The initial production-minded design uses:

1. A deterministic router distinguishes explanation, review and unsupported requests.
2. One planning-support agent handles the bounded review.
3. Read-only policy and project services run in parallel where useful.
4. Deterministic validators check citations and permissions.
5. A human approves any command proposal.

This is intentionally less elaborate than a hierarchy of conversational agents. Complexity can be added after evaluation demonstrates a bottleneck.

10. Failure and observability

Every hand-off needs a contract: input, output, owner, deadline, cancellation behaviour and failure classification. Preserve trace context without copying hidden reasoning. Log decisions and evidence, not private chain-of-thought.

Evaluate each component and the complete route. A 95% router and 90% worker do not automatically make a 90% system; failures compound and interact.

Extended implementation review

11. Choose architecture with measurable forces

Architecture selection should begin with forces, not framework names. Ask how many trust boundaries exist, whether work can be decomposed independently, how frequently plans change, whether partial results have value, and which decisions must remain deterministic. Also estimate the latency, token and operational cost of every model boundary.

A useful decision record compares at least three options: a deterministic workflow, one bounded agent and the proposed multi-component design. Record why the simpler option is insufficient, what evaluation will demonstrate improvement and what condition would trigger rollback. This makes complexity reversible rather than permanent.

For BuildEstate Pro, a router may be justified if planning, finance and customer-support requests use different data policies. A router is not justified merely to choose between three prompts that share the same tools and owner. Likewise, a specialist ecology agent is justified when it is independently operated and evaluated, not simply because ecology has its own system prompt.

12. Planner–executor without unchecked plans

A planner can turn a broad goal into typed steps, but its plan is a proposal. Trusted code validates permitted step types, dependencies, maximum depth and total budget. The executor should receive one step plus the minimum context needed, not an unrestricted plan containing invented tools.

{
  "planVersion": 1,
  "steps": [
    {"id": "s1", "kind": "retrieveEvidence", "dependsOn": []},
    {"id": "s2", "kind": "assessCompleteness", "dependsOn": ["s1"]},
    {"id": "s3", "kind": "prepareProposal", "dependsOn": ["s2"]}
  ]
}

Reject cycles, unknown kinds and plans that exceed policy. Replanning should preserve completed evidence and explain why the previous plan became invalid. Limit replans, because an agent can otherwise spend its budget continually rewriting an approach without producing an outcome.

13. Supervisor–worker and delegation control

A supervisor assigns bounded tasks to workers and combines their outputs. The design works when tasks can be evaluated independently and workers have genuinely distinct capabilities. Define a delegation envelope containing goal, allowed data, tools, budget, deadline, output schema and correlation identifiers.

Workers must not inherit all supervisor authority. A research worker may read approved evidence but never create a task. A calculation worker may run a versioned rule but not fetch unrelated projects. The supervisor validates returned artifacts and remains responsible for the final outcome; a fluent worker response is not automatically trustworthy.

Set maximum delegation depth and fan-out. Without these limits, a worker can create more workers, causing cost explosions and unclear ownership. Cancellation should propagate down the task tree, while completed artifacts retain enough provenance for audit.

14. Critics, judges and verification

A critic model can find omissions, inconsistent citations or poor reasoning, but it is another probabilistic component. Do not let a critic authorise a command or override deterministic policy. Use it to generate review findings against an explicit rubric, then require the producing component to revise or escalate.

Prefer deterministic verification where possible: schema validation, citation existence, arithmetic, permission checks, uniqueness and allowed transitions. Use model-based evaluation for qualities that require judgement, such as whether a summary fairly represents conflicting evidence. Calibrate model judges against qualified human decisions and watch for shared blind spots when producer and judge use similar models.

15. Human-in-the-loop is an architecture, not a button

Human review needs a durable state, a clear consequence and enough evidence to make a decision. The reviewer should see the exact command, affected resource, relevant evidence, policy result and expiry. Approve, edit and reject have different semantics: an edit should normally create a new proposal, because the original model and policy assessment no longer match.

Design queue ownership, escalation and service levels. What happens if no reviewer responds? The safe default is expiry, not silent execution. Protect against approval fatigue by asking for review only where human judgement or authority adds value. Repeated low-information prompts encourage rubber-stamping.

16. Data contracts between components

Do not connect agents with prose alone. Each hand-off should use a versioned schema with a stable task identifier, evidence references and failure classification. Components should exchange observable rationale such as “evidence X conflicts with record Y,” not hidden chain-of-thought.

Apply data minimisation at every boundary. A router usually needs intent and high-level scope, not full project documents. A specialist receives only the records needed for its task. When outputs cross tenants, organisations or jurisdictions, enforce policy before transfer and again before ingestion.

17. Reliability mathematics and graceful degradation

More components create more ways to fail. If three required stages each succeed 95% of the time and failures are independent, the theoretical combined success is about 86%. Real failures are often correlated, so the result may be worse. Parallelism can reduce elapsed time but increases contention, rate-limit pressure and partial-result handling.

Define degraded modes. If the critic is unavailable, perhaps return the assessment marked “review unavailable.” If an external specialist fails, preserve local evidence and request human follow-up. If command capability is disabled, retain read-only explanation. A dependency failure should not automatically erase useful, safely obtained work.

18. Architecture evaluation and migration

Measure route accuracy, worker task success, hand-off completeness, end-to-end correctness, latency percentiles, cost, refusal quality and recovery. Trace the component graph with shared correlation IDs, while keeping each trust boundary independently auditable.

Migrate incrementally. Extract one specialist only after baseline measurements exist. Shadow the new route without affecting users, compare outcomes and introduce a feature flag. Preserve a path back to the single-agent or deterministic flow. Architecture should earn its continued existence through better outcomes, clearer ownership or stronger isolation.

Keep an architecture scorecard per release: end-to-end acceptance, critical safety failures, p95 latency, median model calls, cost per accepted outcome, operator interventions and recovery success. Compare the multi-agent route with the simplest credible baseline. If a specialist improves style but reduces factual accuracy or doubles cost without measurable user value, merge it back into ordinary code or the primary agent.

Production checklist

• Begin with one agent and justify every additional model role.
• Record the owner, input contract, output contract and permission boundary for every model component.
• Keep a tested fallback route when a specialist, router or supervisor is unavailable.
• Review the architecture after incidents and remove components that add cost without measurable outcome quality.
• Keep deterministic rules outside model arbitration.
• Give each component a narrow capability set and owner.
• Bound delegation depth, fan-out, time and cost.
• Persist exact proposals before human review.
• Correlate tasks and observations across boundaries.
• Test component quality and end-to-end outcomes.
• Use ordinary services when the contract is already deterministic.

19. Continue the series

Every architecture needs reliable state. Part 4 separates model context, conversation, working state, memory, business data and checkpoints, then shows how to resume work without confusing any of them.

A practical Azure and ASP.NET Core deployment

Keep the Angular interface and ASP.NET Core control plane as the trusted application boundary. The control plane authenticates with Microsoft Entra ID, applies project authorization, loads state from SQL Server and calls a model selected through Microsoft Foundry.

Angular UI
   -> ASP.NET Core control plane
      -> authorization and agent state
      -> Foundry model endpoint
      -> Azure AI Search evidence service
      -> protected domain APIs
      -> Service Bus for durable background work

Each model role can sit behind an owned interface:

public interface IPlanningDecisionMaker
{
    Task<PlanningDecision> DecideAsync(
        PlanningContext context,
        CancellationToken cancellationToken);
}

public interface IPlanningEvidenceService
{
    Task<EvidenceSet> RetrieveApprovedAsync(
        AuthorizedProject project,
        EvidenceQuery query,
        CancellationToken cancellationToken);
}

If you add a router, make it return a small typed destination. ASP.NET Core validates the route and supplies only the tools permitted for it. If you add a remote worker, Service Bus can carry a durable task envelope, but the message contains a bounded objective rather than the complete conversation.

Microsoft Foundry supports prompt agents and hosted code-first agents. That choice changes who operates the runtime, not who owns your domain rules. A hosted multi-agent graph still needs resource authorization, budgets, contracts and acceptance tests.

A calm pattern-selection guide

• Choose a workflow when code can select every step reliably.
• Choose one agent when one goal requires flexible tool choice inside one trust boundary.
• Add a router when destinations have different tools, policies or owners.
• Add a planner–executor when dynamic decomposition is useful and plans can be validated.
• Add supervisor–workers when subtasks can be bounded and assessed independently.
• Add a critic for qualitative review against a rubric, never to replace policy.
• Add human review when accountable judgement or authority must remain with a person.
• Use A2A only across a genuine independent-agent boundary.

For every addition, record the problem, simpler alternative, expected improvement, new risk, evaluation measure and rollback condition. More agents do not automatically mean more intelligence. They mean more calls, hand-offs and failure modes that must earn their place.

Primary references

• OpenAI practical guide to building agents
• LangChain agents documentation
• Microsoft agent orchestration patterns
• NIST AI Risk Management Framework