The stages

Deciding what the thing is for. The work has not changed, but the output has: an agent that will be built from this statement needs it to say more than a human team would have written down, because nobody will be in the room to ask. What it refuses matters as much as what it does.

Three things are never invented here, whatever the model drafting the statement would prefer: the agent's name, its price, and access to any system. Each is a commitment somebody would be held to, so each is asked for, and the statement goes out with it still open rather than filled in.

Agent

spec-writer, whose AgentDoc says what it does, refuses, needs and records

Role

spec writer

Process

New agent, phase write-the-spec

Given

somebody's account of what they want, with whatever they have: notes, a document, an earlier statement, a prototype

Hands back

a statement of the job: what it does, what it refuses, what it needs access to, what it records, and what it costs; and beside it the questions nobody else could answer

Done when

a package could be built from the statement, and what could not be settled was asked rather than invented

Turning the statement into a shape: the steps, in order, and for each one the decision that matters most in agentic work, whether it is a program or a judgment. A written procedure handed to a model to improvise is the shape that fails, and it fails quietly, because nothing checks that the procedure was followed.

The statement and the shape travel as one artifact, so the same agent holds both stages: each step says when it is the right one, what a good result looks like, what happens when there is nothing to give, and how it is done, program or judgment, in four words.

Four things are settled before the steps, because each one changes what a later stage does and all four are cheap to answer and expensive to discover late. Which kind of agent this is, out of the four an agent's inside can be. One agent or several, since work whose handoffs cross to another agent is a process rather than one overloaded agent. Whether the organization can put a real product behind every system the design names, read against its own stack with the resolver the deploy uses, so a design nobody can deploy is refused here rather than at the approval. And whether the thing already exists, as an agent to hire, a repository to copy, or a released agent to change. The person picks from a short list on each, the simplest answer is already selected, and the writer never answers one on their behalf.

Agent

spec-writer, whose AgentDoc says what it does, refuses, needs and records

Role

spec writer

Process

New agent, phase write-the-spec

Given

the statement of the job

Hands back

the four answers above, and the shape: the steps, what each is given and hands back, and whether each is a program or a judgment

Done when

no step is both fully written down and left to a model to interpret, no system the design names is one the organization cannot stand a product behind, and the four answers are the person's rather than the writer's

Writing the tests before the program, from the statement of the job, by something that will not write the program. Running tests is solved and has been for decades. Writing them was not, and the specific difficulty in agentic work is that the same model often writes the program and the test, so a test can pass by agreeing with a mistake. The answer is the order. The suite comes first, from the statement. It names the functions the program will have to export, so the program is written to meet an interface it did not choose. That is why Test sits before Code here, whatever the habit of the older lifecycles.

A suite written before any program exists has to be checked in a particular way. It is run against an empty stand-in for every program the statement names, and it has to fail; a suite that passes with every function absent has asserted nothing. Once the programs exist, each is removed in turn and the suite has to notice. A program whose absence the suite never notices is a program nothing tests, and it is named.

Agent

test-writer, whose AgentDoc says what it does, refuses, needs and records

Role

test writer

Process

New agent, phase write-the-suite

Given

the statement of the job

Hands back

the suite, and what no test could be written for and why

Done when

the suite fails against empty stand-ins for every program the statement names, and, once the programs exist, notices each one removed

Writing the programs. Models write code well and this stage did not move for a long time, which is the clearest evidence that capability was never the constraint. What it was waiting for was an input and a check: a statement of the job, and a suite written from it before any program exists, by something that will not write the program. With those two handed in, writing the code is a stage like any other, and the person who used to sit in the loop as the missing contract can leave it.

This is the one stage where the model is in control rather than called at a named point. A coding harness works the way a coding session works, write, run the check, read the failures, fix, for as many rounds as it takes up to a ceiling. What makes that safe is that none of the check is the model's. The check is four things: the suite passes; each program is removed in turn and the suite has to notice; the builder, the program that turns a statement and its files into a package at the Build stage, takes what was written; and the tests and the statement are read-only to the writer, compared by digest on every round, so the writer of the program cannot also change what checks it. A test that cannot pass without breaking the statement is a conflict, reported for a person to settle, never resolved here.

Only what this stage delivers, under its own signature, moves on to Build. Whatever else was written, in whatever language and by whoever, is a prototype, and making one is agentic prototyping. It is read here as the most exact statement of what was wanted and written again against the suite, which is agentic transpiling.

Agent

code-writer, whose AgentDoc says what it does, refuses, needs and records. It is installed, and its first delivery was refused by its own check.

Role

code writer

Process

New agent, phase write-the-scripts

Given

the statement of the job, the suite, and a prototype when there is one

Hands back

the programs, an account of what was written and what the statement did not settle, and the record of every round

Done when

the suite passes, each program removed in turn is noticed, the builder takes the package, and no test and no line of the statement changed

Reading the program and saying what is wrong with it. This is the stage with the strongest argument for an agent and the least infrastructure for one. A review is already an artifact in every other setting: a list of findings, each naming a place and a claim, each one answerable. What is missing is an agreement on what a finding is and what answering one means.

Role

code critic

Process

no process holds it yet; the code critic has no implementation

Given

the programs and the tests, and the account the Code stage wrote of what it did and how many rounds it took

Hands back

findings, each naming a place, a claim and a consequence

Done when

every finding is answered, by a change or by a stated reason

Deciding what this thing may reach, what it may spend, and what it must never do, before it is given any of it. This is a stage rather than a property of other stages for one reason specific to agentic work: the thing being built holds credentials and acts without anybody watching, so the blast radius is set at design time and is very hard to reduce afterwards. A review that happens after the credential is bound is not a review, it is an audit.

Dependency and supply-chain vetting belongs here rather than in Build. Build hashes what went into the package, which answers what is in it and not whether it should be.

Role

code critic

Process

no process holds it yet; the code critic has no implementation

Given

the shape, the programs, and everything the package will ask to be given

Hands back

a statement of what it may reach, what it may spend, what it must never do, and what was accepted knowingly

Done when

every access the package asks for has a reason recorded against it

Turning the shape and the programs into one thing that travels. This is where agentic work moved first, because a package was already an artifact: files, a manifest, a digest. The package also carries the declaration, which is what the rest of the lifecycle reads.

This is also where the rule about prototypes is enforced. The builder packs only programs it can trace to a delivery the Code stage signed, and refuses the rest with a reply naming where to send them. The trace is the signed manifest every delivery carries, so nothing new has to be signed to hold the rule.

Agent

agentbuilder, whose AgentDoc says what it does, refuses, needs and records

Role

package maker

Process

New agent, phase make-the-package

Given

the shape and the programs

Hands back

a package: the declaration, the parts, a manifest, a digest

Done when

the declaration validates, what it promises matches what the install file asks for, and every program is traced to the Code stage's delivery

Putting the package somewhere, under a digest, with a record of who built it from what. The record is the reason anyone downstream can trust the bytes, and it is signed by an identity rather than asserted by a pipeline.

Agent

agentbuilder, whose AgentDoc says what it does, refuses, needs and records

Role

package maker

Process

New agent, phase make-the-package; the package is the release

Given

the package

Hands back

a signed build record, and the package at an address

Done when

the digest at the address matches the digest in the record, and the record verifies

Installing the package so that something is running and reachable. The agentic difference is that the result has an identity of its own and an address other agents can find, so a deploy is not finished when files land. Somebody has to be able to write to it and get an answer.

Agent

deploymgr, whose AgentDoc says what it does, refuses, needs and records

Role

deployment manager

Process

New agent, phase deploy-the-agent, after the owner's yes at approve-the-deploy

Given

the package, and where it is going

Hands back

a running agent with an identity, an address and an inbox

Done when

it is installed, it has its identity, and a message sent to its address is answered

Binding what the package asked for: a credential for each service, a value for each setting, a number for each thing that spends. The rule that makes this safe is that a secret is named and never carried, so the instruction to deploy can be read, logged and repeated without leaking anything.

Agent

deploymgr, whose AgentDoc says what it does, refuses, needs and records

Role

deployment manager

Process

New agent, phase deploy-the-agent; the bindings are settled at deploy

Given

what the install file asks for, and the owner's answers as names

Hands back

credentials bound by name, settings placed, a ceiling on everything that spends

Done when

nothing the package asked for is missing, and no secret value appeared in the instruction

Checking that the running agent does what its package says. The cases are derived from the declaration rather than written by hand, which is what makes this cheap enough to run on every deploy. It answers one question only, and answering it is not the same as saying the work is good.

This stage was called Acceptance in the first draft, and the word was wrong. Acceptance is a person deciding they will have the thing, which is a different act and stays a person's. What the agent does is check conformance to a declaration, and it is only half independent, which is worth being plain about. The declaration was written at Build, so a check derived from it catches an agent that does not do what it promised and cannot catch an agent that promised the wrong thing. It is a consistency check on one artifact, not an outside opinion. The outside opinion is Eval, and that is why the two are separate stages rather than one gate with two kinds of case.

Agent

agentevaluator, whose AgentDoc says what it does, refuses, needs and records

Role

conformance checker

Process

New agent, phase check-conformance

Given

the package, the agent's address, and where its records live

Hands back

a signed verdict, case by case

Done when

every case derived from the declaration has run and the verdict is signed

The document a stranger reads before deciding to use the thing. In agentic work this is assembled from what the agent already declares rather than written fresh, for the same reason a résumé is a poor way to check a fact: a document that is authored can say anything, and a document that is gathered can only say what its sources say. Where a source is silent, the silence is printed.

Role

doc writer; the document format is defined at agentdoc.net

Process

New agent, phase publish-the-agent: the AgentDoc is assembled from the deployed agent and its conformance record, and the owner reads it before the agent may be listed

Given

the declaration, the identity, and whatever records and verdicts exist

Hands back

a document a stranger can read, with each claim traceable to its source

Done when

nothing in it was authored, and every silence is shown rather than filled

Putting the output where the person who asked for it can open it. This looks like plumbing and is not: publishing is the one stage that makes work visible outside the system, so it is the one stage where a mistake is public. It needs an authority to write to an address, a record of what was written, and a digest, and until an agent held it, it was done by whoever happened to have the credential.

The agent that holds it writes under the one folder it was bound to and nowhere else, reads every byte before it goes, refuses anything that looks like a credential whatever the file is called, and reads back what is served to check it matches what it was handed. Nothing is given as published until the address has been read.

Agent

publisher, whose AgentDoc says what it does, refuses, needs and records

Role

publisher

Process

no phase of a published process is held by this agent yet. In New agent the listing is made by the platform from the descriptor once the owner says the agent may be listed

Given

the deliverable, and where it may be written

Hands back

an address a person can open, and the digest of what is there

Done when

the address resolves and what it serves matches the digest recorded

Taking down what was published, by the authority that put it there and no other. Publishing is the one stage whose output outlives the job that made it, so the ability to publish without the ability to undo it is a decision, and it should be a deliberate one. It is a stage of its own rather than a footnote to Publish because the check is different: publishing is proven by reading the address and finding the bytes, retracting by reading it and finding nothing.

The record of every name the publisher has placed is what lets it tell what it may take down. An address it never wrote is not its to remove, however it is asked.

Role

publisher

Process

Retire an agent, phase retract-the-listing

Given

the address, or the name it was published under

Hands back

a record of what was taken down, by whom, and when

Done when

the address is read back and nothing is there, and the record says who took it down and why

Knowing whether each agent is alive, answering, and inside its limits. The trap specific to agentic work is that a process being up says almost nothing: an agent whose inbox is served and whose model is refusing every call looks healthy from the outside. Liveness has to be measured by an answer, not by a process.

In practice this is held by supervising programs rather than by anything with an identity, which is why nothing holds the stage yet: a program that watches keeps no record anybody can ask it about afterwards, and the person reading its output is the one who knows.

Role

watcher

Process

no process holds it yet; the watcher has no implementation

Given

the fleet, and what each agent declared it would do

Hands back

whether each one is alive, answering, and inside its limits

Done when

silence is treated as a failure rather than as no news

Judging the work itself. Conformance says an agent answers; eval says whether the answer was any good, and it is a different question with a different apparatus. A mechanical check can catch a fault but has no opinion about whether the work was worth doing. What is missing is the artifact: a written statement of what good looks like for this job, made before the work, by somebody other than the maker.

It sits in Run rather than Prove, where the first draft had it, because it judges what an agent does on real jobs after it is installed, beside the monitoring that says whether it answered at all. A standard set beforehand is what makes that a stage rather than an opinion.

Role

agent critic

Process

no process holds it yet; the agent critic has no implementation

Given

the work produced, and a standard set beforehand

Hands back

a graded judgment, with the reason on each grade

Done when

every piece is graded against the standard, and the standard predates the work

What happens after monitoring finds something, and before anybody decides to roll back. Detection is not response, and the gap between them is where most of the damage is done. The difficulty specific to agentic work is that a misbehaving agent keeps working: it has an inbox, it answers, and it produces steadily worse output for as long as nobody stops it. Stopping it is its own act, separate from fixing it.

Role

incident recorder

Process

Incident, phase record-the-incident; a reference process until a watcher exists

Given

whatever monitoring saw, and the records of what the agent was doing

Hands back

what happened, what was done about it, and what changes as a result

Done when

the thing is stopped or well, and the account of it outlives the people who were there

Accounting for what the work spent against what it was allowed. Individual ceilings are the easy half and are usually in place. The half that is missing is the view across everything, which is exactly the view you need when the spend is made of many small automatic decisions rather than a few large deliberate ones.

Role

watcher

Process

no process holds it yet; the watcher has no implementation

Given

the ceilings, and the record of what each job spent

Hands back

the account: what was spent, by whom, against what was allowed

Done when

every spend is attributable to a job, and the total is reconciled against the ceilings

Moving a running agent to a new version of its package while it keeps its identity, its address and its history. The version changes; the subject does not. What changed between the two versions has to be recorded, because the agent's own document will be read by people who were not present for the change.

The code is rarely the risky part. The records an agent has already written are in the old version's shapes, and the new version has to go on reading them, which is the ordinary migration problem arriving in an unfamiliar place.

Agent

deploymgr, whose AgentDoc says what it does, refuses, needs and records

Role

deployment manager

Process

New agent, run again with the version that runs today attached as the prototype

Given

a new package, and the agent it replaces the old one on

Hands back

the same agent on the new version, with what changed recorded

Done when

the identity and the address are unchanged, and the difference is written down

Putting a running agent back on the version before, quickly, when the new one is wrong. Moving the code back is not hard once update exists. What is missing is the authority: who may decide, on what evidence, and how fast, and whether an agent may make that call about another agent without waiting for a person.

Moving the code back is also not the same as undoing the work. A version that ran for an hour has sent messages, spent money, written files and changed data somebody else now depends on, and none of that reverses when the version does. A rollback that only names the version is a rollback that leaves the mess.

Role

deployment manager

Process

no process holds it; rollback is the deployment manager's own act

Given

the agent, and the version it was on before

Hands back

the same agent back on that version, the reason it was moved, and what the bad version did that cannot be undone

Done when

the agent is answering on the old version, the reason is recorded, and the side effects are named

Taking an agent away. The part that is specific to agentic work is that an agent has an address other agents hold, and work in flight that somebody is waiting on. Removing it cleanly means the address stops answering rather than answering wrongly, and the records outlive the agent that made them.

Agent

deploymgr, whose AgentDoc says what it does, refuses, needs and records

Role

deployment manager

Process

Retire an agent, phase remove-the-agent

Given

the instruction, and the agent

Hands back

nothing running, the records kept, and the address retired

Done when

no work is in flight or the stuck work is accounted for, the records are kept, and the address is not reused