Agentic Software Development Lifecycle: Who Decides What

A coding agent landed in the repository last quarter. Pull requests started arriving faster than the review rota could read them. The board sees more commits and asks why the release train is no steadier than before.

That is a familiar week for founders, CTOs, heads of engineering and operations leads at mid-market and private equity (PE) backed companies, including managed-service businesses (MSPs), the non-IT service firms that run a multi-party platform. The team didn't hire a careless engineer. It added a fast contributor that can draft a plausible change without owning the outcome. Reviewers now spend their time deciding what should change, and proving the change is safe to ship.

Typing speed moved the bottleneck. It didn't remove it. On a fragile platform, or under a PE owner who wants a clean release path, more generated diffs can make the queue worse. The useful question isn't whether an agent can type code. It's who may accept a change, and what evidence has to exist before that yes.

Why Agents Are Changing the Delivery Loop

A generated change is a draft until someone with authority accepts it. A patch can compile, match the ticket's wording and still be the wrong production change. Reviewers feel that gap as a backlog: more pull requests, thinner comments, and less time to challenge scope, security or a quiet dependency.

An agentic software development lifecycle is the software development life cycle (SDLC) with AI agents doing bounded work at several stages, while named engineers keep authority over requirements, risk and release. Agents can sort tickets, draft acceptance criteria, write code in an isolated copy, run checks and prepare a rollout note. They don't grant themselves permission to ship.

The useful way to read this model is as a set of decision rights attached to an evidence trail. Each stage answers two questions: who is allowed to say yes here, and what record has to exist before that yes counts. Speed is a side effect. Safety and maintainability are the test.

What the phrase does not mean

There is no agreed standard. Vendors use the phrase loosely, sometimes for a chat window that edits files. This guide uses the stages and controls that research and working teams describe: triage, specification, implementation, review, verification and release, each leaving a record the next person can inspect.

By the end of this guide, you should be able to point at any stage in your own pipeline and name its decision right and its evidence requirement. The stage where you can't do that is where agent-generated work will do damage without anyone noticing.

Honest limit: The practice is new. Most published evidence comes from surveys and benchmarks rather than long controlled studies, and results depend heavily on the codebase and the team.

What the Agentic Lifecycle Covers at Each Stage

A building site runs on divided responsibility. A fast crew does most of the lifting, and a site engineer signs off each load-bearing wall before the next floor goes up. An agentic software development lifecycle divides software work the same way: agents move material, and named engineers accept the structure.

The loop has six stages.

1. Triage sorts and groups incoming requests.
2. Specify agrees acceptance criteria and impact.
3. Implement writes the change in an isolated copy.
4. Review judges fit, security and maintainability.
5. Verify runs tests and checks.
6. Release authorises promotion and a rollback plan.

Agent work, human decisions and the record

A lifecycle judged only on speed hides the point of the stages. Each stage exists to transfer two things: the work product, and the evidence that lets a named person accept it. The diff itself often matters less than the trail of decisions around it.

The 2024 DORA report, published in October 2024 from a global survey of software professionals, found that more than 75% of respondents relied on AI for at least one daily professional responsibility. The same DORA survey found that a 25% increase in AI adoption was associated with a 7.5% improvement in documentation quality, a 3.4% improvement in code quality, a 3.1% increase in code-review speed, a 1.3% increase in approval speed and a 1.8% reduction in code complexity. These are survey associations, not controlled tests.

Why each stage still needs a gate

Those associations point one way. Agents can speed up individual activities, and speed inside a stage says nothing about whether the stage's output is right. A cleaner diff still requires the same release decision, and quicker review comments still leave the requirement's correctness open. Each stage keeps its own evidence and its own gate, because quality at one stage never settles the judgement owed at the next.

Grail Computer Labs processes every request through the same six steps in its Software Factory. The factory is configured around each customer's product, codebase and release path, works in isolated copies of the repository, and returns completed work with a summary, passed checks and a video. Customers see progress and evidence as work moves, rather than waiting for a silent batch of commits.

Each stage hands evidence to the next, and no stage's output is assumed correct.

Where Engineers Keep Decision Rights

Decision rights attach to risk, not to every keystroke. Agents execute. People decide. A documentation edit and a database migration shouldn't share the same gate, or reviewers will either rubber-stamp danger or stall harmless work.

Read the rows by blast radius. A comment fix can pass automated checks and a sampled review. A dependency upgrade needs compatibility tests and a security sign-off when the package is critical. Authentication changes stay as drafts until a security reviewer accepts them. A migration doesn't move because a script exists. It moves when a named engineer has a tested rollback.

Oversight has to be written down

The NIST AI Risk Management Framework Core says organisations should define, assess and document human-oversight processes in line with their own policy. That is a requirement to document oversight. It isn't a claim that oversight removes risk. NIST doesn't prescribe one SDLC. It asks for a defined, assessed process, with authority sitting on a named person for decisions that affect security, data protection, reliability or customer outcomes.

Two illustrations, not measured deployments, show how a gate looks outside pure coding.

Support triage. An agent may draft replies and propose priorities. Priority overrides, customer commitments and external messaging sit behind an approval gate. Severity calls, customer communications and cross-functional incident ownership stay with a named person.

Contract review. An agent may summarise clauses and flag deviations from standard terms. Legal judgement, privacy risk acceptance and negotiation strategy stay with humans.

A nominal approval button isn't meaningful control unless the reviewer has enough context, time and authority to reject the change. The test for any gate is simple. Name the person who can say no, and confirm they have the information to do it.

How to Verify Agent Work Before It Ships

A green suite can still ship the wrong change. A public repository benchmark can show that an agent moves through a large codebase, finds relevant files, patches a defect and passes held-back tests. That proves task competence inside a controlled setting. Release safety is a wider question: did the change stay inside the approved boundary, keep migration risk explicit, preserve security posture and leave enough evidence for a second engineer to reconstruct the decision?

Treat verification as a chain of custody for judgement. Each step should answer who acted, what they were allowed to touch, what evidence they produced and who accepted the residual risk. Agents execute inside that chain. Engineers keep decision rights where product judgement, risk ownership or customer context is required.

A procedure that writes a record

Separate execution from authority. Agents may triage, inspect, draft, generate tests and run sandboxed checks. Engineers review diffs, approve heightened permissions and authorise production promotion. The NIST Generative AI Profile treats risk management across design, development, deployment, use and evaluation, including actor credentials, auditing and change management. Use that as the control baseline, then make each step leave a file someone else can open.

1. Freeze the requirement baseline. An engineer signs acceptance criteria and impact analysis before code runs. Record: the signed baseline.
2. Run the agent in an isolated copy. Give it a scoped identity and no production credentials. Record: the tool-call log.
3. Run the outcome tests. Cover unit, contract and regression tests tied to business behaviour, plus any held-back tests the team keeps. Record: the test results.
4. Scan the change. Run static analysis, dependency and secret scanning, and security checks. Record: the scan report.
5. Compare the diff with the baseline. Reject scope creep before style nits. Record: the diff review.
6. Prove it in staging. Check logs, traces and the rollback path. Record: the staging evidence.
7. Authorise, then widen slowly. A named engineer approves release, rollout starts with a small share, error rates are watched and rollback stays ready. Record: the release record.

Tests check the behaviour they were written for. Architecture fit, migration safety and operational assumptions still need human review. A suite going green earns the next inspection, while the named engineer keeps release authority.

A Worked Example of One Change Moving Through the Loop

This scenario is hypothetical. A mid-size subscription business, invented for the example, needs its partial-refund logic changed after a backlog of support tickets. Nothing here is a measured client result.

Triage. The agent summarises the tickets, groups duplicates and proposes a priority. A product owner accepts the priority. Work starts only then.

Specify. The agent drafts acceptance criteria and lists affected flows: refunds, cancellations and customer notifications. An engineer approves that baseline. On an older billing core, this is also where a team would map fragile paths before touching shared money logic, the same discipline used in a legacy system migration.

Implement. The agent works in an isolated copy and opens a diff with a short summary of intent, files and checks.

Review. The engineer finds that the agent also changed a shared rounding function used by invoices. That is scope creep. The engineer rejects it. The agent reissues a narrower change that touches refund calculation only.

Verify. A regression test fails for a zero-decimal currency. The agent fixes that case. Static checks then pass. The failed run stays in the record, not only the green one.

Release. The change reaches a small share of traffic first. The engineer watches refund error rates before widening the rollout. Rollback steps are already written.

What the file must contain

The evidence record holds the original request, the proposed change, tool calls, test results, reviewer identity and release outcome. GC Labs designs its Software Factory to keep that kind of record with each change: requirements become tasks, work stays in an isolated copy, and completed work comes back with a summary and passed checks. If a step fails, the workflow should record which step failed and why, so a person can finish the record instead of losing the trail. This refund story shows the shape of that trail. It doesn't report a delivery result.

Metrics That Show Whether Agentic Delivery Is Safe

A dashboard can look healthy while the codebase rots underneath it. Velocity, pull request volume and generated lines are weak measures of success. A large repository study reported about 18% more static-analysis warnings and 35% higher cognitive complexity in projects using coding agents, even where early throughput gains weakened over time.

Output can climb while maintainability slides.

The scorecard answers a harder question than speed. It shows whether the people holding decision rights still control the result, and whether the evidence trail survives contact with production.

How to read the scorecard

Take a baseline before agents touch the repository. Track results by change type, since one company-wide average hides the modules where agents do the most damage. Compare agent-touched modules with control modules the agents never edited. After each release, weigh escaped defects and recovery time more heavily than merge speed.

Review behaviour can shift for reasons that have nothing to do with agents. A holiday rota, a new checklist or a tired team can make comments shorter. Compare against control repositories before attributing a change to the agent.

Each row works like a tripwire with a threshold agreed in advance. Rising output alongside falling retention or more warnings means the codebase is getting harder to keep. In regulated healthcare, financial services and enterprise platforms, a wrong change can cost more than a faster patch saves, so the reading that matters is the one that triggers a pause before the next release.

Confirm Ownership and Exit Terms Before the First Agent Commit

Before the first agent commit lands, one named person must be able to explain the change: why the agent acted, what context it used, and who accepted the risk on behalf of the business. The next team will need to reconstruct that reasoning from the record, so the record has to carry it.

Settle the following points before that commit.

• Named owners: who owns each stage, and who can change agent permissions.
• Durable context: where requirements, rejected alternatives and test results live.
• Exitability: whether another team can read a change record without the original agent or provider.
• Provenance: whether the model version is stored with each change.
• Handover: whether a written protocol exists for an internal team or a replacement provider.

Readiness before you widen the loop

A fast pilot is not a reason to expand. Expand when the owner can explain the workflow in plain language, the exception queue stays small enough to review and is well categorised, and the approval boundary is written down and accepted by the business stakeholders who live with a bad release. Judge any tool or provider against one real workflow, one real owner, one real approval path and one measurable outcome.

Analysts reviewing a dataset of 932,791 agent-authored pull requests found lower acceptance rates, slower interactions and notification fatigue around bot-generated changes. Agents bolted onto an existing review queue can add friction where they were meant to add control.

For a build that has already stalled, GC Labs offers a takeover service: it takes over an existing software build from a previous vendor and becomes responsible for the product, codebase, infrastructure, testing and production. The point is evidence as much as effort. Ownership of the release path gets rebuilt in writing, rather than reconstructed later from old tickets.

No checklist guarantees results. Test the arrangement on one workflow first.

---

Grail Computer Labs helps delivery leaders put decision rights and evidence trails around an agentic software development lifecycle, through GC Labs' Software Factory, where agents execute and engineers decide. If a release path is stalled or a coding agent is outrunning review, book a call or start an outcome engagement, which delivers one pre-defined, measurable outcome in 4 to 8 weeks, with a 15-day trial in which a qualified client can stop without paying, at Grail Computer Labs.