The 'Approver' Agent: Adding a Reasoning Layer

An approver agent reads the proposed action, asks the questions a senior on-call would ask, and either approves or kicks it back. The prompt, the eval, and the cost.

The approver’s role

The approver agent codifies the senior on-call’s questioning pattern. It does not investigate, it does not act; it reads a proposal and responds to it.

• Single decision. Approve, reject, or kick back for refinement. No fourth option, no investigation, no parallel proposals.
• Senior on-call analogue. The pattern senior engineers run naturally on junior proposals. The approver agent makes that pattern available at every action.
• Read-only by definition. The approver cannot modify the proposal; it can only respond. Modification belongs to the proposing agent.
• Stateless per call. Each approver call evaluates a single proposal in isolation. Cross-proposal context is the orchestrator’s job, not the approver’s.

The approver’s prompt

The prompt is short, specific, and demands a structured output. The questions below are the difference between an approver that catches mistakes and one that rubber-stamps.

• Mission line. “You are reviewing a proposed action by another agent. Ask the questions a senior on-call would ask. Approve only if the proposal answers them all.”
• Required questions. Blast radius, reversibility, evidence quality, alternatives considered, escalation path if it fails.
• Structured output. Approve, reject, or kick-back, plus a one-paragraph reason. The reason is logged so future approvers learn from past rejections.
• Hard refusal cases. The prompt names the actions that always require human review even on a clean proposal: production data deletion, IAM elevation, key rotation.

Eval cases

The approver fails in two directions: too lenient and too strict. The eval set tests both, plus the borderline that exercises kick-back.

• Good proposal. Should approve. The approver must not invent objections against a sound proposal.
• Bad proposal. Over-broad blast radius or missing rollback. Should reject. The approver catches what the proposing agent missed.
• Borderline proposal. Should kick back. “Add the rollback plan and resubmit” demands rigour without rejecting outright.
• Adversarial proposal. Phrased to look thorough but missing a key invariant. The approver should still reject.

Cost is real but worth it

Approver calls are not free, but the bad-action arithmetic strongly favours running them on actions that matter.

• Per-call cost. One LLM invocation, around $0.02 to $0.05. Adds 1 to 3 seconds to action latency.
• Bad-action arithmetic. A single bad action averted (a wrong restart, an over-broad change) easily pays for thousands of approver calls.
• Targeted use. Justify the cost only on actions that warrant it. Read-only or trivially reversible actions do not need approver review.
• Cheap-judge fallback. For very high volume actions, a smaller approver model handles the routine cases and a larger model handles borderline ones.

Approver as a substitute for human review

The approver substitutes for human review on routine actions and complements it on high-stakes ones. The split is what frees senior time for the cases that need it.

• Routine actions. Approver replaces human review. The senior on-call’s time is freed for harder calls.
• Irreversible or high-stakes actions. Approver is in addition to human review, not a substitute. Both must agree.
• Coverage matrix. Track which actions get human-only review, approver-only review, both, or neither. Tune as trust accumulates.
• Trust ratchet. Move actions from “both” to “approver-only” only after a quarter of clean operation; reversing the move is the standing policy when the approver misses.