Coding agents can write the change. Your engineer still explains the requirement, passes context between sessions, reads the review findings, asks for a fix and tells QA to try again. The code arrived faster. A person is still moving the work through delivery.
An agentic software development lifecycle, or agentic SDLC, puts a team of agents to work across delivery stages and changes who carries that work forward. Agents take on defined responsibilities, and the system connects their inputs, findings, corrections and verification. People steer the work and own the decisions that require judgment. Start with one bounded workflow and expand its authority when the evidence supports it.
The lifecycle still needs requirements, design, implementation, review, testing and release decisions. The transition changes how those responsibilities are executed and coordinated. It does not make them disappear.
Start with the work your team keeps doing between agents
Take one recent change. Record where someone had to explain the same business rule again, copy a finding into another session, repair the environment or check which revision QA actually tested.
Choose one repeatable problem with a clear result. It could be investigating a failing check, fixing a contained bug or verifying an existing PR. A workflow spanning several repositories needs more coordination than a documentation correction. Company size alone does not tell you which path to use.
Use your current workflow as the baseline. Include setup, steering, review, failed attempts and rework. Counting generated PRs will not tell you whether the team has less work to do.
Give the workflow shared inputs and an accountable owner
Before connecting several agents, define what each one receives and returns. Implementation needs accepted behavior and the affected contracts. Review needs the code revision, relevant rules and a way to record unresolved findings. QA needs those expectations plus a runnable environment and appropriate test data.
Keep a named human owner for the outcome and for decisions that need approval. An agent can perform a stage without having authority to settle every product or architecture question it encounters.
The control plane should retain the requirement revision, agent and skill versions, work state, findings and evidence. A teammate should be able to join the run and understand what happened without reconstructing several private chats. Share relevant context within permissions rather than giving every agent every conversation.
Ready to connect the next stage when a teammate can identify the accepted behavior, current owner, active revision and unresolved decision from the run itself.
Make the tools close the correction loop
Consider an illustrative pilot for investigating a failing CI check. Start by asking an agent to inspect the failure and return a proposed cause with the relevant logs, code revision and uncertainty. Keep the workflow read-only while you assess whether its findings are useful.
If investigation is dependable on the cases your team evaluates, authorize a bounded correction on an isolated branch. The review agent checks the fix, and QA reproduces the original failure and reruns the relevant checks against the new revision. Preserve the evidence for the reviewer instead of stopping at a plausible explanation.
Now introduce a failure outside the agent's authority, such as missing access to a required test dependency. The workflow should identify the blocker, preserve its state and route the access decision to the owner. It should not expand its own permissions or quietly describe an unexecuted check as a pass.
Evaluate both paths before letting a CI event start that workflow automatically. You need evidence that it handles a useful correction and a blocked attempt, including what work remains for the engineer.
Accepted requirement and shared context
-> Implementation
-> Review <-> correction
-> Sandbox verification <-> correction and rerun
-> Evidence for the human reviewerThose exchanges can happen more than once. Tools should preserve their history, reject stale results and stop or escalate when attempts stop making progress. Engineers should receive the decision that needs their judgment with the evidence attached.
The verification sandbox guide explains the environment needed for this loop. A test plan without executed checks does not complete it.
Ready for more delegated execution when a deliberately introduced failure reaches the right owner, gets corrected and is verified on the new revision without someone manually carrying every handoff.
Increase autonomy for a particular responsibility
Your team does not need one autonomy setting for everything. A contained fix may advance through implementation, review and verification without intermediate human approvals. A migration or shared API change may need an approved design before implementation starts.
Keep the required checks and permissions in both paths. If a quick fix exposes a broader contract change, pause and revisit its scope. Do not keep a task in the quick lane after its assumptions have changed.
| Delegation level | What the workflow may do | Evidence before expanding it |
|---|---|---|
| Investigate | Read approved sources and propose an explanation or plan | Relevant sources, explicit uncertainty and findings the owner can check |
| Implement a bounded change | Modify an isolated branch and run the agreed checks | Useful corrections, working permissions and acceptable reviewer rework |
| Coordinate the change | Carry findings between specialist agents and manage correction attempts | Revision-specific evidence, recoverable interruptions and no lost findings |
| Start from an engineering event | Accept an authorized ticket or message and run the configured path | Correct requester scope, duplicate-event handling and visible blockers |
These are evaluation steps, not a mandatory sequence or a promise about how many months adoption takes. Your team may already have some of the foundations.
Ready to expand authority when comparable runs show that the workflow meets your quality and human-effort criteria, including blocked and failed attempts. Keep a way to reduce authority again.
Automate the entry point after the path works
An authorized Linear ticket or Slack request should enter the same workflow with its requester, context and scope attached. It should not create a separate delivery process that bypasses approvals.
The system routes a bounded fix through the shorter path, a feature needing decisions through the fuller path, or an existing PR directly to review or verification. It links the result and evidence back to the original request.
A repeated event should resolve to the existing run. A failed sandbox should produce a visible blocker. A material decision should wait for its owner. Starting from a ticket is useful when the workflow can also handle these outcomes.
Merge and production deployment remain separate permissions governed by the team's release policy. A verified PR does not establish that a production rollout has completed safely.
Retain what the team learned before starting again
When an owner corrects a business rule, keep the approved decision with its source and scope. When the same failure recurs, investigate whether the correction belongs in a skill, a test, environment setup or orchestration.
Those are different changes. Saving a fact in memory does not repair a broken handoff rule. Adding another instruction does not create a missing test fixture.
Review and evaluate proposed changes to the shared setup before promoting them. Version them and retain a rollback path. Look at the whole run so failures between agents are visible alongside failures inside a task.
Ready to call it learning when a later run retrieves the applicable approved knowledge or follows an improved procedure, and comparable evidence shows whether the original problem recurs.
Decide whether delivery has improved
Compare human minutes per verified change, interventions, verification results, reviewer rework and lead time. Include environment repair, abandoned work and compute cost. Keep production outcomes separate from sandbox results.
A workflow can become more autonomous while making reviewers busier. That is a reason to revisit its scope, context or checks before expanding it further.
Use the real-change evaluation scorecard to agree on the comparison. The software factory implementation guide covers the supporting components in more detail.
Pick one change your team already knows how to assess. Make the system carry it through correction and verification. Use the evidence and the remaining human work to decide what responsibility it should take on next.