Kiro writes the code.
Lyzr runs the business.
A straight, architecture-level answer to a fair question: if AWS Bedrock and Kiro can generate the code for an agent, what does a platform like Lyzr actually add? Here it is, laid out layer by layer — grounded in what each tool is actually built to do, not in how it looks in a demo.
If Kiro can generate the code, what's left to build?
Kiro is AWS's agentic coding IDE. It turns a prompt into structured requirements, a design document, and a task list before it writes a line of code — including code for an AI agent.
Inside a demo, that can look like it covers everything a platform such as Lyzr does. It doesn't — not because Kiro is a weak tool, but because it was built to solve a different problem.
What Kiro is built for
Helping a developer write software — turning intent into requirements, design, and code, faster and more reliably than most IDEs on the market.
What Kiro was never designed for
- Running an insurance carrier's agent workforce in production
- Keeping every decision auditable to IRDAI and DPDP
- Getting measurably better after every real customer interaction
Kiro helps a developer write software. Running that software as a governed, improving agent workforce is a platform's job — not an IDE's.
What each piece actually is — and where it stops
All three are real and useful. The confusion comes from stacking them on top of each other instead of side by side.
AWS Bedrock + AgentCore
- Foundation models (Claude, Nova, and others) via a managed API
- AgentCore Runtime — isolated, per-session compute for hosting an agent once it's built
- AgentCore Memory, Identity, Gateway and Guardrails — strong, genuinely useful building blocks
Kiro
- AWS's agentic coding IDE, CLI and web interface — successor to Amazon Q Developer
- Spec-driven: prompt → requirements.md → design.md → tasks.md → code
- Agent Hooks and Steering files keep a developer's own codebase consistent
Lyzr
- Agent Studio, SuperFlow orchestration, and 100+ prebuilt blueprints to build
- Git-driven Control Plane — scan → simulate/evaluate → deploy → auto-rollback
- SRS guardrails, four-eyes Decision Inbox, and a full audit trail to govern
What Kiro genuinely is
- A spec-driven agentic IDE, CLI, and web interface, built on Amazon Bedrock
- The tool AWS now directs all new coding-assistant users to, in place of Amazon Q Developer
- A real step up from simple autocomplete tools for teams shipping production code
- Genuinely useful for hand-writing a custom tool, connector, or one-off script
What Kiro is not
- A runtime that hosts or executes an agent once it's built — that's AgentCore's job
- A multi-agent orchestration engine — no workflow DAGs, no manager/sub-agent patterns
- A CI/CD pipeline for shipping agents to production, with a simulation or eval gate
- A compliance layer — no PII redaction, audit trail, or IRDAI/DPDP-aligned controls for what an agent does live
None of this is a knock on Kiro — it's a strong tool for exactly what it's built to do. It simply isn't built to do what Lyzr does, and Lyzr isn't built to be an IDE. That's precisely why the two sit together well.
One architecture. Two ways to fill the middle.
Everything below sits inside Mahindra Manulife's own AWS account either way. The only thing that changes between the two paths is what fills the layer between "code that runs" and "the infrastructure it runs on." Both diagrams below, one after the other.
AWS Bedrock + Kiro alone
- Multi-agent / multi-step orchestration logic — hand-coded
- A deployment pipeline with a simulation or eval gate — hand-assembled
- PII redaction, toxicity and prompt-injection controls — hand-built
- An audit trail regulators will accept — hand-built
- Bilingual voice + document IDP pipeline — hand-built and tuned
- Continuous improvement from live production traces — hand-built, if built at all
Someone still has to build this layer — one custom integration, one point tool, one compliance review at a time. That work doesn't show up in a demo, but it doesn't disappear either.
AWS Bedrock + Kiro + Lyzr
- Multi-agent / multi-step orchestration logic — hand-coded
- A deployment pipeline with a simulation or eval gate — hand-assembled
- PII redaction, toxicity and prompt-injection controls — hand-built
- An audit trail regulators will accept — hand-built
- Bilingual voice + document IDP pipeline — hand-built and tuned
- Continuous improvement from live production traces — hand-built, if built at all
This is what already exists on Lyzr today — running on the same AWS account, the same Bedrock models, the same AgentCore runtime.
Digital Onboarding, Underwriting & Risk, Organisational Intelligence
These three use cases are already designed, not hypothetical. Underwriting & Risk is the most detailed, so it's the clearest test of the difference — step by step.
| Underwriting & risk — step | Hand-built on Kiro + Bedrock alone | Native on Lyzr |
|---|---|---|
| 1. Proposal worklist | Custom queue and case-state logic, written and tested | SuperFlow DAG — configure, don't build |
| 2. Onboarding (branched eKYC) | Custom branching logic plus a hand-wired KYC vendor integration | Pre-built KYC connector and branching pattern |
| 3. Medical evidence (voice + bilingual IDP) | Custom speech-to-text/text-to-speech plus a document-extraction pipeline, built and tuned | Native bilingual voice agent + document IDP capability |
| 4. Underwriting (rating engine) | Custom integration code to the deterministic rating engine | Pre-built tools framework — connect credentials, not code |
| 5. Decision inbox (write-back) | Custom review UI, four-eyes approval logic, and audit logging | Native Decision Inbox with confidence scoring and a built-in audit trail |
Digital Customer Onboarding
Reuses the same branched eKYC pattern, bilingual IDP, and guardrail layer built for underwriting — not a separate build from zero.
Organisational Intelligence
Reuses the same audit trail and data layer every agent already writes to. Size-of-prize, book evolution, and portfolio risk views compound automatically as more agents go live — no new integration work per view.
It isn't AWS vs. Lyzr. It's one platform vs. fifteen tools.
Without a platform layer, the components above the AWS infrastructure line still have to exist — they just get assembled one vendor at a time, each with its own contract and its own security review.
Lyzr, running on Bedrock and AgentCore inside your VPC — build, deploy, govern, and improve every use case on the same platform, not a new stack each time.
Governance that answers to IRDAI, not just to an IDE admin console
Kiro and Lyzr both use the word "governance." They don't mean the same thing.
Kiro's governance
- IAM / SSO login control — who can open the IDE
- Usage dashboards and credit-based cost controls
- IP indemnity for AI-generated code
Lyzr's governance
- SRS guardrails — PII redaction, toxicity, prompt-injection defence
- Four-eyes Decision Inbox for underwriting sign-off
- Audit trail logged to the hundredth of a second
- IRDAI- and DPDP-aligned controls, full data residency inside your AWS India VPC via PrivateLink to Bedrock
Only one of these will hold up in a regulatory review of a live underwriting decision.
This is AWS, made productive faster — not AWS instead of Lyzr
Lyzr consumes Bedrock as its model layer and deploys onto AgentCore as a runtime target. Every token, every compute-hour, every gigabyte of storage stays on the AWS bill. Lyzr's Control Plane deploys agents onto AWS infrastructure — ECS Fargate, PrivateLink to Bedrock and SageMaker — inside your own account. A faster, better-governed path to production means more of this estate gets built on AWS, not less.
Straight answers
Doesn't adding Lyzr mean paying for two things?
No. Lyzr sits inside your AWS account and uses Bedrock as its model layer — it doesn't replace AWS spend, it makes it productive faster. Lyzr's platform fee sits alongside your AWS bill the same way a CI/CD tool sits alongside a cloud bill, rather than replacing it.
Can our engineers keep using Kiro if we choose Lyzr?
Yes. Lyzr's Agent Framework is open and framework-agnostic — a custom tool or connector hand-written in Kiro plugs straight in. Kiro remains a fine place to write that code; Lyzr is where it gets orchestrated, deployed, and governed.
What does Lyzr add if AgentCore already exists?
AgentCore is the runtime engine. Lyzr is the platform layer above it: orchestration across multi-step and multi-agent flows, a deployment pipeline with a simulation/eval gate, guardrails and an audit trail, and continuous improvement based on live production traces. Different layer, same foundation.
Is this just Lyzr protecting its own position in the deal?
Ask it a different way: would Kiro alone get all three scoped use cases — Digital Onboarding, Underwriting & Risk, Organisational Intelligence — into production, governed, and IRDAI-compliant, without anyone first hand-building an orchestration layer, a guardrail layer, and an audit trail? If the honest answer is no, that gap needs to be filled by something. This is what filling it with a purpose-built platform looks like, instead of custom code maintained in-house indefinitely.
Build the same step twice, and let the outcome speak
Words are one way to make this case. A working comparison is a better one. A short technical session — Accenture, AWS, and Lyzr solution architects in the room — can build the same underwriting step once on Kiro + Bedrock alone, and once on Lyzr + Bedrock. Same use case, same AWS account, two paths, side by side.