AI Automation That Ships · the Propose-Approve-Execute Pattern

Most AI automation fails in the gap between "the model can do it" and "the operator trusts it." The team that closes that gap ships. The team that ignores it builds a system that quietly makes confident mistakes. The Propose-Approve-Execute pattern is the smallest control structure that keeps an AI agent moving without giving it the keys to the production database. This is not a half measure between manual and autonomous. It is the default operating pattern we use inside Arthea for every customer-facing or state-changing automation we build.

What is the Propose-Approve-Execute pattern in AI automation?

The Propose-Approve-Execute pattern is a human-in-the-loop control structure where an AI agent proposes one specific action, a human approves or rejects it in a narrow interface, and only approved actions execute against live systems. The agent does the research, drafting, and formatting. The operator makes one decision. The system then executes the approved action, records the decision, and feeds the outcome back into the agent's context.

It reads like a standard approval workflow, but the mechanics are different from a ticket queue or a manager sign-off. The propose step is not a summary. It is a fully formed, reversible action with the exact payload, the affected records, the rollback path, and the confidence reasoning included. The approve step is not a comment thread. It is a single action: approve, reject, or ask the agent to re-propose with a constraint.

We ship this pattern in our own products. Kleos, our live internal ask engine, proposes answers and actions but does not auto-execute against our systems. Atlas, our early access approval layer, wraps state changes in approve and reject cards. Alexia, our internal ops agent, drafts actions and waits. The pattern is the same in all three: the agent does the work, the human makes the call, the system ships the approved result.

Why this specific order matters: a proposal is cheap to inspect, an approval is cheap to give, and an execution is expensive to reverse. By separating them, you can let the AI run fast on the cheap parts and force a human checkpoint only where judgment has leverage.

Why do fully autonomous AI agents fail operators?

Fully autonomous AI agents fail operators because they optimize for action volume in a context where one bad action can erase a quarter of good ones, and because the systems that observe failure are often the same systems that amplify it. The cost of a single confident wrong action in a customer database, a refund flow, or a published message is not symmetric with the value of a single correct action. Most operators learn this after the first quiet failure, not before it.

The failure starts with context drift. An agent that runs for many steps without a human check begins to treat its own generated assumptions as ground truth. It updates a customer record based on a past conversation, it sends a follow-up based on a guessed intent, it merges two records because the names match. Each step looks reasonable inside the agent's memory. At step four or five, the small drift compounds into an irreversible change.

Then there is the trust loop problem. If an agent runs fully autonomously and fails, the operator responds by adding more logging, more prompts, more "guardrails" inside the agent's reasoning. That does not reduce the blast radius. It buries the failure deeper. The agent still acts, but now it also spends tokens explaining why its bad action was actually good. Full autonomy does not create more control. It creates more narrative.

We do not run fully autonomous agents against state-changing systems at Arthea. We run narrow, well-scoped agents that propose. The approval surface is the safety rail, not a model setting. This is also why our error handling standards exist. An unapproved action should not silently retry itself into production. It should land in a dead-letter path where a human can see it. That principle is built into the way we standardize n8n error handling: the retry and dead-letter pattern.

How do you design an approval step that doesn't slow down AI automation?

Design the approval step as a decision interface, not a reading interface: the agent shows only the change, the context needed to judge it, and a single approve or reject action; everything else is noise that adds latency. If the operator has to open a second system, read a full transcript, or reconstruct why the agent chose the action, the step is already too expensive.

We build every approval card around one decision, not ten. The card contains four elements. First, the proposed action in plain language: "Refund $19.50 to order #4821." Second, the exact payload the system will send: amount, currency, idempotency key, target record. Third, the evidence the agent used: the customer message, the order status, the policy clause. Fourth, the rollback action: what happens if the approve was wrong.

No reading beyond those four elements is required for a simple proposal. For a more complex proposal, we add a fifth element: the constraints the agent considered and rejected. This prevents the operator from asking "why didn't it do X" and forces the agent to show its reasoning at the edge of the decision, not in a wall of text.

The approve and reject actions are one click. We treat silence or timeout as rejection, never as permission. If a proposal sits too long, it expires and returns to the agent with a note: "Operator did not approve. Re-propose with tighter scope or abandon." That default protects the system when a human walks away from the queue.

We also use a five minute rule in our own workflows. If reviewing a single proposal takes longer than five minutes, the automation is too wide. We cut the action into smaller proposals or rebuild it. The rule keeps the approval step from becoming a second job.

For data products that collect approval history or operator decisions, the same care applies. Atlas early access approval logs follow the data handling rules in the Atlas Privacy Policy. We treat the approval trail as a stored record, not as a debug log to ignore.

What does the Propose-Approve-Execute pattern look like in a real AI automation workflow?

It looks like a six-step runbook: trigger, propose, approve, execute, verify, and log. Each step has a defined input, output, and failure path, so the human decision stays at the only point where judgment adds leverage. The agent does the preparation, the operator confirms intent, and the system handles the rest.

Here is a worked example from an internal support workflow we use to test this pattern. It is a refund draft for a low-risk order issue, not a customer story. It illustrates the mechanics.

• Trigger: A customer message arrives with a request for a partial refund. The system classifies the intent and pulls the order record, the policy, and the last three messages.
• Propose: The agent drafts a specific action: "Propose refund of $19.50 for order #4821 under late delivery policy. Payload: {order_id, amount, reason_code, idempotency_key}. Evidence: customer message timestamped 2025-04-11, order shipped 2025-04-02." The agent does not process the refund.
• Approve: An operator sees the card, checks the amount against the policy, and clicks approve. No second system, no manual calculation. One decision.
• Execute: The system sends the approved payload to the payment processor. Every approved action carries an idempotency key so a double click cannot create duplicate refunds, as described in idempotency keys: why every automation needs them.
• Verify: The system confirms the refund settled or failed. If the execution fails, it follows the retry and dead-letter pattern we standardize in n8n error handling. It does not silently retry forever.
• Log: The full chain, from trigger to verify, is written to an audit record with the operator decision and the agent context. The next agent run can read that log as a prior.

This runbook works because the approve step is a decision, not a research session. The agent has already done the research. The operator only confirms whether the proposed action matches intent. The execution step then runs as code, not as a prompt. That is the difference between an AI assistant that suggests and an AI automation that ships.

If you find the proposal step keeps missing the mark, the fix is not more approval gates. It is usually a smaller scope or a rebuilt extraction step. We have a decision rule for that in when to throw out an automation and rebuild it from the brief.

What are the trade-offs of keeping a human in the loop in AI automation?

You trade some throughput for lower blast radius, cleaner audit history, and a system an operator can actually teach. The pattern is not faster than full autonomy on paper; it is more likely to still be running after the first expensive mistake. That trade is worth it for any action that touches money, customer data, external messaging, or irreversible state.

The real cost is not just latency. It is human attention. Every approval card competes with the operator's other work. If you send twenty vague proposals a day, the operator starts approving blindly to clear the queue. That turns the approval step into a false ritual. The pattern only works when the proposal is already good enough that the operator is checking, not correcting.

There is also a subtle failure mode: over-approval. When the system gets good, the operator stops reading. The agent proposes, the human clicks approve, and the pattern degrades into rubber-stamping. That is still safer than full autonomy because the click leaves an audit trail and a final human checkpoint, but it is not a substitute for process discipline. We keep proposals narrow, reversible, and evidence-backed to make rubber-stamping a conscious choice rather than a default drift.

The honest trade-off is this: Propose-Approve-Execute adds a human step that does not scale linearly. If you need ten thousand actions per hour, a human in the loop will bottleneck. For most DTC operations work, that volume is not real. The work is a few hundred decisions a week, each worth real money or real trust. At that volume, the approval step is not overhead. It is the product.

If you find yourself rejecting the same proposal type repeatedly, do not add a fourth approval rule. Rebuild the automation. The decision signal is the audit log, and it is already telling you the proposal is out of scope. Our rule for that judgment is in when to throw out an automation and rebuild it from the brief.

When should you still use fully autonomous automation?

Use full autonomy only when the action is reversible, the cost per bad action is known and small, and the failure mode is observable in minutes instead of months. That set is smaller than most teams think. It includes internal notifications, data enrichment on non-customer records, and read-only reporting. It does not include refunds, pricing changes, customer-facing messages, or anything that writes to a system of record.

Here is the test we use. If you can delete the agent's action and no customer, partner, or financial record changed state, it is a candidate for full autonomy. If the action writes a value that another system will later read as truth, it needs a proposal step. The distinction is not "low risk" in the abstract. It is reversibility and observability. An autonomous agent that posts a Slack message can be ignored. An autonomous agent that updates a subscription can be silent for a month and then hit the books.

The Propose-Approve-Execute pattern does not mean every automation gets a human gate. It means the gate is placed exactly where reversibility ends. For everything before that line, let the agent run. For everything after, make it propose.

What questions do operators ask before adopting the Propose-Approve-Execute pattern?

Operators ask about tooling, scale, latency, and governance. The short answers follow. These are the questions we hear most when we explain the pattern to builders and operators.

Does this require a specific AI automation platform?

No. You can implement Propose-Approve-Execute in n8n, Zapier, custom code, or a queue-based system. The core requirement is a clean separation between the proposal payload and the execution payload. If your tool cannot hold a proposed action before executing it, you need middleware or a manual checkpoint. We prefer n8n for internal builds because the sub-workflow structure makes the separation explicit.

How many approvals can one operator handle per day?

That depends on proposal quality. A well-formatted card with one decision per card takes 30 to 90 seconds to review. If the card requires research, the number drops sharply. We do not publish a benchmark because it is not a productivity metric. The point is not to maximize approvals per hour. It is to maximize correctly shipped actions per week.

Can the AI approve its own proposals later?

Only for actions that meet the autonomous criteria: reversible, low cost, observable failure, and a known error rate you can tolerate. If you cannot name the cost of a failure in advance, the action stays behind the approval step. We do not gradually remove approvals just because the agent's confidence score went up. Confidence is a feature of the proposal, not a permission slip.

What happens when an approval sits too long?

The proposal expires and the system treats it as rejected. The agent can re-propose with a tighter scope or drop the task. This keeps the queue clean and prevents a stale proposal from executing after the context has changed.

One more note: this pattern is a team discipline, not just a prompt engineering trick. If your operators are not willing to read a proposal card, no tool will fix that. If your agent is not able to produce a clean proposal, no approval step will make it safe. The system ships when both sides are sharp.

If you build this way and want to work on these systems, we are hiring operators and builders at Arthea Careers. We do not write about this pattern and then go back to a manual stack. We run it on our own workflows first.