agentic-development // the ordinary stages, and what changes when an agent holds one

A lifecycle for software that agents build

The stages have not changed. Somebody still has to decide what is wanted, write it, test it, review it, ship it, prove it works, and take it away again. What changes when an agent holds a stage is that the handoff has to become a thing, not a conversation. This is a map of the twenty-one stages, the role each one needs, and the artifact it hands to the next.

Three things, for every stage

A lifecycle that only names its stages is a diagram. What makes one usable is saying, for each stage, who is meant to hold it, what they are handed, and how anyone can tell it is finished. Those three questions are the whole of this map.

01

The role

The job, written before any particular agent exists to hold it. Roles are published separately, at agentroles.ai, so a stage here names a role rather than a product. Where an agent holds the stage, it is named too, and the name is a link to its AgentDoc.

02

The handoff

What the stage is given and what it hands back, each an artifact somebody can name, read and check. A stage whose output is a conversation cannot be held by an agent, however capable the agent is.

03

What done means

The check that says the stage really happened, made against something written down beforehand. Without it, a stage held by an agent is a stage nobody is accountable for.

The Agent Development Lifecycle

Two marks. A name that is a link is an agent holding the stage today. coming soon is nothing yet.

StageRoleHands backAgent
Define
Requirements spec writer a statement of the job: what it does, refuses, needs, records and costs spec-writer
Design spec writer the shape: the steps, and which are program and which are judgment spec-writer
Make
Test test writer the suite, written from the statement before any program exists test-writer
Code code writer the programs, passing a suite written before them code-writer
Review code critic findings against the program, each one answerable coming soon
Security review code critic a statement of what this thing may reach, what it may spend, and what it must never do coming soon
Ship
Build and package package maker a package: the declaration, the parts, a manifest, a digest agentbuilder
Release package maker a signed build record, and the package at an address agentbuilder
Deploy deployment manager a running agent with an identity, an address and an inbox deploymgr
Configure deployment manager credentials bound by name, settings placed, ceilings set deploymgr
Prove
Conformance conformance checker a signed verdict: does it do what its package says agentevaluator
Use
Docs doc writer a document a stranger can read before deciding to use it coming soon
Publish publisher an address a person can open, and the digest of what is there publisher
Retract publisher a record of what was taken down, by whom, and when coming soon
Run
Monitor watcher whether each agent is alive, answering, and inside its limits coming soon
Eval agent critic a graded judgment on the work itself, against a standard set beforehand coming soon
Incident response incident recorder what happened, what was done about it, and what changes as a result coming soon
Cost watcher what was spent, against what was allowed coming soon
Change
Update deployment manager the same agent, on a new version, with what changed recorded deploymgr
Rollback deployment manager the same agent, back on the version before, and why coming soon
Decommission deployment manager nothing running, the records kept, and the address retired deploymgr

The three processes

The lifecycle is run as process documents, published at agentprocesses.ai. Each page there says what has actually happened with it.

  • New agent: a request in words becomes a deployed agent, with the owner's yes at two gates. Has run end to end once, on 2026-09-15.
  • Retire an agent: the listing down, the owner's yes, the removal, the AgentDoc closed. Written, not yet run.
  • Incident: notice, gather the records, record the incident with every gap named, decide. A reference process with no holder for the watcher's phase yet.

A change to a released agent is New agent run again with the version that runs today attached as the prototype; there is no separate change process. Stages no process holds yet say so on the stages page.

What the map shows

Ten stages have an agent and two more have one built. The stretch from Build to Conformance, and Update and Decommission at the end of the chain, moved first because it was built out of artifacts before anybody thought about agents. The front moved next, when the missing artifact was made. That artifact is the test suite: a statement of what the program must be true of, written from the specification before any program exists, by something that will not write the program. Once the suite existed, writing the code became a stage with an input, an output and a check the writer does not control.

Review and Security review are the gap left at the front: nothing has agreed what a finding is or what answering one means. The back is thinner still. Eval, Cost, Incident response, Rollback and Retract each need a judgment or an authority that nobody has written down.

The official coder

Anything a person makes in their own tool, a coding harness, a chat, a notebook, is a prototype: agentic prototyping, and nothing in this lifecycle stops it or needs to. What moves on to Build is only what the Code stage delivers. A prototype sent to be packaged is refused, with the reply naming where to send it, and the code-writer reads it as the most exact statement of what was wanted that exists and writes the programs again, in the stack every package on this mesh is written in, against the suite: agentic transpiling. The trace is the signed manifest every delivery already carries, so the rule is one refusal in one place.

That edge is deliberate. Anything the prototype did that the statement of the job never said does not survive the rewrite. If it is wanted, it goes into the statement first, and then the suite, and then the code.

Where this comes from

This draft is written alongside AgentMesh, where the middle of the lifecycle is built and running, where the front is partly held and partly built, and where the gaps were found the ordinary way, by hitting them. Roles are defined at agentroles.ai. What an agent publishes about itself is defined at agentdoc.net. Implementations lists what exists today, stage by stage.

It is a working draft. The stages are stable; the roles and the checks are not, and several are named here before they are written.