Reinventing software delivery with AI-SDLC on Amazon Bedrock AgentCore

This post is co-written with Sajin Jacob, Kate Stukalenko, Ashish Tripathi, Jerry Chen, and Aashish Giri.

Software development teams have largely standardized on agile delivery with well-defined stages: requirements, grooming, development, QA, and code review. At each stage there is repetitive, predictable work such as clarifying requirements, writing acceptance criteria, breaking down tickets, building test plans, and reviewing pull requests. AI coding assistants have changed the development stage. The remaining four still run on manual effort, handoffs, and tribal knowledge.

Verisk partnered with AWS to build an AI-driven software development lifecycle (AI-SDLC). AI-SDLC is a system of specialized AI agents that work across every stage of software delivery. The agents connect to Verisk’s existing enterprise toolchain and run on Amazon Bedrock and Amazon Bedrock AgentCore. In this post, we walk through the AI-SDLC architecture pattern and how Verisk deployed it in a regulated insurance environment. We cover agent design, enterprise tool integration, design principles, organizational adoption, and measured outcomes.

Verisk is a leading strategic data analytics and technology partner to the global insurance industry. Operating across the insurance value chain, from underwriting and risk assessment to claims management, fraud detection, and catastrophe modeling, Verisk has helped property and casualty insurers make smarter decisions about risk for more than 50 years.

Note: For a reference implementation with code samples covering the AI-SDLC pattern, see AI-driven development lifecycle using Amazon Bedrock AgentCore.

Embedding AI across the full delivery lifecycle

For most engineering teams, AI assistance stops at coding. The other four stages stay manual or semi-automated. This can create inefficiencies across:

• Requirements: Tickets are authored manually, often with incomplete acceptance criteria requiring multiple rounds of clarification.
• Grooming: Breaking features into implementation tasks consumed hours of sprint planning, with inconsistent output quality across teams.
• QA: Engineers spent 3–4 hours writing test plans per feature and 1–2 days setting up automation.
• Code review: Review depth and consistency varied depending on reviewer availability and familiarity with the codebase.

The cumulative effect can be a delivery cycle measured in weeks to months, with quality checks applied inconsistently and context lost at every handoff.

Verisk’s engineering leadership asked whether AI agents could handle the generation work at every stage, with engineers governing decisions rather than producing first drafts.

The answer wasn’t to add more AI tools to an unchanged process. Instead, Verisk redesigned the workflow so AI drives the generation work at every stage and humans govern the decisions.

Solution overview

The solution has five stage-specific agents: Requirements, Grooming, Developer, Code Review, and QA. Each has a specific scope, a defined trigger, and a human review checkpoint before its output advances. Rather than relying on a central orchestrator to manage the full lifecycle, Verisk designed each agent to be independently deployable, testable, and refinable.

Figure 1: AI-SDLC architecture at Verisk, where stage-specific agents receive workflow events from enterprise tools, retrieve context from knowledge sources, perform reasoning using foundation models through Amazon Bedrock, and write outputs back to enterprise systems, with human review checkpoints gating every stage transition

AWS services and frameworks:

• Amazon Bedrock AgentCore: Hosts and runs all five agents with secure MCP gateway access, session management, memory, observability, and managed infrastructure.
• Claude Code on Amazon Bedrock: Powers the Developer Agent for end-to-end ticket implementation, reading coding standards, breaking down tasks, and generating code across full stack layers.
• LangGraph / Strands Agents: Open source agent frameworks for multi-step, stateful workflows within each agent.

Architecture deep dive

Four layers connect Verisk’s existing toolchain to the AI agent capabilities.

Enterprise tooling layer

Agents read from and write to the systems Verisk’s teams use daily: Jira for requirements and workflow state, a code repository for source control and pull requests, Confluence for documentation, and a code quality tool for security and quality analysis. Jira ticket state transitions serve as triggers for agent invocation, and agent outputs are written back into the appropriate system.

Verisk built an Atlassian Forge UI integration that presents agent capabilities directly within Jira’s interface. Engineers interact with agents from the same environment where they manage tickets and track workflow state. No new tool to learn, no context switch required.

Integration layer (MCP)

Tool integrations use the Model Context Protocol (MCP), managed through MCP Gateway. MCP provides standardized interfaces that agents use to discover and invoke tools (Jira reader/writer, code repository reader/writer, API spec reader, documentation reader) without requiring custom integration code per agent.

This separation between agent reasoning logic and tool implementation matters: new integrations can be added without modifying agent code, and tool access is centrally managed and secured. When Verisk adds a new tool to their workflow, it becomes available to all agents through a single MCP registration.

AI agent layer (Amazon Bedrock AgentCore)

Each agent is hosted on Amazon Bedrock AgentCore, with session management and scaling handled automatically. Key infrastructure components:

• AgentCore runtime, a capability of Amazon Bedrock AgentCore: Serverless hosting for each agent, no infrastructure to manage.
• AgentCore memory, a capability of Amazon Bedrock AgentCore: Maintains context across invocations so agents can hold conversational interactions (used by the Requirements Agent for iterative refinement with product owners).
• AgentCore Observability, a capability of Amazon Bedrock AgentCore: Tracing, logging, and monitoring for every agent invocation, giving teams visibility into what each agent did and why.

Knowledge and context layer

Agent output quality depends directly on the context provided at invocation time. That context is drawn from four sources: Jira tickets (descriptions and attachments), repository code and conventions, API specs and internal documentation stored as markdown files, and artifacts produced by upstream agents. This context lives directly within the systems the team already uses, namely Jira and versioned markdown files, rather than a separate store. Agents read from and write back to the same sources of record. Quality is maintained through an active feedback loop. A grooming agent reviews each incoming ticket, flags gaps or ambiguities as open questions, and resolves them through a conversational chat with the relevant stakeholder. Answers are written back into the ticket or documentation, so the source of record stays current. This is the mechanism behind progressive context enrichment: each stage’s clarified output becomes richer input for the next, compounding quality improvements across the lifecycle.

How the workflow operates at Verisk

The lifecycle follows three phases. Each stage has a defined trigger, defined inputs, defined outputs, and a mandatory human checkpoint.

1. Planning

Requirements improvement: When a product owner creates or updates a Jira ticket, the Requirements Agent analyzes the description and proposes concrete improvements: missing acceptance criteria, ambiguous language, edge cases, and clarifications. The agent supports conversational memory, allowing product owners to refine requirements through iterative dialogue rather than a single interaction. Human in the loop: The product owner reviews and approves suggestions before the ticket advances.

Technical grooming: After requirements are approved, the Grooming Agent analyzes the ticket alongside repository structure and API specifications, then generates an implementation plan: subtasks, story point estimates, dependency mapping, and a generated technical specification file (spec.md). This gives developers a concrete starting point. Human in the loop: The development team validates the technical approach during grooming.

2. Construction

Developer implementation: The Developer Agent is used by developers to implement tickets using Claude Code with Amazon Bedrock, reading coding standards from Verisk’s documentation, breaking down tickets into tasks, and generating code across full stack layers. It references existing repository patterns to maintain consistency. Human in the loop: Developers review, modify, and commit the code. The agent assists but doesn’t make the final decision.

Code review: When a pull request is created in the code repository, the Code Review Agent analyzes the diff in context of the specification, code analysis and project standards. Feedback is categorized by severity (Critical, Major, Minor) and integrated with code quality tool findings to create a comprehensive quality gate. Human in the loop: Developers review each comment and decide whether to address them. They retain the final approval authority.

3. Quality

QA test planning (Step 1): The QA Agent generates test plans mapped directly to acceptance criteria, covering happy-path scenarios, negative cases, boundary conditions, and integration behaviors. Human in the loop: QA engineers review and approve the plan before automation begins.

Automation generation (Step 2): After QA approval and pull request merge, the QA Agent produces automation artifacts: collections for Bruno, an open-source API client, and Apache JMeter plans for performance and functional testing. This two-step design with a human-in-the-loop gate between planning and automation helps make sure that generated tests are built on validated logic rather than raw requirements. Human in the loop: Generated artifacts are committed to the testing repository for review by QA engineers.

Design principles and lessons learned

Stage independence over orchestration

Each agent operates independently with a well-defined contract: trigger, inputs, output format. Verisk deliberately chose not to use a lifecycle-wide orchestrator, because lifecycle stages are separated by time, different personas, and human decisions that cannot be predicted. Independent agents are simpler to build, test, and maintain. When one agent’s prompts need refinement, the change is isolated.

Progressive context enrichment

The quality of each agent’s output depends on the quality of its input, and this relationship compounds. When the Requirements Agent produces complete acceptance criteria, the Grooming Agent generates a specification carrying those validated requirements forward alongside repository context. The QA Agent then draws on both the specification and the criteria to produce test cases traceable to specific requirements. Those cases cover edge conditions such as boundary values and missing input validation, without the need to cross-reference documents by hand.

Each human checkpoint validates and enriches the artifact before it flows downstream, adding domain knowledge that AI cannot access alone. The result is that downstream agents operate with richer, more accurate context than any single stage could produce independently.

Human-in-the-loop as architecture, not limitation

AI agents propose. Humans decide. Every stage includes a mandatory review checkpoint. This helps prevent error cascades. For example, an uncorrected ambiguity in requirements can compound into flawed specifications, incorrect code, and inadequate tests. Checkpoints also enrich context: product owners add domain knowledge, developers apply architectural judgment, and QA engineers bring edge-case awareness from production incidents.

In a regulated industry like insurance, these checkpoints serve a dual purpose. Beyond maintaining engineering quality, they create the auditable decision trail that regulatory frameworks, such as Sarbanes-Oxley (SOX) compliance and state insurance oversight, require for software changes that affect policy pricing, claims adjudication, or risk models. This architecture makes governance a natural byproduct of the workflow rather than a separate compliance exercise.

Augment existing tools. Don’t replace them

Agents operate within Verisk’s existing Jira, code repository, Confluence, and code quality tool workflows. Engineers don’t need to learn new tools. This reduced adoption friction and showed results without a months-long transformation program.

It’s about people and process, not only technology

Beyond the technical architecture, Verisk’s experience revealed that the organizational implications of AI-SDLC are as significant as the engineering decisions. Discussions about AI-SDLC tend to open with AI agents, models, and frameworks, but in practice, technology is only a small part of the transformation. The real challenge is rethinking how people work together and how software delivery operates.

That starts with examining established ways of working and questioning long-held assumptions: Is the current Scrum cadence still optimal when development accelerates? Should backlog refinement, demos, and feedback happen more frequently to keep AI-assisted teams productive?

It also means rethinking roles, encouraging engineers to become more T-shaped in their skills (deep expertise in one discipline paired with working breadth across others) and capable of delivering features end-to-end, which cuts down on handoffs and reduces bottlenecks. Alongside this, Verisk redefines success through a new set of metrics that measure not only speed but also developer productivity, AI infrastructure costs, engineering quality, and where AI delivers the greatest return on investment.

Above all, successful adoption depends on people. AI agents should not be introduced as a replacement for engineers, but as a powerful new tool that amplifies their capabilities. Building trust, encouraging experimentation, and helping teams embrace new ways of working matter just as much as the technology itself. Ultimately, AI-SDLC succeeds not because organizations deploy AI, but because they evolve their people, processes, and culture to work effectively alongside it.

Measured outcomes

Verisk’s implementation produced measurable improvements across the development lifecycle:

These gains were measured on features developed end to end through the AI-SDLC system, with five agents operating across Verisk’s enterprise development toolchain. Across the complete end-to-end flow, agent output reached an acceptance rate exceeding 90 percent (outputs accepted by human reviewers with minimal modification), against an original target of 50–60 percent.

Verisk’s engineering teams are targeting one-week release cycles with quality checks embedded at every stage.

Customer perspective

The impact of AI-SDLC extends beyond Verisk’s own engineering teams to the insurance carriers they serve. As carriers increasingly build agentic underwriting workflows, they need partner data products exposed as MCP servers they can integrate directly into their own AI systems. Verisk now meets that need through the same agentic pipeline it uses to build software. It recently made its trusted insurance analytics available directly within Anthropic’s Claude through standardized MCP connectors. New MCP solutions for Core Lines insurance products move through requirements, grooming, development, review, and QA under the same governed, auditable process. As a result, Verisk can deliver these capabilities faster and fold continuous customer feedback into product improvements at a pace that was not possible before. This keeps pace with the modernization demands of the insurance customers who depend on their data.

Verisk’s leadership sees this same shift from the inside.

“This is not a proof of concept or a hypothesis. It is a fundamental reimagination of the software development lifecycle through AI agents. The transformation extends beyond how we build software, the tools we use, the processes we follow, and the roles we play. It requires a transformation in mindset. For decades, software development has operated under the constraints of time, talent, and scope, forcing difficult tradeoffs at every step. AI agents are removing many of those constraints. We are no longer simply building software faster; we are building it faster, with higher quality, and with continuous validation and governance embedded throughout the lifecycle.”

— Sid Mohanram, SVP of Core Lines Technology, Verisk

“We are no longer just programmers; we are designers, architects, and governors of systems powered by AI agents. Our responsibility is no longer limited to writing code. It’s about providing the context, guardrails, and judgment that enable agents to deliver high-quality outcomes at scale. As AI removes many of the traditional constraints of software development, we’re spending more time partnering with the business, challenging old assumptions, and reimagining how ideas move from concept to production. The opportunity isn’t simply to build software faster; it’s to fundamentally transform how we innovate, collaborate, and create value.”

— Luis Barbier, CTO, SVP of Underwriting, Verisk

Conclusion

In this post, we introduced the AI-SDLC architecture pattern and walked through Verisk’s implementation: five stage-specific agents integrated into their enterprise toolchain through MCP, producing well-defined artifacts at every stage, under human governance at every critical decision point.

The core architectural insight: agents scoped to individual lifecycle stages, connected to the tools teams already use, producing artifacts that compound in quality as they flow downstream, with human checkpoints that help prevent error propagation. Verisk’s results show this in practice.

To move beyond isolated coding assistants toward adopting AI across the full lifecycle, start with one agent at a high-value stage, connect it to existing tools, add human checkpoints, and expand as results compound. Verisk’s implementation is tailored to insurance engineering, where regulatory governance demands an auditable decision trail. However, the AI-SDLC pattern adapts to any team practicing agile delivery. For insurers and the partners who serve them, that governed speed reaches the underwriting, claims, and risk products their customers depend on. Governance and auditability are built in, so carriers can keep pace with a fast-moving market.

To get started building AI agents on AWS, explore the following resources:

• Amazon Bedrock AgentCore documentation
• Guidance for Multi-agent orchestration on AWS
• Model Context Protocol (MCP) with Amazon Bedrock AgentCore
• Evolving software delivery for agentic AI — AWS Prescriptive Guidance

About the authors