The Agentic Architecture Framework (Overview)

(A well-architected approach to building agentic systems)

This section introduces the Agentic Architecture Framework as a practical, repeatable method for designing agentic systems that are safe, reliable, efficient, and governable. It is deliberately inspired by the discipline of “well-architected” thinking that cloud platforms popularized—because the underlying challenge is the same: complex systems fail when they are built without explicit architectural principles and trade-offs. AWS describes this problem clearly: if you neglect core pillars, it becomes difficult to build systems that deliver on expectations and requirements.

(Insert graphic of the pillars and cross pillars)

However, agentic systems introduce unique dynamics that require additional architectural emphasis:

• they are probabilistic at the reasoning layer,

• stateful over time,

• and capable of actuation via tools, where errors and misuse can have real-world consequences.

Google’s recent work on scaling agent systems highlights the key shift: agents are not isolated predictions; they are sustained, multi-step interactions where a single error can cascade across a workflow—forcing architects to look beyond standard “accuracy” and design for end-to-end system behavior.

The purpose of this framework is not to create a checklist. It is to provide a coherent mental model for:

• designing agentic systems intentionally,

• understanding trade-offs,

• reviewing architectures consistently,

• and scaling autonomy safely.

4.1 Pillars: The Core Architectural Lenses

The framework is organized around six primary pillars that experienced engineers will recognize from mature systems design:

1. Security Architecture

2. Reliability

3. Cost Optimization

4. Operational Excellence

5. Performance Efficiency

6. Sustainability

This pillar structure has a practical advantage: it forces teams to avoid building systems that are “clever” but brittle, or “working” but unsafe, or “useful” but financially unscalable. AWS explicitly groups well-architected guidance under these same six pillars (operational excellence, security, reliability, performance efficiency, cost optimization, sustainability). (docs.aws.amazon.com)

In the agentic context, each pillar is interpreted through an agent-specific lens. For example:

• Security is not only about perimeter and identity; it is about constraining agency and preventing unsafe tool actuation.

• Reliability is not only uptime; it is repeatable outcome achievement under probabilistic reasoning and partial failures.

• Operational excellence is not only deployment and monitoring; it is observability of the full control loop, captured via the observability trace (intent → plan → act → verify), and controlled learning.

4.2 Cross-Cutting Foundations: Context Optimization and Autonomy & Outcome Governance

Agentic systems need two additional “horizontal layers” that cut across multiple pillars. These are not separate concerns; they are structural properties of agentic behavior.

A. Context Optimization (Cross-cuts cost, performance, reliability, security, and operations)

Context is both a capability amplifier and a failure multiplier. Too little context leads to hallucination, poor tool selection, and missed constraints. Too much context leads to higher cost, slower performance, and higher risk of accidental leakage or instruction collisions.

This is not abstract. Tool-enabled agents face a concrete constraint: tool definitions and tool results consume context window budget, and each additional tool increases the burden. Anthropic’s MCP engineering write-up describes how the MCP client loads tool definitions into the model’s context window and how each tool call and result passes through the model during the loop—making context a first-class architectural constraint. (anthropic.com)

Anthropic further points to design patterns that explicitly address this, including tool search and programmatic tool calling to reduce the impact of large tool catalogs on the context window. (anthropic.com)

The practical takeaway is that context management cannot be left to “prompt tuning.” It must be architected: budgeting, retrieval, summarization, and provenance tracking.

B. Autonomy & Outcome Governance (Cross-cuts security, reliability, cost, operations, and context)

Autonomy is not merely “the system does more.” It is a controlled operating mode that determines:

• what the agent is allowed to do,

• how far it can go without intervention,

• what constitutes success,

• and what evidence is required before the system treats an output as authoritative.

This layer directly addresses one of the most common failure modes in agentic systems: excessive agency. OWASP explicitly names “Excessive Agency” as a vulnerability where damaging actions are performed in response to unexpected, ambiguous, or manipulated model outputs; it identifies root causes such as excessive functionality, excessive permissions, and excessive autonomy. (genai.owasp.org)

Autonomy governance is therefore inseparable from:

• security (permissions, policy gates, tool allowlists),

• reliability (definitions of done, outcome verification),

• cost (budgets on steps, tools, spend, and time),

• operations (observability, rollback, audit), and

• context (agents cannot act safely without sufficient, correct context).

4.3 Why This Is Not a Checklist

Checklists fail for agentic systems because agentic systems are shaped by:

• stochastic model behavior,

• tool and environment variability,

• evolving context and memory,

• and topology decisions (single-agent vs multi-agent orchestration).

Google’s scaling research emphasizes that agent systems must be evaluated as the interplay between number of agents, coordination structure, model capability, and task properties, implying that architecture choices are not universal; they are context-dependent. (arxiv.org)

The framework is therefore best understood as:

• a set of architectural lenses,

• a method for surfacing trade-offs,

• and a discipline for creating intentional constraints.

It is not trying to eliminate complexity; it is trying to control it.

4.4 How to Use the Framework

There are three practical uses:

1) Design-time guidance

Use the pillars and cross-cutting layers to design an agent system deliberately:

• What is the autonomy level?

• What is the definition of done?

• What are the allowed tools and permissions?

• How is context constructed and bounded?

• How are failures detected and handled?

2) Architecture reviews and pre-production readiness

Apply the framework as a structured review method to identify:

• missing security boundaries,

• missing verification gates,

• lack of budgets (cost/autonomy),

• weak observability,

• unacceptable topology risks.

3) Iterative maturity model (safe scaling of autonomy)

Most organizations should start with low autonomy (assistive, human-approved) and progressively increase autonomy only as:

• verification improves,

• tooling becomes safer,

• observability is mature,

• and failure modes are understood.

This aligns with the principle that epistemic and autonomy gates must scale with risk: low-stakes workloads can tolerate lighter gates, but high-stakes workloads require strong and unavoidable ones.

For usage patterns, MCP server and skills, and the AAF Posture Review and Reporting CLI (codebase alignment report), see How to Apply the Framework in Practice (Section 15).

4.5 A Note on Ecosystem Alignment (Protocols vs Architecture)

The framework is designed to remain compatible with emerging protocols and standards for agent interoperability, but it intentionally sits “above” them. Protocols (e.g., agent-to-agent messaging, tool discovery mechanisms) enable coordination; architecture governs how that coordination is secured, observed, budgeted, and verified.

For example, MCP is explicitly concerned with tool integration and discovery patterns (e.g., simple tools/list discovery) that influence context construction and governance. (modelcontextprotocol.io)

This distinction matters: protocols define plumbing; the framework defines system design discipline.

Section 4 Citations (Sources & Links)

1. AWS: The pillars of the framework (six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability)
   https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html
   (docs.aws.amazon.com)

2. AWS: AWS Well-Architected overview (six pillars positioning)
   https://aws.amazon.com/architecture/well-architected/
   (aws.amazon.com)

3. Google Research: Towards a science of scaling agent systems: when and why agent systems work (agents as sustained multi-step workflows; cascading errors)
   https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/
   (research.google)

4. arXiv: Towards a Science of Scaling Agent Systems (coordination structure, model capability, task properties interplay)

   https://arxiv.org/html/2512.08296v1
   (arxiv.org)

5. OWASP GenAI Security Project: Excessive Agency (root causes: excessive functionality/permissions/autonomy)
   https://genai.owasp.org/llmrisk2023-24/llm08-excessive-agency/
   (genai.owasp.org)

6. OWASP: Top 10 for Large Language Model Applications (taxonomy including prompt injection, model DoS, supply chain)

   https://owasp.org/www-project-top-10-for-large-language-model-applications/
   (owasp.org)

7. Anthropic — Code execution with MCP: building more efficient AI agents (tool definitions in context window; tool-call loop)

   https://www.anthropic.com/engineering/code-execution-with-mcp
   (anthropic.com)

8. Anthropic: Introducing advanced tool use (tool search; reducing context window impact)
   https://www.anthropic.com/engineering/advanced-tool-use
   (anthropic.com)

9. Model Context Protocol: Architecture overview (tool discovery; tools/list)
   https://modelcontextprotocol.io/docs/learn/architecture
   (modelcontextprotocol.io)