Concepts
Each capability has a contract that any implementation must preserve. The products named below, Amazon Bedrock AgentCore services among them, are the reference choices in this repository, not requirements.
Labels like LLM Gateway, Tool Gateway, agent runtime, memory, identity, registry, policy engine, delivery pipeline, and observability describe architectural capabilities. A capability contract defines the outcomes and controls that any chosen implementation must preserve, regardless of product. The repository supplies one integrated implementation so that the contracts can be deployed and tested end to end.
A substitute is not automatically a drop-in configuration change. It can require new adapters, IaC, runbooks, threat-model updates, and migration logic. The substitute becomes supported only after the same positive and adversarial, mutation, load, rollback, observability, and teardown obligations pass for that implementation.
Source: README.md: Capability Architecture (opens in new tab)
The root README lists 10 capabilities. Each card names the capability, what it does, the reference implementations in this repository, and what a replacement must keep.
Governed access to foundation models with authentication, routing, policy enforcement, and usage attribution.
Authenticated MCP discovery and invocation with least-privilege execution and policy enforcement.
Immutable deployable agent execution with workload identity, isolation, and invocation contracts.
Actor-scoped event storage with encryption and retention policies.
Short-lived credentials with tenant binding and traceable identity exchange.
Ownership, lifecycle state, and approval separation for agents and tools.
Fail-closed authorization with explicit context, versioning, and decision telemetry.
Reviewed source, reproducible build, scanning, promotion gates, and rollback.
Correlated logs, metrics, and traces with cell and fleet views.
Attribution by application, agent, tenant, and environment with budgets.
The table states how strongly each project delivers each capability in its tested form. Postures are coarse on purpose; the text in each cell carries the nuance and links to the file it comes from.
The table is wider than the screen. Scroll it sideways to see every project.
| Capability | WorkshopLearn | Self-ServiceBuild | MCP GatewayGovern | BlueprintScale |
|---|---|---|---|---|
| LLM Gateway | Illustrative Module 2 deploys LiteLLM Proxy on ECS Fargate for governed, cost-attributed access to Amazon Bedrock models. | Not applicable No LLM gateway layer. Agents call one of 13 model providers directly (Bedrock by default). LiteLLM appears only as an optional MCP gateway or registry catalog. | Not applicable Governs tool calls only; model access is out of scope. | Enforced AgentCore Gateway inference targets with a mandatory Guardrail interceptor and a model allow-list; LiteLLMModel is the agent client. README.md: Capability contracts and replaceable implementations (opens in new tab) |
| Tool Gateway | Illustrative Module 3a layers an AgentCore Tools Gateway over the MCP Gateway & Registry for JWT auth, audit and guardrails; Module 3b uses AgentCore Gateway with Lambda targets. | Enforced Selected tools deploy as a single Lambda behind an AgentCore Gateway with Cognito OAuth2; agents discover them at runtime via tools/list. | Enforced AgentCore Gateway with a CUSTOM_JWT (Cognito) authorizer in front of two sample Lambda targets; one governed MCP endpoint. | Enforced An AWS_IAM AgentCore Tool Gateway per Workstream cell; targets derived from approved Registry records. README.md: 2.3 Repeatable Workstream cell (opens in new tab) |
| Agent Runtime | Illustrative Module 4 deploys a FAST travel agent on AgentCore Runtime, wired to the platform through the MCP path or the AgentCore path. | Enforced Canvas agents deploy as code-generated AgentCore Runtime or as a config-driven AgentCore Harness. | Not applicable No agent runtime. An external MCP client such as Kiro or Claude Code drives the gateway; only the optional Atlassian connector runs a server on AgentCore Runtime. | Enforced Nonproduction and production AgentCore Runtime per Workstream cell, deployed as immutable revisions with rollback. README.md: 2.3 Repeatable Workstream cell (opens in new tab) |
| Agent Memory | Illustrative The Module 4 FAST agent ships with conversation memory. | Enforced A Memory node on the canvas; teardown removes the memories it created. | Not applicable Not part of this project. | Enforced AgentCore Memory with actor-scoped events and customer-managed KMS keys. README.md: Capability contracts and replaceable implementations (opens in new tab) |
| Identity | Illustrative Cognito and WorkloadIdentity provide human and machine identity in Module 3b; three IAM persona roles separate duties. module-3b/index.en.md: What you will learn (opens in new tab) | Enforced Cognito user pool for people, an Identity node for agents, and connector credentials that live only in Secrets Manager. | Enforced Cognito OIDC JWT inbound authentication; per-user OAuth 3LO for the optional connectors. | Enforced AgentCore Identity plus Cognito M2M short-lived credentials. |
| Registry | Illustrative Module 3a uses the open-source MCP Gateway & Registry; Module 3b creates an AgentCore Registry with a Publisher and Admin approval workflow. | Enforced Built-in agent registry with an approval workflow (registry-admin and registry-developer personas); a LiteLLM proxy can become the catalog. | Not applicable No registry. The README positions the gateway a layer below platforms that manage which agents and servers exist. | Enforced AWS Agent Registry governance records drive Gateway targets. See advisory for issue #29 on the preview API cutoff. README.md: Capability contracts and replaceable implementations (opens in new tab) |
| Policy Engine | Illustrative Module 3b Part C creates an AgentCore Policy Engine with Cedar policies and attaches it in LOG_ONLY mode; in this setup ENFORCE would empty tools/list. | Enforced Cedar ENFORCE per Policy node (fail-closed, converge-in-place); scope-based RBAC is advisory by default. ENTERPRISE_CAPABILITIES.md: Agent lifecycle & quality (opens in new tab) | Enforced Cedar ENFORCE at the gateway with one policy per statement; policies are created with validationMode IGNORE_ALL_FINDINGS. | Enforced AgentCore Policy Engine plus a retained Lambda Cedar wrapper; 12 SCPs for model, Region, Guardrail, Registry, Gateway and deployment boundaries. README.md: Capability contracts and replaceable implementations (opens in new tab) |
| Delivery | Not applicable Not covered. The five stacks deploy through a shell wrapper with a preflight check. | Enforced A Step Functions deployment pipeline (validate, codegen, IAM, runtime, evaluation) with versioning and rollback; no source-review gate. | Not applicable Deployed with cdk deploy from a workstation; no pipeline. | Enforced GitHub, CodeConnections, CodePipeline, CodeBuild and ECR; digest-bound image scanning blocks Critical or High findings; human approval after deployed-runtime evaluation. |
| Observability | Illustrative Grafana dashboards backed by Amazon Managed Service for Prometheus in Module 3a; Module 4 inspects traces, logs and memory. module-3a/index.en.md: What's already deployed (opens in new tab) | Enforced Per-canvas and platform-level OTEL modes; OTLP traces from every platform Lambda and deployed agent can go to a backend such as Langfuse. | Enforced One structured request_audit record per call in the interceptor logs; refused calls are audited too. | Enforced CloudWatch OAM links for centralized Logs, Metrics and Traces; Transaction Search is opt-in. |
| Cost | Illustrative The Module 2 LLM Gateway gives cost-attributed model access through LiteLLM virtual keys and budgets. | Enforced Cost budgets, usage events and audit analytics; a budget breach emits a CloudWatch metric. | Not applicable No cost attribution controls in this sample. | Enforced Five allocation tags, per-application budgets, account-level Bedrock quotas and CUR reconciliation. |
When replacing a reference implementation with an alternative:
The tested regions, versions and known limitations per project are collected on the support envelope page.