An AI agent approval workflow is the control path between a proposed action and its execution. A useful approval is not a generic continue button. It tells the reviewer what will happen, to which target, with what data or cost, how success will be checked, and where the action must stop.
Bind approval to six exact fields
- Action: the operation—publish, send, change code, deploy, spend, or run paid research.
- Target: the account, recipient, repository, environment, audience, or provider resource.
- Payload: the exact copy, files, patch, query, budget, or configuration under review.
- Scope: the allowed quantity, permissions, duration, and side effects.
- Success check: the evidence that distinguishes completion from an attempted action.
- Stop condition: the time, cost, error, ambiguity, or signal that ends execution.
Use a visible state machine
- Proposed: the agent prepares a bounded action and explains why it matters now.
- In review: the user can inspect the target, payload, scope, acceptance criteria, and likely side effects.
- Revised or rejected: corrections close the old proposal and produce a new version when appropriate.
- Approved: consent is recorded against the exact reviewed version.
- Executing: the specialist attempts only the approved scope and reports holds or failures.
- Verified: provider evidence, test output, a public URL, or another explicit check proves the result.
- Learned: the result and signal return to project context before the next proposal.
Worked example: revise a research card before approval
This example follows Soloop's current approval contract, but it is deliberately illustrative rather than a claimed customer run. It shows how a vague proposal becomes an exact, auditable task.
Research competitors and recommend what we should build. The target, source boundary, cost, acceptance criteria, and stop condition are missing, so this version should not be approved.
Limit the task to one named competitor and approved public domains. Require dated source links, counterevidence, explicit unknowns, and a decision handoff. Prohibit login, purchase, trial creation, and contact.
Review the official homepage, documentation, pricing destination, and terms. Cost: $0 in paid services. Stop before authentication or when a material fact cannot be verified.
Record the approved version, executor, timestamps, sources opened, inaccessible evidence, and whether any stop condition fired. A completed search without this record remains an attempt, not verified completion.
Return the dated evidence ledger, separate observation from inference, and identify the exact founder decision changed by the work. Do not convert secondary research into a demand claim.
Store the result and strongest unknown with the project before proposing the next task. A later publish, email, code, deployment, or spend action needs its own applicable approval boundary.
Gate by consequence, not by agent enthusiasm
Low-risk, reversible analysis can often proceed with lightweight controls. External messages, public posts, code changes, deployments, account connections, paid services, database mutations, and spending deserve explicit review. Risk also depends on the target: editing a draft is not the same as publishing it under a founder's identity.
A handoff to a specialist should not automatically approve that specialist's external action. The later card can contain the real recipient, copy, repository, diff, or cost that was unavailable at handoff time.
Prevent approval fatigue
- Ask once at the latest safe moment, when the reviewer can see the real payload.
- Group only actions with the same risk, target, and stop condition.
- Show the changed fields on a revision instead of making the user reread everything.
- Use defaults that fail closed when ownership, authentication, or scope is missing.
- Keep read-only research distinct from paid services and external writes.
- Let the user pause or reject without losing the proposal's evidence trail.
Keep an audit record that answers what happened
Soloop uses approval paths for research, public posts, beta email, coding changes, and deployments. Its current public boundary matters: X/Twitter is live with OAuth; cold email is beta and needs Gmail; Reddit publishing is manual; ads are plan-only; and coding runs in a sandbox. The approval surface should describe the actual execution path rather than imply a planned channel is live.
- Who proposed and who approved the action?
- Which immutable version and target were reviewed?
- When did approval and execution occur?
- Which provider, account, repository, or environment was used?
- What evidence proves success, failure, or partial completion?
- What cost, output, signal, and follow-up decision resulted?
A practical review card
- Objective: the decision or outcome this action supports.
- Why now: the evidence that makes this the next move.
- Exact action and target: what will change, where, and under which account.
- Preview: final copy, files, diff, query, or budget.
- Acceptance and stop checks: how completion and failure will be judged.
- Controls: approve, revise, reject, or pause.