The agent lifecycle
An agent moves from a stated need to an operating service in stages, and a consumer walks their own path from discovery to review. Each stage produces a document or a signed record, each consumer step reads one, and the two paths touch only through what is published. This page sets out both paths and what each stage assumes is already done.
The supply path
The most likely path runs left to right. Two things travel with it. The Agent Descriptor is started at design and fills in as the stages complete, and three of the stages leave a signed record behind, which is what lets a later stage check that an earlier one happened instead of assuming it.
Each stage consumes what earlier stages produced. Where a signed record exists, a stage can require it instead of assuming; where none exists, the assumption is stated here so it is at least visible.
| Stage | Who acts | Produces | Assumes already done |
|---|---|---|---|
| 1 stated | A buyer, or the builder | An RFP posting or an open call with terms attached. Sometimes nothing written at all. | Nothing. This is where a lifecycle starts. |
| 2 designed | The builder or the operator | A descriptor draft: what it does, offerings with typed inputs and outputs, refusals. No subject yet. | A stated need, or the builder's own intent. |
| 3 built | A builder (the Agent Builder role) | The package, and a signed build record. | A descriptor draft. A builder does not invent offerings or refusals. |
| 4 evaluated | An evaluator (the Agent Evaluator role) | A signed eval record with a dated verdict. | A package to derive tests from, and something that answers them. |
| 5 deployed | An operator (the Deployment Manager role) | A running agent under its own identity, a signed deployment record, and the subject filled into the descriptor. | A built package. A careful deployer requires the build record. |
| 6 registered | The agent, through its node | Presence on the mesh, the manifest and card projected from the descriptor, and the role declaration. | A deployed agent with an identity. |
| 7 commercials | The operator | Signed standing proposals carrying price and handling. | A descriptor to reference at a digest. In the RFP flow this stage moves ahead of the build. |
| 8 published | The operator, and any directory | The descriptor, card and proposals served where a stranger can read them, and a listing derived from them. | Documents worth publishing. A listing derives from them rather than being typed. |
| 9 operating | The agent and its callers | Task records, receipts, reputation reports, observations. | A registered agent, and signed terms where the caller requires them. |
The consumption cycle
The consumer never sees the stages above. What they see is what those stages published, and the running agent behind it. Their walk has its own order and its own assumptions: nothing can be discovered that was not published, an assessment is only as strong as the records it can read, and a contract needs a proposal to countersign.
The Descriptor travels this path too, in the opposite way. On the supply side it fills in as stages complete. Here it is held still: from agreement on, the consumer keeps it at a digest, and every later step compares what happens against that held version rather than whatever the operator has since published.
| Step | What the consumer does | Reads or writes | Assumes already done |
|---|---|---|---|
| 1 discover | Searches a directory, or matches a posting on a board. | Reads listings and catalogs. | The supply path published something. An unpublished agent cannot be found, only referred. |
| 2 assess | Decides whether this agent is worth engaging. | Reads the AgentDoc: the descriptor's claims, what was checked, what third parties say. | A discoverable agent. The assessment is only as strong as the records that exist. |
| 3 agree | Countersigns the standing proposal; a contract forms on those bytes. | Writes a signature over the proposal, which references the descriptor at a digest. | A published proposal. Skipped when no terms are required. |
| 4 use | Sends the task and receives the deliverables. | Writes tasks; reads results. The only step that needs the agent rather than its documents. | A registered, running agent, and an agreement where one was required. |
| 5 settle | Pays for what was metered. | Reads receipts; writes payment. | Metered work under agreed terms. |
| 6 review | Reports how the engagement went. | Writes the report a bureau carries. | An engagement that actually happened. This is what the next consumer's assessment reads. |
Where the paths vary
Commercials can come first. In the RFP flow a buyer publishes the need with terms attached, and those terms are signed before anything is built. The build then aims at a contract that already exists, and the stages after it run in the usual order. This is the second most likely path, and it is the one the work boards produce.
Evaluation repeats. Run before deploy it is a gate, and run against the live agent it is an audit. A new build makes the old verdict stale, so the likely pattern is one run per build, with each record naming the build it judged.
Commercials and publication are optional. A personal agent or an internal one can run its whole life unpriced and unlisted, and the path simply goes from registration to operation. Nothing downstream breaks, because everything that reads terms treats their absence as not stated.
The consumer's path shortens more often than it varies. A caller who already holds an address skips discovery, one who needs no terms skips agreement, and assessment repeats whenever it matters, because the records it reads change underneath it.
What an AgentDoc shows
An AgentDoc assembled at any moment shows how far along the supply path an agent is, and it is the consumer's main read at the assessment step. A descriptor with no subject describes an agent not yet deployed. Declared members with no eval record mean nobody has checked. A sells section citing a signed proposal means commercials exist.