For the last two years most teams have treated AI as a better autocomplete. A developer still reads the ticket, designs the solution, writes the code, runs the tests, fixes the bugs, updates the docs and pushes the release. AI made each of those steps faster. It did not change who was doing them.
An agentic SDLC is a different shape. Specialized agents participate across the lifecycle with defined responsibilities, scoped permissions, shared memory and feedback loops. Engineers move from performing every step to setting intent, reviewing output and governing the system that produces it.
This is not a forecast. It is how AI-native teams, ours included, are starting to ship.
What an agentic SDLC actually is
A working definition: a delivery model where autonomous and semi-autonomous agents execute defined parts of the software lifecycle under human supervision. The loop is simple to state and hard to run well.
- A human sets the intent and the definition of done.
- Agents do the work inside scoped permissions.
- Humans approve the decisions that carry real risk.
- Agents continue execution from that approval.
- Telemetry from production feeds the next iteration.
Think of it as a delivery pipeline staffed by specialists that happen to be software.
Traditional SDLC vs agentic SDLC
| Stage | Traditional | Agentic |
|---|---|---|
| Requirements | An analyst writes the stories | A requirements agent drafts them from meetings, docs and tickets |
| Architecture | An architect produces the design | An architecture agent proposes options with trade-offs |
| Development | Developers write every line | Coding agents implement scoped tasks |
| Testing | QA writes the tests | Test agents generate, run and triage them |
| Security | Periodic review | A security agent scans continuously |
| Documentation | Usually late | A documentation agent updates as the code changes |
| Deployment | DevOps runs the pipeline | A release agent prepares and validates the promotion |
| Operations | Manual triage | An ops agent correlates logs, traces and incidents |
The shift is continuous machine participation across the lifecycle rather than isolated AI usage inside one step.
The agentic delivery loop
Each transition can be owned by a different agent: a planner decomposes the work, a coder implements it, a reviewer checks it against standards, a test agent validates behaviour, a security agent enforces policy, a release agent promotes the build, an observability agent reads production signals, and an optimization agent proposes the next change. The system carries context between iterations instead of starting every task from a blank prompt.
What it looks like on one feature
Add SSO for enterprise customers using Microsoft Entra ID.
In a traditional flow that request becomes a run of meetings, tickets, implementation tasks, QA cycles and a documentation backlog item nobody gets to. In an agentic flow most of it runs in parallel.
- Requirements agent: extracts acceptance criteria, identifies the affected services, generates the edge cases people forget.
- Architecture agent: proposes the OIDC flow, produces the sequence diagram, flags the tenant isolation question early.
- Coding agent: opens the branch, adds the authentication handlers, updates configuration.
- Test agent: writes unit, integration and negative tests, runs the suite, reports failures with root cause hints.
- Security agent: checks token validation and redirect URI handling, looks for exposed secrets.
- Documentation agent: updates the setup guide, adds the admin onboarding steps, drafts the release notes.
- Human reviewer: reviews the architecture and the final diff, and approves the deployment.
The elapsed time drops because the sequence collapses, not because anyone skipped a step.
The four layers
Intent layer
Where business goals enter the system: meeting transcripts, product requirements, tickets, support conversations, analytics. If intent arrives vague, everything downstream inherits the vagueness.
Context layer
The memory of the delivery system: the codebase, architecture docs, API contracts, runbooks, security policy, coding standards and past incidents. This is the layer teams underinvest in, and it is the one that decides whether agents produce work you can merge. Without it, they guess.
Execution layer
Specialized agents doing the work with scoped permissions: a read-only architecture agent, a write-enabled coding agent, a deployment agent that can reach staging and nothing further.
Governance layer
Approval gates, audit trails, role-based access, compliance checks, cost controls and rollback policy. Most failed AI programmes skipped this layer and had to retrofit it under pressure.
What changes for the team
- Developers stop writing every line and start defining intent, refining specs, reviewing diffs, owning the genuinely hard logic and correcting the agents that got it wrong.
- Architects spend their time on standards, reusable patterns, guardrails and system boundaries, because those are now inputs to the machine.
- QA moves up a level: test strategy, quality policy, simulation and failure injection rather than writing cases by hand.
- Engineering managers manage throughput, agent effectiveness, governance, risk and the cost of automation.
The organisation becomes AI-amplified, not AI-replaced. The judgement stays with people; the typing does not.
The metrics that matter
Story points stop meaning much when a large share of the output is machine-generated. Measure the system instead.
| Metric | What it tells you |
|---|---|
| Lead time to production | Whether the loop is actually faster end to end |
| Human review time | The cognitive load the model is placing on your engineers |
| Agent acceptance rate | The quality of autonomous work before a human touches it |
| Defect escape rate | Whether speed is costing you production quality |
| Deployment frequency | Delivery cadence |
| Mean time to recovery | Operational responsiveness when it goes wrong |
| Cost per shipped change | The economics, including inference and retries |
How it fails
- “We gave an AI access to the repo.” Access is not architecture. Agents need scoped responsibilities and a defined handoff.
- “The AI wrote bad code.” Usually a context problem: no standards, no patterns, no memory of how this system is meant to be built.
- “Security blocked everything.” Governance was added after the automation instead of before it.
- “The team stopped understanding the system.” Review discipline and ownership were quietly dropped.
- “Costs exploded.” Unbounded execution and silent retries, with nothing measuring cost per change.
Agentic delivery succeeds through engineering rigour, not enthusiasm. Every failure mode above is a control someone chose not to build.
A minimal adoption path
Do not attempt full autonomy in week one. Earn each phase with the results of the last.
- Phase 1, assisted: code generation, test generation, documentation drafts. Humans still drive every step.
- Phase 2, coordinated: a planning agent, a review agent, and a test agent wired into CI.
- Phase 3, governed automation: automated pull requests, security policy enforcement, release preparation behind approval gates.
- Phase 4, adaptive delivery: production feedback loops, automated optimization proposals, continuous backlog refinement.
Most teams can reach phase two in weeks. The constraint is rarely the models. It is context, standards and the willingness to instrument what you are doing.
The stack we see emerging
- An orchestration layer that routes work to the right agent.
- A sandbox for code execution, isolated from anything that matters.
- A context store holding the codebase, contracts and decisions.
- A policy engine that can say no.
- CI/CD integration, because agent output has to travel the same road as human output.
- An observability platform that closes the loop from production back to intent.
- A human approval workflow with real teeth.
- An audit and telemetry store for everything the agents did and why.
The architectures that survive are vendor-agnostic and composable. Models will keep changing underneath you; the delivery system should not have to.
Where the return shows up first
Highest leverage where feedback cycles are fast and the blast radius is contained: internal business applications, workflow automation, API-heavy products, SaaS feature delivery, modernisation work, test automation programmes and documentation-heavy systems.
Lower leverage to begin with: safety-critical systems, real-time embedded software, regulated core transaction engines and novel research algorithms. Start where a mistake is cheap and the signal comes back quickly.
Our view
The question stopped being whether AI can write code. The better one is how you design a delivery system where people and agents keep improving each other, iteration after iteration.
The advantage will not come from picking one model. It comes from the system around it: shared context, specialized agents, real governance and measurable outcomes. That is what we build for ourselves and for the teams we work with.
If you are thinking about introducing agents into your delivery process, start with one workflow that is repetitive, measurable and low risk. Instrument it end to end, add governance before you add autonomy, and scale only once the feedback loop is working.
