Designing AI automations that touch money or customers: human-in-the-loop approval gates

Let the AI prepare and let a person decide, for any step that moves money, messages a customer or can't be undone. That is an approval gate: the workflow stops, shows a person what it wants to do and why, and carries on only when they say yes. Add a record of every decision and hard limits on spending, and the rest can run on its own.

Which steps need a person

• ✓Always ask firstPayments, refunds, credits, changes to an account, anything sent to a customer in your name while the automation is new, and anything with a legal side.
• ✓Check a sampleSteps that are easy to fix if wrong, like a draft reply that's sent after a delay, or a tag on a ticket. Review all of them at first, then a sample once you know how often they're right.
• ✓Let it runInternal summaries, sorting, notes to your own team. The cost of a mistake is a moment of someone’s attention.

The question for each step is not "could the AI get this wrong?" It can. The question is what a wrong answer costs, and whether you can take it back.

What a good approval screen shows

• The action in plain words: "Refund $48.00 to Jane Doe for order 1042."
• What it was based on: the ticket, the order, the policy it applied.
• Why: the model's short reason, so the reviewer can spot bad logic, not only a bad result.
• Approve, edit or reject in one click, with edit as a real option, because "almost right" is the most common answer.
• What happens if nobody answers. The safe default is to do nothing and tell someone, never to go ahead.

The workflow waits, it doesn’t poll

A gate can stay open for minutes or for a weekend. That needs a workflow that can pause without holding anything open, and pick up exactly where it stopped when the answer comes. Durable workflow engines are built for it. In Temporal, a refund with a gate looks roughly like this:

import { condition, defineSignal, proxyActivities, setHandler } from "@temporalio/workflow";
import type * as activities from "./activities";

const { draftRefund, askReviewer, issueRefund, record } = proxyActivities<typeof activities>({
  startToCloseTimeout: "1 minute",
});

type Decision = { approved: boolean; by: string; amount?: number };
export const decide = defineSignal<[Decision]>("decide");

export async function refundRequest(ticketId: string) {
  const draft = await draftRefund(ticketId); // the AI step: amount, reason, sources
  await askReviewer(draft);

  let decision: Decision | undefined;
  setHandler(decide, (d) => void (decision = d));
  const answered = await condition(() => decision !== undefined, "48 hours");

  const final = answered && decision ? decision : { approved: false, by: "timeout" };
  await record(ticketId, draft, final); // every outcome is logged, including no answer
  if (final.approved) await issueRefund({ ...draft, amount: final.amount ?? draft.amount });
}

Audit logs: what to record

Every decision should be explainable later, to your team, a customer or a regulator. That habit comes from working on the systems that keep every account's money and shares correct at a US brokerage: if a number changed, you can say who changed it and why.

• What ran: the workflow, the step, the model and the prompt version.
• What it saw: the inputs, or a reference to them if they are sensitive.
• What it proposed, and what actually happened.
• Who approved, edited or rejected it, and when.
• Kept append-only: rows are added, never edited or deleted.

Spend limits and other hard stops

• ✓A budget per runA cap on tokens and steps for one run, so a loop stops itself instead of running all night.
• ✓A budget per dayWhen the day’s budget is spent, new runs wait and someone gets an alert.
• ✓Limits on actionsRefunds over a set amount go to a senior person. No more than a set number of customer emails an hour.
• ✓An off switchOne setting that pauses the automation without a deploy, for the day something looks wrong.

Start strict, loosen with evidence

Begin with a person approving every risky step, and record whether they approve, edit or reject. When a step is approved unchanged almost every time for weeks, move it from "ask first" to "check a sample". When edits are common, the step needs a better prompt or better inputs, not less oversight.

This is how I build automations for clients: the gates, logs and limits are designed in the plan, before any code. How AI automation works with me.