How Much Context a Batched Approval Item Needs

An approval item that can survive batching carries the exact change, the stated reason, the evidence and the blast radius. Each field has a failure mode that is specific to being batched, which is why none of them can be swapped for a prose summary.

1. The exact change. Not "updated the customer record." The field-level diff: which object, which field, the old value, the new value, and the operation. A reviewer scanning a column of diffs can spot the row where region changes from us-east-1 to eu-west-1 because it breaks the pattern. A reviewer reading "updated customer record" one hundred times cannot, and that is exactly the gap a malformed item hides in.

2. The stated reason, with a policy code attached. Free text is unrankable. Attaching a machine-readable code (for example RETENTION_CLEANUP, PRICE_SYNC, SEGMENT_BACKFILL) lets the queue group by cause instead of by tool, and lets you measure later whether a given reason code correlates with incidents. The reason should also name the source of the instruction when there is one, because agentic systems merge system prompts, retrieved data and user input into one context, and conflicting signals let untrusted text steer the action as Teleport explains in its prompt injection analysis.

3. The evidence. The artifact that shows the change does what the reason claims. For a code change, the test output for the affected path. For a data change, the dry-run log or the count of affected rows. For a config change, the plan output. For a content change, the rendered preview. Evidence is what turns "trust me" into "verify this," and it is the field reviewers use to complete a decision in seconds rather than open a second tool per the evidence-pack pattern.

4. The blast radius. A named statement of what breaks if the call is wrong, including reach (how many records, customers or services), reversibility (can it be undone, and how), and detection (would you know it went wrong). This is the field that connects the item to policy. A restart in staging and a restart in the payments namespace are different actions and belong in different tiers even though the command text differs by one string as NOFire's runtime policy guide puts it.

A useful habit: require the agent to produce all four as structured fields, not as prose it composes at pause time. Structured output is what makes the batch grouping below possible, and it is what an audit trail can later be reconstructed from.

The reason a summary is insufficient is not aesthetic. An approval is an authorization decision, and authorization requires enough specificity that a reviewer is actually approving this invocation with these arguments, right now. OAuth scope answers whether an agent may call a category of tool at all, which is a different question from whether this specific call should run a distinction Scalekit draws clearly. An approval gate that shows only the tool name and not the arguments has quietly reverted to a scope check with a human face.

Approval should also be narrow in time and scope. Authorizing one update should not grant standing authority, and grants should expire with the task rather than outliving it as Oso recommends for least-privilege agents. In a batch, narrowness gets subtle: what you are actually granting is "these N items, as shown, matching the shared frame." That is why the queue's execution step must bind the approval-record to the request it showed, so a payload edited after approval does not ride in on the same decision.

This is also where approval staleness bites. An item can sit in a queue while the world moves: the record was edited, the deploy landed, the price changed. Approval that was correct at pause time may be wrong at resume time, and the failure most approval implementations skip is revalidating state between the two per this HITL design guide. Batches make staleness worse because they take longer to assemble and approve than single items, so the revalidation check needs to run at the batch level and per item.

Finally, write a timeout policy per action type before launch. An expired item needs a defined default: approve for internal reversible work, hold and escalate for anything that leaves your system or moves money, cancel for time-sensitive actions, and re-plan for proposals built on data that may now be stale per these timeout defaults by reversibility. A global "approve anything older than a day" rule is how a dangerous item nobody wanted to sign off on gets through automatically.

The queue's job is to make the common case cheap and the uncommon case loud. That means a three-band layout rather than a list of cards.

Band one: the shared frame, stated once. The tool, the target resource class, the reason code, the blast-radius summary and the evidence link for the group. The reviewer reads this once and it is true for the whole run, or the group should not exist.

Band two: the variation table. One row per item, showing only what differs: the identifier, the changed field, before, after, the affected-row count and a verdict column. This is where a reviewer's pattern recognition does its best work, because the normal shape of a row is established in the first few seconds and the odd row stands out visually.

Band three: the split tray. Any item that failed a group check sits below, expanded, with a note naming which check pulled it. The reviewer can approve the run and handle the outliers individually in one pass.

A worked example. Suppose one hundred records get a status field changed from pending_review to approved under reason BATCH_QA_PASS, each backed by a test-run log, all in the staging tenant, each reversible by flipping the field back. The shared frame holds. Then three rows arrive where the diff also touches owner_email, one of which points at an external domain. Those three fail the diff-shape check and land in the split tray, with the external one flagged for a second reviewer because it crosses a trust boundary. The run of ninety-seven costs one decision. The three cost real attention, which is exactly where attention is worth spending.

That layout also keeps the batch honest about approval fatigue. Constant prompts train reviewers to click through, and the fix is to start with materially consequential actions and use incident data to widen automation later, not to front-load everything as ThreatLocker's approval guidance recommends. If your queue can show ninety-seven greens per hundred items, reviewers stay calibrated to the meaning of green.

Grouping is a computation, not a vibe. Define the checks as code and run them whenever an item joins a group. If any check fails, the item is pulled out and reviewed on its own. A workable starter set:

• Same tool and same operation. A PATCH and a DELETE against the same object never share a group.
• Same target class and environment. Production and staging are separate groups by definition; so are two tenants.
• Same reason code. Different codes mean different justifications, which means different evidence expectations.
• Identical diff shape. The same set of fields changes in the same direction for every item. Any extra or missing field is a split.
• Blast radius within tolerance. Affected count inside a declared band per item (not just in total), same reversibility class, same named escalation owner.
• Evidence present and matching. Every item has its own evidence artifact, and the artifact's run identifier is unique, not one log reused across the group.
• No policy escalation. Any item that trips a deny or escalate rule under your policy engine is removed before a human ever sees the batch.

That last check matters because instructions in a prompt are text the model reads, and a gate outside the model is a rule it cannot argue with as the runtime policy guide stresses. Batches should compose only from items the policy layer already cleared as approvable.

Here is a compact version of the grouping logic you can adapt:

def group_key(item):
    return (
        item.tool,
        item.operation,
        item.target_class,
        item.environment,
        item.reason_code,
        frozenset(item.diff_fields_changed),
    )

def splittable_reason(group):
    shapes = {frozenset(i.diff_fields_changed) for i in group}
    if len(shapes) > 1:
        return "diff shape differs"
    if len({i.evidence.run_id for i in group}) != len(group):
        return "evidence reused across items"
    counts = [i.blast_radius.affected for i in group]
    if max(counts) > 3 * max(1, min(counts)):
        return "affected count outside 3x band"
    if len({i.blast_radius.escalation_owner for i in group}) > 1:
        return "escalation owner differs"
    if any(i.policy_decision != "require_approval" for i in group):
        return "policy decision not uniform"
    return None

Two properties are worth stating explicitly. First, every check is mechanical, so a batch either holds together or breaks in a way you can explain to an auditor. Second, the split reason is shown to the reviewer, which turns a silent exception into a visible one. If you want the grouping thresholds tuned to your own traffic, an analyst who has seen your queue data is worth more than a generic default, and that is the sort of work Quanta's experts take on when a team would rather not build the instrumentation from scratch.

One more design decision: cap batch size and cap batch age. A group of five hundred items takes long enough to assemble that every item in it is more likely to be stale by approval time. Smaller groups with per-group revalidation keep approval fresh and split decisions cheap.

Batching feels faster, and it usually is, but the number you care about is not items per hour. It is agreement: on a sample of batched runs, how often would a reviewer, looking at one item in isolation with full context, have reached the same decision as the batch pass? Re-show a random slice of items individually and compare. When agreement drops, the grouping tolerances are too loose or the frames are hiding something.

Then plot reviewer accuracy against queue depth and time of day, because the same reviewer produces different judgments at item three and item three hundred per the queue analysis cited earlier. The point where accuracy falls to the agent's own error rate is the point at which the human gate is no longer adding safety. You cannot find that point without the plot, and you cannot build the plot without structured fields on every item.

That is the through-line: the four fields are not paperwork. They are the inputs to grouping, the inputs to your audit trail, and the inputs to every measurement that tells you whether the queue is working. If a coding agent is writing the approval UI or the policy layer, Quanta skills can be installed directly into it so the agent works from a consistent set of patterns rather than reinventing the item schema per feature.