Write down your processes
so agents can run them

where this sits

How this fits with the other two libraries

Agent Collab covers what happens inside one room: who may speak, who holds the pen, and what the record is. Agent Work Patterns covers the shape of a whole job: the phases, what crosses between them, and what happens when a phase fails. Its patterns are reusable, and they belong to nobody.

This library covers your organization's own work. A process names work patterns and collaboration patterns for its phases, and adds what only you can supply: your trigger, your systems, your legal gate, your owner. Processes refer to patterns, and the patterns never refer back, which is how the rest of the family works too.

Why a process is not a work pattern

A work pattern is generic. Train and certify is the same shape at your company and at your competitor, which is why there are only a few of them and why one earns its place by recurring across organizations.

A process is yours. It has your brand rules in it, your compliance gate, your systems, and a person's name on it. A department usually has somewhere between ten and forty of them. You would never have forty work patterns.

They also last different lengths of time. You pick up a work pattern when you need it and put it down again. A process is a standing document: it gets amended a few times a year, runs hundreds of times, and outlives everyone who wrote it. That is why it carries a version, an owner, an effective date and an amendment history, and why every run records which version it ran under.

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>
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.

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, including the process-level failure edges — a missed deadline, a refused gate, a trigger that fires while a run is in flight, a run abandoned after it has already changed the world — is in 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.

a worked process

The social campaign process

This is one process from the marketing catalog below, with every blank filled in. The legal phase is marked never, and the claims phase above it only became autonomous after twenty clean runs.

PROCESS: social campaign              id: mkt/social-campaign   v4
owner: Head of Social                 effective: 2026-06-01
trigger: a campaign brief is approved in mkt/campaign-planning
concurrency: runs may overlap - up to six live at once, one per campaign
goal: a legally cleared campaign scheduled on every channel the brief
      names, and a readout of how it did
phases:
  direction - runs evaluate-options          owner: Head of Social
              after: trigger                 by: 2 days
              automation: supervised
  produce   - runs build-by-talent           owner: Creative Lead
              after: direction               by: 5 days
              automation: supervised
  claims    - convenes assessment            owner: Brand agent
              after: produce                 by: 1 day
              automation: autonomous
  legal     - convenes approval              owner: Legal reviewer
              after: claims                  by: 1 day
              automation: never
  schedule  - system: the scheduler          owner: Social agent
              after: legal
              automation: autonomous
  readout   - runs collect-and-report        owner: Analytics agent
              after: schedule + 14 days
              automation: autonomous
policy:
  no claim ships without a citation in the claims register
  legal approval is a human gate and is never delegated to an agent
  an asset changed after approval goes back through legal. There is no
    minor-change path
amendments:
  v2 - claims moved out of legal into its own phase, so legal reviews
       the exceptions rather than every asset (debrief, run 12)
  v3 - claims raised from supervised to autonomous after twenty clean
       runs (debrief, run 31)
  v4 - readout moved from 7 days to 14. A week was too early to see
       anything on the slower channels (debrief, run 38)

Version 2 is what fixed the bottleneck. Legal used to read every asset, which put one reviewer in front of a process that runs forty times a quarter. Moving the claims check into its own phase did not change who approves anything. It changed how much reaches the reviewer, who now reads only the assets that failed the check.

The records a run produces

Each phase leaves whatever record its own kind of work produces. A phase that convenes a collab pattern leaves that pattern's CONVENED and DONE records. A phase that runs a work pattern leaves its plan and its JOB DONE. A system phase leaves one line saying what happened and when. The run opens and closes around all of them:

RUN: mkt/social-campaign v4 · run 47
started: 2026-08-03 by Head of Social
trigger: campaign brief CB-118, approved in mkt/campaign-planning run 9

RUN DONE: mkt/social-campaign v4 · run 47
outcome: completed
result: 14 assets live across 4 channels, scheduled 2026-08-11
open: one asset held back - the claim about response times has no
      citation, and the claims register entry is with Legal

Between them, those records answer what an auditor asks for. The process document says what the process is, and the run records show that it ran. Because each record was written as the work happened and names who acted and when, nobody has to reconstruct any of it afterwards.

a worked catalog

A marketing department's catalog

This is the whole department: eleven processes, one row each. It is what you have after a first pass, which is enough to see what exists, who owns it, and where the work piles up.

Two rows say documented rather than running, which means the process is written down but nobody has run it against the document yet. A catalog that says a process is running before it has run is one people stop believing, so the state is recorded as it stands.

The same catalog as a graph

Drawing the feeds and fed by columns shows which processes hold up which. The number on a box is how many others wait on that one, and eight of the eleven are drawn here.

Two processes have a lot of other work depending on them, and neither one runs very often. The competitor review feeds six others and runs sixteen times a year. The claims register feeds three of the four processes that write anything a customer will read, and runs ten times a quarter. If you ranked this catalog by how often each process runs, both would come near the bottom, and both are still worth automating early.

The high-volume work is somewhere else. Inbound lead routing runs four hundred times a week, more than everything else in the catalog put together, and it is already autonomous. That is what usually happens to the busiest process in a department, whether or not anyone planned it.

Two processes wait on the same person. Social and email campaigns both report never, and in both cases it is the same legal approval done by the same reviewer, which puts one person in the path of sixty runs a quarter. The catalog cannot automate that away. What it does tell you is that the thing to fix here is how that review is staffed, rather than the automation level.

The full catalog, the eleven rows, and what the department's first pass got wrong are in the worked example.