Documentation menu
Open protocol · Draft core-2
Agent Process
An open protocol for business processes that AI agents and people work through together. Write a process as one plain-language file; a process server hands each step to an agent or a person, checks what comes back, and keeps the record.
What it is
One file. Steps for agents and people.
A short YAML frontmatter names the process, the inputs a run starts with, and its steps in order. A body in plain language says what the process is for.
Agents connect to a process server over MCP and do the work with their own tools. People approve and complete their tasks. The server keeps the order and the record.
---
name: supplier-onboarding
description: Check a new supplier and get finance approval.
inputs:
vendorName: string
steps:
- id: check_vendor
agent: Check the vendor against the OFAC and EU sanctions lists.
output: { cleared: boolean }
evidence: [file]
next:
- { to: approve, when: Vendor is cleared on both lists }
- { to: decline, when: Any sanctions hit }
- id: approve
person: finance-approver
approve: Approve when the vendor is cleared and the spend is justified.
on_reject: check_vendor
next: done
- id: decline
finish: declined
- id: done
finish: onboarded
---
# Supplier onboarding
The agent screens the vendor, finance approves, and the supplier is onboarded.Why
Agents can do the steps. Something has to hold the process.
Agents can now screen a supplier, check an invoice or draft a contract summary. What they lack is everything around the steps. Who goes next? Who must sign off? Was the output what was asked for? Who did what, and when?
Agent Process puts that in a server and keeps the process file small. Everything specific to a scenario stays in plain-language instructions that the agent or person adapts to. The design rule comes from Agent Skills: the format carries as little as possible; the instructions and the model carry the rest. The one exception is the wire between agent and server, where every tool contract is exact.
What a server guarantees
Five rules, enforced on every run. Nothing else.
- 01
Order
Work exists only along the declared steps.
- 02
One actor at a time
A claimed step belongs to one agent until it submits, hands off, or its lease ends.
- 03
Acceptance
Output must match the declared fields and evidence, or nothing changes and every issue comes back at once.
- 04
People decide
Only a person completes an approval or a person's task. An agent never can.
- 05
Immutability
A published version never changes, and a run keeps its version for life.
How it works
From a file to a finished, recorded run.
- 01
Write
An author writes PROCESS.md: steps for agents, people's tasks, approvals, waits and finishes, with the fields and evidence each must return.
- 02
Publish
A server checks the file, maps each role to a group of people, and publishes a numbered version with a content hash.
- 03
Work
Agents find, claim and submit steps over MCP. People get work items and decide. A stuck agent escalates to a person.
- 04
Record
Every completion keeps who, when, the output, the evidence and a summary. Rework keeps earlier attempts in history.
Start here
Three ways in.
Write a process
A complete process in one file, then a test run step by step.
Quickstart Agent buildersConnect an agent
Find work, claim it, do it with your own tools, and submit on any conforming server.
Add support Server implementersRun processes
Parse, publish, enforce the five guarantees and keep the record.
Implement a serverOpen development
Developed in the open. Called a standard only when it has earned it.
The specification, the JSON Schemas, the agent skill and the conformance fixtures are Apache-2.0 on GitHub. This is a draft: one server implements it today, and it will be called a standard only when a second, independent implementation passes the conformance suite.
Proposals go to GitHub Discussions. The bar for adding to the specification is high, and every proposal starts from a real process that the core cannot express.