When should an AI workflow be allowed to act?

Start with the action

An AI workflow can summarize a conversation, recommend a next step, draft an offer, or send that offer to another person. Each step has a different consequence. The product needs to make those differences visible before it decides what can happen automatically.

For an opportunity workflow, finding a candidate is an exploratory action. Drafting a proposal is a preparation step. Sending it creates an external communication. Accepting terms creates a commitment. Define each boundary explicitly, including the actor, destination, permitted scope, and conditions for stopping. A broad instruction to help close a partnership does not answer all of those questions.

Keep facts, interpretations, and unknowns distinct

A recommendation should have an inspectable basis. A candidate’s published interest in community events is evidence. The conclusion that they might suit a particular event is an interpretation. Their budget or availability may still be unknown.

That distinction should survive into the interface and the draft. Otherwise, an uncertain inference can become a confident claim as information moves between steps. Useful products preserve source references, record the limits of the available information, and give people a way to correct it. They also let an unknown remain unresolved. A complete-looking form is not a reason to invent an answer.

Source material cannot grant itself authority

A retrieved page, uploaded document, or incoming message may contain instructions addressed to the system. Those instructions are still part of the material being examined. They do not become permission to disclose other information, change the workflow, or contact someone.

This boundary belongs in the application’s permissions and available tools. A model can help interpret content within that boundary; it should not be able to expand its own access because a document told it to. Minimize what each step can read and change, and make exceptional access a deliberate decision.

Approve a specific version

A review button is useful only when everyone understands what it authorizes. The person should be able to inspect the recipient, message, scope, timing, and any commercial terms before approving the proposed action.

The approval then needs to identify that version. If a later response changes the package, the recipient changes, or someone edits a material term, the old approval must no longer authorize execution. The system can continue preparing the next version while clearly returning the action to review.

This is a product rule, not merely a reminder in a prompt. In a production implementation, the service that performs the action should check the current proposal against the approved version. The interface should explain why review is needed again, so the person can focus on what changed.

Check the outcome before reporting success

Preparing an action, attempting it, and completing it are different states. A delivery plan should not appear because a generated response says a partnership is closed. The workflow needs the acceptance event that its rules require.

For an external integration, a timeout may leave the result uncertain. Check the receiving system before trying again. Where possible, give the operation a stable identifier so a repeated request does not create a duplicate. Tell the user whether the action is pending, failed, completed, or needs investigation. The status should describe the evidence available to the system.

Design the way back

Failure is part of the workflow. A service may be unavailable, the evidence may conflict, or a person may decide that the proposed action is wrong. Preserve the work that remains useful and make the next choice clear.

Recovery can mean revising a draft, reconnecting an integration, asking for a missing fact, or handing the decision to a person. Some actions can be reversed; others need a corrective follow-up. The product should be honest about which is possible, and retain enough context to explain what happened.

Test the boundaries as well as the happy path

A useful evaluation plan would include ordinary tasks alongside conflicting sources, unsupported claims, revised offers, expired approvals, misleading instructions in documents, and uncertain integration responses. Each test needs a defined permitted outcome and a way to detect a boundary violation.

For model-driven behavior, repeat trials, inspect failures, and record the model and configuration used. Grade the resulting state as well as the visible response. Anthropic’s guide to agent evaluations makes this distinction explicit: the outcome is what exists in the environment after the attempt. That is a useful foundation for evaluating a system that can act.

These are evaluation requirements to apply to a production system. This article does not report a completed benchmark or a measured safety result.

See the decision in context

Our opportunity-to-partnership concept makes several of these decisions visible: evidence behind a candidate, an unsupported claim in a draft, approval tied to the offer, and a simulated acceptance before delivery planning.

It is a prepared, browser-local interaction with fictional data. It does not call a live model or perform external actions. Its purpose is to make the product decisions tangible, so you can explore the experience before discussing the system it would take to operate it.