Declare AI agents in YAML. Deploy on AWS.
A configuration-driven, provider-agnostic runtime for AI agents — built over Strands Agents SDK and Amazon Bedrock AgentCore. Define agents, strategies, and multi-agent workflows as YAML blueprints. The platform handles Runtime, Gateway, Memory, Identity, Policy, Observability, Evaluation, and everything in between.
The Problem
Amazon Bedrock AgentCore provides powerful primitives for building production AI agents on AWS — Runtime, Gateway, Identity, Memory, Tools, Observability, Evaluation, Policy, A2A, and more. Wiring them together requires hundreds of lines of infrastructure code, SDK plumbing, and deployment configuration per agent.
This platform eliminates that boilerplate. You write a YAML blueprint. The platform reads it, resolves all dependencies, and produces a fully operational agent on AgentCore Runtime.
Blueprint Engine
Define agents in YAML. The platform assembles Runtime, Gateway, Memory, Identity, Policy, and Observability from a single file. Zero glue code.
Provider-Agnostic Inference
Four inference providers out of the box: Amazon Bedrock, Anthropic, LiteLLM, and Google Vertex AI. Switch providers by changing one line in the blueprint.
How It Works
graph LR
A[YAML Blueprint] --> B[BlueprintLoader]
B --> C[Strands Agent]
C --> D[Docker / ECR]
D --> E[AgentCore Runtime<br/>microVM]
E --> F[Gateway]
F --> G[Lambda Functions]
F --> H[MCP Servers]
F --> I[OpenAPI / REST]
E -.-> J[Memory Service]
E -.-> K[Identity Service]
E -.-> L[Policy Engine]
style A fill:#00bcd4,stroke:#00bcd4,color:#000
style E fill:#ff9800,stroke:#ff9800,color:#000
style F fill:#10b981,stroke:#10b981,color:#000
One handler serves every agent. The YAML blueprint determines which inference provider, tools, prompts, memory strategies, identity providers, and Cedar policies are wired. Your domain repo provides: prompt content, business schemas, and domain-specific tool implementations. The platform handles everything else.
The 12 Building Blocks
Every agent blueprint can configure any combination of these blocks:
| # | Block | What It Does |
|---|---|---|
| 1 | Runtime | Hosts agents in isolated microVMs per session with streaming and OTel flush |
| 2 | Gateway | Protocol translator — Lambda, MCP, OpenAPI, and Smithy backends through one interface |
| 3 | Identity | JWT validation, API keys, OAuth 3LO, and M2M credential injection |
| 4 | Memory | Short-term session events + long-term semantic knowledge via pgvector |
| 5 | Tools | Managed Code Interpreter, Browser, custom MCP servers, and artifact store |
| 6 | Observability | OTEL traces, Langfuse integration, audit logs, and cost tracking |
| 7 | Evaluation | 12 built-in LLM-as-judge evaluators + custom evaluators via agentcore or Langfuse |
| 8 | Policy | Cedar fine-grained access control on every Gateway tool call |
| 9 | Inference | Bedrock, Anthropic, LiteLLM, and Vertex — provider selected per blueprint |
| 10 | A2A | Agent-to-agent discovery, delegation, and streaming via the A2A protocol |
| 11 | Infrastructure | Composable Terraform modules for platform, agents, workflows, and utilities |
| 12 | Blueprints | Declarative YAML abstraction that drives all 11 blocks above |
Quick Start
# Install the SDK and CLI
pip install agent-core agent-cli
# Validate your agent blueprint
agentcli blueprint lint blueprints/agents/my-agent.yaml
# Deploy platform infrastructure (Terraform)
cd infra/
terraform init && terraform apply
# Deploy your agent to AgentCore Runtime
agentcli deploy --env production
Your domain repo writes:
- YAML blueprints — agent, strategy, and workflow definitions
- Prompt content — versioned prompt files managed by the Prompt Registry
- Domain tools — your own Lambda functions or MCP servers
The platform handles everything else.
Platform vs. Domain
| Concern | Platform (this repo) | Your Domain Repo |
|---|---|---|
| Blueprint parsing & validation | BlueprintLoader, schema validation | Blueprint YAML files |
| Agent runtime wiring | @app.entrypoint, AgentCoreApp | app.py (5-line handler) |
| Inference provider dispatch | BedrockModel, AnthropicModel, LiteLLMModel, GeminiModel | provider: in blueprint |
| Gateway target routing | TargetRegistry, GatewayClient | gateway-targets.yaml |
| Memory strategies & hooks | MemoryHookProvider, MemoryWiring | Memory config in blueprint |
| Identity provider wiring | Credential resolution, decorator injection | Identity config in blueprint |
| Cedar policy generation | PolicyWiring, translator | Policy rules in blueprint |
| Observability auto-instrumentation | OTel, LangfuseHook, CostTracker | trace_attributes in blueprint |
| Infrastructure deployment | Terraform modules | module "platform" { ... } |
| Prompt versioning | PromptRegistry (S3 + DynamoDB) | Prompt content files |
| Domain-specific tools | — | Lambda functions, custom MCPs |
FAQ
What is the relationship to Amazon Bedrock AgentCore?
This platform is an abstraction layer over AgentCore, not a replacement. It uses AgentCore Runtime, Gateway, Memory, Identity, and all other AgentCore services. The platform's value is turning multiple separate service configurations into one YAML blueprint per agent.
Which inference providers are supported?
Four providers are supported out of the box: Amazon Bedrock (default, Converse API), Anthropic (direct API), LiteLLM (proxy for any OpenAI-compatible endpoint — Ollama, vLLM, custom gateways), and Google Vertex AI (Gemini models). Provider is a single field in the blueprint's model: block. See the Inference Providers section.
Do I need to understand all 12 building blocks?
No. Start with Runtime + Gateway — that gets an agent running with tools. Add Memory, Identity, Policy, and Observability incrementally as your requirements grow. Every block in the blueprint schema is optional except id, name, version, model, and prompt_ref.
What agent frameworks are supported?
Strands Agents SDK is the primary framework with native AgentCore integration (BedrockModel, HookProvider, MCPClient, A2A). Any framework that exposes POST /invocations and GET /ping on port 8080 can run on AgentCore Runtime.
How do domain repos consume this platform?
Two ways: Terraform modules for infrastructure (module "platform" { source = "git::https://github.com/The-Cloud-Clockwork/tcc-aws-agent-platform.git//modules/platform?ref=v1.0.0" }) and pip packages for the SDK (pip install agent-core). Deploy platform infrastructure first, then deploy domain agents on top.
Why Terraform instead of CDK?
Portability, composability, and broader adoption. Domain consumers use standard terraform init && terraform apply. No CDK knowledge, no Node.js dependency, no synth step required.
Why not Lambda for agents?
Agents are stateful, long-running, and session-oriented. Lambda is suited for short, fast, stateless operations. AgentCore Runtime hosts agents in isolated microVMs with warm pools, session routing, and streaming support. Lambda is used for tools behind the Gateway — not for the agents themselves.
What does a developer actually write?
Three things: YAML blueprints (agent, strategy, and workflow declarations), prompt content (versioned text files managed by the Prompt Registry), and domain tools (Lambda functions or MCP servers implementing your business logic). The platform handles all infrastructure wiring and deployment.