AWS Builder Center
Building a Production-Grade Multi-Agent Platform with Zero Trust Governance on Amazon Bedrock AgentCore

Building a Production-Grade Multi-Agent Platform with Zero Trust Governance on Amazon Bedrock AgentCore

Enterprise AI agents without governance are insider threats that never sleep. We built a hierarchical multi-agent platform on Amazon Bedrock AgentCore that enforces Zero Trust on every tool call, deploys new agent versions with automatic rollback, detects rogue agents in real time, and produces compliance-ready audit trails for ITAR/EAR environments. Here's how.

Building a Production-Grade Multi-Agent Platform with Zero Trust Governance on Amazon Bedrock AgentCore

How We Built Enterprise Agent Lifecycle Management — From Onboarding to Canary Deployments — for a Semiconductor Company
Diksha Sharma | AWS Solutions Architect — Sr. AI/ML Specialist | Published April 28, 2026


TL;DR: We built a hierarchical multi-agent platform on  Amazon Bedrock AgentCore  that governs 12 AI agents across their full lifecycle — from qualification gates through canary deployments to automated quarantine. The platform enforces Zero Trust identity propagation on every tool call, detects rogue agents via  AWS CloudTrail , and supports multi-framework interop (Strands, LangGraph, n8n) without vendor lock-in. Built for a semiconductor enterprise running 20,000+ agents at scale.



The Problem: Agents Without Governance Are a Liability

Every enterprise AI team hits the same wall. You've built impressive agent demos — they answer questions, call tools, retrieve documents. But when the CISO asks "who authorized that agent to access financial data at 2 AM?", you have no answer.
For semiconductor companies, the stakes are higher. Design IP worth billions flows through EDA tools. Revenue forecasts move stock prices. HR data is regulated. An ungoverned agent with broad tool access is an insider threat that never sleeps.
We built the Enterprise Multi-Agent Platform (EMP) to solve this — not as a framework, but as a complete governance system that treats agents as first-class identities requiring the same controls as human employees.

Architecture: Five Agents, One Orchestrator, Zero Trust Everywhere

The platform runs on Amazon Bedrock AgentCore with this topology:
Plain text
User (Flask UI) → Cognito Auth → JWT Token
│
▼
Orchestrator Agent (Claude Sonnet 4.5)
├── Zero Trust Gateway Interceptor ([AWS Lambda](https://aws.amazon.com/lambda/))
├── AgentCore Memory (session persistence)
├── Canary Router (weighted version selection)
└── Routes to sub-agents:
├── Finance Agent → [Bedrock Knowledge Base](https://aws.amazon.com/bedrock/knowledge-bases/) + [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)
├── HR Agent → Knowledge Base + DynamoDB
├── EDA Agent → [Strands Agents SDK](https://strandsagents.com/) Graph (RTL review loop)
├── General Agent → Cross-cloud (Hugging Face Spaces)
├── LangGraph Agent → A2A protocol adapter
└── n8n Agent → On-prem workflow engine (webhooks)
Every arrow in this diagram passes through the AgentCore Gateway with a Lambda interceptor that enforces RBAC before any tool executes. The same query — "What's our Q3 revenue?" — returns different data depending on who's asking.

What Each Agent Actually Does

The orchestrator uses keyword-based routing to select the right sub-agent. Here's what a real conversation looks like:
Query
Routed To
What Happens
"What are the Q4 2025 revenue metrics and analyst consensus?"
Finance Agent
RAG retrieval from Finance KB + DynamoDB scan of financial metrics table
"Show me the engineering org chart and open requisitions"
HR Agent
RAG from HR KB + filtered scan of employee records table
"Review the RTL design for the NextGen AI Accelerator ASIC"
EDA Agent
Strands Graph: intake → rtl_analysis → review_decision → approve/revise/escalate
"Trigger the employee onboarding workflow"
n8n Agent
Webhook to on-prem n8n: validate → accounts → security → hardware → orientation → notify
"Search local research papers for transformer optimizations"
Local Agent
MCP Server query against local paper index
"What are the top AI chip demand trends for 2026?"
General Agent (HF)
Cross-cloud invocation to Hugging Face Spaces via AgentCore Gateway
The EDA agent is particularly interesting — it uses the Strands Graph pattern with a conditional revision loop (up to 3 iterations) for RTL design reviews. If the review identifies issues, it cycles back through analysis before escalating to a human approver.

Key Insight #1: Identity Propagation Is Non-Negotiable

The most common failure in multi-agent systems is identity collapse. Agent A authenticates as a service account, calls Agent B, which calls a tool — and the tool has no idea which human initiated the request.
We solved this with an  IdentityContext  dataclass that travels through every hop:
Python
@dataclass
class IdentityContext:
user_id: str
role: str # role_executive | role_manager | role_readonly
business_unit: str # finance | hr | eda | corporate
session_id: str
permitted_tools: List[str]
data_scope: str # all | business_unit | summary
This context is passed via Strands  invocation_state  — never exposed to the LLM's conversational context. The Gateway Interceptor checks it on every tool call. The tool Lambda checks it again independently. Two layers, neither trusts the other.
The result: An executive sees all financial records. A manager sees only their business unit. A read-only user gets aggregate counts. Same agent, same query, different data — enforced at the data layer, not the prompt layer.
Why this matters for Zero Trust in agentic AI: Most enterprise platforms filter at the API gateway — if you can call the endpoint, you get the full dataset. That's insufficient when agents make autonomous tool calls on behalf of users with different clearance levels. In EMP, the tool Lambda itself applies  apply_rbac_filter()  based on the caller's  data_scope . Even if the gateway interceptor is misconfigured or bypassed, the data layer independently enforces access boundaries. This is defense-in-depth applied to AI — the same principle that makes Zero Trust architectures resilient to single-point failures.
Here's what this looks like in practice. Same query, three roles, simultaneous execution:
Plain text
Query: "Show me the sensitive financial metrics — operating income,
EBITDA, and cash flow for Q1 FY26"

Executive (data_scope: all):
→ Returns: Full financial data with analyst summaries,
individual line items, YoY comparisons

Manager (data_scope: business_unit):
→ Returns: Only metrics for their assigned business unit,
no cross-BU visibility

Read-Only (data_scope: summary):
→ Returns: "3 financial metrics found for Q1 FY26"
(count only — no actual figures)
The LLM sees the same prompt in all three cases. The difference is what data the tools return based on the caller's role. The model can't hallucinate data it was never given.

Key Insight #2: Agent Versioning with Automatic Rollback

Production agents need the same deployment discipline as microservices. You wouldn't deploy a new API version to 100% of traffic without canary testing — why would you do it with an agent?
We added versioning directly to the agent registry:
Python
# Registry schema additions per agent
{
"agent_id": "finance_agent_v2",
"agent_name": "finance_agent",
"version": 2,
"traffic_weight": 10, # 10% of traffic
"is_canary": True,
"agent_arn": "arn:aws:bedrock-agentcore:..."
}
The orchestrator's canary router does weighted random selection across versions:
Python
def select_version(agent_name: str) -> dict:
versions = get_agent_versions(agent_name)
weighted = [(v, v["traffic_weight"]) for v in versions
if v["traffic_weight"] > 0]
# Weighted random pick
r = random.randint(1, sum(w for _, w in weighted))
cumulative = 0
for version, weight in weighted:
cumulative += weight
if r <= cumulative:
return version
Automatic rollback: If the canary version's composite evaluation score drops below 0.6 for 5 consecutive evaluations, traffic weight drops to zero and the stable version absorbs 100%. No human intervention required.
What happens during the 10% window? Users routed to the canary may receive lower-quality responses — but only 1 in 10 requests is affected, and the evaluation pipeline detects degradation within 5 invocations (typically under 2 minutes of active traffic). The moment rollback triggers, all traffic returns to the stable version. Users never see errors or data loss — just slightly worse answers for a brief, bounded window. This is the same trade-off every canary deployment makes: bounded blast radius in exchange for production validation that no staging environment can replicate.

Key Insight #3: Rogue Agent Detection via CloudTrail

Here's a scenario every enterprise will face: a developer deploys an agent outside the governed platform. It calls Bedrock directly, bypasses the gateway, and accesses data without RBAC filtering.
We detect this with a CloudTrail metric filter:
Python
# Matches API calls where the caller is NOT an AgentCore runtime
filter_pattern = FilterPattern.all(
FilterPattern.exists("$.userIdentity.arn"),
FilterPattern.string_value(
"$.userIdentity.arn", "!=", "*bedrock-agentcore*"
),
)
Alarm threshold: zero. Any single rogue call triggers an  Amazon SNS  notification. The UI shows a live comparison — compliant agent (full audit trail, RBAC enforced) vs. rogue agent (no governance, no filtering, no accountability).

Key Insight #4: Multi-Framework Without Vendor Lock-In

Enterprise customers won't standardize on one agent framework. Their ML team uses LangGraph. Their ops team built n8n workflows. Their platform team chose Strands.
EMP supports all three through the A2A (Agent-to-Agent) protocol:
Framework
Integration Pattern
Use Case
Strands
Native (Agents-as-Tools)
Finance, HR, EDA agents
LangGraph
A2A HTTP adapter
EDA design review (StateGraph)
n8n
Webhook adapter
HR onboarding workflow (6 steps)
External
Cross-cloud (HF Spaces)
General agent on Hugging Face
The cross-cloud agent on Hugging Face Spaces isn't a novelty — it demonstrates that AgentCore primitives (Memory, Gateway, Identity) work regardless of where your agent is hosted. Your agents can live on any platform and still use AgentCore for persistence, governance, and observability. That's the point: AgentCore is the control plane, not the hosting constraint.
The orchestrator doesn't care what framework runs behind the A2A endpoint. It sends a payload, gets a response, logs the hop. Framework choice becomes a team-level decision, not a platform constraint.

n8n Integration: On-Prem Workflow Engines

The n8n integration deserves special mention because it mirrors the most common enterprise deployment pattern — the workflow engine stays where the sensitive data is (ERP, HR systems, design tools), and AgentCore orchestrates from the cloud.
When a user says "Trigger the employee onboarding workflow," the orchestrator calls n8n via a secure webhook. n8n executes a 6-step DAG: validate employee data → create accounts → configure security → order hardware → schedule orientation → notify manager. Each step writes to DynamoDB — action log (audit trail), approval queue (for escalations), token attribution (cost tracking), and evaluation scores (quality assessment).
The agent doesn't execute the workflow — it delegates to the workflow engine and reports back. This separation of concerns means the agent can be updated without touching the workflow, and vice versa.

Key Insight #5: Observability Is Not Optional

Every operation in EMP is observable through  Amazon CloudWatch  GenAI Observability — no custom dashboards required.
Plain text
CloudWatch GenAI Dashboard shows:
├── Invocations — per agent, per round, with latency P50/P95
├── Memory — write and read events per memory ID
├── Latency — orchestrator is slowest (routing overhead)
├── Identity — workload identity requests per agent
└── Custom Metrics — EnterpriseAgentPlatform namespace
├── RogueAgentAPICallCount (alarm threshold: 0)
├── AgentInvocationCount (by agent_name)
└── TokenUsage (by model, by agent)
But the real observability story is the structured audit logging. Every identity-bearing operation emits a JSON log entry:
JSON
{
"event_type": "identity_audit",
"user_id": "exec_user",
"session_id": "sess-abc123",
"role": "role_executive",
"agent_name": "finance_agent",
"tool_name": "get_financial_metrics",
"action": "query",
"records_returned": 12,
"records_filtered": 0,
"timestamp": "2026-04-28T14:30:00Z"
}
And every agent-to-agent delegation emits a hop log:
JSON
{
"event": "agent_hop",
"source_agent": "orchestrator",
"target_agent": "finance_agent",
"latency_ms": 234,
"user_id": "exec_user",
"timestamp": "2026-04-28T14:30:00Z"
}
These logs answer the question every CISO asks: "Who accessed what data, through which agent, at what time?" Without them, a data breach investigation is impossible.

Key Insight #6: Persistent Memory Across Sessions

AgentCore Memory gives every agent a persistent memory that survives across sessions. The orchestrator loads memory at the start of each conversation and saves it at the end:
Python
# Load memory at conversation start
memory_events = ac.list_events(
memoryId=memory_id,
actorId="orchestrator",
sessionId=session_id,
maxResults=10
)

# Save memory after response
ac.create_event(
memoryId=memory_id,
sessionId=session_id,
actorId="orchestrator",
eventTimestamp=datetime.now(timezone.utc),
payload=[
{"conversational": {"role": "USER", "content": {"text": query}}},
{"conversational": {"role": "ASSISTANT", "content": {"text": response}}},
],
)
This means "last quarter's revenue" resolves correctly even in a new conversation — the agent remembers what "last quarter" meant in context. The cross-cloud agent on Hugging Face shares the same memory ID, proving that memory persistence works regardless of where the agent is hosted.

The Agent Lifecycle: From Birth to Retirement

Every agent in EMP goes through a governed lifecycle:
  1. QUALIFYING — Runs 4 qualification gates: property tests (≥0.95 pass rate), evaluation score (≥0.75), security scan, 48-hour pilot
  1. PILOT — Limited traffic via canary routing (10-20%)
  1. ACTIVE — Full production traffic
  1. UNDER_REVIEW — Flagged by drift detection or feedback loop; write tools blocked
  1. SUSPENDED — Credentials revoked, all tools blocked, requires two-approver reinstatement
  1. DECOMMISSIONED — Offboarded, removed from gateway
Behavioral drift detection: After 100 invocations establish a baseline, every 10th response is compared via cosine similarity. Drift score > 0.5 triggers a WARNING; drift > 0.7 triggers automatic quarantine — write permissions drop to read-only in real time.
Research basis: AgenticOps practices (InfoWorld, March 2026); NIST AI RMF MONITOR 2.2 (continuous monitoring of AI system behavior).

Agent Quality Assessment

Every agent response is scored on 4 dimensions in real time:
Dimension
Weight
What It Measures
Completeness
30%
Did the response fully address the query?
Groundedness
30%
Are claims backed by retrieved data (KB or DynamoDB)?
Task Success
25%
Did the agent achieve the user's stated goal?
Hallucination Risk
15% (inverted)
Lower is better — penalizes fabricated claims
Composite Score = 0.3 × completeness + 0.3 × groundedness + 0.25 × task_success + 0.15 × (1 - hallucination_risk)
Scores below 0.7 for 3 consecutive evaluations trigger an SNS alert. The quality chart in the UI shows the trend over time — you can visually spot degradation before it hits the threshold.
How we implemented it: A judge agent (Claude Sonnet 4.5) evaluates each response against the original query and the retrieved context. The evaluation runs asynchronously — it doesn't block the user response. Results are stored in a DynamoDB evaluation scores table with a GSI on  agent_id + timestamp  for efficient time-series queries.
Research basis: Andrew Ng's agentic evaluation patterns (2025); Gartner prediction that 40% of enterprise AI projects will require continuous evaluation by 2027.

Human-in-the-Loop Approval Queue

Not every agent action should execute autonomously. HIGH-risk operations (financial writes, credential changes, data deletions) pause mid-execution and wait for human approval.
Python
# In the gateway interceptor
if risk_tier == "HIGH" and action_type == "write":
# Create approval request in DynamoDB
table.put_item(Item={
"action_id": str(uuid4()),
"agent_id": agent_id,
"tool_name": tool_name,
"payload": json.dumps(tool_input),
"status": "PENDING",
"requested_by": identity_context.user_id,
"requested_at": datetime.now(timezone.utc).isoformat(),
})
return {"status": "PENDING_APPROVAL", "message": "Action requires human review"}
The UI shows pending approvals grouped by agent. A reviewer can approve (execution resumes), reject (action cancelled), or request modification. Every decision is logged with reviewer ID and timestamp.
Research basis: EU AI Act Article 14 (human oversight requirements for high-risk AI systems); NIST AI RMF GOVERN 1.7 (human oversight mechanisms).

Reversible Action Log

Every write operation in EMP captures before/after state — making any action reversible with one click.
JSON
{
"action_id": "act-7f3a2b",
"agent_id": "finance_agent",
"tool_name": "update_financial_metric",
"pre_state": {"metric_id": "rev-q4", "value": 2847000, "status": "draft"},
"post_state": {"metric_id": "rev-q4", "value": 3102000, "status": "published"},
"user_id": "exec_user",
"timestamp": "2026-04-28T14:30:00Z",
"rollback_available": true,
"status": "PENDING"
}
When a reviewer clicks "Rollback," the system executes the inverse operation — restoring  pre_state  — and logs the rollback as a new action entry. The audit trail is append-only; nothing is ever deleted.
Research basis: Broadcom "reversible autonomy" research (2025); NIST AI RMF MANAGE 2.4 (mechanisms to revert AI system actions).

Cost and Token Attribution

At 20,000+ agent scale, you need to know exactly where your AI spend is going. EMP tracks token usage per invocation with full attribution:
JSON
{
"attribution_id": "tok-9c4e1a",
"agent_id": "finance_agent",
"model_id": "claude-haiku-4.5 (via global on-demand inference profile)",
"input_tokens": 1247,
"output_tokens": 892,
"cost_usd": 0.0018,
"user_id": "exec_user",
"business_unit": "finance",
"timestamp": "2026-04-28T14:30:00Z"
}
The UI shows 4 cost views: by agent, by business unit, by user profile, and by model. This answers "which team is spending the most on AI?" and "should we move this agent from Sonnet to Haiku to save cost?"
Token pricing rates are stored in  AWS Systems Manager Parameter Store  — not hardcoded — so they update without redeployment when model pricing changes.
Research basis: FinOps Foundation AI Cost Framework (2025); enterprise customer requirement for chargeback at 20,000+ agent scale.

Context Compression

Long multi-turn conversations accumulate tokens fast. When context exceeds the threshold, EMP automatically compresses the conversation into a KnowledgeBlock:
Python
# Triggered when context > token_threshold
summary = compress_context(
conversation_history=full_history,
strategy="knowledge_block", # preserves key facts, preferences, entities
)
# Typical savings: 35-65% token reduction
The compression event is logged with tokens before/after and compression ratio. The UI shows a timeline of compression events per session — useful for debugging when an agent "forgets" something from early in a long conversation.

Agent Qualification Gates

No agent goes to production without passing 4 gates:
Gate
Criterion
What It Tests
Gate 1
Property tests ≥ 0.95 pass rate
Routing correctness, RBAC enforcement, lifecycle transitions
Gate 2
Evaluation score ≥ 0.75
Response quality across 20+ test queries
Gate 3
Security scan pass
Injection resistance, credential handling, data leakage
Gate 4
48-hour pilot stable
No drift, no errors, no approval queue overflows
The qualification workflow runs as a DAG — gates execute sequentially, and failure at any gate blocks progression. The UI shows live gate status during qualification.
Research basis: NIST AI RMF MANAGE 1.3 (pre-deployment testing requirements); enterprise customer verbatim: "ensure 5 things before production."

Privilege Quarantine

When a security engineer spots a misbehaving agent, they need a middle ground between "do nothing" and "shut it down." Quarantine provides that:
  1. Agent transitions to  UNDER_REVIEW  state
  1. Gateway permissions immediately override to read-only (within 5 seconds)
  1. Agent continues serving read queries — no business disruption
  1. Two-approver reinstatement review is required to restore write access
Quarantine can be triggered manually from the UI (from the Agent Registry or directly from an Action Log entry) or automatically by drift detection when drift score exceeds 0.7.
Research basis: NIST SP 800-61 (incident response — immediate containment); NIST SP 800-207 (Zero Trust — continuous re-evaluation, access reduction on anomalous behavior); NIST AI RMF RESPOND 1.1.

Structured Offboarding

When an agent reaches end-of-life, it goes through a 6-step offboarding workflow:
  1. Revoke credentials — ephemeral credentials invalidated
  1. Remove from gateway — tool access terminated
  1. Archive registry entry — marked DECOMMISSIONED with timestamp
  1. Export evidence package — compliance archive generated
  1. Notify stakeholders — SNS to agent owner and security team
  1. Clean up resources — memory, logs retained per retention policy
This mirrors the HR offboarding process for human employees — because agents ARE digital employees with the same governance requirements.
Research basis: Forbes "AI agents as digital employees" (2025); cydenti agent lifecycle research (2025); enterprise customer verbatim: "digital employee... offboarding."

Feedback Loop and Self-Improvement

Users rate agent responses (1-5 stars) with optional failure categories: incomplete, irrelevant, inaccurate, wrong tone. When negative feedback accumulates:
  1.  negative_count  increments per agent
  1. Threshold reached → agent becomes  FEEDBACK_CANDIDATE 
  1. System generates revised prompt based on failure patterns
  1. Revised prompt runs regression tests against historical queries
  1. If regression passes → deploy as canary (10% traffic)
  1. If regression fails 3x →  ESCALATED  (human intervention required)
  1. If fails 5x →  RETIREMENT_CANDIDATE 
This creates a closed loop: user feedback → automated improvement → validated deployment → monitoring. No human needs to manually rewrite prompts.
Research basis: Andrej Karpathy's autoresearch loop (2025); Andrew Ng's agentic self-reflection patterns (2025).

Compliance Evidence Export

One-click export generates a tamper-evident compliance package:
  • All audit logs for the selected time window
  • Agent registry state at time of export
  • Evaluation scores and drift history
  • Approval queue decisions with reviewer IDs
  • SHA-256 hash of the entire package for tamper detection
This is designed for SOC 2 Type II auditors, ITAR/EAR compliance officers, and ISO 27001 certification reviews. The auditor gets a single ZIP file that proves the complete chain of accountability — no manual log assembly required.
Research basis: SOC 2 Type II CC7.2 (system monitoring); EU AI Act Articles 12-13 (logging and transparency requirements).

What We Learned Building This

1. Defense-in-depth is worth the complexity. Two independent RBAC checks (gateway + tool) caught 3 bugs during development where one layer would have silently passed unauthorized requests.
2. Agent versioning pays for itself immediately. The first time we deployed a prompt change that degraded finance agent quality, the canary router caught it at 10% traffic and rolled back automatically. Without it, 100% of users would have seen degraded responses.
3. Rogue detection changes behavior. Once developers know unregistered agents trigger alerts, they voluntarily onboard through the platform. The governance system becomes self-reinforcing.
4. The audit trail is the compliance story. 19 DynamoDB tables capture structured audit logs for every identity-bearing operation — who accessed what data, through which agent, at what time, with what role. Hop-by-hop tracing across multi-agent chains produces a tamper-evident accountability record. For semiconductor companies operating under ITAR/EAR export controls, SOC 2 Type II, or ISO 27001, this audit chain is the difference between "interesting demo" and "we can actually deploy this in production."
5. The orchestrator is not a single point of failure. It's stateless by design — no local state between invocations. If it fails mid-request, the client retries with the same  session_id  and AgentCore Memory rehydrates the full conversation context. The orchestrator is replaceable infrastructure, not a bottleneck.
6. Memory persistence is table stakes. AgentCore Memory means the orchestrator remembers context across sessions — "last quarter's revenue" resolves correctly even in a new conversation because the agent remembers what "last quarter" meant in context.

Try It Yourself

The platform runs on standard AWS services — no custom hardware, no exotic dependencies:
  • Compute: Amazon Bedrock AgentCore (5 runtimes deployed via  agentcore launch )
  • Models: Claude Sonnet 4.5 (orchestrator), Claude Haiku 4.5 (sub-agents) — all via global on-demand inference profiles
  • Data: DynamoDB (19 tables, PAY_PER_REQUEST, KMS encrypted, 90-day TTL)
  • Knowledge Bases: 3 Bedrock Knowledge Bases (Finance, HR, EDA) backed by S3
  • Auth:  Amazon Cognito  (User Pool with 4 demo personas: Executive, Manager, Analyst, Read-Only)
  • Memory: AgentCore Memory (5 memory IDs — one per agent)
  • Observability: CloudWatch GenAI dashboard,  AWS X-Ray  active tracing, CloudTrail metric filters, SNS alerts
  • Gateway: AgentCore Gateway with Lambda interceptor (RBAC + lifecycle + injection detection)
  • UI: Flask with Jinja2 templates (8 tabs)
  • Local services: n8n workflow server, MCP paper index, local A2A agent
  • Cross-cloud: Hugging Face Space with AgentCore Memory + Gateway registration

Configuration Pattern

Nothing is hardcoded. All config lives in  AWS Systems Manager Parameter Store  under a project-specific prefix, with secrets in  AWS Secrets Manager . Lambda functions receive only two environment variables ( APP_REGION ,  SSM_PREFIX ) and fetch everything else at cold start — agent ARNs, KB IDs, memory IDs, pricing rates, and thresholds are all centralized and update without redeployment.



A Note on AgentCore Registry

Since we built this platform, Amazon Bedrock AgentCore has launched its own Registry primitive — a managed service for agent discovery, metadata storage, and lifecycle tracking. Several capabilities we custom-built in DynamoDB now have native equivalents:
Capability
What We Built (Custom)
What AgentCore Registry Provides Natively
Agent registration & metadata
DynamoDB table with  agent_id , owner, BU, risk tier, status
Managed registry with agent metadata, descriptions, and tags
Agent discovery
Custom discovery table + keyword routing
Semantic search across registered agents by capability
Lifecycle state tracking
Custom state machine (6 states) in DynamoDB
Built-in lifecycle states with transition rules
Version management
 version  +  traffic_weight  fields in registry
Native versioning with alias support
Cross-account visibility
Manual scan via CloudTrail
Federated registry across accounts and organizations
What we still needed to custom-build — governance logic that goes beyond what any single primitive provides today:
  • Behavioral drift detection — cosine similarity scoring against a baseline, with auto-quarantine triggers
  • Canary routing with automatic rollback — weighted traffic splitting with quality-gated rollback logic
  • Privilege quarantine — instant read-only override with two-approver reinstatement
  • Feedback loop → self-improvement — closed loop from user ratings to automated prompt revision and canary deployment
  • Compliance evidence export — tamper-evident ZIP with SHA-256 hash aggregating data from multiple sources for auditors
  • Agent qualification gates — multi-gate DAG (property tests + eval score + security scan + pilot) as a promotion workflow
The takeaway: if you're starting a new multi-agent project today, use AgentCore primitives as your foundation — they eliminate significant custom code. Then layer the governance logic (drift detection, quarantine, feedback loops, qualification DAGs) on top. The primitives give you the building blocks; the governance layer answers "should this agent be allowed to do this right now?"



What's Next: Migrating Custom Code to AgentCore Primitives

Several capabilities we custom-built are now available — or becoming available — as native AgentCore primitives. Here's our migration roadmap:
What We Built Custom
AgentCore Primitive to Migrate To
Status
Custom RBAC tool filtering ( TOOL_ROLE_MAP  in Lambda)
 AgentCore Gateway Policy 
— Cedar policies for tool-level authorization based on JWT claims
Available now
Custom DynamoDB agent registry
 AWS Agent Registry 
— managed catalog with semantic search, approval workflows, cross-account federation
Available now
Custom token tracking in DynamoDB
 AgentCore Observability 
— native CloudWatch metrics for token usage, cost allocation via tags, GenAI dashboard
Available now
CloudTrail metric filter for rogue detection
 Agent Registry approval workflows 
— preventive control (unregistered agents can't enter the catalog) + Gateway Policy denies unregistered callers
Available now
Custom quality assessment (judge agent)
 AgentCore Evaluation 
— built-in evaluation metrics and scoring
Evolving
Custom identity propagation code
 AgentCore Identity 
— workload identity with OAuth2/JWT, automatic token propagation across hops
Available now

Still Exploring

Beyond the migration, we're building toward:
  1. Automated prompt improvement — using the feedback loop to generate and A/B test prompt revisions without human intervention
  1. Cost-aware routing — factoring AgentCore Observability's native token metrics into the canary router's selection algorithm alongside quality scores
  1. LLM-managed Knowledge Base — replacing traditional RAG with Karpathy-style markdown files that the agent itself maintains, updates, and cross-references — a self-healing knowledge base that improves with every interaction
  1. AgentCore Registry migration — replacing our custom DynamoDB registry with the native Agent Registry primitive for all supported capabilities (metadata, discovery, lifecycle, versioning)
  1. EC2-hosted on-prem services — moving the local MCP server and n8n workflow engine from localhost to a dedicated EC2 instance for persistent availability
  1. Terminal-based demo mode — a rich CLI interface ( rich  library) for running the full demo from the command line — persona selection, query execution, RBAC comparison, trace visualization, and governance simulations with colored panels and tables. No browser needed.
  1. Cedar policy migration — replacing our custom  TOOL_ROLE_MAP  Lambda with AgentCore Gateway's native Policy engine for declarative, auditable access control



Complete Feature List

For reference, here's every capability implemented in EMP:
#
Feature
How It Works
1
Hierarchical multi-agent orchestration
Orchestrator routes to 7 sub-agents via keyword matching
2
Zero Trust Gateway with RBAC
Lambda interceptor checks role against TOOL_ROLE_MAP on every tool call
3
Identity propagation (end-to-end)
IdentityContext dataclass travels via  invocation_state  through every hop
4
Defense-in-depth (2 independent checks)
Gateway interceptor + tool Lambda both verify role independently
5
Agent lifecycle management (6 states)
QUALIFYING → PILOT → ACTIVE → UNDER_REVIEW → SUSPENDED → DECOMMISSIONED
6
Agent versioning + canary routing
Weighted random selection across versions; automatic rollback on quality drop
7
Behavioral drift detection
Cosine similarity every 10th invocation; auto-quarantine at threshold
8
Rogue agent detection
CloudTrail metric filter for non-AgentCore API calls; zero-threshold alarm
9
Quality assessment (4 dimensions)
Judge agent scores completeness, groundedness, task success, hallucination risk
10
Human-in-the-loop approval queue
HIGH-risk writes pause for human review; approve/reject/modify
11
Reversible action log
Before/after state for every write; one-click rollback
12
Cost and token attribution
Per-invocation tracking by agent, user, BU, model
13
Context compression
KnowledgeBlock summarization when context exceeds token threshold
14
Persistent memory (AgentCore Memory)
Session context survives across conversations; cross-cloud shared
15
Agent qualification gates (4 gates)
Property tests, eval score, security scan, 48h pilot
16
Privilege quarantine
Read-only override within 5 seconds; two-approver reinstatement
17
Structured offboarding (6 steps)
Credential revocation → gateway removal → archive → evidence → notify → cleanup
18
Feedback loop + self-improvement
User ratings → failure analysis → prompt revision → canary deploy
19
Compliance evidence export
One-click ZIP with SHA-256 hash for SOC 2/ITAR auditors
20
Multi-framework interop (Strands/LangGraph/n8n)
A2A protocol adapters; framework-agnostic orchestration
21
Cross-cloud agent hosting (HF Spaces)
AgentCore Memory + Gateway work with agents hosted outside AWS
22
On-prem workflow integration (n8n)
Webhook-based delegation to self-hosted workflow engines
23
Strands Graph pattern (EDA agent)
Conditional revision loop for RTL design reviews (≤3 iterations)
24
Structured audit logging
JSON logs for every identity-bearing operation
25
Hop-by-hop tracing
Every agent delegation logged with source, target, latency, user
26
CloudWatch GenAI Observability
Native dashboard — invocations, memory, latency, identity
27
X-Ray distributed tracing
Active tracing on every Lambda and Runtime
28
Injection detection
Gateway scans for instruction-override patterns in tool inputs
29
Credential TTL enforcement
Expired ephemeral credentials return 401
30
Cognito authentication
JWT-based auth with 4 demo personas
31
Portable infrastructure
Parameterized for any AWS account — no hardcoded values
32
Demo simulation (12 scenarios)
Baseline, drift, qualification, quarantine, rogue, HITL, canary, offboarding
33
Property-based testing (36+ properties)
pytest + hypothesis covering routing, RBAC, lifecycle, drift, compression



Research References

This platform was informed by the following research and standards:
Source
What We Used It For
 NIST NCCoE, "Accelerating Adoption of AI Agent Identity and Authorization" (Feb 2026) 
Identity propagation architecture, workload identity model
 Marro et al., "Authenticated Delegation and Authorized AI Agents" — arXiv:2501.09674 (ICML 2025) 
Delegation chain design, credential scoping
 IETF, "OAuth 2.0 Extension for Multi-AI Agent Collaboration" (2025) 
Token propagation patterns
 EU AI Act Articles 12-14 (August 2026) 
Logging, transparency, and human oversight requirements
 NIST AI RMF (GOVERN, MANAGE, MONITOR, RESPOND functions) 
Qualification gates, drift monitoring, incident response
 NIST SP 800-207 (Zero Trust Architecture) 
Defense-in-depth, continuous re-evaluation
 NIST SP 800-61 (Incident Response) 
Privilege quarantine as immediate containment
 AWS Well-Architected Reliability Pillar — Canary Deployments 
Agent versioning and traffic splitting
 Andrew Ng, "Agentic Design Patterns" (2025) 
Self-reflection, tool use, planning patterns
 Andrej Karpathy, "Autoresearch Loop" (2025) 
Feedback-driven self-improvement
Satya Nadella on Agent Provenance (2026)
Decision lineage and accountability
 MuleSoft Agent Fabric (2026) 
Federated agent discovery, cross-platform governance
 InfoWorld, "AgenticOps Practices" (March 2026) 
Behavioral drift detection, operational governance
 FinOps Foundation AI Cost Framework (2025) 
Token attribution and chargeback at scale
Broadcom "Reversible Autonomy" Research (2025)
Action log with rollback capability
 SOC 2 Type II CC7.2 
Compliance evidence export requirements
 Forbes, "AI Agents as Digital Employees" (2025) 
Lifecycle management, onboarding/offboarding


The Enterprise Multi-Agent Platform is an open reference implementation for AWS Solutions Architects working with enterprise customers who need governed, auditable AI agent systems. Built on Amazon Bedrock AgentCore, Strands Agents SDK, and standard AWS services.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.


Related Resources:
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article