Designing Approval Workflows for AI Agents

An autonomous agent that can send email, update your CRM, or post to Slack is useful exactly to the degree that you trust it. And trust, for software that makes judgment calls, is not something you grant once and forget. It is something you design into the system with an approval workflow: a set of rules that decide which actions run on their own, which actions pause and wait for a human, and what happens while they wait.

This guide covers how to design that workflow well. Most of it is general advice that applies to any agent platform. Where we describe specific mechanics, we describe how approvals work in Skopx, because that is the system we build and can speak about honestly.

What an approval workflow actually is

Strip away the terminology and an AI approval workflow is three decisions:

1. Classification. For every action an agent can take, decide in advance whether it runs automatically, always asks first, or lets the agent judge when to ask.
2. Presentation. When an action does pause for review, decide what the human sees. A vague summary ("the agent wants to update some records") is not reviewable. The exact call and its exact arguments are.
3. Resolution. Decide what approving, rejecting, and ignoring each request actually does, at the level of guarantees, not intentions.

Many teams get the first decision roughly right and then fumble the other two. They build a system where approval means "the agent is now free to do something like what it described," or where a stale request from last Tuesday can still fire when someone clears their inbox. Both failure modes destroy trust faster than an agent mistake would, because they make the safety mechanism itself untrustworthy.

In Skopx, the resolution semantics are strict by design. A write-shaped action parks as a pending approval that shows the exact call and its arguments. Approving executes exactly that parked call, once. Rejecting executes nothing. Approvals can expire, and an expired approval also executes nothing. There is no interpretation gap between what you reviewed and what runs.

Reads and writes are different animals

The single most important line in any approval design is the one between reading and writing.

A read (fetch these emails, query this table, pull this HubSpot deal, load this web page) gathers information. If the agent reads something irrelevant, the cost is a few wasted tokens. A write (send this email, update this deal stage, create this Jira ticket, post this message) changes the world outside the agent. If the agent writes something wrong, a person has to notice it, understand it, and undo it, and some writes cannot be undone at all.

This asymmetry should shape your workflow. Requiring approval for every read makes an agent useless: a single research pass might involve dozens of reads, and no human wants to approve "search the web for competitor pricing" forty times. Requiring approval for no writes makes an agent dangerous on day one, before you have any evidence about its judgment.

Skopx bakes this distinction in: under the "asks first" tier, reads still flow without approval. Only write-shaped actions park. That means an agent in its most cautious configuration can still do a full investigation, gather everything it needs, and arrive at your approval queue with a complete, well-informed proposed action rather than pausing at every step of the research. If you want to understand what agents typically do with all that read access, what AI agents can actually do walks through the realistic range.

The three tiers, and when to use each

Skopx grants are set per integration toolkit, and each grant carries a tier. The three tiers, and the reasoning behind each, generalize to any approval design.

Runs automatically

The agent executes actions in this toolkit without asking. Use this for:

• Pure reads in systems where nothing sensitive lives. Web search, web fetch, reading a shared calendar.
• Writes with trivial blast radius. Saving an insight to your own Insights Hub, appending a row to a scratch spreadsheet the agent owns.
• Proven paths. A write the agent has performed correctly across many reviewed runs, where you have looked at the run history and concluded the review step is pure overhead.

The mistake to avoid: granting auto-run because approval requests are annoying, rather than because the evidence supports it. Annoyance is a signal that your tiering is wrong somewhere, but the fix is usually narrowing what the agent attempts, not removing the gate.

Asks first every time

Every write in this toolkit parks for approval, no exceptions, no agent discretion. Use this for:

• Anything customer-facing. Emails to external addresses, public posts, review responses. A wrong internal Slack message is embarrassing; a wrong customer email is a relationship problem.
• Anything irreversible or costly. Refunds, deletions, invoice actions, changes to billing objects in Stripe.
• Every new agent's writes, for the first stretch. Treat "asks first" as the default posture during a break-in period. You are not just preventing mistakes, you are collecting evidence. Each approval you grant or reject teaches you where the agent's judgment is solid and where its instructions need tightening. Our guide to testing agents safely treats this break-in period as a first-class phase, not an inconvenience.

Agent decides when to ask

The agent runs routine actions automatically but escalates ones it judges to be sensitive, ambiguous, or outside its normal pattern. This is the most powerful tier and the one to grant last, because it delegates the escalation decision itself to the model.

Use it when two things are true: the toolkit sees a high volume of low-stakes writes (so "ask every time" would bury you), and your instructions clearly describe what counts as sensitive (so the agent's escalation judgment has something concrete to apply). "Escalate anything involving a named account over $10k in pipeline, anything that changes a close date, and anything you are less than confident about" gives the agent a real rule. "Use your judgment" does not. The quality of this tier is mostly a function of the quality of your agent instructions.

The fourth option: drafts only

Alongside the three tiers, Skopx supports a drafts-only mode: the agent prepares the artifact (an email draft, for example) but never sends anything. This is worth calling out because it is often the right permanent setting, not just a training-wheels phase. For high-judgment writing like sales outreach or support replies, many teams want the agent to do 90 percent of the work and a human to do the last 10 percent forever. That is not a failure of autonomy. It is a correct division of labor.

A decision table for tier assignment

Here is a compact way to assign tiers. For each toolkit an agent can touch, ask two questions: how reversible is a bad write, and how visible is it outside your team?

Two notes on reading this table. First, "reads run automatically" assumes the read itself is not the sensitive act. If an agent querying a database could surface data its audience should not see, treat the downstream write (the report, the Slack post) as the gate. Second, "relax later with evidence" means what it says: look at actual run history and approval outcomes before loosening anything. If you have rejected zero of the last fifty requests from a toolkit, the gate is probably overhead. If you have rejected three, it is doing its job.

Design the request, not just the gate

An approval workflow is only as good as the moment of review. If reviewing a request takes real effort, reviewers stop reviewing and start rubber-stamping, and a rubber-stamped approval workflow is worse than none because it produces false confidence.

Three properties make requests genuinely reviewable:

Show the exact action. Skopx approval requests show the precise call and its arguments: the actual recipient, the actual message body, the actual field values. The reviewer is not approving an intention, they are approving a specific operation. This is the difference between "agent wants to email the customer" and seeing the literal email that will be sent.

Guarantee the mapping. Approving must execute exactly what was shown, once. If the system re-plans after approval, or retries in a way that could produce a different action, the review was theater. In Skopx, approval executes the parked call and nothing else.

Keep the queue short. A queue of 3 gets reviewed carefully. A queue of 40 gets bulk-cleared. If an agent regularly produces long approval queues, that is a design smell: either its scope is too broad (consider splitting it, see one agent versus many), its tiering is too strict for actions that have earned auto-run, or its instructions let it attempt writes it should not be attempting at all.

What rejection and expiry should mean

Approve is the easy case. The other two resolutions deserve more design attention than they usually get.

Rejection executes nothing. This sounds obvious, but the guarantee matters: rejecting a parked call in Skopx means that call never runs, and the system does not silently try an alternative version of it. What happens next is up to how the run is designed. Often the useful move after rejecting is to edit the agent's instructions so the same class of proposal does not come back. Rejections are the highest-signal feedback your agent setup will ever get; each one marks a precise spot where the agent's judgment and yours diverged. Treat a rejection without an instruction edit as a bug you chose not to fix.

Expiry executes nothing, and that is the correct default. Approvals in Skopx can expire, and an expired approval does not run. Consider the alternative for a moment: a "send this pricing update to the customer" request parks on Friday afternoon, nobody sees it, and it fires on Monday when someone finally opens the queue, three days after the context that made it correct. Or worse, an auto-approve-on-timeout design, where ignoring a request is the same as approving it. Expiry-as-rejection encodes a sane principle: a proposed action is only valid within the context that produced it, and stale context should fail closed, never open.

The practical implication: if requests are expiring regularly, your problem is review latency, not the expiry mechanism. Fix it by routing approval notifications somewhere your team actually looks, scheduling agents so their requests land during working hours rather than at 3 a.m., or reassigning who owns the queue.

Approval workflows and the rest of the safety stack

Approvals are one control among several, and they work best when you know what each layer is for. In a Skopx agent, the full stack looks like this:

• Grants define which toolkits the agent can touch at all. An agent with no Stripe grant cannot park a Stripe approval, let alone execute one. Grants are attached when the agent is dispatched, so the boundary is structural.
• Approval tiers (this article) govern how writes inside a granted toolkit execute.
• Budgets cap tokens per run, tokens per day, maximum steps, and runtime minutes. Three budget failures auto-pause the agent. Budgets catch runaway behavior that approvals never see, because a loop of reads costs money without ever parking a write.
• Pause and stop are the human kill switches: a run can be stopped mid-flight, and pausing an agent kills its queued runs.
• The run record is your audit surface. Every run keeps a step timeline with expandable raw results, duration, token count, and a final report, and run history is append-only. This is where you gather the evidence to justify relaxing a tier.

The common design error is asking approvals to do a job that belongs to a different layer. If you find yourself wanting approval gates on reads because you do not trust the agent near a system at all, the right tool is removing the grant. If you are worried about cost, the right tool is budgets. Approvals are specifically for writes whose correctness a human can judge better than the model can.

Worked example: tiering a lead-follow-up agent

To make this concrete, here is a hypothetical setup, clearly an example rather than a customer story. Suppose you describe an agent in Skopx's Create Agent chat: "Every weekday at 8:00 UTC, find new inbound leads in HubSpot, research each company, update the lead record with a summary and a fit score, and draft a personalized follow-up email."

A sensible initial grant configuration:

• Web search and web fetch: runs automatically. Pure reads, no blast radius.
• HubSpot: agent decides when to ask, with instructions defining the line: "Update lead properties and log research notes automatically. Ask first before changing lifecycle stage, deal amounts, or anything on an account that already has an owner assigned."
• Gmail: drafts only. The agent writes the follow-up; it never sends. A human reviews drafts each morning and sends the good ones.
• Budgets: a per-run token cap sized for roughly a dozen leads, a step cap, and a minute cap, so a malformed lead list cannot turn into an expensive spiral.
• Success criteria: every new lead has a summary, a fit score, and a draft, and the run report says how many of each were produced.

After a few weeks of run reports and approval history, you review the evidence. If every "agent decides" escalation from HubSpot was one you would have approved anyway, tighten the escalation rule so fewer things ask. If Gmail drafts have needed near-zero edits for a month, you might move send-to-existing-threads to "asks first" while keeping cold outreach drafts-only indefinitely. Each relaxation is a decision backed by the append-only run history, not a hunch.

FAQ

Should every AI agent action require human approval?

No, and designs that try collapse quickly. Approving every read makes agents useless for research, and approving every trivial write trains reviewers to rubber-stamp, which defeats the purpose. Gate write-shaped actions by consequence: irreversible, costly, and customer-facing writes should ask first; trivial and proven writes should run automatically. Skopx reflects this by letting reads flow without approval even under the strictest tier, while write-shaped actions park for review.

What happens if nobody responds to an approval request?

In a well-designed system, nothing executes. Skopx approvals can expire, and an expired approval runs nothing, the same as a rejection. This fail-closed behavior matters because a proposed action is only valid in the context that produced it; an email that was right on Friday can be wrong by Monday. If requests expire often, fix review latency (notification routing, scheduling runs during working hours, queue ownership) rather than extending expiry windows indefinitely.

How do I know when to move an action from "asks first" to automatic?

Use the run record, not your gut. Skopx keeps append-only run history with step timelines and reports, plus the record of what you approved and rejected. If a toolkit has accumulated a meaningful stretch of approvals with zero rejections and the underlying action is reversible, the gate has become overhead and you can relax it. If you are still rejecting requests, or the action is irreversible or customer-facing, keep the gate regardless of how good the streak looks.

Is "agent decides when to ask" safe, or is it a loophole?

It is safe when two conditions hold: the writes it covers are individually low-stakes, and your instructions define escalation concretely (named thresholds, named record types, explicit "when unsure, ask"). It becomes a loophole when granted early, on high-stakes toolkits, or with vague instructions like "use your judgment." Grant it last, after "asks first" has generated enough history to show you where the agent's judgment matches yours, and remember that grants and budgets still bound what it can do even when it chooses not to ask.

Do approval workflows slow agents down too much to be worth it?

They add latency only at the points you chose to gate, and reads never wait. In practice a well-tiered agent does all its research and internal bookkeeping at full speed and pauses only at the handful of consequential writes per run. The comparison that matters is not "gated agent versus ungated agent" but "gated agent versus no agent," because for most teams an ungated agent with write access to customer-facing systems is not an option they would actually ship. Approval workflows are what make real write access deployable at all.

Where to go next

Approval tiers are one piece of running agents responsibly. The natural companions to this guide are AI agents with human approval, which covers the broader human-in-the-loop pattern, agent guardrails for the full control stack including budgets and pause semantics, and audit trails for proving after the fact what an agent did and who authorized it.

If you want to see the mechanics rather than read about them, Skopx's Create Agent lets you describe an agent in chat, set grants and tiers per toolkit, and watch write-shaped actions park with the exact call visible before anything executes. Start everything at "asks first," collect a few weeks of run history, and let the evidence tell you what to relax.