Messages can be read and never answered: add sender-declared severity and boomerang for blocking questions

[khaliqgant]

The gap

A message can be delivered, read, and still never acted on — and nothing in the system records that an answer was owed.

Concrete case from today: an agent finished its work, asked its coordinator one gate question, and sat blocked for nearly three hours. The message was not unread. It was read and passed over, because it arrived looking like every other status update. No unread badge would have caught it, because it was not unread.

"Unread" and "unanswered" are different problems. We solve neither today: check_inbox is broken (#1471), and even when it works it answers "did you see it", not "do you owe someone a decision".

Asked for

1. Sender-declared severity on a message. The sender knows whether it is a status update or a blocking question. Something like severity: info | needs-answer | blocking, defaulting to info.

2. Boomerang — an unanswered needs-answer/blocking message returns to the recipient's attention after an interval, rather than decaying into scrollback.

3. The clearing rule, which is the load-bearing part:

A boomerang clears when the SENDER marks it answered — not when the recipient reads it, and not on a timer.

This is the whole design. Read-receipts would have marked today's case resolved while the sender stayed blocked. Only the blocked party knows whether they are unblocked. A recipient reply is evidence, not proof — a reply that does not answer the question should leave the flag standing.

4. An escalation ladder. If a blocking message is unanswered after N intervals, it should surface to the recipient's supervisor, not merely repeat at the recipient. A single unresponsive coordinator should not be able to strand a dozen agents silently, which is the failure mode this exists to prevent.

Design notes

Severity inflation is the obvious failure, and the mitigation is to bind severity to a stated cost. A sender should have to say what staying blocked costs — "this blocks a customer-facing answer" versus "this affects a doc comment" — so a recipient can order the queue by something real. Severity with no stated cost tends to converge on "everything is urgent".

Boomerang interval should scale with severity, not be global. A blocking question repeating every few minutes is noise; one that never repeats is the current behaviour.

The recipient needs a queryable open set, not just interruptions. "What am I currently blocking?" should be one call and should be the first thing a coordinator reads — today the equivalent is maintained by hand in a state file, and that has proven more current than any tool-based sweep.

Do not build this on read state. Read state is the wrong signal and is also currently unreliable (#1471).

Why this class of defect keeps recurring

This is the same shape as several other issues in this repo: a spawn that reports success and launches nothing; a heartbeat written by a timer rather than by progress; a status field reporting healthy over a dead queue; an empty result indistinguishable from a failed query. In each case a well-formed signal stood in for a fact nobody verified.

An unanswered question sitting in scrollback is that same shape, with the coordinator as the component that silently failed. The fix is the same in kind: make the state explicit and make its absence loud.

Acceptance

• A blocking message unanswered past its interval visibly returns to the recipient, and does so again until cleared.
• Reading it does not clear it. Only the sender marking it answered clears it.
• A recipient can list everything currently blocked on them, ordered by declared cost.
• An unanswered blocking message escalates beyond the original recipient rather than repeating indefinitely.
• Test the negative case explicitly: a message read but not answered must still boomerang. That is the case this issue exists for, and a test that only covers "delivered and answered" would pass today.

[khaliqgant]

Protocol settled first — one change to what this issue asks for

The protocol counterpart (AgentWorkforce/c2a#3) now has a settled design, so this issue can be built against one definition instead of growing a second. The full argument is on that issue; what follows is only what changes here.

The one substantive change: do not add a severity field.

This issue proposes severity: info | needs-answer | blocking. That should map onto the response policy that already exists rather than sit beside it:

Proposed here	Existing concept
info	no obligation — the event simply does not carry must_respond
needs-answer	must_respond
blocking	must_respond

must_respond already is the severity signal. A second field beside it drifts from the policy — two places to look, two ways to disagree — and the usual end state is that everything is marked urgent, at which point the field sorts nothing. The distinction this issue is reaching for between needs-answer and blocking is a difference in cost, and cost belongs in a hint bound to something checkable, not in a severity ladder.

The replacement is an optional object on the event:

"obligation": {
  "blocks": "halted",
  "defaultAction": "hold until ruled"
}

• blocks: halted | degraded | none — a claim about the author's own execution state, not about how important the author thinks the message is. That distinction is the entire point: importance cannot be checked, execution state can. Claiming halted is falsifiable, because an author still emitting work events on that workstream was not halted. It self-polices in a way a severity enum cannot.
• defaultAction — free text: what the author will do absent an answer. Read, not sorted.

The recipient's queue orders by blocks, then age.

Unchanged, and now normative in the protocol:

• Discharge is author-side. Only the obligating author's signal closes it — not read state, not a recipient reply, not elapsed time. Reuse the existing reaction primitive (done from the obligating author on their own obligating event); no new signal type.
• Boomerang returns as a lightweight knock rather than a re-injection of full content.
• No backoff on the return interval. Backing off makes an unanswered obligation quieter over time, which is the failure being fixed.
• Escalation is recursive — each rung is itself an obligation with the escalation target as recipient — and terminates at a human. Escalating to a second component that also silently fails is the original bug one rung up, and only a recursive ladder catches that.
• Nothing auto-closes. Discharge authority is the obligating author, or a human at the escalation tier; an agent may never discharge an obligation owed to someone else.
• Interval derives from injection mode. Note the protocol now forbids pairing an obligating policy with a delivery mode the model may never see as actionable.

Open-set queries — two, each one call: what I owe (open with me as recipient) and what I am blocking (open with me as author). A benchmark worth stating plainly, because it is the current state of the art here: the equivalent list is maintained by hand today and has been more current than any tool-based sweep. The tool has to beat the hand-written file or it will not be used.

On the acceptance criteria, which are the reason to be careful here. The negative case is the deliverable: an event delivered, injected, read, and not answered must still return. That test must fail before the change — a test that passes against current behaviour is testing something else. Read state must not be an input to discharge anywhere in the implementation, including as an optimisation.

Recommend not starting implementation until the spec PR against c2a is settled, so the field names and the discharge rule are fixed once.

[khaliqgant]

The protocol settled differently — five corrections before anyone implements this

The comment above predates the rulings on AgentWorkforce/c2a#3. An independent review broke that design and the rulings that followed changed it materially. Five things that comment states are now wrong, and each of them changes what gets built. Correcting them here so implementation does not start from the superseded shape.

The spec counterpart is AgentWorkforce/c2a#4, currently open on branch spec/obligation-lifecycle. Field names below are from that branch.

What changed

The comment above says	What the rulings settled
"must_respond already is the severity signal"	must_respond is an addressing signal. The presence of the obligation object creates the obligation; policy means "you were addressed" and nothing more.
"no new signal type"	Withdrawn. A reaction event shape is required, carrying actor, targetEventId, signal, createdAt, recipient.
"claiming halted is falsifiable, because an author still emitting work events on that workstream was not halted"	Dropped. The protocol has no workstream and no work event, so the falsifier is not computable from anything it carries. blocks survives with a different job.
"discharge authority is the obligating author, or a human at the escalation tier"	An obligation names a dischargeDelegate at creation, defaulting to the author's coordinator.
"that test must fail before the change"	Retired as a discriminator. See below — this one matters most.

Why the first correction is the important one. If must_respond creates the obligation, then every DM opens a never-expiring obligation closable only by its sender — including "thanks, shipping now", which the protocol separately forbids answering. The open set then grows with traffic and fills with social filler. Making the author-declared obligation object the trigger keeps the set to actual blocking questions.

Why "fail before the change" had to go. Every test of a feature that does not exist yet fails beforehand. That proves the feature is new; it does not prove the test targets this defect. What discriminates is the pair: a must-fire case and a must-not-fire case. Arm A alone is satisfied by an implementation that never discharges anything; arm B alone is satisfied by today's code, which does nothing. Only both together test this design. Plus a control that removes the mechanism and confirms the suite goes red.

Substrate survey — what this repo can and cannot support today

I had the substrate mapped against those requirements before sizing the work. Findings, with citations:

1. Read state is set by infrastructure, not by attention — and this repo already documents that. Delivery is confirmed by echo verification: the broker scans the recipient's PTY stdout for the literal injected string within a 5s window (crates/broker/src/broker/delivery_verification.rs). On match, delivery_ack fires and mark_delivery_read_ack (crates/broker/src/runtime/delivery.rs:247-268) calls mark_read_as_agent automatically. The doc comment at crates/broker/src/runtime/delivery.rs:196-198 says it plainly:

A read-ack means "delivered to the recipient location", not proof that a model turn cognitively processed the message.

That is this issue's thesis, already written down in the code that sets the flag. It is strong corroboration for "do not build this on read state" — the read bit is a string match, with no model in the loop.

2. There is no "the model took a turn" signal on the default path. The nearest proxy the existing tests use is whether the agent subsequently called send_dm/post_message itself. That is evidence, not proof — the same distinction this issue draws between a reply and an answer. The native AI-SDK harness does emit a real one, turn.settled (packages/harnesses/src/ai-sdk/harness-host.ts:492), fired once model generation actually completes, but runtime: 'native' is not the default. This is the open question on the conformance evidence: the arms must assert a model turn, and the path that carries the traffic cannot currently report one.

3. Reactions exist but carry no semantics. add_reaction/remove_reaction (packages/cli/src/cli/mcp/messaging-tools.ts:345-387) store { id, message_id, agent_id, emoji, created_at }. No recipient field, so a discharge cannot name who it discharges — which the spec now requires. No tombstone on removal, so "discharge is monotonic" is not currently expressible. Nothing distinguishes reacting to your own message from reacting to anyone else's, which is the entire author/recipient asymmetry the design rests on.

4. There is no scheduler for this. crates/broker/src/scheduler.rs coalesces near-simultaneous sends; it does not re-surface stale ones. Recurring tokio::time::interval ticks exist and are reasonable hook points. Worth copying: Scheduler::push/drain_ready take now as a parameter instead of calling Instant::now() internally, which makes them testable — boomerang state should do the same, or arm C (returns at t, 2t, 3t at equal intervals) cannot be asserted without sleeping through real time.

5. No organizational hierarchy exists. The agent model has persona, metadata, channels — nothing that resolves "the coordinator of X". Both dischargeDelegate (defaults to the author's coordinator) and the escalation ladder need that edge to exist before either can target anyone. This is the most underestimated piece of the work and it is a prerequisite, not a detail.

6. #1471 sits on the path this feature needs. check_inbox/list_dms are the natural home for "what am I currently blocking", and they fail today for any agent with a non-trivial DM history. An open-set query built on them inherits that failure. Worth sequencing #1471 first, or deliberately not building the open set on those calls.

7. No prior art. No branch, PR, or code in this repo references obligation, boomerang, or blocking-message severity. Starting clean.

Where the state lives

Durable obligation state — the discharge signal, its actor, its timestamp, the recipient it names — has no home in this repo's schema. relay is the CLI/broker/harness layer; the message, delivery, and reaction records live in the hosted store. The spec now requires a named authoritative log ("the event and reaction record held by the host that owns the conversation and assigns eventId"), so this cannot be solved with a broker-side shadow store without duplicating the log the spec just mandated and drifting from it. Expect this to span both repos, and size it accordingly.

On the acceptance criteria

Unchanged in substance and still the point of the issue: a message delivered, injected, read, and left unanswered must still return. What changed is how that gets proven. The evidence is one fixture, four arms, every message driven through the production send path rather than a test-only constructor, each arm asserting the recipient took a model turn rather than that an event was emitted — plus a control run with the mechanism disabled that confirms the must-fire arms go red. A suite that stays green with the feature removed is passing vacuously, and that is the failure mode worth guarding against here, because it is the same shape as the bug.

[khaliqgant]

Corrections to my substrate survey above

Building the conformance fixture (#1476) turned up four errors in what I posted. Correcting them here rather than leaving them to be found later. One of them makes the case for the underlying issue stronger, not weaker.

1. crates/broker/src/scheduler.rs is dead code. I described behaviour that never runs.

I wrote that it "coalesces near-simultaneous sends". It does not coalesce anything, because nothing calls it. Its only references are pub(crate) mod scheduler; at crates/broker/src/lib.rs:46 and its own #[cfg(test)] module. Verified by grepping the whole crate for references outside the file itself.

The reason I cited it still stands and is worth keeping: push/drain_ready take now as a parameter instead of reaching for Instant::now() internally, which is exactly the shape boomerang state needs if arm C (returns at t, 2t, 3t at equal intervals) is to be asserted without sleeping through real wall-clock time. Copy the shape; do not expect the module to be doing a job today.

2. The PTY path does emit turn.started / turn.settled — and the broker labels them "inferred" itself.

I said no turn signal exists on the PTY path. That was wrong, and the truth is more damning. crates/broker/src/runtime/worker_events.rs publishes turn boundaries via publish_pty_busy / publish_pty_idle, derived from stdout busy/idle transitions. The broker's own capability report at worker_events.rs:377-379 declares:

{"available":true,"fidelities":["inferred"]}

for thinking and idle, against "exact" for starting and error. The default soak output prints the comparison in the same terms: turns: {reference:["exact"], candidate:["inferred"]}.

So the accurate statement is not "there is no turn signal" but "there is a turn signal, and the component emitting it declares it inferred from terminal output rather than observed from the model." That is stronger evidence for #1475, not weaker — the system already knows the distinction between an exact and an inferred turn, names it in a capability report, and the default runtime only has the inferred kind. These signals also publish to the hosted stream rather than to local getAgentEventHistory, which holds only native sidecar frames — so they are not reachable from a broker integration test as things stand.

3. Read state is auto-set on the native runtime too, not only on PTY.

I framed the auto-mark-read as a PTY/echo-verification artifact. The native sidecar acks deliver_relay and mark_delivery_read_ack fires off that ack in the same delivery_ack arm of worker_events.rs. "Read is set by infrastructure, not by attention" is true on both runtimes. This is why conformance arm D (read state set vs unset must be byte-identical) is not assertable on either path today: read state cannot currently be left unset, so the independent variable cannot be varied.

4. The natural implementation hook is the maintenance sweep, not the scheduler.

crates/broker/src/runtime/maintenance.rs runs a 500ms sweep, which is the closest existing thing to a periodic re-surfacing tick. It is not one today: it is a transport retry keyed on the pending-delivery map, and a delivery leaves that map as soon as the worker acks — i.e. precisely when the interesting part (was it ever answered) begins. It is the right place to hang a boomerang scan, and it is worth being explicit that its current semantics are the opposite of what is needed.