The easiest way to make an AI feature feel impressive is to let it do the thing. The easiest way to make that feature frightening is to let it do the thing before the user understands what it decided.
Take a shared inbox. An AI assistant can classify a support request, draft a reply, find the order, and propose a refund. It can also send the reply, issue the refund, and close the ticket. The model calls may be identical. The product is not. In the first version, AI assists a person. In the second, it automates a workflow and owns consequences.
Product teams often use “automation” and “assistance” as interchangeable labels for any feature that uses a model. They aren’t. They describe different allocations of control, and the distinction changes the interface, the safety model, the evaluation plan, and the metric you should optimize.
This article gives a practical way to choose between the two. The short version: automate bounded, repeatable, reversible work; assist when the user’s context or judgment matters; and make the handoff between those modes explicit instead of hiding it behind a toggle called “AI.”
Automation changes who owns the outcome
An AI feature is assistance when it helps a person make or perform a decision while leaving the person in control of the consequential step. It is automation when the system makes the decision or performs the action without requiring the user to review each instance.
The difference is not how much AI is involved. A sophisticated model that produces a draft for review can be assistance. A small classifier that routes every ticket to a queue without human review is automation.
The difference is also not whether there is a human somewhere in the process. A manager who can reverse an automated decision next week is not necessarily meaningfully in control of each decision today. The useful questions are:
- Who decides what action should happen?
- Who checks the action before it takes effect?
- Can the user see why the system suggested or took it?
- Can the action be undone, and by whom?
- Who bears the cost when the system is wrong?
Anthropic’s distinction between workflows and agents is related but not identical: workflows use predefined paths, while agents dynamically choose tools and steps. Either architecture can deliver assistance or automation. A fixed workflow can automatically deny a request; an agent can merely draft a recommendation. The architecture describes control flow. The product mode describes authority over the outcome. (Anthropic, “Building effective agents”)
The first design task is therefore not choosing a model. It is drawing the line between a model output and a user-visible consequence.
The autonomy ladder is more useful than an on/off switch
There is rarely a single correct autonomy level for an entire feature. One workflow may contain safe steps to automate and consequential steps that should remain reviewable.
Consider an invoice-processing assistant:
- Read the invoice and extract supplier, date, and total.
- Match the supplier to a vendor record.
- Check the amount against purchase-order limits.
- Prepare an accounting entry.
- Approve and submit payment.
The first four can be automated to different degrees, depending on confidence and policy. The last one may require an authorized person. Treating the whole workflow as either “AI automation” or “AI copilot” hides this structure.
A practical ladder is:
| Level | System behavior | User’s role | Typical use |
|---|---|---|---|
| Explain | Answer a question or summarize evidence | Interprets the result | Search and analysis |
| Suggest | Recommend a next action | Chooses whether to act | Triage, prioritization |
| Draft | Prepare an editable artifact | Reviews and edits | Email, SQL, support reply |
| Confirm | Prepare an action and ask before execution | Approves or rejects | Refund, publish, send |
| Bounded auto | Execute within explicit rules and limits | Handles exceptions | Low-value repetitive work |
| Full auto | Decide and execute without per-item review | Monitors system-level outcomes | Stable, low-risk operations |
This is not a maturity score. Moving downward is not always progress. A draft that saves a reviewer time may be a better product than a system that sends automatically but creates a costly audit burden.
1. Automate the parts with a stable contract
Automation works when the allowed action can be stated in rules the application can enforce. “Refund duplicate charges below $50 when the payment is captured and the order is delivered” is a contract. “Resolve the customer’s problem in a way that feels fair” is not.
When the contract is stable, let the model handle interpretation and let deterministic code enforce the boundary. The model can extract the order ID and classify the request. The application checks payment state, refund amount, role permissions, and idempotency before calling the payment provider.
The model should not be the only component deciding that a request is eligible. A prompt saying “only refund according to policy” is useful guidance, not an authorization boundary. The actual policy belongs in code or a policy engine that can reject invalid actions regardless of what the model says.
Automating a stable contract also makes the exception path clear. If the order is outside the return window, the amount exceeds a threshold, or the records conflict, route the case to a person. The system should not improvise a new policy because the prompt didn’t anticipate the case.
2. Assist when the user’s context is not in the system
The model may see a ticket, account history, and company policy, while the user knows that the customer is a long-term partner, the team promised a deadline on a call, or the “usual” workaround is currently broken. This missing context is not a model limitation that can always be fixed with a larger context window. It is a product boundary.
When the decision depends on tacit knowledge, expose the model’s work as a suggestion. Let the user add context, edit the draft, and select an action. Make the missing information visible rather than pretending it is known.
A good assistant does not merely place an “Approve” button under a recommendation. It presents enough evidence for the user to disagree: the source records, the assumptions, the proposed action, and any uncertain fields. “Refund $42.00 because the payment is duplicated” is reviewable. “Recommended: refund” is not.
If users routinely override an AI suggestion for the same reason, do not immediately tune the prompt. The product may be missing a data source or a workflow step. Assistance is often a valuable way to discover what the system needs before automation is safe.
3. Keep irreversible actions behind an explicit boundary
Sending a message, issuing a payment, changing permissions, deleting a record, and publishing a document are different from drafting text. The fact that an API call is technically reversible does not mean the consequence is easy to reverse. A recipient can read an email; an access token may already have been copied; a deleted record may have triggered downstream jobs.
For consequential actions, separate the proposal from execution:
user request
↓
model extracts intent and proposes structured action
↓
application validates schema, identity, policy, and current state
↓
preview shows exact action and evidence
↓
authorized user confirms (or bounded policy permits automation)
↓
idempotent tool call executes and records outcome
The confirmation should bind to the exact payload the user reviewed. If the amount, recipient, or content changes after confirmation, require approval again. Otherwise the confirmation is a generic “yes” that may authorize a different action than the user saw.
For low-risk actions, the boundary can be lighter: auto-apply labels, draft a response, or update a reversible preference. For high-impact actions, use stronger authentication, role checks, and an audit record. Do not use one global “human in the loop” pattern for every action.
4. Make automation gradual and scoped
Teams often launch a feature in manual mode, see positive feedback, and flip a global switch to automatic execution. That jump changes the failure cost abruptly. A safer progression is scoped:
- Observe: run the model in shadow mode; compare proposed actions with current human decisions.
- Suggest: show recommendations without executing them.
- Draft: create a pending artifact for a person to review.
- Confirm: execute only after per-item approval.
- Auto within a bound: execute actions under explicit thresholds, with exceptions routed out.
- Expand by slice: widen only for categories where evaluation and live outcomes support it.
Scope automation by action, tenant, risk tier, and confidence of the underlying data—not by a vague user-level preference. A user may want automatic tagging but still require approval before sending customer-facing text. A tenant may permit auto-routing but not auto-refunds.
Shadow mode is particularly useful when the existing process already produces a decision. The model can make a parallel recommendation without changing the user’s workflow. But shadow comparisons are only meaningful if you capture the same inputs and policy version, and if human outcomes are labeled consistently. A human decision is not automatically ground truth; people make mistakes too.
5. Design the interface around the user’s decision
The interface should reveal whether the system has suggested an action, prepared one, or executed one. A spinner followed by a result is not enough when the result may have changed data.
For assistance, show:
- the proposed result in an editable form;
- the evidence or source material that supports it;
- fields the model could not determine;
- actions available to accept, edit, reject, or escalate;
- whether the change is saved or only a draft.
For automation, show:
- what the system is allowed to do;
- what it did, in plain language;
- what conditions triggered the action;
- how to undo or dispute it;
- what happens when it cannot decide safely.
Avoid making users approve a long series of low-risk actions one by one if the product can provide a sensible batch review. But batch approval must preserve the ability to inspect individual items and exclude exceptions. A giant “approve all” button that hides 200 records has moved cognitive work, not removed it.
The same principle applies to confidence indicators. A score such as “92% confident” is often misleading unless it is calibrated for that exact task and threshold. Show decision-relevant evidence and uncertainty instead: “The invoice total matches the purchase order; the tax value was not present in the source.”
6. Measure work removed, not clicks avoided
Automation is often justified by “time saved.” The first measurement is usually the time the user spends in the old interface. That misses review, correction, exception handling, and downstream work created by mistakes.
Measure the full task:
net time saved = baseline end-to-end effort
- AI interaction time
- review and correction time
- exception handling time
- downstream rework caused by errors
For an AI-generated support reply, the relevant comparison is not typing time alone. Include the time to verify policy, edit the reply, handle a customer confused by an error, and correct the CRM record if the model selected the wrong disposition.
Track at least:
- time to a completed, accepted task, not time to first draft;
- acceptance rate and meaningful edit rate;
- override and escalation reasons;
- downstream correction or reversal rate;
- quality and customer outcomes by risk slice;
- workload transferred to reviewers or support teams;
- cost per successful task.
If the feature reduces an agent’s typing but doubles the supervisor’s review queue, it has moved work around. That may still be useful, but it is not the productivity result the launch deck promised.
7. Treat human review as a capacity constraint
“A human will review it” is not a complete safety plan. Reviewers have limited time, and a system that sends every uncertain case to a person can create a new queue faster than it resolves the old one.
Design the review path as part of the product:
- prioritize by consequence and uncertainty, not just arrival time;
- provide the evidence and the exact proposed action in the review item;
- allow reviewers to correct labels and record a reason;
- batch low-risk, similar items where appropriate;
- escalate unresolved cases to a named owner;
- measure queue age and reviewer disagreement;
- reserve human review for cases where it changes the outcome.
Review should be selective. A model can automatically apply a reversible label with high confidence, send a medium-risk draft to a person, and block a payment action until an authorized reviewer approves it. The routing policy is product logic, not just an LLM confidence threshold.
NIST’s AI Risk Management Framework treats risk management as an ongoing activity spanning design, development, deployment, and use; it is voluntary guidance rather than a product recipe, but its emphasis on context and monitoring is a useful reminder that review design cannot be postponed until after launch. (NIST AI RMF)
8. Make the failure mode match the autonomy level
An assistant that cannot answer should say so, preserve the user’s work, and offer a sensible next step. An automation system that cannot safely decide should stop before the side effect and route the case to a queue.
The same model failure demands different recovery behavior:
- Suggestion mode: show uncertainty or ask the user for missing context.
- Draft mode: keep the draft editable and mark unsupported claims for review.
- Confirmation mode: do not execute until the exact payload is approved.
- Bounded automation: fail closed on policy ambiguity, record the reason, and create an exception task.
- Full automation: use circuit breakers, rollback or compensating actions where possible, and alert on drift in outcome metrics.
Do not make the fallback “try the same prompt again” by default. Repeated calls can produce a different answer without resolving the missing context. Ask a targeted question, choose a deterministic fallback, or hand off.
When the feature performs a write, make the write idempotent and record a correlation ID. If the network fails after the remote system commits, the application must reconcile the outcome rather than issue the action again. This matters even when the AI component is only a small part of the workflow.
9. Give users a way to change the delegation
User trust is not a binary attitude. The same person may happily accept automatic meeting summaries and insist on reviewing every customer email. Let people choose at the task level when the choice is meaningful.
Useful controls include:
- “Draft only” versus “send after approval”;
- “Automatically tag these categories” with an easy undo;
- a per-action notification preference;
- a visible history of actions the system took;
- a pause button that stops future automation without deleting prior records.
Avoid a single global “AI on/off” switch when the feature combines low- and high-consequence actions. Also avoid presenting a control that the backend does not honor. If a user chooses review-only, no retry path or fallback model should silently bypass that setting.
The product should remember delegation preferences with scope and provenance. A preference set by an administrator may apply to a whole workspace; a personal preference may only affect the current user’s drafts. Treat that as authorization and configuration, not text that the model can reinterpret.
When automation is the wrong goal
Automation is a poor fit when the task is rare, the rules change frequently, errors are hard to detect, or the user must supply context the system cannot observe. It is also a poor fit when the “saved time” comes from removing a meaningful decision the user is accountable for.
Assistance can be the stronger product when it makes expert work faster without pretending to replace expertise. It can surface evidence, draft routine language, translate technical material, or catch omissions while leaving the decision where the domain requires it.
The opposite is true too. A system that asks for approval before every harmless, reversible action becomes a notification generator. If the action is predictable and cheap to undo, automate it and make the history visible. Over-caution can impose real work and train users to approve blindly.
The right autonomy level is a cost-sensitive choice: weigh the cost of a false action against the cost of review, delay, and false alarms. Define those costs for each action, not for the AI feature in the abstract.
Pilot automation without teaching users to rubber-stamp it
The transition from assistance to automation is often hidden inside a rollout plan: the team shows the recommendation to reviewers for a month, sees a high acceptance rate, and turns on auto-apply. Acceptance alone is weak evidence. Reviewers may accept because the suggestion is right, because it is faster than checking, or because the interface makes rejection cumbersome.
Build the pilot so you can tell those cases apart. For a sample of accepted items, ask reviewers to mark whether they independently verified the evidence, merely agreed with the proposed action, or accepted without checking. Randomize which items appear with an AI suggestion and which appear in the existing workflow. Reviewers should not know which version they are seeing if the comparison is intended to measure accuracy rather than preference.
Track disagreement separately from correction. If a reviewer changes the model's classification but keeps the recommended action, that may be a harmless label issue. If the reviewer cancels a payment or rejects a permission change, the same numeric "edit rate" hides a much higher-impact error.
A useful pilot report groups results by consequence:
| Action class | Example | Pilot evidence before auto mode |
|---|---|---|
| Reversible metadata | Add a topic label | Low correction rate; undo works; no cross-tenant errors |
| User-visible draft | Prepare a reply | Factual support, edit distance, send-time corrections |
| External communication | Send an email | Recipient/content verification; complaint and recall rate |
| Financial or access change | Refund, role update | Rule-based validation, independent audit, explicit authorization |
Do not let success on a low-risk slice justify automation on a high-risk one. That is a category error, not a rollout shortcut.
There is also an accountability question: who owns the result when the system acts? The product should name a business owner for the policy, an engineering owner for the execution path, and an operational owner for exceptions. A dashboard that shows model accuracy but no one responsible for the queue is not governance.
One final safeguard: keep a kill switch that can pause execution without taking the entire product offline. The switch should stop new automated side effects, preserve pending work, and leave read-only explanations available where possible. A deploy rollback may not be fast enough if the problem is a bad policy threshold or a data feed that has gone stale. The owner on call should know exactly which actions the switch blocks and how queued cases resume.
Choose product language that matches the mode. “Suggested reply” and “sent automatically” describe different states; “AI handled it” tells the user almost nothing. The interface, notification, audit record, and support documentation should use the same terms. This prevents a user from believing they approved a draft when the system actually published it, and helps support staff explain what occurred without referring to an internal model trace.
The audit view should answer the user’s practical questions: what changed, when it changed, which policy allowed it, and whether a person reviewed it. It should not require the user to understand prompt engineering or model internals. Transparency is about making the decision and its consequences legible, not exposing every token the model received.
A launch decision framework
Before increasing autonomy, answer these questions for each action:
- Is the input structured enough to validate?
- Is the allowed outcome expressible as a rule or bounded set?
- Can the system access the information needed to decide?
- What happens if it is wrong, and can the action be reversed?
- Is there a clear owner for exceptions?
- Can the user inspect the evidence and change the result?
- Does evaluation cover normal, ambiguous, adversarial, and high-impact cases?
- Do live metrics capture corrections and downstream rework?
If the input is incomplete, the rule is ambiguous, or the action is hard to reverse, keep the feature in assistance or confirmation mode. If the action is bounded, low-risk, observable, and easy to undo, limited automation may be appropriate. Expand the scope only when the measured outcomes support it.
The product question is not whether the AI can do the task. It is whether the user should have to supervise that task, and what happens when the system gets it wrong. Assistance and automation are two different answers. Good product design makes the choice deliberately, one consequential action at a time.