Ship One Agent.
Govern a Thousand.
Amazon Bedrock AgentCore gives every team a secure, isolated runtime for AI agents. Lyzr is the git-driven deployment pipeline, cross-framework governance layer, and improvement loop that sits on top of it — so the tenth agent, the hundredth agent, and the agent your partner team built in LangGraph all move through one pipeline, one registry, one identity plane.
AgentCore is genuinely excellent. Here’s what changes once you’re past agent number five.
Amazon Bedrock AgentCore, GA since April 2026, is a deliberately unopinionated platform: strong isolated primitives that any team can build on however they choose. That flexibility is a feature — and it’s also exactly why a fast-growing agent program needs an operations layer on top of it.
What AgentCore gives every team natively
VERIFIED · GA UNLESS NOTED- AgentCore Runtime — each session runs in its own Firecracker microVM, isolated CPU/memory/filesystem, sessions up to 8 hours, memory sanitized at session end.
- AgentCore Memory, Identity & Gateway — short/long-term memory extraction, per-agent workload identity via IAM or Cognito JWT/OIDC, and a Gateway that turns Lambdas/OpenAPI specs into MCP-compatible tools.
- Code Interpreter & Browser — sandboxed execution and a managed headless browser tool, ready to call.
- Bedrock Guardrails + Policy — deterministic guardrails enforced at the gateway layer, outside agent code.
- Evaluations, Recommendations & A/B testing — 13 pre-built agent-quality evals, LLM-as-judge, and GA trace-based recommendations that work even on non-AgentCore runtimes. This is AWS’s strongest 2026 capability.
What starts to hurt past the first few agents
WHERE TEAMS BUILD THEIR OWN GLUE- One runtime per agent. In AgentCore’s multi-agent model, each specialized agent is its own independently deployed Runtime, versioned, monitored, and IAM-scoped on its own. At scale, that’s a fleet-management problem, not a platform.
- Cross-framework orchestration is DIY. AgentCore hosts any framework, but doesn’t visually coordinate a LangGraph agent, a CrewAI crew, and a custom agent as one governed workflow — that’s customer-authored code.
- No packaged, no-touch CI/CD. CDK constructs and the CLI enable GitOps, but a staged pipeline with an automatic pre-prod simulation gate, auto-PR-to-prod, and cloud-aware rollback is something your team assembles.
- Build friction for non-Bedrock teams. ARM64-only images add emulation time on x86 CI, and AgentCore is “primarily designed for Bedrock models” — other models need a framework layer.
- Governance stops at the AWS boundary. Guardrails, the (preview) Agent Registry, and CloudWatch are excellent inside AWS — but give no single plane if a team also runs agents elsewhere.
None of this is a shortfall in AgentCore — it’s a deliberately composable platform, built to be extended rather than to opinionate for you. That’s precisely the layer Lyzr adds.
One pipeline, every framework, running on your AgentCore.
Lyzr Deploy doesn’t replace anything in your AWS account. It’s the control plane that takes agents from any framework, walks them through a governed pipeline, and lands them on Bedrock AgentCore — consuming Bedrock models, IAM, ECR, and CloudWatch the entire way.
Build, Deploy, Govern, Refine — mapped directly onto what AgentCore already gives you.
Each pillar is scoped to close a specific, verifiable gap in the native AWS stack — not to duplicate what AgentCore already does well.
A way in for every team, not just Bedrock-fluent engineers
AgentCore is code-first by design. Lyzr adds the no-code layer without leaving Bedrock behind.
AgentCore Runtime, Memory, Gateway, Code Interpreter, Browser, and Knowledge Bases — powerful, but code-only, and primarily scoped to Bedrock models.
Agent Studio’s drag-and-drop canvas, 100+ prebuilt blueprints, and a model-agnostic layer — while still calling Bedrock models via PrivateLink and using AgentCore Memory as a bring-your-own-memory option.
Full technical detail
- Visual builder for single- and multi-agent orchestration (managerial, DAG, sequential patterns)
- SuperFlow — durable, exactly-once workflow engine with human-in-the-loop approval nodes
- Cognis Memory — cross-session, temporal-aware memory as the default provider
- Knowledge Base/RAG: Basic/MMR/HyDE retrieval; Qdrant, Weaviate, Milvus, PGVector; knowledge graphs via Neo4j or AWS Neptune
- Voice Agents (STT/LLM/TTS) with Telnyx/Twilio/Plivo telephony
- Model-agnostic model layer: OpenAI, Anthropic, Google, DeepSeek, and Bedrock models side by side
Stop managing a runtime per agent
This is the single biggest lever on AWS: collapsing runtime-per-agent sprawl into one governed pipeline.
AgentCore CLI and CDK constructs enable GitOps — agent-as-code, A/B testing, traffic splitting — but you assemble the promotion pipeline yourself, one agent at a time.
A full git-driven, no-touch pipeline: scan → build → push to ECR → deploy to AgentCore → CloudWatch health check → identity → simulation/eval gate → auto-PR to prod → cloud-aware rollback — with one Agent Registry spanning every framework.
Full technical detail
- Preset Configuration Bundles: tenant, repo URL, branch, security settings, integrations, RAI guardrails — versioned alongside code, redeploy in one click
- Environment Readiness Check before every deploy: VPC/security groups, IAM, ECR access, quotas, connectivity
- Automatic health check with auto-rollback and self-healing attempt on failure, plus stakeholder notification
- Version control via GitHub webhooks; rollback is a revert to the prior version tag
- Same agent, same version tag, redeploys to Vertex AI Agent Engine or Azure by switching target — no re-engineering
One governance plane, not one per team
AWS governance is strong — and scoped to AWS. Lyzr adds the plane that travels with the agent.
Bedrock Guardrails, the Policy engine, the Agent Registry (preview), CloudWatch, and IAM — genuinely strong, but bounded by the AWS account.
Embedded Responsible AI (prompt injection, toxicity, PII redaction, secrets detection, banned topics) that travels with the agent regardless of runtime, plus an IdP-agnostic Identity Broker so you’re not locked into Cognito.
Full technical detail
- Identity Broker supports OIDC (Entra ID, Google) and SAML 2.0 (Okta, ADFS) — not tied to any single IdP
- Platform-wide Audit Log covering every agent action, LLM call, and tool execution
- VPC-isolated reference architecture: segmented public/private-app/private-db subnets, PrivateLink to Bedrock and SageMaker, no public internet transit
- RBAC (Owner/Admin/Member) with role mapping from IdP attributes
- Agent Versioning with snapshot and rollback, independent of the deploy pipeline
Trace-driven improvement, reviewed before it ships
AWS Evaluations are genuinely strong here. Lyzr adds config-scoped depth and a human-reviewed hardening loop.
13 pre-built Evaluations, LLM-as-judge, and GA Recommendations + A/B testing that works even on non-AgentCore runtimes — AWS’s strongest capability heading into late 2026.
The Agent Improvement Engine scores 7 metrics auto-scoped to each agent’s config and produces an “Agent Hardening” diff a human reviews before pushing — plus a path to distill agents onto customer-owned models.
Full technical detail
- Metrics: Task Completion and Hallucination always on; Tool/Argument Correctness when tools are present; Contextual/Answer Relevancy and Knowledge Retention when a KB is present
- 0.00–1.00 scoring with Critical/Medium/Low severity, on configurable schedules
- Agent Hardening never pushes automatically — a human reviews the inline diff, and the prior config stays reversible
- ShadowLM Pre-GA — a path to fine-tune an agent off a frontier model onto a customer-owned open-weights model, hosted inside your AWS VPC via SageMaker or Trainium
The granular detail, for the person who has to vet this.
Everything below is verifiable against AWS documentation and Lyzr’s own technical collateral. Where something is preview, pre-GA, or a vendor-reported figure, it’s labeled as such — not asserted as fact.
AgentCore Runtime internals — what Lyzr deploys onto +
Each session on AgentCore Runtime runs inside its own Firecracker microVM — isolated CPU, memory, and filesystem — for sessions up to 8 hours. The microVM terminates and sanitizes memory at session end, which is strong per-session isolation for multi-tenant workloads. Runtime infrastructure is ARM64, so container images built for x86 CI need cross-compilation. A Stateful Runtime Environment persists state across invocations via session affinity, routing requests carrying the same session-ID header back to the same microVM.
Lyzr’s Deploy pipeline targets this runtime directly via ECR, IAM roles, and CloudWatch — the same primitives you’d use deploying manually, just orchestrated through a git-driven pipeline with a pre-prod simulation gate in front of it.
The full Lyzr Deploy pipeline, stage by stage +
- Stage 1 — Approval + readiness. Stakeholder approval, Preset Configuration Bundle applied, Environment Readiness Check (VPC/security groups, IAM, ECR access, quotas, connectivity).
- Stage 2 — Build. Git clone, static code analysis and security scan, version tag, container build, container scan, push to ECR.
- Stage 3 — Non-prod deploy. Deploy to AgentCore non-prod, automatic health check; on failure, auto-rollback plus a self-healing attempt and error logging.
- Stage 4 — Identity. Registration in the Non-Prod Agent Registry with a non-prod identity issued through the Identity Broker.
- Stage 5 — Simulation & Evaluation gate. RAI scans, hallucination checks, relevance/correctness scoring. Pass → auto-PR to the prod branch. Fail → full cloud-aware cleanup of AgentCore runtimes, ECR images, IAM roles, registry entries, and identities, with logged and analyzed errors and recommended fixes.
- Stage 6 — Prod deploy. On PR merge: webhook-triggered prod deploy with the preset bundle, health check, production registry entry, production identity, and stakeholder notification. Prod failure triggers auto-rollback to the previous version, logs, and an alert.
Multi-agent orchestration: AgentCore’s five patterns vs. one registry +
AgentCore supports five multi-agent patterns (A2A, Supervisor+Sub-agent, direct boto3 invocation, Skill System, Voice Mode). In every pattern, each specialized agent is deployed as its own independent AgentCore Runtime, and coordination across them is the customer’s responsibility. Lyzr’s Agent Registry sits above this: one catalog spanning LangGraph, CrewAI, Strands, and Lyzr-native agents, with discovery by team, function, department, or use case, and full version lineage across both environments. MCP and A2A connectors let foreign agents register into the same registry without Lyzr having built them.
Identity: IAM/Cognito vs. the Lyzr Identity Broker +
AgentCore Identity issues distinct workload identities per agent, with inbound auth via IAM (SigV4) or JWT/OIDC through Cognito, and outbound OAuth 2.0/API-key auth for third-party services. Lyzr’s Identity Broker is IdP-agnostic by design — OIDC for Entra ID and Google, SAML 2.0 for Okta and ADFS — with role mapping from IdP attributes, so a customer isn’t required to route agent identity through Cognito specifically. This matters most for enterprises whose workforce identity already lives outside AWS.
Observability: CloudWatch GenAI Observability vs. Lyzr traces +
AgentCore Observability is OpenTelemetry-based, emitting session count, latency, duration, token usage, and error rate to CloudWatch under the bedrock-agentcore namespace, surfaced in the CloudWatch GenAI Observability dashboard AgentCore tab: Preview. It requires a one-time CloudWatch Transaction Search enablement, and Runtime-hosted agents are auto-instrumented while non-Runtime agents need the ADOT SDK. Lyzr’s Traces & Monitoring layer runs alongside this with per-run traces, latency/token/model metadata, and an analytics dashboard that spans agents regardless of which runtime or framework they’re on — feeding directly into the Agent Improvement Engine.
Compliance — verified certificates, not marketing claims +
ISO/IEC 27001:2022 — certified by Gradient Certification Inc., registration GCI/IS/202501002, issued 30 January 2025, valid through 30 January 2027. Scope covers the Lyzr Agent Framework and Lyzr Agent Studio SaaS, and applies to both Lyzr, Inc. (Jersey City, NJ) and Lyzr AI India Private Limited (Bengaluru).
GDPR — assessed as Satisfactory by Accorp Partners CPA LLC. Lyzr is positioned mainly as a data processor in customer relationships, with controller obligations remaining with the customer.
Deployment options: Lyzr Cloud (SaaS), Private VPC with PrivateLink into your AWS account, or full on-premise/air-gapped — agents never run on shared Lyzr infrastructure by default.
AWS’s Evaluations, Recommendations, and GA A/B testing are a real continuous-improvement loop, and Lyzr doesn’t try to replace them. The Refine pillar layers config-scoped scoring and a human-reviewed hardening step on top of that same trace data — so the improvement loop keeps working even as an agent moves across AgentCore, Foundry, or Vertex.
An honest checklist, not a sales gate.
Lyzr on top of AgentCore earns its place at a specific point in an agent program’s growth. Here’s how to tell if you’re there.
You’re running, or planning to run, 20+ agents in production on AgentCore.
More than one team or framework is involved — LangGraph, CrewAI, Strands, or custom, built by different teams.
You need one governance and audit plane across teams building independently, not one per team.
You want the same pipeline to also reach Vertex AI or Azure later, without re-platforming.
Your identity provider isn’t Cognito, or you don’t want agent identity routed through it exclusively.
That’s the easiest time to put a governed pipeline in place — before runtime-per-agent sprawl becomes a fleet-management problem. Lyzr runs alongside AgentCore from agent one, so there’s no re-platforming later.
Most teams that get to this page are already planning past their first few agents. We’ll show you what the pipeline looks like before you need it.
The math that changes as agent count grows.
Running five agents by hand on AgentCore is entirely reasonable. Running fifty the same way means fifty independently versioned runtimes, fifty IAM scopes, and fifty places an incident can hide. The cost of that model doesn’t grow with the number of agents — it grows faster.
- 01Engineering hours saved by not building and maintaining a bespoke CI/CD pipeline per team.
- 02Reduced incident response time from one unified trace and audit view, instead of stitching CloudWatch across teams.
- 03Avoided cost of ungoverned agent sprawl — the agents nobody remembers are running, still holding IAM roles and Bedrock spend.
- 04No re-platforming cost if the estate later needs to reach Vertex AI or Azure — same pipeline, different target.
Illustrative, not a guarantee — actual savings depend on agent count, team structure, and current pipeline maturity. Ask us for a walkthrough against your own numbers.
What solution architects and buyers usually ask first.
Does Lyzr replace Bedrock Guardrails or AgentCore Identity?+
Does our AWS spend still count the same way?+
We’re only on AgentCore today, one framework, one team. Do we need this yet?+
How long does it take to get our first agent through the pipeline?+
Is Lyzr Deploy open source?+
See your agents running through one pipeline.
Bring your current AgentCore setup, or your first agent still in a notebook. Either way, we’ll show the pipeline running against a real deploy target, not a slide.