How approvals work

Every write pauses for a human.

apsera.ai runs AI workers against your real systems — Salesforce, GitHub, Confluence, the cloud CLI. Read-only calls run silently. Anything that changes external state stops at a human gate before it executes. This page explains why we built it that way and how it works in practice.

The problem

An LLM that talks fluently and an LLM that’s right are not the same thing. When a confidently wrong worker calls sf_update_record, you discover the mistake later, on a customer call. We don’t want our software to be the reason someone has to apologise to a CEO.

So we made a choice early: apsera.ai is auditable, not autonomous.Every destructive call surfaces in your queue with the proposed input, the worker’s reasoning, and a one-click Approve / Reject. You see what’s about to happen before it happens. After 30 days, you’ll start auto-approving the workflows you trust; the gate stays in place for the ones you don’t.

What pauses, what runs silently

Each tool the workers can call is tagged at the runtime level (in portal/src/lib/workers/generic.ts). The full destructive list today:

• sf_update_record, sf_create_record
• cf_create_page, cf_update_page
• gh_create_or_update_file, gh_create_branch, gh_open_pr
• az_run_command, az_deploy_static_site

Anything else — sf_query, cf_get_page, gh_get_file, describe / list / search calls — runs immediately. The whole system is biased toward "look, then ask, then act."

On top of that, the runtime watches for two patterns and pauses on its own:

• Hallucination guard— if a worker says they’re done but the summary actually reads like "I need access," "please confirm," or "stopped due to," we convert the message into an approval request. You answer in the chat; the worker continues.
• Loop circuit-breaker — if the same tool with the same input fails three times in a row (or once for an authentication failure), we stop instead of looping forever. The task lands as Awaiting approval with the last error.

What an approval looks like

When a worker hits the gate, the task moves to status Awaiting approvaland a chat-style card appears on that worker’s page. The card shows:

• The proposed tool and its full input (e.g. "Update Account 0015… set Industry = Healthcare").
• The worker’s plain-English reason ("Migrating tickets you flagged in the Gong call at 2:14").
• Any options the worker presented ("Use Northwind Q3 expansion vs. Northwind Q4 expansion?").

You answer in one of three ways:

• Approve — the call executes, the worker continues from there.
• Reject — the call is cancelled, the worker stops cleanly with a note in the activity log.
• Reply — type a free-text message ("not Healthcare, use Software"). The worker reads your reply in their next turn and adjusts.

Namespace scoping (so you’re not clicking 50 times)

Once you approve the first sf_* write in a task, the worker can run more sf_* writes in the same task without re-prompting. Each integration namespace (sf, cf, gh, az) gets its own grant. A task that updates 50 Salesforce records asks once, not fifty times.

The grant is per-task, not global. Starting a new task means starting from "ask first."

You can always undo

For Salesforce updates, we capture the prior values before the write. Every task’s audit page renders a Field / Before / After diff and a one-click Undo button that re-applies the previous values. If something slips past the gate that shouldn’t have, you don’t need to dig through Salesforce’s field history — the rollback is right there.

Confluence undo is on the roadmap; for now, the diff view shows you the before/after body text so you can paste the old version back manually.

Per-tool approval rules (coming)

Today every tagged tool pauses unconditionally. For high-volume personas (a data analyst running 50 SELECTs/day, a Salesforce admin doing routine field updates), that’s friction. We’re moving to three tiers driven by per-org working_agreements.approval_rules:

• Auto — read-only tools, pure SOQL queries, anything that can’t change state. Run silently.
• Auto with notice — low-impact writes (creating a Confluence page in a draft space, e.g.). Run, log loudly, surface in the activity feed.
• Approve — destructive writes against customer-facing data, anything explicitly tagged. Pause for human.

Schema is in place; the runtime read-path lands later this quarter. Until it does, everything in the destructive set above pauses.

If you’re evaluating us against fully autonomous agents

Plenty of competitors will call the SOQL update without asking. They demo great. The first time one of them deletes a wrong record in a customer’s instance, the IT review at that company stops being routine.

We bet that auditable beats autonomous in B2B contexts, and we built the product around that bet. It’s also why every action is diffable, every change is rollback-able where the API allows, and every task has a permanent audit trail you can hand to a security reviewer without preparation.

Questions? [email protected] — or sign up and try it on your own data; the gate is on by default for every new workspace.

Last updated: 2026-05-05.