agent processes · the agent lifecycle

New agent

A request in words, with a prototype attached when one exists, becomes a running agent on the fleet. Six phases are held by agents of the lifecycle, three are the owner's to answer, and every handoff is a file the next phase can read.

where it stands

What has actually happened with it

This process has run end to end once, as run r-20260915-f17b on 2026-09-15, which produced the incident recorder. It took three starts; the first two stopped on plumbing that has since been fixed. One phase is weaker than its name: the conformance check ran and confirmed nothing, with eleven cases, seven inconclusive and four flagged for a person. Two have been rewritten since that run. The deploy phase was done by hand then and now files a request into the platform's queue, already approved at the gate before it, which was proved on 2026-09-15 by deploying a throwaway agent and removing it. The publish phase named an agent that publishes files rather than listings, and now reads as the owner's decision that the agent may be listed. The owner's gates were answered by the operator's seat. The plan behind it is at agenticdevelopment.ai.

Who holds what

The spec-writer, the test-writer, the code-writer, the package maker, the deployment manager and the conformance checker each hold one phase; the roles are published at agentroles.ai. The owner holds three: the spec, the deploy, and whether the agent may be listed. The deploy phase files its request into the platform's queue carrying the owner's yes, and the deployment manager answers the run with the handle and the signed deployment record. No fleet agent holds the listing act yet, so the platform makes the listing from the descriptor once the owner says it may.

Four things settled before the shape

Version 2 moved four answers to the front of the spec phase, because each one changes what a later phase does, all four are cheap to answer now, and two of them can end a run before a suite is written. They are the person's to settle and the spec-writer only gathers and drafts them, which is why that phase reads as assisted rather than autonomous.

Which kind of agent this is, out of the four an agent's inside can be; only a package a harness reads is made here, and any other answer says so out loud and hands the request to the path it belongs on. Whether this is 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. And whether the thing already exists, where using one that does ends the run without building anything, which is a good outcome rather than a failure.

What a change is

There is no separate change process. A change to a released agent is this process run again, with the change in words and the version that runs today attached as the prototype; the deploy phase updates the agent that runs. Before a version is released there is nothing to change: the run's own deviations send a spec, a suite or the scripts back.

the document

New agent, in the process language

This is the document the process runner reads, as it stands in the repository. The roster that names which agent holds each phase travels with the run, not with the document.

PROCESS: make a new agent     id: agentmesh/new-agent v2
owner: letta1.jeffrschneider@gmail.com   effective: 2026-09-15
trigger: a person asks for an agent, in words, with a prototype attached
         when one exists; or asks for a released agent to differ, with the
         version that runs today attached as the prototype
concurrency: runs may overlap - one run per agent
goal: a running agent on the fleet whose package was made from a spec
      the owner approved, whose scripts pass a suite written before them,
      and whose conformance was checked by an agent that did not build
      it, with every step on the record. What this process makes is one
      kind of agent: a package a harness reads, which the Common Agent
      specification calls plugin-on-harness. Code that answers on the
      network itself, and somebody else's framework wrapped as an agent,
      are made another way and not here.

phases:
  write-the-spec      - runs write-a-spec: the four answers settled and
                        the request turned into a spec, with every blank
                        the request left named. The four are which kind
                        of agent, one agent or several, whether the
                        organization can stand a product behind every
                        system the design names, and whether the thing
                        already exists; each is the person's from a
                        short list, and two of them can end the run
                        owner: spec-writer
                        after: trigger    automation: assisted
  approve-the-spec    - human: the owner reads the spec, answers what it
                        left open, changes it or says yes
                        owner: letta1.jeffrschneider@gmail.com
                        after: write-the-spec
                        automation: never
  write-the-suite     - runs write-a-suite: the tests the scripts will
                        be held to, written from the spec alone and shown
                        to fail against nothing
                        owner: test-writer
                        after: approve-the-spec
                        automation: autonomous
  write-the-scripts   - runs write-the-scripts: the scripts the spec
                        names, in the house stack, passing the suite,
                        with the prototype read when there is one
                        owner: code-writer
                        after: write-the-suite
                        automation: autonomous
  make-the-package    - runs build: the signed package made from the
                        spec and the delivered scripts, and nothing else
                        owner: agentbuilder
                        after: write-the-scripts
                        automation: autonomous
  approve-the-deploy  - human: the owner reads the package's record and
                        says whether it goes on the fleet
                        owner: letta1.jeffrschneider@gmail.com
                        after: make-the-package
                        automation: never
  deploy-the-agent    - runs deploy: the package installed on the fleet
                        through the deploy queue, approved at the gate
                        before it, or updated when the name already
                        runs; the deployment manager answers with the
                        agent's handle and the signed deployment record
                        owner: deploymgr
                        after: approve-the-deploy
                        automation: autonomous
  check-conformance   - runs evaluate: the test derived from the
                        package's own declarations, run against the
                        installed agent, with each case confirmed or
                        failed
                        owner: agentevaluator
                        after: deploy-the-agent
                        automation: autonomous
  publish-the-agent   - human: the owner reads the agent's AgentDoc, which
                        the platform assembled from the deployed agent's
                        descriptor and the conformance record, and says
                        it may be listed; the listing is the platform's,
                        made from the descriptor, and no fleet agent
                        holds this act yet
                        owner: letta1.jeffrschneider@gmail.com
                        after: check-conformance
                        automation: never

handoffs:
  write-the-spec -> approve-the-spec [spec]: spec.json, the four answers
      as the person settled them, and the list of what the request left
      open
  approve-the-spec -> write-the-suite [approved-spec]: the spec as the
      owner left it, with who approved it and when
  approve-the-spec -> write-the-scripts [approved-spec]: the same spec,
      and the prototype when one came with the request
  write-the-suite -> write-the-scripts [suite]: every test file, and the
      note of what the suite could not cover
  approve-the-spec -> make-the-package [approved-spec]: the spec as the
      owner left it, which names the scripts the package must ship
  write-the-scripts -> make-the-package [scripts]: every script the spec
      names, the writer's account, and the job manifest the adapter
      signed on delivery
  make-the-package -> approve-the-deploy [package]: the package address,
      its sha256, and the build record
  approve-the-deploy -> deploy-the-agent [approved-package]: the package
      address and sha256, with who approved it and when
  deploy-the-agent -> check-conformance [agent]: the agent's handle and
      the deployment record
  check-conformance -> publish-the-agent [eval-record]: the signed eval
      record, every case confirmed, failed or flagged, and the AgentDoc's
      address

deviations:
  approve-the-spec -> write-the-spec [changes]: the owner names what is
      wrong or answers a blank; the spec is revised, not redrafted
  write-the-scripts -> approve-the-spec [conflict]: a test cannot pass
      without breaking what the spec says; the owner decides which of
      the two is wrong, and the suite or the spec is revised
  make-the-package -> write-the-scripts [untraced]: a script the package
      would ship cannot be traced to the code-writer's delivery; it goes
      back through the code-writer
  check-conformance -> write-the-scripts [failed]: a case the package's
      own declarations promise has failed; the scripts are revised
      against the same suite
  approve-the-deploy -> write-the-spec [wrong-spec]: what was built is
      not what was wanted; the request is restated and the spec redone

bindings:
  roster: spec-writer, test-writer, code-writer, agentbuilder,
      deploymgr and agentevaluator are agents, one per phase, named in
      the roster the owner sends with the run; the person is the owner
      and holds the three human phases
  systems: none of the phases reaches a system of its own; each agent
      brings what its package declares
  data: the request, and the prototype when there is one

policy:
  a request for an agent this process cannot make, meaning anything but
      a package a harness reads, is said out loud at the spec and never
      built as something else that looks close
  a spec goes to the owner before any suite or script is written
  the suite is written from the spec and never from the scripts
  no test is edited to make a script pass, and no script is delivered
      that the suite fails
  only scripts the code-writer delivered are packed; a script written
      or changed by hand goes back through the code-writer
  nothing goes on the fleet without the owner's yes on the package
  a prototype is read as the most exact statement of what was wanted and
      is never shipped as it stands

measures:
  time: from the request to the agent's handle
  rounds: revisions before the owner approves the spec, and before the
      conformance check passes
  defects: cases the conformance check failed on the first pass

amendments:
  v2 - the spec phase settles four answers before the shape: which kind
      of agent, one agent or several, whether the organization can stand
      a product behind every system the design names, and whether the
      thing already exists. Two of them can end a run, which is why they
      come before a suite is written rather than at the deploy approval,
      where the stack was the thing that found them. The phase reads as
      assisted because the four are the person's to settle and the
      writer only gathers and drafts.