When should an AI take the next step?

Separate an answer from an action

An assistant that suggests a reply and an assistant that sends it are doing different jobs. The words may be identical, but the consequences are not. Once the message leaves the system, a customer can rely on it, a colleague can act on it, and a correction may arrive too late.

This distinction is easy to lose when people talk about “agents” as if more autonomy were always an improvement. The useful question is which steps a system should take, under which conditions, with what ability to recover.

Start with one task. “Handle operations” is too broad. “Read an approved order status and draft a delivery update for review” is a task you can describe, test, and improve.

Choose the simplest workflow that fits

Some tasks need a fixed sequence: receive a document, extract fields, validate them, and prepare a report. Others involve choosing among tools or changing the plan as new information arrives.

Anthropic's guidance distinguishes predefined workflows from agents that direct their own process and tool use. It also argues for starting with simple solutions. That is useful design advice, not proof that a particular implementation will work for your task. ^[1]

A fixed workflow has advantages when the steps are known. It can be easier to inspect and reproduce. More flexible behavior may help when the route is genuinely uncertain, but it also gives you more possible failure paths to understand.

Do not add planning loops because the demo looks impressive. Add them when a simpler process fails on a real requirement, and keep a record of that requirement.

Draw the permission boundary

List the actions the system can take. Reading a record, drafting a change, saving a draft, sending a message, and issuing a refund should not quietly share one permission level.

These are starting points for design, not universal policies. The right boundary depends on the organization and the consequences. What matters is that the boundary is deliberate and enforced by the system, rather than mentioned only in a prompt.

Make failures visible

A system should not quietly substitute a guess when a required source is missing. It should report the gap and choose an allowed fallback, such as asking for review or stopping the action.

Test the awkward cases before broadening access: unavailable tools, conflicting records, timeouts, incomplete input, and a request that falls outside the task. Include content that tries to redirect the assistant away from its actual assignment. Retrieved text is evidence to inspect, not authority to change the workflow.

Decide what a reviewer sees when something goes wrong. A useful record includes the requested task, relevant inputs, proposed action, validation result, and reason for escalation. Keep private data out of logs where it is not needed.

Treat retries as actions too

A failed response does not always mean the underlying action failed. A payment, message, or database change may have succeeded before a connection was lost. Repeating it blindly can create a second problem.

Use task identifiers and action records so the system can determine what already happened. Where supported, use the destination system's mechanisms for preventing duplicate operations. The implementation depends on the service; a generic “try again” button is not enough.

Recovery should be part of the design from the beginning. It is much harder to add after users depend on a workflow whose state nobody can explain.

Earn the next step

Begin with drafts and observe the work. Review representative tasks, record failures, and improve the workflow. Expand the action boundary only when the evidence supports that particular expansion.

A system can be valuable without completing every task alone. Preparing a reliable draft with clear evidence may save substantial effort while preserving the final decision where it belongs.

For your next automation, write down the exact action you want to remove from human review. Then write down the evidence you would need before doing so. That is a more useful roadmap than a general ambition to make the system autonomous.