AI agents need a running tab, not another approval button

The dangerous moment in AI agent work is not always the dramatic one. It is not the agent deleting a database in a single stupid move, or sending one obviously reckless command for a human to approve.

The more common risk is quieter. The agent tries something. It fails. It tries a variant. It gets nudged by a handoff from another session. It reads a compressed note instead of the original source. It calls another tool. It burns more time, more budget, more permissions and more context. Every individual step looks reasonable enough. The run as a whole has drifted somewhere nobody actually approved.

That is the gap most agent governance still misses.

The received wisdom is simple: keep a human in the loop. Ask before writes. Confirm before sends. Put an approval button between the agent and anything sensitive. It sounds sensible because it is sensible, at least at the start. An approval gate is better than blind autonomy.

But an approval button is not an operating model.

The risk accumulates across the run

The live conversation is starting to expose the weakness. Humans are not perfect filters for high-volume tool use. A game-based permissions study published by ScaleX reports that participants missed one in three simulated threats across more than 40,000 agent-command decisions. That is one study in a simulated environment, not a universal failure rate. The practical warning still matters: review quality drops when the reviewer is tired, rushed, under-contextualised or staring at the fiftieth nearly identical permission prompt of the day.

That means the risk is cumulative. Not just what did the agent ask to do this second, but how many attempts has it made, how many similar paths has it tried, how much budget has it burned, how much authority has it touched, how many failures has it normalised, and how far is the current state from the original brief?

This matters even more as agents get better at memory and handoffs.

Compiled knowledge systems are useful. Turning a large reference pack into a compact skill, with deeper source files loaded only when needed, is exactly the right direction. Cross-session messages are useful too. A small handoff between workers can keep long jobs moving without stuffing every session with the full history.

But compression is not evidence. A chapter summary is not the book. A handoff message is not shared state. A neat "next action" is not the same as the original decision, the source, the test result and the unresolved caveat.

What is a running tab for an AI agent?

A running tab is the live operating record of an autonomous workflow. It combines the current state with the history needed to judge whether the agent should continue. Foundry's view is that this record should include retries, tool calls, elapsed time, spend, permissions touched, external writes attempted, repeated failures, handoffs received, evidence produced and thresholds crossed.

This is technically achievable now. LangGraph's persistence layer, for example, checkpoints thread state so a workflow can resume after an interruption or failure. The persistence is useful because it preserves continuity. It becomes governance when the saved state also exposes limits, evidence and decision history to the reviewer.

The approval question should not be "does this next command look acceptable in isolation?" It should be "given everything this run has already done, should it still be allowed to continue?"

That changes the shape of the system.

Supervise the workflow, not just the command

A normal approval gate asks for consent. A running tab gives the reviewer context. It can say: this is the seventh attempt at the same class of fix; this job has touched three systems; this worker is acting from a compressed handoff; this source was last refreshed yesterday; this run has used 82% of its spend ceiling; this next step is the first external write.

That is the difference between supervising a command and supervising a workflow.

Observability standards are moving in this direction too. The OpenTelemetry generative AI semantic conventions define common telemetry for agent and model operations. A business does not need to adopt every emerging convention on day one. It does need a consistent record that can explain what ran, what it touched and why it stopped.

Give every autonomous job hard limits

The practical version is not complicated. Start by recording the limits and evidence that matter:

• Maximum retries, tool calls, elapsed time and spend.
• Maximum failed approaches before escalation.
• Clear approval rules before external writes.
• An artefact path, version, decision and evidence pointer for every handoff.
• An unresolved issue, owner and next action for every paused run.
• Permission-neutral messages, so one agent cannot approve work on behalf of another.
• Knowledge answers that trace back to source files, not confident summaries alone.

For a small business using AI, this is the part that matters this week. Do not start by asking how much autonomy your agent can have. Start by deciding how you will know when that autonomy has gone stale, noisy, expensive or unsafe.

Agents do not just need permission to act. They need a running tab that knows when to stop them.

Further reading

• AI Agents Need Receipts, Not Trust
• AI Agents Need a Control Plane, Not More Prompts
• AI Agent Workspaces Need Permission Design, Not Vibes