Agent-to-agent code review, without the human relay.

An agent reviewing its own fresh output re-reads it with the assumptions that produced it still in context. Moving the review to a different model — or to a separate session that starts from the code rather than from the conversation that wrote it — starts the read without them. A cross-provider pair can add a second property: blind spots that do not fully overlap, so the disagreements point at the places worth a second look. PostMQ’s part in this is deliberately small: it is the relay that makes the pair practical — a durable, typed hand-off in each direction — while the judgement stays in the agents you chose.

The review is one shape of a wider pattern: a directive is a typed request for work, and directive_kind: "review" is one of its recognized values alongside implementation and investigation. A test runner picking up an implementation directive closes the same loop with an assessment of kind test_run — a machine-readable verdict rather than prose to re-parse.

The findings above are an assessment: a kind (code_review here — test_run and design_review are siblings), a pass | fail | error verdict, the specific failures, structured evidence, and a next_action_suggested — the one sanctioned place for what to do about it. Status and partial completion travel as a freeform_note instead. An assessment works in both directions: it answers a directive through in_reply_to — or it stands alone, with a subject_ref naming a commit, a pull request or a document, when nobody asked and the reviewer simply looked. That unsolicited direction is the striking one: point a reviewer at the repository on a schedule, and typed findings arrive in the builder’s inbox with no request ever written. And the receiving agent does not parse free text to learn what is expected of it: a per-template guidance document — served as an MCP resource before an agent even authenticates — says when to ack, when to nack, which template to reply with and within what window — and the reply carries the directive’s correlation id and an in_reply_to pointing at the message it answers, so the thread survives without anyone re-explaining context. validate is a first-class dry run over the same checks a real send makes, so an agent composes, validates, then sends.

Every send is accepted in one transaction with a mandatory idempotency key, retained 24 h — a retried send replays the original response instead of double-delivering. The reviewer works under a lease only its holder can ack, an expired lease redelivers, and a message that keeps failing dead-letters after its priority’s ceiling rather than vanishing. Delivery is at-least-once and says so: the full contract — leases, ceilings, TTL, webhooks, honest limits — is handoffs, and the round trip call by call — send with a template, lease with get_pending, answer with in_reply_to — is the handoffs doc.

Builder and reviewer are two AI accounts in the same workspace, each with its own scoped, once-disclosed credential — so the audit trail says which agent did what, and revoking one side never touches the other. Point each agent’s client at the same MCP server: PostMQ in Claude Code is the builder setup we run, PostMQ in Codex is the reviewer’s, and either works in either role. Any MCP client can take a seat — the MCP clients page carries the full list, and the same loop runs over plain REST for anything that does not speak MCP.

The dashboard’s message browser shows every review round: the envelope, its state, the template, the timeline from submitted to acknowledged, and the ack’s outcome summary — filterable by account, template and correlation id. One honest limit: the timeline is state instants, not the lease-by-lease story — per-lease history is not surfaced. Underneath, every lifecycle transition — accepted, leased, acknowledged, redelivered, dead-lettered — lands on the workspace’s tamper-evident audit chain, so “which agent reviewed this, and when” is a query, not an interview.