Daily Edition Sources +5

You Sent the Correction. Has the Agent Read It?

QM now places a mid-run correction where the agent runtime receives it. That small change separates a delivery problem from an agent that had the information and still went wrong.

QM queues a correction, records native intake and places it before the next tool call; a stamp distinguishes intake from obedience.
Diagram Punksending a correction and recording its intake are separate events.
repo yc-software/qm evidence
5 source signals 1 repo commit 46387a9
Evidence: commit 46387a9 / September 27, 2026 / Daily Edition
Open Edition Evidence below

QM has changed when a correction appears in an agent’s work history. In a change merged September 26, the shared agent harness in yc-software/qm moves steering messages into the tool timeline at native intake, instead of placing them beside the assistant’s entire run. Sending the message and reaching the running agent now have different visible states.

Imagine an agent working through a customer report when a colleague says to use the revised figures. A transcript that puts the correction above the whole run can make an earlier calculation look like deliberate disregard. A transcript that records only the send time cannot establish whether the agent had the correction before its next action. The ordering is part of the evidence.

A message bubble acquires a receipt

QM describes itself as a multiplayer agent harness for work, with personal and shared scopes across Slack and the web. It can run Pi, OpenCode, Codex or Claude Code behind the same core. That choice makes a uniform-looking transcript harder to produce honestly: each underlying runtime exposes a different indication that new input has arrived.

The patch moves the durable steering acknowledgment later. Polling a queued signal no longer automatically means it has been consumed. The common intake helper records the user entry, then attempts the acknowledgment; individual harness adapters decide when to call it from their native event flow.

Those adapters do different work. Claude’s adapter matches replayed user messages, using their identifiers when available. Codex’s matches completed user-message events against pending steering input. OpenCode’s checks message identifiers in the captured model request. Pi’s records intake when the corresponding user message reaches its event stream. These are concrete protocol boundaries, not a measurement of the model’s understanding.

The web interface then places the recorded message between tool activity and splits a collapsed group of work around it. A correction should remain visible even if the surrounding operations are folded away. The useful question becomes answerable without opening a separate log: did this action precede or follow the recorded instruction?

The pending badge is not the ledger

The strongest qualification sits in the pending-message regression test. Accepting a steer keeps a “Steering” chip but fabricates no transcript message. Two identical corrections remain distinct through their signal timestamps; receiving one must not clear the other simply because the text matches.

But the chip disappears when the run ends, even without intake. The pull request also says that this browser state clears on reload, while the server signal remains durable. A missing chip therefore does not prove delivery. The recorded intake entry carries the stronger claim.

That distinction matters when diagnosing a bad outcome. Before intake, investigate delivery and scheduling. After intake, investigate what the agent did with the instruction. Neither the new bubble nor its position proves that the model followed it, that an already-running tool stopped, or that earlier side effects were undone.

Four adapters, unequal proof

The public validation report is unusually specific about its limits. The author reports real-model runs with Postgres and a cloud sandbox for Pi and OpenCode, checking live and reloaded ordering. Claude and Codex received focused harness and protocol tests, without a fresh authenticated end-to-end run. The linked browser preview uses simulated activity. Those are different kinds of evidence and should stay different.

We inspected the merged adapters, intake helper and regression tests; we did not repeat those live integrations or verify deployment pins. The change earns attention as a more honest account of a human intervention, rather than a claim that all four agents now handle corrections equally well.

For a team evaluating this revision, the revealing test is small: send two identical corrections while work is running, compare their recorded positions with the next tool calls, then reload. Repeat with a run that ends before intake. The next signal to watch is whether the same ordering survives authenticated Claude and Codex runs. Oversight gets more useful when the interface can say precisely when the instruction arrived—and leaves obedience to the evidence that follows.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateSeptember 27, 2026
LaneDaily Edition
Confidence78%
Sources5
Reposyc-software/qm

Primary Evidence

  • Public change and validation report: https://github.com/yc-software/qm/pull/1652
    • Shows: Explains prior receipt/consumption conflation, reports real Pi/OpenCode tests and limits Claude/Codex validation to focused harness tests.

Evidence Limits

  • Intake is a runtime event, not proof of model understanding, obedience, cancellation or reversal of prior tool effects.
  • We inspected source and tests but did not rerun authenticated integrations or verify a deployed build. Author-reported live tests cover Pi/OpenCode; Claude/Codex and the mocked preview supply different evidence.
  • Pending browser chips clear on end/reload and do not prove durable intake.
Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.