CHAP, the Collaborative Human-Agent Protocol: an MCP/A2A runtime with human sign-off and verifiable records

Who it's for

CHAP (Collaborative Human-Agent Protocol) is an open protocol: it turns the "human in the loop" decisions of approval, override, handoff, and escalation into one single auditable shape that spans both MCP and A2A.

It fits two kinds of people. First, teams that want to genuinely embed human sign-off into agent workflows and require a verifiable record for every change the coordinator accepts; second, developers who already run their own workflows but lack a way to record "who approved what, and when". Typical situations: multiple agents running tasks in parallel, decision points that must block on a human, and people and agents taking turns at the same batch of tasks.

It also has clear cases where it does not fit: if you just want an agent to run a script to completion, with neither sign-off nor records, then the integration cost of CHAP will exceed its value — its value comes precisely from the steps that "require a human signature".

Your first attempt in 3 minutes

There is only one prerequisite: Python 3.10 or later, and no other dependencies to install. The repository ships with START_HERE.md, which lets you bring up a local review console on your own machine to watch how one call is accepted and how one decision is recorded.

Clone and start:

git clone https://github.com/BrightbeamAI/chap.git && cd chap
python3 start-here/start.py

There are two places to configure. On the integration side, it happens when the workspace is created: a new workspace broadcasts the two profiles core/1.0 and review/1.0 by default, and you can also name other profiles of your own to negotiate version identifiers. The local side is covered by START_HERE.md in the repository, which holds the instructions for launching the review console. If you want to embed the coordinator into your own process or run it as a service, you can instead use the officially provided coordinator package (for TypeScript, npm install @brightbeamai/chap-coordinator; for Python, pip install chap-coordinator) — that step is not required for a first attempt.

For the first call, pick the read-only audit.read: it reads and returns the workspace's audit records without writing any state, so it is the safest possible first touch. The observable success signal is that the call returns audit record entries in order; with the hash chain enabled and the most recent chain head kept independently, you can also use those entries to check whether a given entry has been altered.

Use cases

Scenario one: wire a "human sign-off required" write action into an agent workflow. The agent submits a task with task.create and starts a review with review.request; a human then gives a verdict with decide.approve, decide.reject, or decide.override. The coordinator validates each call against the workspace rules and records every change it accepts in the workspace audit log. Evidence scope: the README gives only the role semantics of this verb set and the behavioral convention that "accepted changes are recorded"; it does not give the request field format, the authentication method, or sample JSON, so when you build on it, the coordinator package's interface definition remains the source of truth.

Scenario two: handoff, escalation, and after-the-fact traceability across multiple agents and multiple people. A person or agent proposes a handoff with handoff.propose, reports an escalation with escalate.raise, and then pulls the records back with audit.read to check whether the handoff was accepted and who rejected the escalation. Evidence scope: the README explicitly lists these two verbs along with audit.read, and states that the audit log records every change in order; determining whether a given record has been altered depends on the hash chain and its prerequisites (see the boundaries below), and the README does not give a more detailed comparison procedure.

Boundaries

• The hash chain is a guarantee with prerequisites, not an "unerasable" one. When the hash chain is enabled and the most recent chain head is stored somewhere the operator cannot reach, altered entries are detected during verification; when the hash chain is off, or the chain head sits in the same place as the operator, that guarantee does not hold.
• Signatures and identity are optional extensions (profiles). When enabled, they require every call to be signed, bind the signing key to a verified identity, and submit entries to a transparency log — which brings key management and external publication costs.
• The coordinator is an intermediary with write side effects: it validates calls and records every change it accepts, so the call itself leaves a trace; before integrating, confirm that the workspace rules and audit use fit your own compliance requirements.
• The audit log covers only accepted changes; rejected calls are not written to it, so it is not a full request log, and using it to count "who attempted what" is not complete.
• Where you store the chain head and the records is your call: the official guidance notes that the most recent chain head must be separated from the operator, and that is the only prerequisite for the first guarantee above — do not put both in the same writable location.
• The scope of the evidence itself: what can be confirmed is the verb semantics, the profile mechanism, and the hash chain and signature requirements; the repository gives no description of the storage backend, concurrency model, deployment topology, or tenant isolation, and that part has to be verified on your own.