One Approval Box for Two Actions: When a Batch Is Too Big to Send

Write the rule down as three conditions that must all hold. An item is eligible for a batch only if:

1. It sits in the same risk tier as every other item in the batch.
2. It targets the same recipient, destination account, or resource path.
3. Its amount is at or below the batch maximum you have set for that tier.

If any condition fails, the item leaves the batch and gets its own approval request. This is a small rule with large consequences, because it forces the system to compute the properties of each action before deciding how to present it. That computation is the actual work. The checkbox is trivial.

A worked example makes the arithmetic concrete. Suppose your policy says that a reviewer may approve a batch of up to 25 customer refunds if each refund is at or below $50, all refunds go to accounts that have received a refund in the past 90 days, and the batch total is at or below $500.

The batch now contains three items totaling $129. The reviewer sees exactly those three, not a list of six with two greyed out. Sending a partial batch is cleaner than sending a batch with hidden exclusions, because the reviewer's mental model matches what will execute.

Note what the maximum does. It caps the blast radius of a single mistake. If the reviewer misreads one line, the worst case is bounded by the batch total, not by the sum of everything the agent wanted to do. That bound is the number you should be prepared to defend in a risk review, and it should be set by the owner of the system the actions affect, not by the team that built the agent.

Splitting is not a UI concern, it is a state machine concern. You need three objects: the proposed item, the batch, and the approval record. The approval record references a specific batch version, and a batch version is an immutable snapshot of its item list.

The simplest implementable version looks like this in pseudocode:

function assemble(items, policy):
  batches = []
  current = new Batch(tier = items[0].tier, recipient = items[0].recipient)

  for item in sort(items, by amount descending):
    if not eligible(item, policy, current):
      batches.append(current)
      current = new Batch(tier = item.tier, recipient = item.recipient)

    current.add(item)
    if current.total + item.amount > policy.max_total:
      batches.append(current)
      current = new Batch(tier = item.tier, recipient = item.recipient)

  batches.append(current)
  return batches

Two details matter more than the loop itself. First, sorting by amount descending causes the largest items to be evaluated against a fresh batch, which reduces the chance that a big item slips in behind a wave of small ones. Second, grouping by tier and recipient before any of this runs means you never compare items that should not be compared at all.

The batch record then gets a version identifier and a digest. The digest is a hash over the canonical serialization of every item: identifier, amount, recipient, credential used, and the policy version in force. Pomerium describes this as binding approval to the action digest, policy version, approver, and a short expiry, and invalidating approval if any material argument or target changes the approval design guide. Veeva's batch approval documentation shows the same pattern at the document level: the entire batch action can fail if the associated documents do not meet entry criteria for the target state Veeva Vault batch approval.

That last point is worth pausing on. If the execution step can fail partway, you need to decide whether a batch is atomic or per-item. For money movement, per-item with explicit per-item status is almost always the right answer, because a partial success you can see beats a silent rollback you cannot.

The most dangerous inheritance is quiet. An approver approves a batch of 20 items. Sixteen succeed. Four fail because the destination account is closed. Someone retries the four later using the original approval record, because the approval record still exists and still says "approved." That is the exact failure the design must prevent.

Three rules close it:

Rule one: an approval is consumed by the item, not by the batch. When an item executes successfully, mark the approval as consumed for that item. An item that failed has no valid approval, full stop. Retrying requires a new request.

Rule two: a declined item is removed from the batch, and the remainder is re-presented. If a reviewer approves items 1 through 10 but explicitly excludes item 6, the batch that executes is the set of nine, and it executes under a new batch version with a new approval. The reviewer's exclusion is documented in the audit trail, and the nine-item batch carries its own consent. This sounds like friction, but the alternative is a reviewer's yes being stretched to cover something they specifically rejected.

Rule three: state revalidation happens at execution, not at approval. Between the yes and the write, the target may have changed. The system must re-check that the recipient account is still open, that the amount is still within policy, and that the credential has not been rotated. The approval workflow literature is consistent on this: approval can become stale if external conditions change while the workflow is paused, and the run should revalidate current state before resuming the Promptessor HITL guide.

A tidy way to express this is a single invariant you can test against: no item ever executes under an approval record whose item list does not contain that item, whose digest does not match that item's current parameters, and whose creation time is later than the item's last failure. If you can enforce that, the inheritance problem cannot occur.

Batching is the exception, not the default. Force single-action approval when any of the following is true:

That last row deserves emphasis. Exception processes in government and regulated settings are almost always one-request-one-decision. Section 508 guidance notes that most exception types do not even require formal documentation, but the ones that do are handled individually with a named responsible official Section 508 exceptions process. A university accessibility exception takes about ten business days from submission to review by its committee the University of Illinois exception form. A security risk exception form asks the requester to name the machines, the data at risk, and the compensating controls, and then collects three separate signatures the MDC security exception form. None of that compresses into a batch. If your item needs a justification paragraph, it needs its own approval.

The pattern carries over to identity controls. The ServiceNow MFA enforcement FAQ explains that exemptions can be granted per user, per role, per group, or per trusted network, and that each exemption is a separately configured decision the ServiceNow MFA enforcement FAQ. A blanket exemption that covers a group is a batch in disguise, and it should be reviewed as one.

The reviewer's screen is where this design either works or becomes theater. A generic prompt asking whether to proceed with a group of changes forces the operator to guess, which is exactly how approval fatigue starts Exemplary's reviewer guidance.

An effective batch approval screen shows five things:

1. The boundary of the yes. "This approves 3 refunds to account ACC-94812, total $129, under policy version 7." Not "approve these items."
2. The items, fully resolved. Each line shows the exact amount, the exact recipient, and the exact reason code. No summaries standing in for numbers.
3. The delta from what the reviewer saw last. If a batch was re-presented after a decline, highlight what changed. The reviewer should not have to re-read everything to spot the difference.
4. What is excluded. If the agent proposed 6 items and 3 were split out, say so and say why in one clause per item. A reviewer who does not know about the excluded items cannot ask why.
5. The decision options beyond yes and no. Approve exactly, edit a parameter, reject with a note, or escalate. Approve and reject alone are often too narrow for a real decision the StackAI decision-type guidance.

There is a measurable trade-off here that is worth stating out loud to stakeholders. Frequency of prompts and value of automation pull in opposite directions. Frequent prompts reduce automation value and cause habituation, while rare prompts can miss high-impact combinations Pomerium. The right operating point is not "fewest prompts" or "most oversight," it is the point where reviewers still read what they see. You can find it empirically: sample 20 approvals a month, ask the reviewer to explain in one sentence what they authorized, and track the share who get it right. When that share drops, your batches are too big or too frequent.

GitHub's secure use guidance offers a comparable control for a different domain: workflows can require review before a job reaches protected secrets, and the review is a gate on a specific job rather than a blanket permission for the repository GitHub Actions secure use reference. The lesson transfers. The gate is scoped, the scope is visible, and the scope cannot be widened after the fact.

For teams running agents that propose actions across text, image and other modalities, the practical next step is often not more policy but a single place to route those approvals and meter the calls. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key, which makes the action log easier to assemble in one place (https://quantaintelligence.ai/inference). If the harder question is which actions in your business should sit behind a batch at all, a free 30-minute discovery call is a reasonable way to get a second opinion before you write the policy (https://quantaintelligence.ai/calendar).

Before you ship batching, verify each of these against a test fixture that includes a declined item, a failed item, and a changed target. If any check fails, do not ship.

The audit row is the one people skip. Store what was proposed, what the reviewer saw, who decided, and what executed, and do not confuse the approval page with the target system's own audit event Pomerium. When the question comes six months later, the approval page tells you what the person was shown; the target's log tells you what actually happened. You need both to answer "did this person approve this action."