An agentic software development lifecycle, or agentic SDLC, is a way of developing software where you work with a team of agents that performs the work across the lifecycle. Agents shape requirements, propose designs, implement changes, review code, verify behavior and prepare release work. They share relevant context, pass work and findings to each other, and work toward the same accepted outcome. People steer the work and retain accountability for scope, quality and authorized release decisions.
You give the team a feature request. It should carry the work through the stages that change needs, return for corrections when something fails, and bring back evidence or a decision that needs your judgment.
In my essay on the path to autonomous software factories, I described an agent team sitting alongside your engineering team. Some responsibilities can run with little intervention. Others need an engineer, product owner or architect to challenge a proposal or make the final call. The level of autonomy can be different at each stage.
What does each agent do?
The software development lifecycle still includes understanding the problem, deciding what to build, designing it, implementing it and checking the result. In an agentic workflow, specialist agents perform that work with defined responsibilities and outputs.
| Stage | Work the agent performs | What the accountable human owner steers or decides |
|---|---|---|
| Requirements | Clarifies the request, identifies ambiguity and drafts scope and acceptance criteria | Whether the behavior solves the right problem and which tradeoffs are acceptable |
| Architecture and design | Identifies affected systems, contracts, dependencies and design options | Boundaries, compatibility and material architecture decisions |
| Planning | Breaks the agreed approach into tasks, owners, dependencies and checks | Scope, sequencing and unresolved assumptions |
| Implementation | Changes code, adds relevant tests and returns the revisions and known gaps | Clarifications and exceptions that change the agreed scope |
| Code review | Examines the implementation, records actionable findings and checks corrections | Disputed findings and whether the review standard is met |
| QA and verification | Runs the affected behavior in a sandbox, captures failures and reruns after fixes | Whether the evidence covers the accepted behavior and remaining risks |
| Release work | Prepares deployment order, compatibility checks, smoke checks and rollback steps, and executes only authorized actions | Release approval, operational risk and authority to change production |
| Learning | Proposes reusable facts, skill changes or workflow improvements from run evidence | Which proposals should enter the shared setup after evaluation |
These are responsibilities to cover. They do not require eight separate services or every stage on every change. Your workflow can combine roles or use a shorter path where appropriate. Give each stage a clear output and an accountable owner so work does not fall between agents.
How does the agent team work on one feature?
Consider an illustrative request to let workspace admins invite members. Viewers must not be able to invite through either the UI or the API.
The requirements agent makes those rules explicit and identifies the expected failure behavior. The design agent checks the API authorization path, UI, invitation record and background email worker. The implementation agent makes the change using the accepted rules and contracts.
The reviewer finds that the API checks whether the requester is logged in but does not check the workspace role. That finding goes back to implementation with the affected revision and failure scenario.
After the fix, QA tries the direct API request as a viewer, checks that no invitation or email job was created, and confirms that the admin path still works. If QA finds another failure, the finding goes back for another correction. The relevant checks run again against the corrected revision.
Feature request
-> Requirements -> Design -> Plan
-> Implementation <-> Code review
-> Sandbox verification <-> Correction and rerun
-> Reviewer evidence and authorized release work
-> Reviewed learning
Shared context and scoped governance support the whole run.
Human owners can steer the work and approve material decisions.The tools should close that loop. A human should not have to copy the same finding into another chat, reconstruct the context and remember to ask for a rerun. The system needs to preserve the finding, route it to the right owner and connect its resolution to evidence.
If the agents cannot resolve the issue, the run should stop with a clear blocker and the attempts already made. Repeated agent agreement does not prove the feature is correct. The accepted behavior and independently checkable evidence are the standard.
What connects the agents?
Shared context gives the agents the applicable business rules, architecture, contracts and accepted decisions. Keep the sources and revisions visible. An implementation summary is useful, but it cannot be the only statement of what review and QA should expect.
The orchestration layer manages the handoffs. It tracks who owns the work, what inputs are required, which dependencies are ready and whether an approval is needed before the next task starts. It also preserves the correction history when work goes back to an earlier stage.
The verification layer gives agents an environment where they can run the application and inspect behavior. A generated test plan is useful preparation. It is not evidence that the change was tested.
Governance scopes each agent's tools, repository and environment access, operating limits and approvals. Shared context does not grant every agent every permission. Learning proposes improvements to the shared knowledge and operating setup, with review and evaluation before they become defaults.
The software factory implementation guide explains how to build these supporting components. They are what let specialist agents work as one delivery system.
Where do people stay in control?
An architect may decide that the proposed design solves a scale problem the company does not need to solve yet. A product owner may change a requirement before implementation starts. A verification owner may find that the evidence does not cover a critical permission case.
The workflow should let that person inspect the work, give feedback and redirect the responsible agent. Where approval is required, record it against the artifact revision. A material revision may need a new decision before downstream work continues.
Human control also means being able to pause a run, inspect its tools and evidence, change its allowed scope or stop it. Those controls need to exist in the operating system around the agents.
For a small, bounded fix, the team can configure a short implementation, review and verification path. A cross-system feature may need requirements and design approval before implementation fans out. A team can also call an individual agent to review or verify an existing PR.
The workflow fits the change. Autonomy grows where the team has evidence that the responsibility is being handled well.
What should the team receive back?
For a reviewer-ready PR, expect the accepted behavior, affected components, code revisions, checks that actually ran, results and unresolved gaps. A review finding should have a resolution or an explicit owner decision. Verification should identify the revision and environment it checked.
A sandbox pass does not mean production deployment is complete. Merge permissions, rollout decisions, production checks and observation remain governed work in their own right.
Judge the system by the work still required from your team. How much time went into clarifying, coordinating, repairing the environment, reviewing and correcting? Did the run reduce that effort while meeting the quality bar?
The real-change evaluation scorecard gives you a way to assess that on a representative change. Start with a request your team can evaluate, then inspect what each agent did and what the human reviewer still needs to resolve.