Notation for the human-agent symphony: how CHAP records human judgment alongside MCP

For most of history, a piece of music existed only while someone was playing it. When the last note faded, the performance was gone, and nobody who missed it could replay it, verify it or improve it. Notation changed that by giving performance a written form: once a piece was on the page, it could travel between cities and centuries, and a hundred players could follow one score and stay together.

Musical notation for the human-agent symphony

Agentic work is at a similar point today. A single support ticket can pass through a person who delegates it, an agent that drafts a reply, a tool the agent calls, a second agent that takes over, and a reviewer who corrects the result. The Model Context Protocol gives agents a shared way to reach tools, and the Agent2Agent protocol gives them a shared way to reach each other. The decisions people make along the way still land in chat threads, tickets and logs that every system writes differently, so when someone later asks who did what, in what order and on whose authority, a team has to rebuild the answer by hand.

At AGNTCon + MCPCon Europe in Amsterdam in September, we presented the Collaborative Human-Agent Protocol (CHAP), an open proposal for giving that collaboration a written form. This post walks through the design with the analogy we used on stage, and shows how CHAP runs as an ordinary MCP server.

A room with its rules on the door

CHAP begins with a room, called a workspace. The rules of the room are written on its door, and any participant can read them with workspace.describe before it acts. The people, agents and services in the room wear typed badges such as human:alice, agent:triage-bot#v3 and service:coordinator, and each of them enters with participant.join and leaves with participant.leave, much like signing a visitor book.

A workspace, its typed participants and the visitor book

The work itself moves through the room like a parcel. Alice creates a task and hands it to the triage bot with task.create, and from then on anyone can follow it the way they would follow a delivery: task.update reports progress, and task.complete hands back the result with the agent's draft attached as an artefact.

A task tracked from created to completed

Every message is a single JSON-RPC 2.0 envelope, the same framing MCP uses. It names the room, the sender, the recipient, the time and the method, and the coordinator appends every accepted envelope, in arrival order, to the workspace's audit log. Signatures, identity binding and a hash-chained log come from optional profiles, which keeps those capabilities outside the mandatory Core.

Seven notes and a small Core

Add audit.read, which reads that log back, and you have all seven methods of CHAP's mandatory Core. A scale has seven notes and every melody is built from them, and every CHAP session is built from these seven methods in the same way. Keeping the mandatory part this small means every implementation can be tested against all of it.

The seven Core methods as the seven notes of a scale

Everything beyond the Core is an optional, versioned profile, and a workspace switches on only the profiles its work needs. Our rule of thumb is to add a profile when you feel its pull. Review usually pulls first: the moment a team says "please look at this before it ships", the workspace adds review and gains the five actions that carry human judgment, which are approve, reject, override, abstain and escalate.

Other profiles follow as the work demands them. whisper puts a deadline on a quick question to one named person, deliberation records a vote with its dissent, and handoff passes work across a shift with its context intact. routing sends riskier work to more senior reviewers, modes lets a new agent earn autonomy in stages from shadow to trial to production, and control can pause, snapshot or roll back a workspace. When the record has to satisfy an auditor, security-signed, identity-oidc, identity-vc and audit-scitt add signed envelopes, identities bound to OIDC tokens or verifiable credentials, and an external transparency log. The door announces every active profile, so a newcomer, human or agent, knows the rules before it says a word.

Eleven optional profiles in orbit around the Core

Stringing the methods together

Give each participant a line on a score, and write each envelope as a note on the line of whoever sent it. Read from left to right, the evidence log becomes the score of the session. Our support ticket reads like this: the room is described and the players join, Alice hands over the task, the triage bot reports progress, delivers a draft and asks for review, and Alice overrides the draft with a recorded reason.

That last note is the one most systems lose. In CHAP, an override is its own record, carrying an RFC 6902 JSON Patch against the draft together with the reviewer's reason (abridged here):

{
  "jsonrpc": "2.0",
  "id": "01J8Z6N4Q7",
  "method": "decide.override",
  "params": {
    "workspace": "wsp_support",
    "from": "human:alice",
    "to": "service:coordinator",
    "ts": "2026-09-17T09:14:31Z",
    "task_id": "tsk_48219",
    "intent_preserved": true,
    "diff": [
      { "op": "replace", "path": "/body/opening", "value": "Thanks for following up." }
    ],
    "rationale": "Too apologetic for a routine update",
    "tags": ["tone-adjusted"]
  }
}

The support ticket as a score, with the review shape traced

After a few sessions you begin to recognize the shapes, the way you recognize a tune from its opening bars. A review rises to a decision and resolves. A whisper is a grace note to one named person and back, and a handoff carries the melody from one player to the next without dropping a bar. Because every tool records these shapes in the same vocabulary, a team can compare them across frameworks, vendors and years.

The whisper and handoff shapes

Replay, verify, improve

Once collaboration is written down, it can do what written music does. A session that takes forty-five minutes of digging through logs and threads to reconstruct becomes a single audit.read query. When a workspace chains its log, each entry carries a hash of the one before it, and a verifier can replay the chain to confirm that the entries it holds are internally consistent. With security-signed, each envelope also carries an Ed25519 signature that verifies against the sender's key, and identity-oidc or identity-vc binds that key to a real person or organisation. Providing evidence outside the chain needs an external witness: audit-scitt registers entries with an IETF SCITT transparency service, whose receipts show that an entry existed at a given time, independently of the coordinator.

Replaying a session and verifying its chain

The record can also help teams improve performance. Overrides and abstentions can show where human review is still shaping the work. Teams can use that evidence to improve their agents and inform decisions about how much autonomy to give them, and modes records that decision as an explicit promotion.

CHAP as an MCP server

CHAP is designed to ride on the plumbing teams already run. The reference coordinator ships as an MCP server, @brightbeamai/chap-coordinator-mcp, which exposes every CHAP method as an MCP tool, 39 in all, from chap.workspace.describe to chap.decide.override and chap.audit.read. Any MCP client can host it:

{
  "mcpServers": {
    "chap": {
      "command": "npx",
      "args": ["-y", "@brightbeamai/chap-coordinator-mcp"]
    }
  }
}

An agent then records its work by calling tools it already knows how to call, and a reviewer's decision arrives through the same server as chap.decide.approve, chap.decide.override or chap.abstain.declare. The same methods are available as skills on an A2A agent card, and bridges for LangGraph, Pydantic AI, LlamaIndex, AG2 and Google ADK keep the record in the same CHAP format across frameworks.

CHAP composed with MCP and A2A

What we would pass on

Three design choices have held up as we built CHAP, and they may help anyone designing human oversight for agents. The first is to record a human decision as its own event with its reason, instead of folding it into an edit, because the reason is what a team learns from. The second is to put the rules on the door: when a workspace announces its active profiles, a newcomer can adapt without any prior agreement. The third is to keep the mandatory Core small and move everything else into optional profiles, so a single developer and a regulated production line can speak the same protocol.

CHAP is an open proposal, and it improves with use. Version 0.2 is a public draft, stable enough for experimentation and early pilots, and its profile surface may still change. The specification, reference coordinators in TypeScript and Python, and a conformance suite are all open, and the full design is described in the CHAP paper (arXiv:2606.09751). Feedback from teams running MCP in production is especially welcome, as are proposals for new profiles.

The CHAP specification is published under CC BY 4.0, with the code under Apache 2.0. Learn more at chap.brightbeam.works and find the code at github.com/BrightbeamAI/chap.

About the author

Dr Arsalan Shahid is Principal Solutions Director at Brightbeam AI, where he heads applied research, and co-author of the Collaborative Human-Agent Protocol (CHAP). He holds a PhD in high-performance computing and AI and an MBA.