AI batch lock approval workflow: preventing two agents from acting on the same queue

Shared queues fail when ownership is implied instead of locked.

Most multi-agent workflow mistakes do not come from a bad model output. They come from two actors touching the same batch with different context, or from nobody proving who owned the queue when the action happened. A batch lock approval workflow adds a simple control: before anyone sends, updates, approves, or writes, the workflow names one execution owner, records the queue slice, captures the proof surface, and blocks parallel action until the lock is closed or deliberately handed off.

Lock the batch before any action runs

The queue should become a named batch before the workflow touches live records. That batch should define the exact row range, record set, or task list the owner is allowed to act on, along with the source-of-truth surfaces checked first.

Buyer persona: an ops or revenue leader coordinating multiple agents or workers around a shared outbound, support, billing, or approval queue

Inputs: batch id, queue slice, source-of-truth surface, proposed execution owner, stop-registry check, previous-action check, and current risk notes

Approval rule: no live action until the batch has one named owner and the proof surfaces show the slice is clean for action

Output: lock record, queue manifest, owner assignment, pre-action proof receipt, and stop conditions for the batch

Record proof before and after the work

A lock without proof becomes a story. The workflow should store what was checked before execution and what changed after execution so the next reviewer can tell whether the batch actually moved, partially failed, or needs a controlled retry.

Pre-action proof: queue state, source timestamp, unresolved blockers, prior-send or prior-write check, and who approved the release

Post-action proof: completed records, held records, errors, follow-up queue, and whether ownership remains open or is now closed

Example: an outbound batch lock captures the released rows, the stop-registry check, the sent-items surface, and the tracker state before more emails are sent

Metric: duplicate-action rate, handoff clarity, blocked unsafe retries, and time spent reconciling who touched the queue

Force a hard stop when ownership changes

The dangerous moment is not the first owner. It is the handoff. If a different agent, human, or automation path wants to continue the batch, the workflow should stop and reconcile before anything else happens.

Handoff rule: a new owner requires a fresh lock, refreshed proof surfaces, and a clear reason the prior owner released or lost the batch

Risk: two agents both believe they own the same pending set because one is using stale state or a copied queue export

Control: one open lock per batch, explicit closeout, post-action reconciliation, and a do-not-continue rule after route ambiguity

When not to automate: no stable queue id, no source-of-truth surface, or no way to prove whether prior actions already happened

Keep the lock small enough to review

The tradeoff is that large locks feel more efficient but become harder to audit. Smaller locks create more check-ins, but they make failures easier to contain and easier to route around without freezing the whole lane.

Use small slices when the queue is high risk, externally visible, or likely to drift while the work runs

Hold only the affected rows if one record is blocked; do not stop a healthy lane because one item needs review

Pair the lock with an owner summary, blocker code, and next-step state so the queue can continue safely

Expand batch size only after the workflow shows low duplicate-action risk and clean reconciliation discipline

Questions to ask before the first sprint

What exact queue slice is being released to one owner?

Which proof surfaces must be checked before and after execution?

What event should force a new lock instead of continuing the old one?

Keep reading on Fabren

Managed Codex workspace AI deployment services AI workflow evaluation scorecard First 30 days of AI deployment

External references

GitHub Actions concurrency Salesforce approval process basics PostgreSQL explicit locking

Next step

Prevent duplicate actions before shared queues turn into cleanup work.

Fabren helps teams define queue locks, execution ownership, proof receipts, and safe handoff rules for multi-agent operations.

Design queue controls

Related playbooks

Workflow Recipes