Governing and architecting agentic AI at scale
B · Useful, limited AWS Prescriptive Guidance by five AWS solutions architects; a clear reference model for enterprise agent governance and architecture, but vendor practice guidance with no evidence or cases, mapped throughout to AWS products.
Summary based on the full text·Original: about 40 minutes to read
In short
A 42-page AWS Prescriptive Guidance document (first published 23 April 2026) for CIOs, enterprise architects and AI governance leads on governing many kinds of AI agents across a company, not within one project. It sorts use cases by risk, sets out what governance has to cover (registries, model catalogues, quality gates, access, lineage), compares centralized, federated and hybrid models, and lays out a layered reference architecture with AWS services slotted into each layer.
Key numbers
- threegovernance models compared: centralized, federated and hybrid
- threetool access patterns compared: in-runtime, direct remote (MCP) and tools gateway
- up to 90%storage and search cost reduction AWS claims for S3 Vectors vs traditional vector databases
As reported by the source.
English·PDF·opens docs.aws.amazon.com
What it reports
- Use-case typology: simple chatbots, personal assistants and autonomous team agents (internal productivity); domain-specialised and customer-facing applications (business). Rigor rises from personal assistants, which "can tolerate occasional errors", to customer-facing systems.
- Governance scope: a registry of agents, tools and MCP servers with owner, permissions, purpose and incident history; an LLM catalogue with approved use cases, quotas and deprecation dates; evaluation gates before agents are shared.
- Shadow AI: make the governed path more attractive than the shadow path through fast approvals and self-service.
- Access: agents must not become proxies for data a user cannot reach directly; tool calls must respect both agent identity and the invoking user's rights; agent-to-agent calls need explicit authorization.
- Lineage: log enough to reconstruct a decision (example: a credit score) without logging every intermediate step.
- Governance models: centralized suits regulated or early-stage firms but becomes a bottleneck; federated suits large diversified firms but loses visibility; hybrid, with central standards for high-risk agents and local autonomy for low-risk ones, "suits most enterprise organizations".
- Stateless LLM inference is easy to abstract behind a gateway; stateful agent services are not, which weakens multi-cloud centralisation as agent use grows.
- Citizen developers start with limited permissions that widen as they demonstrate competence, with role-based certification and tested templates.
- Tool catalogues: past a small stable set, putting all tool descriptions in context raises selection errors, which argues for a gateway with search and discovery.
How they got it
Practitioner guidance written by AWS solutions architects and a technical writer, with one internal reviewer. No case studies, data or external sources beyond AWS's own resources.
Limits
- Every architectural layer is mapped to AWS services (Bedrock AgentCore, Quick, Kiro, Claude Code on Bedrock), so neutrality is limited.
- No evidence on which governance model works better in practice.
- The cost figure for S3 Vectors is a vendor claim with no benchmark.
Why it matters for companies
The document is a usable checklist for a central AI team deciding what to own. The most practical points: keep one registry of agents, tools and MCP servers with named owners; enforce that agents act with the user's permissions; tier controls by risk so low-risk internal assistants are not stuck behind the same gate as customer-facing agents. The point about stateful agent services also matters for platform strategy: an LLM gateway buys provider independence for model calls, but agent memory, tools and runtime will tie you to a platform.
Summary based on the full text. Read the original for the full argument and data.Open PDF on docs.aws.amazon.com
- Tags
- Governance