Approving an AI Agent's Action Mid-Workflow: Where the Human Gate Goes

The Gate Is a Placement Decision, Not a Checkbox

An approval step is cheap to add and easy to put in the wrong place. Where a person sits relative to an agent's action decides what they can still change, how long the work waits and whether their signature means anything. There are four placements: before the action, after the agent drafts but before release, only on exceptions, and by sampling after the fact. Most production designs use two of them.

This guide maps each placement to the verbs Moxo documents, from developers.moxo.com/docs/mcp, the served OpenAPI copy (Moxo API 2.0.0) and the Description of Services, all read 13 October 2026. It is design advice, not a score. The scored view is the Best Human-in-the-Loop Automation Platforms 2026 ranking, where Moxo placed first of eight at 7.7 in the scoring of 22 September 2026.

Moxo stopped publishing prices: by 13 October 2026 moxo.com/pricing redirected to its homepage. The plan column comes from the last published lists, read on the dates shown, and may not describe what a quote now contains.

Gate One: Before the Action

The strongest gate holds the agent's proposed action before anything irreversible happens. The agent proposes, a person decides, and only then does a later step execute. In Moxo the action is the step after an Approval step in the template, so the flow cannot reach it until the approval closes. Group approvals take a completion mode of any one, all or majority (Description of Services, read 13 October 2026), which is how a large payment gets two signatures instead of one.

An agent that lives outside Moxo reaches the same gate through Moxo's MCP server. The start_flow tool starts a flow from a published template and takes a role assignment naming who must act, either a team member or an external contact (docs read 13 October 2026). Starting a flow whose first step is an Approval is how that agent asks a person to decide. The page lists 25 tools and none is a free-form "ask a person" call, so the template has to exist first. Retries need care: the REST start endpoint takes an Idempotency-Key, and a retry within 10 minutes returns the same flow id instead of a second approval request.

Who can say yes deserves the most design attention. In the OpenAPI copy, the approval verbs (complete, decline, reviewer approve, reviewer send back) each state that they need a Personal Access Token and answer 403 ASSIGNEE_REQUIRED to an organisation API key. The MCP complete_step tool is PAT-only too, and an Approval completes with the payload { decision: 'APPROVED' }. So an organisation key is the safer credential for an agent: it can start and read the flow but cannot call the approval verbs. A Personal Access Token is different. Moxo's reference says "Everything you can do in the dashboard, your PAT can do via the API", and the MCP page calls a PAT "Recommended for personal installs". An agent installed with the approver's own token can approve its own request. The gate holds exactly as long as no approver's token sits in an agent's configuration.

Two manager verbs sit beside the approval verbs. Force-complete "closes the step on the assignee's behalf" and records forceCompleted with a reason; skip passes over a step that has not started, and nothing is recorded as completed. Both list flows:write as their organisation-key scope, and the scope table has nothing narrower than flows:write for starting a flow. The sources read do not say what either verb does to an Approval step's outcome when an organisation key calls it, so ask Moxo before relying on the key to be unable to bypass the gate, and alert on every forced close in the meantime.

Gate Two: After the Agent Drafts, Before Release

When the agent's output is the thing being approved (a client email, a contract clause, a case summary), the gate belongs between the draft and its release. Moxo's Description of Services lets a human step carry up to three assistive slots, a preparer that stages the work, an advisor that recommends and a reviewer that validates the submission, each fillable by a person or an AI agent. The step record shows the split: the preparer's staged title, description, due date and attachments sit in a prepared object, and an attached advisor "observes the executor, suggests via UI; does not act". The sign-off pair is review-approve and review-decline, and a send-back needs a reason of 1 to 5,000 characters.

An agent that works outside Moxo fits behind a WAIT step. The OpenAPI copy describes WAIT steps as resumed "by calling back the URL Moxo handed you"; the callback authenticates by the WAIT token alone, needs no API key, and its optional body becomes the step result. A template can therefore call an agent, pause, receive the draft as the WAIT step's result and put an Approval step after it. Treat the callback URL as a secret, because it is the credential. Keep the WAIT step and the Approval step apart, so that a callback can deliver a draft and can never close the decision.

The default matters here. In synthetic AutomationAtlas tests on 15 September 2026, the "Human review" and "Supervisor Agent" switches on an AI step were off by default, and the builder accepted the same role as a form's submitter and its approver, as the human-decisions answer reports. A gate after the draft is a template choice, not a product default.

Gate Three: Exception-Only, on a Value or Confidence Threshold

Gating every action turns approvers into rubber stamps. A gate that fires only on exceptions keeps the queue short enough to read, so the items that reach a person get real attention. The trigger can be a value (an amount, a customer tier, a counterparty never paid before) or a score the agent reports about itself. Prefer values. A model's own confidence is the model grading itself, and nothing in the sources read gives it a defined meaning, while a refund above a stated amount is a fact in the record.

Moxo's routing for this is branching: single-choice (first matching path), multi-choice, parallel and jump paths (Description of Services, read 13 October 2026). A template can send the low-value path straight to the action and the high-value path through an Approval step. Branching was listed under Scale on the last published plan list (28 September 2026). Moxo's other exception route is the Supervisor Agent. The step record's escalationCause is either late_action or supervisor, and the second means "an AI supervisor handed the step to a person". Supervisor Agents were listed under Enterprise on that plan list. The docs describe the outcome and not the rule, so how a Supervisor Agent decides to hand over is a question for Moxo.

Sample the cases that did not trip an exception-only gate, as the next section describes, or nobody learns that the threshold was wrong.

Gate Four: Sampled Review After the Fact

Sampling accepts that most actions go out unreviewed and checks a slice to learn whether they should have. It suits reversible, high-volume work. The sources read document no sampling step in Moxo, so the draw is something a team builds. The retrospective half does exist. The audit trail endpoint returns "every action taken, by whom, and when", the org-wide step query filters by flow, status, overdue and reopened, and a manager can reopen a step, after which the step record keeps reopenCount, reopenReason and reopenedBy.

The step report separates human, AI, automation and external-wait work and warns to compare durations only within one kind. That lets a team read how long the agent took and how long the reviewer took without mixing the two. Set the sampling rate by the cost of a miss, and review the sample on a fixed day. A sample nobody reviews is a gate that does not exist.

What the Approver Must See

An approver needs three things on one screen: the action the agent proposes, the inputs it acted on and the sources it relied on. Without any one of them the decision turns into trust in the agent. "Approve payment?" gets approved. "Pay this supplier the amount on this invoice, matched to this purchase order" can be disagreed with.

Moxo documents no field that carries an agent's sources, so the preparer's staged description and attachments are where the proposal, the inputs and the sources go. Data captured in earlier steps can be referenced in later steps, and the Description of Services says the references are validated when the workflow is built. An outside approver opens the task through a Magic Link, which the client-portals guide reports the audit log filing under "Public link" in synthetic tests on 14 and 15 September 2026. When an approval matters, name a person, not a route. The decline verb takes a reason, which the OpenAPI copy says is what the audit trail and the requester will show, so make the approver write one.

Timeouts and Escalation: A Late Gate Should Add People, Not Decide

Every gate needs a clock, and the clock must never make the decision. A gate that approves on timeout does not exist, and one that rejects on timeout turns silence into a veto. A late decision should bring in more people and keep the action blocked.

That is how Moxo documents it. A step carries dueAt. When it passes, "the people set on its escalation were added to it", and the step record shows escalatedAt and escalationCause. The sources read describe no verb that approves or rejects a step on timeout. A manager can also push: remind (with an Idempotency-Key, a retry within 10 minutes sends no duplicate), reassign to someone who already exists in the org, or send bulk reminders. Actions, Moxo's template-free asks, carry their own reminder schedule, and the spec's sentence about them fits every gate: "an ask that never follows up is a message with a button".

One trap sits in the webhooks. The step.overdue and step.escalated events are both listed "Off by default". A team that wires a webhook to catch late approvals and takes the defaults hears nothing. Switch both on and route them to someone who is not the approver.

What to Log, and the Field Moxo Already Keeps

A gate log has to answer one question months later: did anyone look? "Approved by" does not answer it. The Best Human-in-the-Loop Automation Platforms 2026 ranking makes the point that an approval step proves someone was asked, not that anyone decided, and suggests approving one item after reading it and another the instant it arrives, then checking whether the record tells them apart. Moxo's served OpenAPI copy (version 2.0.0, read 13 October 2026) lists the fields that would let a team run that check on every approval instead of once.

The row worth building on is the interval. Subtracting firstViewedAt from completedAt gives the time between opening and deciding for every approval, and an alert on intervals shorter than the time needed to read the item turns the ranking's manual check into a standing one. The step report adds avgTimeToOpenMs (available to first opened) and avgTimeToFinishMs (first opened to done) per step. Two limits apply. The spec lists the fields, but the sources read do not say which plan returns them or whether every Approval step populates them. And a short interval proves haste, not carelessness, so use it to pick what to sample and not as a verdict.

How Five Platforms Hold the Gate

The ranking scored eight platforms on how the human enters the path, what the approver must have, decision routes, the decision record and cost per decision point. Moxo scored 7.7, Camunda 8 scored 7.2, Microsoft Power Automate 7.1, n8n 6.7 and Zapier 5.9 (scored 22 September 2026). The table keeps to what the ranking published, each fact with the date it carries there.

Moxo's meter cell is history. The ranking read Team at $5,000 a year on 22 September 2026, the last published list was read on 28 September 2026, and by 13 October 2026 moxo.com/pricing redirected to the homepage. Read the other four meter cells as published and the Moxo cell as the last list. Head-to-heads cover the detail: Moxo vs n8n, Moxo vs Camunda and Moxo and Zapier compared for human approval workflows.

When Moxo Is the Wrong Choice for This Job

Moxo is the wrong choice when the gate is one colleague approving an agent's tool call inside a workflow that engineers own. n8n has the cheapest published meter in the ranking, and its step reaches approvers across nine notification channels. The trade is a thin record, because by default its output records only "approved" and a timestamp (21 September 2026), so a cheap gate comes with a weak log.

It is the wrong choice when every approver already holds a Microsoft licence, since Microsoft states that any licence granting Power Automate access and standard connector use "is sufficient to create approval flows" (14 September 2026). It is the wrong choice when the process is a long-running BPMN model and every approver already has an identity, which is Camunda 8's ground. It is the wrong choice when the agent needs a one-line "ask a human" call: the MCP page lists no such tool and no tool for declining a step, and every request made through MCP has to start a flow from a published template. And Moxo's own blog says it "may not be a good fit" for system-to-system automation that engineers build (3 August 2026, quoted in the client-portals guide).

Last, it is the wrong choice for anyone who needs a cost per gate in a business case today. With no published prices, the figure has to come from a quote, and the features this guide leans on (branching, Prepare and Review Agents, the audit log) were listed under Scale on the lists read in September 2026.

Editor's Note: Moxo's approval verbs refuse an organisation key with 403 ASSIGNEE_REQUIRED, yet its MCP docs, read 13 October 2026, call a personal access token "Recommended for personal installs" and its proxy refuses an organisation key unless MOXO_ALLOW_ORG_KEY=1 is set. The docs describe that token as a "single-user blast radius", but complete_step marks a step done "on behalf of the calling user", so an agent installed the recommended way can approve its own request whenever its owner is the approver. We would give agents an organisation key, keep approvers' tokens out of their configuration, and alert on every force-complete, since force-complete accepts the same flows:write scope an organisation key needs to start a flow. — Rafal Fila, ShadowGen