What an approval gate actually is
Three of November's releases land on the same question: who signs off before an automated run does something that cannot be taken back. Anthropic's espionage report of 13 November bears on it most directly, since it describes a long chain running to completion with very few human checkpoints in it. Approval keeps getting discussed as a platform feature, and we think that framing is where the trouble starts. We treat it as three separate decisions, placement, evidence and logging, all settled before the workflow is built.
An approval gate is a durable suspension point in a workflow. The run reaches the step, serialises its state, creates a work item addressed to a named person or role, and stops there. When somebody decides, the decision is written against their directory identity with a timestamp and the run resumes down the branch that matches the decision. Each part of that carries an engineering requirement, and these are the three we check for first: the serialised state has to survive a process restart, the resume has to be idempotent so a double click does not send two emails, and the workflow needs defined behaviour for the case where nobody decides at all.
One form we run into regularly when we open an existing build is an email with two links in it, and it fails all three of those checks. The workflow state sits in the memory of a running process, so a restart loses the run. If the recipient forwards the email, whoever clicks becomes the approver while the log still names the original recipient. If nobody clicks, the item falls into a timeout branch, and we rarely find a test covering it.
UiPath's 2025.10 release, described in a post on 19 November, adds tooling for this at the platform level, and it is the November release closest to our own work. Maestro gained Case Management, which models case-driven workflows by establishing stages, assigning responsibilities, setting service-level agreements and creating escalation rules, alongside Process Apps, which give business users dashboards displaying live process data, approvals, SLA tracking and exceptions requiring attention. UiPath describes both as progressing through preview with early customers on the way to general availability. The capabilities they cover, an owner for each item, a deadline, an escalation path and a view of what is currently waiting, are the ones an approval gate depends on. Having a platform provide them saves rebuilding the same machinery inside every workflow, which is the state we usually find.
Where the gate belongs
We place gates where an action becomes visible outside the system, or where reversing it is expensive: sending a message to a customer, posting a journal to the general ledger, writing a payment file, or updating a CRM field that triggers downstream workflows. A classification step that assigns a category to a document is cheap to correct afterwards, so we log the result and let the run continue without a gate. Gating a step like that anyway is a common instinct, and it spends attention the queue will need later.
Position within the sequence matters as much as the choice of step, because it determines what the approver can see. A gate that sits early in the run presents a description of what the system intends to do, since the artefact does not exist yet. Moving that same gate to the point immediately before the irreversible call presents the finished output, which is the message body, the payment line or the API request that will be sent. We put the gate in the late position wherever the workflow allows it.
The Anthropic report published on 13 November, describing an espionage campaign run largely through Claude Code, is the one we keep going back to, for reasons beyond the security story. Anthropic reported that the threat actor was able to use AI to perform 80 to 90 per cent of the campaign, with human intervention required only sporadically, at perhaps four to six critical decision points per hacking campaign, and that the model occasionally hallucinated credentials or claimed to have extracted secret information that was in fact publicly available. The 80 to 90 per cent is Anthropic's own account of a single campaign, so how far it carries to any other estate is unestablished. Two things in it apply to gate placement anyway. A long agentic chain can run to completion with very few checkpoints in it, and the model's own summaries were sometimes wrong, so the record of what a chain did has to be assembled from the executed steps rather than from the chain's account of itself.
What evidence goes on the item
The test we apply to an approval item is whether the approver has enough attached to reach a different conclusion from the system's, and we design the item so a minute of reading is enough to do it. For a supplier invoice being coded to a cost centre, that means the invoice page rendered inline with the extracted fields highlighted at the coordinates they were read from, the supplier's recent coding history, the purchase order it matched against with the match score, and the general ledger line that will be posted.
This is where we part company with a good deal of current practice. An explanation produced by the same model that produced the answer is correlated with it, including in the cases where the answer is wrong, so we do not count it as an independent check. The approver needs material generated by something other than the model: the source document, the rows the query returned, the query itself, and the exact payload that will be sent. Where the action is an API call we render the literal request body, because a rendered summary can be built by a different code path from the one that sends the call and can drift from it.
We also want the item to state what rejection does, because the effect varies between workflows. Rejecting can send the work back for reprocessing, route it to a colleague, or discard the item, and the item needs to name which of those applies before the approver decides.
What to log
The decision record is a separate artefact from the run log, retained as long as the business record it produced. It holds the item identifier, the approver's directory identity, the timestamp, the workflow version, the model and model version used for any interpretive step, a hash of the inputs, the exact payload approved, and the outcome of executing it. We store the payload because after an incident the question is what the approver was shown at the moment they clicked, and reconstructing that from the run log afterwards is not reliable.
The rejection path gets more detail in our schema than the approval path does, and we would argue for that in any design review. A rejection carries a reason code identifying a case the automation got wrong, and the accumulated codes are the most direct evidence available about which rules, prompts or extraction steps need changing. Two timing measures are worth recording: the interval between an item being opened and the decision being submitted, and the proportion of items decided faster than a threshold set for that queue, with the threshold derived from how long it takes to read the attached evidence.
Microsoft's Agent 365, announced at Ignite on 18 November, addresses an adjacent layer. It issues agents identities in Microsoft Entra, scopes access to the resources an agent needs, and produces telemetry through Defender and Purview. Microsoft describes the registry as an inventory of all agents in an organisation, and the Microsoft 365 blog describes coverage of shadow agents as coming soon. A capability described as coming soon carries no delivery date a design can rely on, so it stays outside the scope of a build going in now. Agent 365 covers agent inventory and access scope. The per-decision record of which person approved which business action is something the workflow still has to write itself, and we would not design on the assumption that a control plane will one day supply it.
Queues that get rubber-stamped
Rubber-stamping is a predictable result of queue design, and we would rather examine the design than the approver. Three conditions produce it: high volume, a low rate of genuine errors, and no cost attached to approving. With those three conditions in place the approver comes to expect that the default answer is correct, reading each item stops being worth the time it takes, and the log records each of those clicks as an approval by a named person.
Volume is the main lever, because a gate on a reversible step consumes the same attention as a gate on a payment run, and removing the low-consequence gates raises the average weight of what is left in the queue. Sampling is the second lever: for an action class with a measured low error rate, review a fixed proportion of items and let the rest through. Batching is the third, since twenty invoices from one supplier shown on one screen make an outlier easier to spot than the same twenty presented as separate items.
Four structural choices help alongside those levers. Items go to the person who carries the consequence of the decision. The timeout behaviour is a hold, so an item nobody decides on expires without the action being sent. Approvers see the downstream outcome of their earlier approvals, including the ones that turned out to be wrong. Known-bad items are seeded into the queue on a schedule, and the rate at which approvers catch them is recorded as a queue metric.
Anthropic released Claude Opus 4.5 on 24 November and described it as the most robustly aligned model it has released to date and as harder to trick with prompt injection than any other frontier model in the industry. Those characterisations come from Anthropic's own evaluation of its own model, so what they establish is how the model behaved under Anthropic's testing. Improvements of that kind reduce the number of genuine errors reaching the queue, which is one of the three conditions that produce inattentive approvers. Fewer errors in the queue is a real effect and it does not on its own justify removing a gate. We treat the timing measures and the seeded known-bad items as the checks on whether the gate is still doing work, and we keep reading them after a model upgrade.
How much a model upgrade shifts the error rate arriving in a given queue is not something a benchmark score settles. Establishing it takes a few months of the timing measures and the seeded-item catch rate on either side of the upgrade, read from the queue itself. Until a queue carries that history, the defensible position is that the upgrade moved the error rate by an unknown amount, which keeps the gate where it is and the measures running.