What is an agentic software and product development lifecycle?

What changes when agents do development work?

Agents can investigate a repository, propose a plan, change code, run checks and prepare a pull request. The lifecycle must make the conditions around that work explicit: what the agent may change, which evidence it must produce, who checks that evidence and when it stops.

The software development lifecycle concerns the production and operation of software. The product development lifecycle also asks whether the work solves a worthwhile problem, whether people adopt it and what the next investment decision should be. An agent that finishes a ticket has completed an intermediate step in that wider lifecycle.

This collection uses agentic development to mean development performed with agents. Developing an AI agent as the product is a different problem, although the two can overlap.

What belongs in the end-to-end loop?

Start with a named user or operator and an intended change in behavior. Record what is known, what is assumed and who owns the result. Then connect the following activities at the level appropriate to the risk:

1. Frame intent and decide whether the opportunity deserves attention.
2. Investigate the assumption that could invalidate the investment.
3. Specify an agreed increment and its verification.
4. Build, check and release within explicit authority.
5. Observe adoption and the intended result.
6. Continue, change direction or stop using that evidence.

These activities need not form a sequential project plan. A small, reversible change may move through them quickly. An uncertain product bet may revisit discovery several times. The important connection is from evidence to the next decision.

What should a workflow contract contain?

Name the unit of work, the steps it can move through, the evidence needed at each transition and the person or system that owns each decision. For an agent-operated step, add permitted tools, a budget, a verification method, a stop condition and an escalation destination.

Keep two loops visible. The delivery loop advances the product work. The improvement loop examines the workflow itself: recurring mistakes, weak checks, excessive human intervention and missing context. A generated specification describes neither loop automatically.

What remains unproven?

A complete set of files does not establish that the workflow runs reliably or improves outcomes. Check actual transitions, evidence, human effort and downstream behavior. A deployment receipt proves a release occurred; it cannot establish that users benefited.

Sources and further detail

• Portfolio-PDLC and flow-driven source: the portfolio and single-stream contracts behind this answer.
• From Babysitting AI to Developing the Factory: the wider product, factory and company argument.
• Portfolio-PDLC operating details.