Supervised or autonomous? What an AI employee should be allowed to do on its own

Imagine it is a new hire’s first morning. You hand them the company card, the customer email list, the login to the bank, and the keys to the website. Then you say: “Run the business. I’ll check back in a month.”

Nobody does this to a person. Not because new hires are untrustworthy, but because trust in a workplace is built in steps. First they watch. Then they draft, and someone reads the draft. Then they act on small things alone. Only later, and only for the kinds of work where they have shown good judgement, do they get a card with a limit on it. Even then the limit is written down, someone reviews the statement, and the really big decisions still go to a manager.

Yet a lot of what is sold today as an “AI employee” is pitched as the opposite of that: it works on its own, around the clock, no human in the loop. That is a real design choice with real consequences, and it deserves the same scrutiny you would give the new hire with the company card.

This post is not an argument against automation. Most of the value of an AI employee is the work it does without anyone watching. It is an argument about where the line belongs: which actions an AI employee should take alone, which should wait for a person, and how to tell, before you commit, whether a product has drawn that line on purpose.

Two promises that sound alike

Listen closely and you will hear two different promises under the same name.

Neither is wrong for every job. If the task is low-stakes and reversible (tidying a spreadsheet, drafting ideas you will never publish unreviewed), an autopilot is fine and cheaper. The trouble starts when the same autopilot is pointed at things that leave the building: a message to a real customer, a payment, a change to someone’s record, something published under your name.

Five ways “nobody is watching” tends to fail

We have not tested every product, and we are not going to name any. But the failure patterns are consistent enough to describe in general terms, and each one maps to a control you can ask about.

1. It acts on the world without asking. An agent decides that the best next step is to email a list, or to contact a person who was never meant to hear from you. Each message is a small thing. Together they are your reputation. The control: certain kinds of action (anything sent outward, anything that spends money, anything published) wait for a person unless you have deliberately said otherwise.

2. It reports “done” when it is not. An agent works in turns. A step fails quietly, the next step proceeds anyway, and the summary says the task is complete. This is the most corrosive failure because it destroys the thing you bought the agent for: not having to check. The control: a record of what each run actually did, step by step, so “done” can be checked against evidence (an id from the system it wrote to, not a sentence).

3. Money passes through the vendor’s hands. If the agent’s earnings, or your customers’ payments, sit in an account you do not control, then your business depends on the vendor’s terms, holds and mood. The control: the agent works inside your own accounts and systems, with permissions you granted and can withdraw.

4. Spend has no ceiling. A loop, a retry, or a schedule that fires every few minutes can burn through a budget while everyone sleeps. The control: hard limits on spend and on how often unattended work may fail before it stops itself.

5. Nobody can tell what happened. When something is wrong, the question “what did it do?” has no answer, or the answer is a paragraph the AI wrote about itself. The control: an independent log of actions, and a named human who owns the agent.

Notice what these have in common. None of them is about the AI being “not smart enough.” A smarter model does not fix any of them. They are about design around the model: who may do what, who gets asked, and what is written down.

A simple ladder: how much rope does this action get?

It helps to stop thinking of “autonomous or not” as one switch. It is a ladder, and different actions belong on different rungs.

flowchart LR
  A["Look something up<br/>or read a record"] --> B["Draft something<br/>for a person to read"]
  B --> C["Act alone, within<br/>a limit you set"]
  C --> D["Act only after<br/>a person approves"]

• Rung one: read. Looking up an order, finding a policy, checking a status. Nothing changes in the world. This should almost never need approval.
• Rung two: draft. Preparing a reply, a summary or a proposal that a person reads before anything happens. Cheap to review, easy to reverse.
• Rung three: act within limits. Logging a note, updating a low-risk field, answering a customer’s question from your own documents. The AI does it alone, but inside boundaries you set and a record you can read.
• Rung four: act after approval. Money, promises, someone’s record, anything you cannot take back, anything that speaks for you to a new audience. The AI prepares the action; a person says yes.

A good way to place an action is to ask three questions about it:

1. Can it be undone? A typo in an internal note is reversible. A refund, a deleted record and a sent message are not.
2. Who sees it? Internal and invisible is lower risk than something that reaches a customer, a partner or the public.
3. What does a wrong one cost? Cheap and rare is different from cheap and repeated forty times, or expensive once.

Reading those three answers off an action usually tells you the rung. The point is that you decide it, per kind of action, ahead of time, instead of discovering the AI’s opinion after the fact.

“But isn’t asking a person slower?”

It is the question every team asks, and it has a fair answer: only for the small share of actions that are consequential.

An AI employee that asks for approval on everything is not supervised, it is a very elaborate form. People start approving without reading, and the approval means nothing. The goal is the reverse: let the AI do the large, boring majority alone, and stop only at the few points where a mistake is expensive.

Two habits keep this honest:

• Start strict, loosen with evidence. Begin with approvals on the consequential steps. After a few weeks, read the records. If one kind of action is approved every single time without edits, that is evidence you can move it down a rung. If people are editing or rejecting a third of them, you have learned something about the AI’s judgement, cheaply, before it cost you a customer.
• Make approving easy and expiring safe. A request that sits unread forever is a different kind of failure. The request should reach the right person, carry enough context to decide, and have a defined outcome if nobody answers in time (for example, “tell the customer someone will follow up”, not “do it anyway”).

What this looks like in Wetel today

We build AI employees, so we have to hold ourselves to the same standard. Here is the honest, tense-labelled version.

Live today:

• An approval step you add to a workflow. The workflow pauses at that step. A workspace owner can approve, reject with a comment, or correct specific fields you allow them to edit, and the workflow continues down the matching path. If nobody answers before the time limit you set, it follows an explicit “expired” path. All three outcomes must be wired up, so there is no silent default. See the approval node reference and the step-by-step walkthrough.

flowchart LR
  S[start] --> R["response: I've asked a manager"]
  R --> P{{approval}}
  P -- approved --> OK["carry on"]
  P -- rejected --> NO["decline politely"]
  P -- expired --> EX["someone will follow up"]

• A way to test the approval path without bothering anyone. In a draft, you can simulate “approved”, “rejected” or “expired” and see the workflow follow that branch, with no real request created and nobody notified. (Draft tests.)
• A record of every run. You can inspect what a workflow actually did, step by step, and check “done” against evidence rather than the AI’s own summary. (Observability.)
• Limits on unattended work. Scheduled workflows are bounded by your plan, by a monthly spend cap, and by a breaker that stops a schedule after repeated failures. (Cost controls.)
• Your systems, your permissions. An AI employee works inside the tools you already run, using credentials you provide, and each workspace’s data is kept separate on every request.

Not built yet, and we would rather you read it here first:

• Approval by default. Today an approval pause exists where someone adds an approval step. We do not yet pause risky actions automatically, and we do not describe the product as if we did. Making “ask first” a policy you set once for kinds of action, and a label on each action a workflow can take, is specified and not built.
• Email notice for approvals. In-app notifications work; email does not yet.
• Approvers beyond workspace owners, and approval chains across a team.
• A named owner and a registry for every AI employee.

That list is the gap between “a workflow can ask first” and “the platform asks first unless you say otherwise.” We think the second is where an AI employee product should end up, and we would rather close the gap than hide it. That is direction, not a dated promise.

A checklist you can use on any AI employee, ours included

Before you hand an AI employee real work, ask the vendor, and ask yourself:

1. What can it do alone, and who decided that? Is the line written down per kind of action, or left to the model?
2. What must wait for a person, and which person? Can you name them? What happens if they do not answer?
3. Can I see what it did, independently of what it says it did?
4. What are the limits on spend and on repeated failure when nobody is watching?
5. Whose systems and whose money does it work in? Can I withdraw access?
6. Who is accountable for it inside my company? Is there a named owner?
7. Which of these answers is true today, and which is on a roadmap? If the answer to that one is vague, treat every other answer with the same suspicion.

The new hire with the company card analogy holds all the way down. You do not need to distrust the person. You need a structure that lets you trust them a little more each month, because you can see what they did and you decided what they may do alone.

Related reference docs

• Approval node reference: fields, the three required edge labels, expiry and what the workflow receives when it resumes
• Human approval: a walkthrough: build the graph, test it in a draft, then decide from the inbox or the API
• Draft tests: draftApprovalOutcome: simulate each outcome without creating a request
• Observability and debugging: per-run traces and what you can inspect
• Scheduled workflows: cost controls: plan quota, monthly spend cap and auto-disable
• Roadmap: the engineering direction (telephony, supervision, event triggers) and how it differs from what is live

If you are deciding which work to hand over first, tell us which one and we will tell you honestly which parts are live and which are still being built.