Building Approval Workflows for Autonomous Actions

Key facts, with sources

• METR found the length of tasks frontier AI agents can complete autonomously with 50 percent reliability has been doubling roughly every 7 months since 2019. (METR)
• Continuations of METR's time-horizon tracking show frontier models in 2026 completing tasks that take human experts around 12 hours at 50 percent reliability, up from about 50 minutes for early-2025 models. (AI Digest)
• About 88 percent of AI agent pilots never reach production, with integration, reliability, latency, and security named as the main blockers rather than model quality. (Institute of Project Management)
• Gartner predicts at least 15 percent of day-to-day work decisions will be made autonomously through agentic AI by 2028, up from 0 percent in 2024. (Gartner)
• The global AI agents market was valued at about $7.6 billion in 2025 and is projected to reach roughly $183 billion by 2033, a compound annual growth rate near 50 percent. (Azumo)

Decide which actions park and which flow

Not everything needs approval — an agent that asks permission for every read is unusable, and an approval queue drowning in trivia protects nothing. The sorting question is undo cost. Actions that are irreversible, expensive, or customer-visible park for review: external emails, refunds, payments, deletions, permission changes. Reversible internal writes flow autonomously with an audit log.

I run this classification with the business owner in the room, not as an engineering exercise, because the two groups reliably disagree about what is actually reversible. The output is a written action policy — and it evolves. Action types with months of clean approvals get promoted to autonomous; anything involved in an incident gets demoted back behind review.

The queue pattern: request, park, resume

Mechanically, the agent serializes its intended action — tool name, exact payload, and its justification — into a pending-approval record, then stops. For short waits the run can block and poll; for approvals that might take hours, the run checkpoints its state and a decision event resumes it later. Either way, the decision itself is recorded permanently: who approved, when, and any note they attached.

One subtlety that bites teams: the approved payload must be executed exactly as reviewed. If the agent re-generates the action after approval, you have signed off on one thing and executed another. Approval binds to the specific serialized payload, byte for byte, and any change invalidates it.

A minimal approval service in FastAPI

Here is the skeleton I start from — an approval resource with a pending state, a decision endpoint for the reviewer UI, and a poll endpoint for the agent. In production the dict becomes a database table, decisions carry authenticated reviewer identity, and a notification hook pings the reviewer's Slack or mobile app when something parks.

from uuid import uuid4
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()
approvals: dict[str, dict] = {}  # swap for a database table in production

class ActionRequest(BaseModel):
    tool: str
    payload: dict
    justification: str  # the agent's stated reason, shown to the reviewer

class Decision(BaseModel):
    approve: bool
    note: str = ""

@app.post("/approvals")
def request_approval(req: ActionRequest):
    approval_id = str(uuid4())
    approvals[approval_id] = {"request": req.model_dump(), "status": "pending"}
    return {"approval_id": approval_id}

@app.post("/approvals/{approval_id}/decision")
def decide(approval_id: str, decision: Decision):
    item = approvals.get(approval_id)
    if item is None or item["status"] != "pending":
        raise HTTPException(status_code=404, detail="No pending approval")
    item["status"] = "approved" if decision.approve else "rejected"
    item["note"] = decision.note
    return item

@app.get("/approvals/{approval_id}")
def poll(approval_id: str):  # the agent polls this before executing
    item = approvals.get(approval_id)
    if item is None:
        raise HTTPException(status_code=404)
    return item

Show reviewers the payload, not a summary

The reviewer must see exactly what will happen: the full email text that will be sent, the precise refund amount and recipient, a before/after diff of the record being changed. A summary like "send follow-up to customer" hides precisely the errors the queue exists to catch — the wrong recipient, the hallucinated discount, the tone problem in paragraph two.

Alongside the payload, I surface the agent's justification and the key context it relied on. This does double duty: reviewers make better calls, and the justifications become a corpus for improving prompts. Timeouts are the other non-negotiable — a pending approval that nobody actions expires to rejected. Auto-approving on silence converts your safety mechanism into a formality with a delay.

Fight rubber-stamping from day one

Approval systems decay predictably: volume grows, each item gets seconds of attention, and approval becomes a reflex. The countermeasures are structural. Keep the queue small by aggressively promoting consistently-approved action types out of review — a queue humans trust everything in is a queue nobody reads. Track rejection rate; if it sits near zero for months, either the agent is flawless or nobody is looking, and one of those is more likely.

I also sample-audit approved actions retroactively, which catches both agent drift and reviewer fatigue, and I watch approval latency as a health signal. When decisions that used to take a minute start landing in three seconds, that is not efficiency — that is the moment the safety layer stopped existing.

When to hire senior help

Senior help matters most for the safety and reliability envelope, meaning sandboxing, permissions, rollback paths, and evaluation, which determines whether autonomy is an asset or a liability. If pilots keep failing on reliability rather than capability, an experienced agent engineer can usually diagnose whether the problem is tooling, prompts, or architecture within days. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — Autonomous Agents projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Ignoring compounding error rates; an agent that is 85 percent reliable per step succeeds only about 20 percent of the time across a 10-step workflow unless you add checkpoints and recovery
• ✕Granting write access to email, payments, or deletion without approval gates or sandboxing, turning a single hallucination into an irreversible action
• ✕Running long-lived loops with no budget cap, timeout, or kill switch, so a stuck agent burns tokens for hours before anyone notices
• ✕Evaluating on single runs when agent pass rates drop sharply under repeated-run consistency testing, making one good demo a misleading signal

Frequently asked questions

Sources

• METR
• AI Digest
• Institute of Project Management
• Gartner
• Azumo