Agentic SDLC: How a Network of Specialist Agents Preserves Context Across Software Delivery

In an MVP built for a Guidewire insurance platform, a connected network of specialist agents cut the delivery time for one requirement from a week to a matter of hours, largely by eliminating handoffs between teams rather than by automating code generation alone.

Key Takeaways

• Enterprises are adopting AI Co-Pilots team by team, but context rarely flows between them, so requirements, decisions, and artifacts still get manually re-explained at every handoff.
• Cognizant AI Lab built an Agentic SDLC on Cognizant Neuro® San: one orchestrator and ten specialist agent networks covering user stories, design, code, unit testing, underwriting rules, CI/CD, test design, UI testing, and observability.
• In an MVP for a Guidewire insurance platform, the network reduced delivery time for one specific change from a week to a matter of hours. The gain came mostly from removing handoffs, not from automating code generation alone.
• Existing tools stayed in place. Jira, Confluence, Jenkins, and the Guidewire implementation itself were unchanged; the agents coordinate around them rather than replacing them.
• Every write action, creating a Jira ticket, publishing a Confluence page, editing code, triggering a deployment, or raising a defect, waits for explicit human approval.
• Neuro San's Agent Network Designer lets any team generate a starting Agentic SDLC network from a plain-language description of their own workflow.

It's hard to deny the importance of a structured, disciplined software development (or delivery) life cycle in producing high-quality software. Organizations that consistently ship reliable software tend to be the ones that invest in well-defined requirements, systems design, rigorous testing, and sustainable code. These practices reduce technical debt, improve quality, and make systems easier to evolve, but that discipline comes at the cost of a longer delivery cycle.

At the same time, software delivery teams are under real pressure to move faster, and engineering organizations are expected to ship features at unprecedented speed. The challenge is no longer choosing between speed and quality. It's finding a way to get both at once.

AI has become a powerful accelerator across many SDLC stages, particularly software development itself. But enterprise adoption of AI has mostly been fragmented rather than systemic. Individual teams adopt AI co-pilots for their own tasks, and those tools rarely share context across teams, which leaves the overall delivery process just as fragmented as before.

For example, developers might use Claude Code to help with implementation while the QA team uses a separate Copilot to generate test cases. Each team benefits locally, but the business context rarely flows automatically between them. Requirements get copied by hand from one tool to another, decisions get re-explained, and these repeated handoffs introduce delay, duplicate effort, and cognitive load for teams already working under tight deadlines.

What if AI could unify these stages instead of just accelerating each one on its own?

Rather than treating AI as a collection of isolated assistants, we explored whether the entire SDLC could be orchestrated as a connected network of collaborative agents, an Agentic SDLC, where business context flows in natural language from one delivery persona to the next while staying intact.

We built exactly that for one of our insurance clients. The goal was not to replace existing engineering processes and tools, but to eliminate the manual effort between them. The MVP involved a modification to a complex Guidewire submission page, and the connected agent network reduced the overall delivery time for that specific change, from requirements through testing, from a week to a matter of hours. The exact benefit depends on the complexity of the requirement, the existing tooling, and data quality, among other factors, but the largest gains came from eliminating handoffs rather than from automating code generation on its own.

Turning the SDLC Into a Connected Network of Agents

To understand the opportunity, it helps to look at the SDLC process as it exists today. At a high level, the business workflow consists of the following steps:

1. Create the Jira user story for the requirement.
2. Create the design document for that user story in Confluence.
3. Assigned developers work on the user story.
4. DevOps deploys the code to the required environment.
5. The QA team creates a test design workbook and manually collects evidence.
6. Analysts monitor for errors in the logs.

None of these activities is inherently inefficient. They represent well-established engineering practice found across many enterprises. The inefficiency shows up in the transitions between them, where context has to be recreated, re-validated, or manually carried from one team to the next.

The client's core platform is Guidewire, a market-leading insurance platform used to build and customize insurance products. Guidewire implementations typically involve multiple specialized artifacts, including business rules, configuration, integrations, and UI customizations, which makes preserving context across delivery stages especially important.

To address this, we built a solution using Cognizant's Neuro® San, an open-source multi-agent framework designed to make developing agents simple through a data-driven approach. Rather than building one monolithic agent responsible for every SDLC stage, Neuro San let us build multiple specialized, collaborative agents that work together while remaining independently maintainable.

Using Neuro San, we created a multi-agent network called the Guidewire SDLC Orchestrator. The orchestrator receives a user's request in natural language and autonomously delegates it to one of several specialized agent networks (see Figure 1), each responsible for a specific SDLC capability. This lets each specialized network optimize for its own domain while maintaining a consistent flow of context across the broader delivery cycle.

Different reasoning tasks also benefit from different language models. The specialist agents draw on a combination of Anthropic's Claude Sonnet 4.6 and OpenAI's GPT-5.2, depending on the nature of the task, balancing code generation, document authoring, structured reasoning, and workflow orchestration to use whichever model performs best for that job. That also helped us optimize our overall token budget.

Figure 1. The orchestrator and its ten specialists. Every persona talks to the same front man, which reads the request and routes it to the specialist that owns it. Each specialist shown here is an agent network of its own.

Each of these subagents is a full agent network in its own right, not a single agent. The Design Document subagent, for example, contains its own coordinator, a retriever that fetches the approved story from Jira, an author that writes the technical design, and a publisher that creates the Confluence page. Each component has its own responsibilities, instructions, and tools.

This hierarchical architecture intentionally keeps individual agent networks manageable, focused, and easier to reason about. That modular structure brings a few concrete advantages: individual stages can evolve independently, be maintained more easily, and be replaced without disrupting the rest of the workflow, while governance policies can be enforced consistently at the coordinator level. The result is a system that scales by composing specialized agent teams rather than by continually growing the complexity of a single orchestration layer.

Figure 2. One subagent opened up. The Design Document network has its own front man, its own agents, and its own tools. The orchestrator above it only ever talks to the coordinator. MCP stands for Model Context Protocol.

One Requirement, End to End

Before looking at each SDLC stage individually, it's useful to follow one requirement as it travels through the entire delivery pipeline.

Take the requirement introduced earlier: capture a driver's age on a motor insurance submission, and automatically refer the quote to an underwriter whenever the driver is under 25.

In a traditional SDLC, this requirement would pass through a business analyst, a developer, a DevOps engineer, a QA engineer, and a support analyst. Each persona performs a different task, often in a different system, with work progressing asynchronously from one queue to the next.

In an Agentic SDLC, these roles stay exactly the same. Human expertise, ownership, and approval remain intact. What changes is how information flows between them. Instead of repeatedly translating a requirement into a new artifact at every stage, each stage builds directly on the artifact the previous stage produced, so business context stays intact throughout the delivery lifecycle.

The business analyst starts by describing the requirement in plain English. The SDLC orchestrator delegates it to the User Story subagent, which works with the analyst to draft a Jira story with acceptance criteria. The analyst reviews and approves the generated story, and the conversation continues from there. Without switching applications or copying requirements by hand, the analyst simply asks the SDLC orchestrator to prepare the design document.

The Design Document subagent retrieves the approved story directly from Jira, then generates a design document covering the required UI changes, data updates, and business rules, and submits it for human review before publishing it to Confluence.

Notice that no business context has to be rewritten. The design document is grounded directly in the approved Jira story, rather than in a manually reconstructed interpretation of it.

The developer opens their own conversation and starts from the approved story rather than a fresh description of the requirement, for example: “Add an age field to the PolicyCenter submission page. Read KAN-42 for more context.”

The Code Editor subagent retrieves both the Jira story and its associated design document, then grounds itself in the existing Guidewire codebase. Rather than generating code in isolation, it first analyzes the relevant implementation, proposes a structured change plan, and presents that plan for approval before making any changes.

Similarly, the Unit Test subagent generates and runs the required unit tests, and the Underwriter Rules subagent generates the Guidewire rules package that can then be imported into Guidewire PolicyCenter. Although several specialist agents are involved, the developer experiences all of it as one continuous conversation.

DevOps, or the developer, next requests a build and deployment. The CI/CD subagent triggers the appropriate pipeline, waits for the outcome, and reports the result back into the conversation. If the build succeeds, the workflow continues naturally. If it fails, the SDLC orchestrator returns the build logs directly into the current conversation, which removes the need to open a new ticket. Since the developer already has the context and the logs, troubleshooting starts from a shared understanding instead of from scratch.

The QA or test engineer begins the test workstream once deployment is complete, referencing only the Jira user story. The Test Design subagent pulls the approved story and its Confluence design document, then generates the test design workbook in the prescribed format, so the acceptance criteria and business rules stay consistent with the original intent.

From there, the test engineer asks the SDLC orchestrator to execute a specific test case. The UI Test subagent retrieves the selected case from the workbook, generates the corresponding Playwright automation, runs it against the live Guidewire PolicyCenter instance, and captures screenshots as evidence. Instead of manually navigating PolicyCenter and collecting screenshots one at a time, the test engineer reviews the generated evidence while remaining responsible for validating the final outcome.

The support analyst, weeks after deployment, notices unexpected behavior in production. The Observability subagent retrieves the relevant logs, analyzes the data, produces a root-cause explanation, and creates the Jira defect ticket, tracing the issue back to its originating story where possible. As with every earlier stage, the defect is only created after explicit human approval, keeping governance consistent across the whole workflow.

One important point: none of the engineering roles disappear. Every engineer still works in their own workstream, with their own tools. The value comes from removing unnecessary reconstruction of information, not from removing human expertise.

• The design document originates from the approved Jira story.
• The QA test workbook originates from the approved design document.
• The automated browser test originates from the approved workbook.
• The defect originates directly from the observability analysis.

Each artifact becomes the input to the next agent in the SDLC, creating a continuous, traceable, and auditable chain of context across the whole cycle. Most importantly, nothing is written automatically without explicit consent from the engineer. Every action passes through a human in the loop before execution, and that balance between automation and governance is essential to software delivery.

Just as important, the client kept using Jira, kept using Confluence, kept the Guidewire implementation unchanged, kept the test engineers on the same workbook format, kept Jenkins running the CI/CD pipelines, and kept the existing logging and observability infrastructure in place. Agentic orchestration introduces a coordination layer rather than replacing existing infrastructure. By preserving the investment already made in tools and platforms while eliminating repetitive work between engineers, organizations can improve delivery efficiency without disrupting practices that already work.

Figure 3. Who asks for what. Every role keeps its own conversation and its own tools. The orchestrator is the one entry point they share, and the artifacts carry context from one role to the next.

Seven Architectural Principles From Building This MVP

A few principles emerged from building this MVP that are less about the framework itself and more about the design decisions that determined whether the solution would scale or just look impressive in a demo.

1. Let the artifacts carry the context: It's tempting to solve context continuity by passing ever-larger prompts between agents. A more durable approach is to have each stage read the approved artifact the previous stage produced. The design document reads the Jira story, the test workbook reads the design document, and the browser test reads the workbook. The artifacts already exist, the teams already trust them, and they provide an auditable chain of decisions. Anyone can later ask why a particular test case exists and trace it back to the requirement.
2. Prefer lifecycle tools with open connectors and APIs: Agents are only as useful as the systems they can reach. Jira and Confluence were accessible through the Model Context Protocol, and Jenkins through its REST API, so those stages needed very little custom work. Where an open interface didn't exist, we wrote a small, purpose-built tool instead. In practice, the effort required to agentify a stage has less to do with how much reasoning is involved than with how reachable its system of record already is, which is worth assessing before committing to a delivery plan.
3. Gate every write behind human approval: A useful distinction is between reading and writing. Agents should read broadly and without ceremony, but every action that changes something outside the conversation should wait for an explicit human decision. That includes creating a Jira ticket, publishing a Confluence page, editing code, triggering a deployment, and raising a defect. Just as important is when the approval is requested: the Code Editor subagent presents a structured change plan before touching the codebase, because reviewing an intention is considerably cheaper than reviewing and reverting a change.
4. Build modular, specialized agent networks rather than one large one: A single network holding every connector becomes hard to maintain, and more practically, hard for the model to reason about, since the instructions grow long and the choice of tool becomes ambiguous. Ten focused networks, each with its own coordinator, instructions, and tools, can be understood, tested, and updated independently. This also turns model selection into a configuration decision rather than an architectural one, letting each specialist use the model best suited to its task.
5. Give deterministic work to deterministic code: Not every step in an SDLC benefits from reasoning. Editing a Guidewire configuration file, assembling a rules package, polling a build until it completes, or capturing a screenshot are all tasks with one correct outcome. We implemented these as conventional code invoked by the agents, and reserved the language models for interpretation, authoring, and orchestration, which kept the unpredictable parts of the system confined to the places where flexibility actually pays off.
6. Keep the change non-invasive: The best automation is almost invisible to the people using it. The clearest signal of success in our MVP was that no team had to abandon a tool: Jira, Confluence, Jenkins, the test workbook format, and the Guidewire implementation itself all stayed exactly as they were. If an engineer has to leave their established workflow to use the agents, they'll eventually stop using the agents.
7. Design for the organization you have: Tooling, governance requirements, artifact formats, and working culture differ meaningfully between enterprises, and an Agentic SDLC that ignores those differences will be resisted regardless of its technical merit. The architecture described here transfers readily: an orchestrator, specialized networks, artifact-based context, and approval gates. The specifics shouldn't be inherited wholesale. Treat the agent networks as configuration to adapt to your environment, not a fixed product to install.

Where This Goes Next

The MVP shows that an Agentic SDLC can preserve context across the software delivery lifecycle while integrating with existing enterprise tooling. A few areas remain open for further exploration:

1. Adaptive delegation: The orchestration could be extended using the AAOSA protocol, where specialist agents dynamically claim all or part of a request, letting compound or complex requests be decomposed and coordinated across multiple agent networks.
2. Exception and recovery paths: Today, when a build fails or generated code doesn't compile, control returns to the engineer. A bounded repair loop could instead feed the log back to the agent that made the change, letting it iteratively propose fixes while still requiring human approval before each subsequent attempt.
3. Responsible AI and governance: Enterprise adoption requires governance that goes beyond conversational approvals. Future iterations could maintain a persistent audit trail of approvals, decisions, and actions taken by agents, to strengthen compliance, traceability, and auditability.

Build Your Own Agentic SDLC With Neuro San

If you're interested in building an Agentic SDLC for your own organization, try Neuro San's Agent Network Designer, a multi-agent system builder built into Neuro San that takes a high-level description of a use case and generates a custom agent network to support it.

Try the prompt below in the Agent Network Designer and see how quickly you can put together your own Agentic SDLC. Adjust it to fit your own workflow.

Create an Agentic SDLC network for a Guidewire PolicyCenter team.

Use one SDLC Orchestrator to receive requests and route them to specialist agents:

• User Story: Create Jira stories and acceptance criteria.
• Design: Create Confluence design documents from approved stories.
• Development: Review the story, design, and codebase; propose and make code changes.
• Unit Test: Create and run unit tests.
• Underwriting Rules: Create Guidewire rules packages.
• CI/CD: Trigger and monitor Jenkins builds and deployments.
• Test Design: Create test workbooks.
• UI Test: Run Playwright tests and capture evidence.
• Observability: Analyze logs and prepare Jira defects.

Keep Jira, Confluence, Guidewire, Jenkins, Playwright, and logging tools as the existing systems.

Pass context between agents through approved artifacts such as stories, designs, code, test cases, build logs, and production findings.

Ask for human approval before making any external change, such as updating Jira or Confluence, changing code, deploying, or creating a defect.

The Guidewire MVP is one instance of a pattern that generalizes well beyond insurance or Guidewire specifically. Any organization running a disciplined SDLC across multiple tools and multiple teams has the same underlying opportunity: let the artifacts carry the context, keep a human approving every write, and let specialized agents handle the translation work between stages instead of the people doing it by hand. The technology to build that already exists today. What's left is mostly a design decision: which stages to connect first, and how closely the resulting network should mirror the way your teams already work.