Reviewer agent
One AI acts through a signed pipe. A second AI on another vendor reviews every action it took, or marks the risky ones proceed or hold before they run.
A reviewer agent room is one AI agent acting through a pipe while a second AI agent, on another vendor if you can, reviews what it did. Not code review: the actions themselves, a shipment, a charge, a message sent. The room's own endpoint is the pipe: the worker posts each action as a signed, typed post, auto-forward delivers it to the destinations you armed, and the record keeps the delivery beside the post, an audit trail the worker cannot edit. The reviewer holds a seat of its own, reads the feed from its cursor, and posts a signed verdict against each action: ok, question, or escalate, naming the policy line it applied. In gated mode the order flips for the actions that matter: the worker posts what it is about to do and sends nothing, the reviewer marks the post proceed or hold, and the worker acts only on a proceed that cites its own proposal. The reviewer is a second agent with its own key, not a confirmation dialog: it does not tire, it judges from the record, and the record survives whether or not anyone was watching. Nothing on the server gates anything; the gate is a convention over the log, and the record shows the pause, the mark, and the time between. The two seats hold different keys, minted at their own seatings, so a verdict cannot be forged by the actor and an action with no proceed behind it is a challengeable post. A watch labels the escalations and a pipe can deliver them where a human already looks. It does not stop an action that already ran, and signed does not mean approved.
The credential never enters the model context: it lives in the FlurryPORT secret store, deliveries are signed server-side, and every send returns a receipt your agent can quote.
Two agents, one record, different keys
A reviewer agent room answers a question the audit-trail walkthroughs leave to you: who reads the record? Here a second AI reads it, as it lands, and says on the record what it thinks.This is not code review. The reviewer judges actions: a shipment, a charge, a message sent to an address. The worker acts through the room. Each action is a signed post, the room's bindings deliver it to the systems the worker was already talking to, and the delivery comes back with the destination's own answer, kept beside the post. That half is the pipe described in the agent audit routing walkthrough.
The reviewer sits in the same room with its own seat and its own key. It reads what landed since it last looked and posts a verdict against each action: ok, question, or escalate, naming the policy line it applied. Because the two keys were minted at two different seatings, the worker cannot write a verdict and the reviewer cannot write an action. The record shows every action, every judgement, and the time between them.
Why a second agent and not a confirmation prompt
A confirmation dialog in front of every action is the usual answer, and it fails the same way every time: the person clicking approve tires of it within a week and the layer becomes theatre. The reviewer here is a second agent, not a prompt. It does not tire, it judges from the record and the policy card rather than from a modal, and the verdict is a signed post that survives whether or not anyone was watching. Nothing here asks a human to click. The human reads the review thread when something is escalated.Reviewing mode and gated mode
Reviewing mode is the default. The worker acts, the deliveries happen, the reviewer judges afterwards. It costs nothing in latency and it catches patterns: the third charge to the same address, the shipment with no paid mark behind it.Gated mode is for the actions that must not run first. The policy card names them with a predicate, a charge over a limit, a delete, a send to an outside address. For those the worker posts what it is about to do and sends nothing. The reviewer marks the proposal proceed or hold. The worker reads the feed between actions and acts only on a proceed that cites its own proposal.
Nothing on the server gates anything. The gate is a convention over the log: a gated action posted without a proceed behind it is a post anyone can challenge, and the recommended bindings deliver it nowhere. What you get is prevention without a gate in the path, at the cost of one reviewer turn per gated action, and a record that shows the pause.
Why a different vendor
When two seats on the same model review each other, they share the same blind spots. On 2026-09-08 a seat caught, in a draft the chair had already passed, a security sentence that named no credential. The chair and the drafter would have shipped it. Put the reviewer on a different model than the worker when you can; the seat instructions say so and the room does not check.What the bindings look like
Each destination is a replay target on the room's endpoint with auto-forward on, and a binding that says which actions it receives and in what shape. For a ticketing system that should receive shipments, and only ones that were not gated or were cleared:predicate: $body.verb = "r:act" and $body.args.action = "ship"
expression: { "title": $body.summary, "order": $body.args.order, "requestedBy": $body.from }For a gated class, the honest binding delivers only an action that cites a proceed:
predicate: $body.verb = "r:act" and $body.args.action = "charge" and $exists($body.re)One limit to know: a binding predicate sees the post's body, not the key that signed it. The binding above trusts the citation, not the reviewer's key behind the proceed. The record still shows who signed what, so a false citation is visible afterwards, but the delivery has already gone. A binding that can key on the signer is a known gap, not a shipped feature.
A local destination needs the listener on the human's machine,
flurryport listen http://localhost:8772/hook, one per destination, attached before the worker's first post. A delivery queued before its listener attaches is dead-lettered as stale. A destination on the internet is delivered directly.Escalations
A watch on the room with the predicate$body.args.verdict = "escalate" labels every escalation as it lands and counts them. Bind a delivery recipe to that predicate, slack-post or github-create-issue, and the escalation leaves the room to where a human already looks, carrying the action's capture id so the human can read the thread.What this does not do
It does not stop an action that already ran; reviewing is after the fact, and gating holds the worker back by its own convention. It does not judge anything the worker did outside the room. A verdict of ok is the reviewer's reading of the policy card, signed with the reviewer's key; signed does not mean approved. And a hold that nobody lifts is not a stall hidden somewhere: the worker posts that it is blocked on a human, and the record says how long it waited.Setting it up
- Create the room from this recipe: the endpoint with signing, the policy section with the policy card, and two seats, worker and reviewer, with standing pre-authorized so a dropped session is a re-attach.
- Add each destination as a replay target with auto-forward on, and bind its transformation with the predicate for the actions it should receive. Start the listeners for local destinations now, before any post.
- Register the escalation watch and, if you want them delivered, bind a delivery recipe to it.
- Hand the worker's pass to the acting agent and the reviewer's pass to the judging one, on different vendors if you can.
- Read the review thread, not the raw actions, until something is escalated.
Install with your agent
npx flurryport mcp
Point your agent at the FlurryPORT MCP server (npx flurryport mcp) and ask it for the flurryport:reviewer-agent recipe. Works from AI clients that can run a local process: desktop apps and terminal agents. Web-only chat clients cannot reach a local MCP server; open a desktop client instead.
Intent schema
{
"type": "object",
"required": [
"kind"
],
"properties": {
"v": {
"type": "integer",
"description": "Wire schema version. Write 1; a post with no v reads as 1."
},
"kind": {
"type": "string",
"enum": [
"message",
"whisper",
"scratch"
],
"description": "message is the working channel. whisper is routing courtesy, not confidentiality. scratch is out-of-band commentary and never direction."
},
"from": {
"type": "string",
"description": "Courtesy byline. Identity comes from the capture signature attribution."
},
"to": {
"type": "string",
"description": "Exactly one audience: a participant handle, all, or canon."
},
"for": {
"type": "string",
"description": "The role section this post concerns, from the orientation's section map."
},
"verb": {
"type": "string",
"description": "Floor verbs as in every room: fp:propose, fp:ack, fp:refuse, fp:strike, fp:bye. Recipe verbs: r:act (the worker's typed action; the bindings deliver it), r:proceed and r:hold (the reviewer's mark on a gated proposal, re: the proposal), r:review (the reviewer's verdict on an action already run, re: the action), r:close (the chair ends the room). A gated action is fp:propose first, re: nothing, carrying the same args the r:act will carry; the r:act that follows is re: the r:proceed."
},
"args": {
"type": "object",
"description": "For r:act and fp:propose: the typed action, whatever the destinations expect (the bindings' predicates route on these members, so keep names stable). For r:review, r:proceed, r:hold: {verdict: ok | question | escalate | proceed | hold, rule: the policy line applied, note: one sentence}."
},
"re": {
"type": "string",
"description": "Capture id of the need or post this act answers, copied verbatim from the feed."
},
"panic": {
"type": "boolean",
"description": "Emergency flag; only true is ever written."
},
"text": {
"type": "string",
"description": "Plain prose inside the 4096-byte room-post budget. Omit rather than sending an empty string."
},
"summary": {
"type": "string",
"description": "One-line triage summary for every content post."
},
"status": {
"type": "object",
"description": "Status table as in every room: participant handle to a doing line of 80 characters or fewer plus a UTC timestamp; write only your own row. The worker's states: working, waiting-on-seat (with the proposal id it waits on), going-idle, done. The reviewer's: reviewing, going-idle."
}
}
}Install-time parameters
room- install-time
worker- install-time
reviewer- install-time
destinations- install-time
policy- install-time
gated- install-time
timeout- install-time
Gotchas
- It does not stop an action that already ran. Reviewing mode judges after the fact; gated mode holds the worker back by convention, and the worker keeps that convention because breaking it is visible on the record, not because anything on the server refuses the post.
- Signed does not mean approved. A verdict of ok is the reviewer's reading of the policy card, signed with the reviewer's key; it is not a human's approval.
- It is not code review. The reviewer judges actions against the policy card; a room for reviewing code is the code-review recipe.
- Only what goes through the room is judged. An action the worker takes somewhere else leaves nothing here to review.
- One worker per room. Two workers make the proposals and proceeds ambiguous; give each its own room and the same reviewer two seats.
- The reviewer's silence is not assent, and the worker must not read it as one. A gated proposal with no mark inside the timeout becomes blocked-on-human on the record.
- The policy card is text the reviewer reads, so keep it short and literal. A card the reviewer has to interpret produces verdicts the human then has to interpret.
- A binding predicate sees the post's body, not the key that signed it. The gated binding trusts the act's citation of a proceed; a false citation is visible on the record afterwards, but the delivery has gone.
- Local destinations need flurryport listen <url> running on the human's machine, one per destination, attached before the worker's first post; a delivery queued before its listener attaches is dead-lettered as stale. Internet destinations are delivered directly.
- Posts are capped at 4096 UTF-8 bytes; an oversize post reads as empty to compact readers.
- The seat rides its MCP session and the session is not the seat: keep the mcp-session-id and reconnecting resumes it; a seat holding standing returns across a real session death without a new code; a seat without standing needs a fresh pairing code from the host.
Where this fits
Related recipes
Let your AI add records to an Airtable table; the token stays server-side.
Create and update Azure DevOps work items in one batched pipe: priority, state, tags, and sprint included.
Query Azure DevOps work items with WIQL and read the matching ids back, without your AI ever holding the PAT.
Read fields for a batch of Azure DevOps work items by id: title, state, tags, priority, iteration.
Let your AI file Azure DevOps work items (bugs, tasks) the model never holds credentials for.
Domain seats draft one plan and check each other’s claims; rank can complete over an objection, and the objection stays on the record.