Evidence Is Not Oversight

We standardised how agents reach tools. That is MCP. We standardised how agents reach each other. That is A2A. Nobody has standardised the room where humans and agents do accountable work together, which is the part anyone will be asked about later.

So the moment that matters most, when a person reads what a model produced and changes it, disappears. It ends up in a ticket comment, a chat thread, a design tool's revision history, or in one person's memory. Ask a team six months on why a human overrode an agent's recommendation and you get a reconstruction rather than a record.

In June, Brightbeam AI published the Collaborative Human-Agent Protocol, a working draft that takes aim at that gap. The premise is that human judgement in an agentic workflow is a collaboration event, and collaboration events need a representation on the wire rather than in product-specific application code.

Credit where it belongs. Brightbeam could have kept this as internal product architecture and sold it as a differentiator, which is what most vendors do with a good abstraction. Instead they wrote it up as an open protocol, put it on arXiv, published a reference implementation, and listed in the paper itself every place the work falls short. That is the slower commercial route and the right technical one, and there is no competing proposal to point at.

Crediting the attempt is not the same as recommending adoption, so the rest of this piece is about what the draft does not yet do. The paper largely makes that case for itself.

What it proposes

The core is small. A workspace, meaning the bounded space where work happens under a stated policy. Participants, who may be humans, agents, services, groups, or bridges to another system. Tasks. Artefacts, meaning drafts, decisions, overrides, citations. And an append-only evidence log, where every accepted message becomes an entry that can be hash-linked, signed, and anchored to an external transparency service.

Everything else is optional and layered on when a workflow needs it. Review turns approve, reject, override, abstain and escalate into typed events. Modes run an agent in shadow, then trial, then production. Beyond those sit routing, deliberation with quorum and weighted votes, shift handoff, identity binding, message signing, and transparency-backed audit.

The distinctive event is the structured override. A human approves a modified version of an agent's output, and the record carries the base snapshot, the diff, the reviewer's rationale in their own words, tags, and the policy references that applied. That single record then serves as an audit trail, a supervision signal, a policy signal, and an adoption signal at once. I think that claim holds.

The sceptical read

It is version 0.2, a public draft, and the wire format may still move. There is one reference implementation where standards-track convention wants two independent ones passing the same interoperability suite, and the authors name that as their most consequential next step. The method catalogue lists fifty-nine methods; reference code exercises the core set plus four profiles, and the rest are specified but not demonstrated. No implementation can claim full conformance under this revision, because the interoperability substrate needed to test it does not exist yet.

The profile surface is also expected to move faster than the core, and the specification does not yet formalise how deployments should handle that upgrade discipline.

Early is the right word for all of this. The distinction matters when someone brings the specification to your architecture board as a solution rather than a direction.

What it does not discharge

The protocol produces a verifiable record of who decided what, when, and on what basis. It makes no claim about whether that record satisfies any regulatory regime, and says so explicitly. Conformity assessment, framework alignment, control reliance, none of that sits inside its scope. Sufficiency is left to the deploying organisation and its regulators, which is the right place for it.

Read the AI Act carefully and the split is sharper than most summaries suggest. Article 14 puts the oversight measures on the provider, who must either build them into the system before it reaches the market or identify measures the deployer can implement. Article 26 then puts operational duties on the deployer: assign oversight to people with the competence, training and authority to exercise it, and retain the logs the system generates for at least six months.

Note what Article 26(6) actually covers. Logs automatically generated by the AI system, to the extent they are under the deployer's control. A structured record of human judgement is not that. It is additional, voluntary, and nobody is currently required to keep it.

There is a harder problem in the paper's own threat model. The protocol does not defend against a participant who lies within the schema. A human who approves without reading produces an evidence chain byte-for-byte as clean as one produced by a human who read carefully and made the right call. Rubber-stamping is invisible to the wire format, which means the record demonstrates that oversight occurred, not that it was any good.

Two further problems are openly unsolved. Confidentiality of evidence content is not handled at protocol level, so sensitive material has to live outside the chain and be referenced by hash. And an append-only, hash-linked record sits awkwardly against a right to erasure, which the authors list as future work.

The idea worth taking regardless

One concept in this draft is worth adopting whether or not the protocol survives.

The specification distinguishes two kinds of human override. In the first, the person kept the agent's underlying decision and changed how it was expressed. In the second, the person replaced the decision itself.

Any system that stores only the final text records these identically. A high rate of the first tells you the agent reaches the right answer in the wrong way, which is a retrieval, template, or tone problem. A high rate of the second tells you the agent reaches the wrong answer, which is a policy, context, or capability problem. They resolve to different fixes, and most organisations are guessing between them.

You do not need a protocol to start capturing that. You need two checkboxes and someone senior enough to insist they get ticked.

Where this leaves a leadership team

Three positions look defensible.

Watch it, if agentic work in your organisation is still confined to drafting and a human reads everything anyway.

Pilot it in shadow mode alongside your existing system of record, never as the system of record, if you are heading toward agents that touch customers, claims, code, or product quality.

Write the requirement rather than the product into your procurement language, if you buy AI systems from vendors. Ask for structured, exportable records of human decisions in an open format. That requirement survives any particular specification failing.

On timing, the pressure came off and the work did not. The Council gave final approval to the Digital Omnibus on AI on 29 June, deferring the Annex III high-risk obligations to 2 December 2027 and the embedded-product obligations to 2 August 2028. The Article 50 transparency obligations were not deferred and took effect on 2 August this year.

Sixteen extra months is a build window, not a reprieve. Most organisations running agents today cannot say who made a given decision, or why, and no specification is going to answer that for them. December 2027 is closer than it reads.