Digitize your processes
so agents can run them

the phase graph

Some phases run at the same time

If you number the phases 1, 2, 3, you are saying that each one follows the last, and that is usually not what happens. When somebody is terminated, access revocation, final pay and equipment return all start at once, and none of them waits for the others. So phases have names instead, and each one lists what it comes after. Two phases that do not appear in each other's after: lines can run at the same time, and the phase that closes the run waits for all of them.

A phase is one of four things:

• runs a work pattern — the phase is a whole job of its own, with its own plan and its own ending. The process says what comes out of it and leaves the inside alone.
• convenes a collab pattern — the phase is one room, running an Agent Collab playbook as written.
• a system acts — nothing collaborates. A scheduler publishes, a job runs, a record is written.
• a person acts — somebody does something outside any room.

The last two are in the list because most real processes have steps where nobody collaborates with anybody. If the format has no way to describe those steps, people end up writing down something other than what really happens.

by: is the deadline for a phase. It belongs to the process rather than to any one run, because deadlines usually come from a rule: payroll has a legal one, and revoking access has a security one.

automation

How much of a phase an agent is allowed to run

Every phase says how much of it an agent may do. A team decides where to start automating by reading this, and the levels move up as the team gets more confident.

The first four are steps you can move through over time. Never is different. It means the phase stays with a person no matter how good the agents get, because a regulator, a contract or a customer relationship requires it. It is worth having a separate word for that, so that nobody automates a step that was deliberately left to a person.

Moving a phase to the next level is an amendment, and it gets a version and a date. That way, when somebody asks when an agent started deciding whether a claim was substantiated, you can point at a version number instead of trying to remember.

the format

What a process document contains

Every process uses these headings, so a reader who knows one can read all forty:

# the shape of every process document
PROCESS: <name>                     id: <team>/<slug>   v<version>
owner: <who owns this document>     effective: <date>
trigger: <what starts a run, and who may start one>
concurrency: <one run at a time | runs may overlap>
goal: <what exists when a run is done>
phases:
  <name> - <runs|convenes|system:|human:> <what>   owner: <who>
           after: <phase names, or trigger>        by: <deadline>
           automation: <manual|assisted|supervised|autonomous|never>
run-scoped:
  <name> - <runs|convenes|system:|human:> <what>   owner: <who>
           every: <cadence> | on: <event>
           from: <phase or trigger>   until: <phase or run close>
           automation: <manual|assisted|supervised|autonomous|never>
handoffs:
  <phase> -> <phase>: <what crosses, and what it has to contain>
bindings:
  roster:  <role = agent or person, standing>
  systems: <system (read|write), ...>
  data:    <reference material a run reads>
policy:
  <a rule that exists for legal, compliance, or brand reasons>
measures:
  <what a good run looks like: cycle time, volume, quality gate>
fed by: <process ids>
feeds:  <process ids>
amendments:
  v<n> - <what changed, and which debrief or run produced it>

Bindings are what an agent needs before it can actually run a phase: which agent or person holds each role between runs, which systems a run may touch and whether it may write to them, and the reference material it reads. They also settle permissions in advance. When a trigger fires, nobody should still be working out what the agents are allowed to do.

Run-scoped lines cover what never sits in a phase: the weekly status report, the budget watch, the escalation path. They run or convene patterns the way phases do and carry the same automation level, but instead of after: edges they carry a cadence or an event, plus from: and until: lines saying when they are live. Most of a process's management lives here, and a process that lists only its phases reads as if nobody is watching between handoffs.

Policy is kept apart from coordination on purpose. A rule like "one agent holds the pen during synthesis" is about coordination: it comes from the pattern, and it applies anywhere that pattern is used. A rule like "no claim ships without a citation in the claims register" is your own, and it applies only to your process.

The full format is in the specification, including the failure edges a whole process has: a missed deadline, a refused gate, a trigger that fires while a run is in flight, and a run somebody stops halfway through. The repo keeps the format as process.md.

the catalog

Why a department needs a catalog

One process written down is easy enough to keep track of. Once a department has forty of them, nobody can hold them all in mind: it gets hard to say which ones matter most, and nobody notices when one of them stops being true.

A catalog is a table with one row per process. Each row says the same few things about its process, so you can read the whole department at once and know which documents to open:

Every one of those is copied from the process document's header, and that is what keeps a catalog usable. A row stores nothing of its own, so when the two disagree, the process document is right and the row is out of date. Nobody has to maintain the same fact in two places.

The automation column shows the least automated phase in the process, so a process with four autonomous phases and one legal approval reads as a manual gate. Averaging them instead would make the department look further along than it is.

Coverage and upkeep

• Work that is missing from the catalog gets missed. You cannot automate it, measure it, or hand it over when somebody leaves. Turning up work that nobody had written down is the point of the exercise, so it is a good sign rather than an embarrassing one.
• Every row needs an owner. If nobody will own a process, that is something to fix rather than a row to file. Either somebody takes it or you retire it.
• Retire anything that has not run in a year. Once a catalog fills up with processes nobody runs, people stop reading it.

How to build one, how ids survive renames and splits, and how to rank what to automate first are in process-catalog.md.

the agent lifecycle

Three processes that make, retire and record agents

The Agent SDLC at agenticdevelopment.ai is run by these documents. Each page says what has actually happened with it.

• New agent: a request in words becomes a deployed agent, through a spec, a suite written before the scripts, the scripts, a package, a deploy, a conformance check and a listing, with the owner's yes at two gates. Has run end to end once.
• 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.

worked examples

Both formats, filled in with real work

A format earns its keep when somebody fills it in, so each format has a worked example on its own page.

• The social campaign process — one process written out in full: the document, the records one run left behind, and a simulation that plays that run from start to finish, including a failed legal review.
• A marketing department's catalog — eleven processes after a first pass: the rows, who owns them, and what the catalog shows about where to start.