Agentic Architecture Patterns and Autonomy Selection
Select the minimum sufficient architecture for the problem and risk rather than maximizing how agentic the design appears.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
4. Pattern contracts
Deterministic and assistance patterns
Keep rules in code when requirements are stable and testable. For prompt assistance, label outputs as proposals and provide source/context disclosure. For retrieval assistance, add source registry, permission filtering, exact citations, freshness, contradiction handling, and revocation. Memory is unnecessary unless a measured cross-session need exists.
Bounded single-agent loop
Freeze the model, prompt, context, skills, tools, policy, budgets, and quality contract. Persist attempt state outside the model. Restrict tools by resource and side effect. Stop on acceptance, attempts, tool calls, time, tokens, cost, no improvement, denial, cancellation, or dependency failure. A human reviews consequential results with independent evidence.
Coordinated multi-agent pattern
Add only with a measurable specialization, parallelism, or assurance reason. Define delegation, context, authority, handoff, join, disagreement, partial result, and correlation contracts. Budget fan-out and preserve a deterministic aggregation path where possible.
Durable autonomous workflow
Add triggers, admission, queue, durable graph, leases, idempotency, reconciliation, pause/cancel/quarantine, SLOs, on-call ownership, and evidence gates. Autonomy applies to a bounded workflow, not an unrestricted goal.
Enterprise-integrated system
Add governed inventory, unique workload identity, tenancy, policy decision points, knowledge and capability lifecycles, data classification, independent assurance, delivery and rollback, monitoring and incident response, continuity, cost attribution, supplier controls, and periodic recertification.
6. Failure and risk comparison
| Added level | New dominant failure | Required containment |
|---|---|---|
| Prompt assistance | Hallucinated or misleading proposal | Clear advisory boundary and human review |
| Retrieval | Unauthorized, stale, poisoned, or contradictory source | Pre-ranking permission, lineage, revocation |
| Single agent | Tool misuse, nonconvergence, hidden state | Scoped gateway, durable attempt, hard stops |
| Multi-agent | Correlated error, delegation drift, fan-out cost | Collaboration contract, independence tests, parent budget |
| Durable workflow | Duplicate/partial effects, orphaned work | Idempotency, leases, reconciliation, emergency control |
| Enterprise system | Cross-tenant impact, governance and supplier failure | Inventory, identity, policy, control tower, continuity, recertification |
8. Tradeoffs and nonclaims
Lower levels sacrifice flexibility but improve predictability, testability, cost, and security. Higher levels can handle ambiguity and long-running work but demand stronger operations. This review-ready ladder is not a universal risk classification and does not claim that higher autonomy produces better business outcomes.
9. Architecture review exercise
Choose one repository question, one bounded code change, and one cross-system release workflow. For each, document the lowest eligible level, rejected alternatives, required contracts, evaluation, evidence, human authority, failure recovery, cost, promotion criteria, and fallback. A reviewer must be able to challenge the design without knowing a particular vendor stack.
Curriculum maturity is not implementation proof.
This chapter defines architecture or practice. It does not by itself prove a corresponding production implementation.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence