The Open Co-Prompting Standard

1. Scope

This Standard defines how a group of people delegates work to AI agents during a live, synchronous session — a meeting, a design review, a war room, a ward round, a trading desk huddle — without losing track of who is responsible for the result.

It is a standard of conduct, not a software interface. It specifies what participants say, in what order, and what each utterance commits them to. It does not specify a wire format between machines, a model, a vendor, or a user interface. Conformance Level 3 (Section 10) additionally defines an event record so that sessions can be instrumented, but Levels 1 and 2 require no software at all.

1.1 What this Standard is not

It is not an agent-to-agent protocol. See Section 3.
It does not govern what an agent is permitted to do, what data it may access, or how it is secured. Those concerns belong to an organization's own policies.
It does not replace professional judgment, licensure obligations, or any legal duty. Section 9 exists to protect those obligations, not to substitute for them.

2. Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174, when and only when they appear in all capitals.

Defined terms appear in spec/glossary.md.

3. Motivation

Existing protocols in this space describe machines talking to machines. Model Context Protocol connects an agent to tools. Agent-to-agent protocols connect agents to each other. Open Floor Protocol arbitrates turn-taking between conversational agents.

None of them describe the layer where the risk actually concentrates: several qualified humans, in one room, each driving their own agents, talking to each other.

That layer has a specific failure mode. When someone says "I'll look into that" and starts typing into an agent, the room loses the ability to answer four questions:

Who heard the request?
Who turned it into a prompt, and what did that prompt actually say?
Who is watching the work?
Who is accountable for deciding whether the output is correct?

Agents produce a large amount of motion very quickly. Without an answer to those four questions, motion is not progress — it is unattributed work product arriving in a professional setting where somebody's licence, signature, or fiduciary duty is attached to the outcome.

This Standard exists to keep those four questions answerable at every moment of a session.

4. Relationship to prior practice

This Standard extends principles from established practices in high-reliability fields. It is not endorsed by, affiliated with, or evaluated by any of the organizations named below, and the evidence supporting those practices does not transfer to this Standard.

Closed-loop communication, originating in military radio procedure: a sender transmits, the receiver acknowledges and repeats the message back, and the sender confirms the readback is correct. The Claim beat (Section 6.2) is a direct application of this three-step pattern.
Crew Resource Management in aviation, and its adaptation into healthcare as team-training programs that formalize call-outs (announcing critical information to the whole team while directing responsibility to a named individual) and check-backs (the receiver repeating information to confirm it was understood).
Structured clinical handoff tools, which treat a handoff as the transfer of information together with authority and responsibility, and which hold that the sender remains accountable until the receiver has explicitly acknowledged acceptance. Several such tools require a synthesis step in which the receiver restates what they heard.
Deliberative assembly procedure, which establishes that a motion must be stated, seconded, and disposed of — never left ambiguous.

The contribution of this Standard is not the discovery of these patterns. It is their application to a case none of them anticipated: a delegate that is not a person, that works invisibly, that produces confident output at speed, and that has no professional accountability of its own.

4.1 Relationship to research on co-prompting

The term co-prompting (equivalently, collaborative prompting) is established in the human-computer interaction literature, where it is defined as a process involving the sharing and discussion of prompts for generative AI systems among two or more individuals. Prior work has studied tooling to support collaborative prompt authoring, and has documented the awareness and communication costs that arise when collaborators cannot see each other's prompts.

This Standard does not claim to originate the term or the practice. It addresses a different question: given that people already co-prompt, what conduct makes co-prompting accountable in a professional setting?

See spec/background.md for citations.

5. Roles

A role is a position held with respect to one task. The same person will hold different roles for different tasks in the same session, often simultaneously.

Role	Definition
Caller	The participant who raises a task. Any participant MAY be a Caller.
Listener	A participant capable of owning the task, who must acknowledge before the task is described.
Owner	The single participant accountable for the agent work on a task from Claim until a terminal state.
Contributor	Any participant who supplies context to the Owner's prompt.
Adjudicator	The participant qualified to decide whether the agent's output is acceptable.

5.1 Owner and Adjudicator

The Owner and the Adjudicator MAY be the same person. In regulated settings they frequently are not: an analyst owns the task, and a licensed professional adjudicates the result.

A profile (Section 11) MUST state who is eligible to adjudicate each call type in its domain. Where a jurisdiction, licensing body, or engagement agreement designates a responsible person, the profile MUST NOT designate anyone else.

6. The session loop

The loop has four beats and ten states. The beats exist so the loop can be taught and spoken. The states exist so it can be specified and instrumented.

CALL ─→ ACKNOWLEDGE ─→ DESCRIBE ─→ [CLARIFY] ─→ CLAIM ─→ PROMPT ─→ [AUGMENT] ─→ RUN ─→ RETURN ─→ ADJUDICATE
└────────────── Call ──────────────┘            └ Claim ┘  └──── Co-prompt ────┘  └──────── Close ────────┘

Square brackets denote OPTIONAL states.

6.1 Beat one — Call

CALL — The Caller utters a call type from the active profile's vocabulary and then stops speaking. The Caller MUST NOT describe the task in the same utterance.

The purpose of the pause is to let participants who are mid-prompt reach a stopping point before information they are accountable for hearing is spoken.

ACKNOWLEDGE — Each Listener utters an acknowledgement.

The Caller MUST NOT proceed to DESCRIBE until every Listener has acknowledged.
A Listener who needs more time before acknowledging SHOULD utter a hold, then acknowledge when ready. A hold is not an acknowledgement.
If no Listener acknowledges within a reasonable interval, the Caller SHOULD re-issue the CALL.

DESCRIBE — The Caller states the task in one or two sentences: what must be determined, and where. The Caller then stops speaking.

The description SHOULD identify the subject matter and its location precisely enough that a Listener could restate it. It SHOULD NOT include a proposed solution unless the Caller intends to constrain the approach.

CLARIFY (OPTIONAL) — Any Listener MAY ask a clarifying question before any participant claims the task.

A clarifying question MUST NOT be interpreted as a claim.
A Listener asking for clarification SHOULD mark it as such, so the room does not mistake the question for ownership.

6.2 Beat two — Claim

CLAIM — One Listener takes ownership and becomes the Owner.

A CLAIM MUST include a restatement of the task in the claimant's own words. A claim without a restatement is not a valid claim.
A CLAIM MUST identify the claimant, by name or by unambiguous voice recognition among the participants.
From a valid CLAIM until a terminal state, the task MUST have exactly one Owner.

The restatement is the load-bearing element of this beat. It is the only point in the loop where the Caller can detect that the task was misheard, and it is cheap relative to the cost of discovering the error after an agent has run.

Contention. If two participants claim simultaneously, the first unambiguous claim prevails and the other participant MUST withdraw. Contention MUST be resolved before PROMPT. Participants MUST NOT debate the merits of the assignment during the loop; a reassignment is a new CALL.

Prior ownership. If the task is already owned from earlier in the session, the existing Owner MUST say so and report status instead. The loop MUST NOT be re-run for a task that is already owned.

6.3 Beat three — Co-prompt

PROMPT — The Owner utters the prompt aloud before submitting it to an agent.

At Conformance Level 2 and above, the Owner MUST utter the prompt aloud before RUN.
The utterance SHOULD convey what the agent is being asked to investigate, against what inputs, and what form the answer should take. It need not be read verbatim.
Where a prompt is too long to speak in full, the Owner MUST speak a faithful summary and MAY supply the remainder in writing. Omitting the spoken summary is a conformance failure.

Announcing that work is underway is not a substitute for this state. "I'm on it" conveys nothing that lets the room correct a misunderstanding. The purpose of PROMPT is to expose the Owner's interpretation while it is still cheap to change.

AUGMENT (OPTIONAL) — Any participant MAY supply additional context after hearing the prompt and before the agent runs.

The Owner MUST acknowledge each augmentation aloud and state whether it was incorporated.
An augmentation that the Owner declines to incorporate MUST be declined audibly, with a reason. Silent omission is a conformance failure.
Augmentations offered after RUN SHOULD trigger a re-prompt where the cost of restarting is lower than the cost of an answer built on an incorrect premise.

Any participant may contribute, including participants who are not eligible to own the task. Contribution does not transfer ownership.

6.4 Beat four — Close

RUN — The Owner submits the prompt and the agent begins work. The session continues; the room does not wait.

The Owner remains accountable for monitoring the work. Other participants MUST NOT direct new tasks at the Owner until the Owner has reached a terminal state or has explicitly parked the task.

RETURN — The Owner reports the result to the room.

The report MUST state what the agent produced and MUST distinguish it from what has been verified. A result that has not yet been adjudicated MUST be labelled as preliminary when reported.

ADJUDICATE — The Adjudicator decides the disposition.

Agent output MUST NOT be treated as an outcome, relied upon, transmitted to a client, or incorporated into a work product until an Adjudicator has accepted it.
The Adjudicator MUST be qualified under the active profile for that call type.
The disposition MUST be one of the terminal states in Section 8 and MUST be stated audibly.

7. Vocabulary

The loop in Section 6 describes what must happen. This section names what people actually say.

Every cue below is a spoken phrase bound to a state or an invariant. They are listed here, in the core, rather than in individual profiles, because they mean the same thing in every domain. A profile that needed to invent its own word for acknowledging a call would be inventing a dialect, not a discipline.

7.1 The cue registry

The requirement level of a cue is the requirement level of the behavior it carries. A MUST cue is not a stylistic preference — omitting the utterance means the invariant it serves was not satisfied.

Cue	Default phrase	Carries	Level
`acknowledge`	"Ready"	`ACKNOWLEDGE`; invariant 2	MUST
`claim`	"Mine"	`CLAIM`; invariants 1 and 3	MUST
`prompting`	"Prompting"	`PROMPT`; invariant 4	MUST at L2+
`augment_response`	"Got it" / "Didn't include that"	`AUGMENT`; invariant 5	MUST
`preliminary`	"Preliminary"	`RETURN`; Section 9.1	MUST
`accepted`	"Accepted"	`ADJUDICATE`; invariant 7	MUST
`rejected`	"Rejected"	`ADJUDICATE`; invariant 7	MUST
`parked`	"Parked — waiting on …"	`ADJUDICATE`; invariant 7	MUST
`superseded`	"Superseded by …"	`ADJUDICATE`; invariant 7	MUST
`hold`	"Hold"	before `ACKNOWLEDGE`	SHOULD
`already_owned`	"Already mine"	prior ownership	SHOULD
`pass`	"Pass"	contention at `CLAIM`	SHOULD
`return`	"Back with …"	`RETURN`	SHOULD
`out_of_scope`	"Out of scope"	Section 9.2	SHOULD
`files_first`	"Files first"	before `PROMPT`	SHOULD
`clarify`	"Clarify: …"	`CLARIFY`	MAY
`propose`	"Propose: …"	before `PROMPT`	MAY
`augment`	"Add: …"	`AUGMENT`	MAY
`running`	"Running"	`RUN`	MAY
`check`	"Check: …"	after `RETURN`	MAY
`handoff_offer`	"Yours — I'll feed it"	`AUGMENT`, across disciplines	MAY

Three of these deserve emphasis because they are the ones rooms drop first.

augment_response is MUST because invariant 5 is MUST. When someone offers a constraint and the Owner says nothing, the contributor reasonably believes it was included. Silence is the failure mode; both "Got it" and "Didn't include that, because …" satisfy the invariant, and only silence violates it.

preliminary is MUST because an unlabelled result becomes a commitment the moment someone outside the professional relationship repeats it. The label costs a word.

hold is SHOULD rather than MUST because a Listener who simply takes two seconds and then acknowledges has broken nothing. It exists so that taking those seconds is a recognized move rather than an awkward silence.

7.2 Universal call types

A call type opens the loop. Most are domain-specific and belong in a profile, but one is universal:

Call type	When
Question	A decision is unknown and blocks progress. May resolve with no agent work at all.

Every profile inherits Question. A profile MUST NOT redefine it and MUST NOT declare a call type of the same name.

This list is deliberately short. A term is promoted to universal only once independent profiles have converged on it in practice — not because it seems like every industry ought to have one.

7.3 Dialects

A profile MAY substitute the phrase for any cue where its domain genuinely says something else. Architecture and engineering rooms say "Listening" where software teams say "Ready"; both acknowledge, and neither is wrong.

A substitution:

MUST keep the cue's meaning and its requirement level
MUST be declared in the profile's cueDialect so the substitution is documented rather than folklore
MUST NOT remove the cue or make it optional

A profile that declares no dialect uses the default phrases. Most profiles should need no dialect at all; a long dialect block usually means the author is renaming for taste rather than recording how their people already speak.

8. Terminal states

Every claimed task MUST reach exactly one terminal state before the session ends.

State	Meaning
Accepted	The Adjudicator accepts the output. It may be relied upon within the limits the Adjudicator states.
Rejected	The output is not acceptable. The task is closed. A further attempt is a new `CALL`.
Parked	Progress is blocked by a dependency outside the session. A Parked task MUST name the blocker and the party responsible for clearing it.
Superseded	The task was overtaken by another task or by a decision that made it moot. The superseding task MUST be identified.

A task that is silently abandoned has not reached a terminal state and is a conformance failure. This includes discarding an unsatisfactory agent result without saying so: an undisclosed discard is indistinguishable from work never attempted, and the question will return.

9. Accountability invariants

These invariants are the substance of the Standard. A session that follows the vocabulary but violates an invariant does not conform.

Single ownership. A task MUST have exactly one Owner from CLAIM until a terminal state. Ownership MUST NOT be shared, implied, or assumed.
Acknowledged attention. The Caller MUST NOT DESCRIBE until every Listener has acknowledged.
Restatement on claim. A CLAIM MUST include a restatement of the task.
Audible prompt. At Level 2 and above, the prompt MUST be uttered aloud before RUN.
Acknowledged augmentation. The Owner MUST state aloud, for each augmentation, whether it was incorporated.
Qualified adjudication. Agent output MUST NOT be treated as an outcome until accepted by a qualified Adjudicator.
Explicit disposition. Every claimed task MUST reach exactly one terminal state, stated audibly.
No silent transfer. Ownership transfers only by an explicit statement from the current Owner and an explicit acceptance by the new Owner. An Owner remains accountable until that acceptance occurs.

9.1 Preliminary results

A result that has not been adjudicated MUST be labelled preliminary whenever it is spoken, and MUST NOT be presented to a client, counterparty, or authority as a finding.

This invariant exists because an unlabelled agent output becomes a commitment the moment someone outside the professional relationship repeats it. The label is cheap. Withdrawing a number a client has already acted on is not.

9.2 Scope boundaries

Where a called task falls outside the scope of the engagement under which the session is being conducted, a participant SHOULD say so during the loop rather than absorbing the work silently. This Standard takes no position on how such work is authorized; it requires only that the boundary be named while everyone is present.

10. Conformance

Conformance is claimed per session, not per organization. See spec/conformance.md for full requirements.

Level	Name	Summary
L1	Spoken	The loop is followed verbally. No record is required.
L2	Recorded	Additionally, every claimed task has a durable record of its Owner and terminal state, and prompts are uttered aloud.
L3	Instrumented	Additionally, the session emits machine-readable events conforming to `schema/session-event.schema.json`.

11. Profiles

A profile adapts this Standard to a domain by supplying vocabulary and accountability rules. A profile MUST conform to schema/profile.schema.json and MUST NOT weaken any invariant in Section 9.

A profile declares:

callTypes — the domain's call vocabulary
ownerEligibility — who may own each call type
adjudicator — who is qualified to adjudicate each call type
additionalStates — OPTIONAL additional REQUIRED states, such as a formal sign-off
retention — what MUST be recorded and for how long

Profiles MAY add states, add vocabulary, and tighten requirements. Profiles MUST NOT remove states, remove invariants, or lower a requirement level from MUST to SHOULD.

Published profiles live in profiles/. To write one, see profiles/WRITING-A-PROFILE.md.

12. Versioning

This Standard uses MAJOR.MINOR versioning, documented in VERSIONING.md. Version 0.x is a draft; breaking changes may occur in any release. A conformance claim MUST cite the version it was assessed against.

13. Citation

The Open Co-Prompting Standard, Version 0.2 (Draft). https://co-prompting.com