Where should your AI agent stop and ask?

A useful AI workflow needs a clear answer to a simple question: which decisions can the system make, and which decisions belong to a person?

Decide that at the level of actions. Reading a document is different from editing it. Preparing an invoice is different from sending it. Drafting a customer reply is different from making a commitment to the customer. This guide is an operational starting point for a conversation with your implementation team.

Separate preparation from commitment

The system can often prepare the information a person needs to decide: summarize the request, identify the relevant context and draft the next step. The review should happen before an action creates the commitment your team wants to control.

For an email workflow, specify whether the output is a draft or an actual send. For a calendar workflow, clarify whether the agent is proposing times or creating an event. Use the language of the tools and the business so everyone understands the boundary.

Give the reviewer something concrete

Approval works better when the person can see the intended result. A vague request to continue does not tell the reviewer what they are authorizing. Present the relevant recipient, content, record or change before the action happens.

• What exactly will happen?
• Which person, customer or record is affected?
• Which information supports the proposed action?
• Is anything missing or uncertain?
• Who owns the result after approval?

The amount of review should fit the consequences of the action. Define that with the people responsible for the process rather than treating every task as identical.

Missing context is a state to handle

A workflow needs a useful response when the answer is not available. That might mean flagging the missing source, returning a partial draft or asking a specific question. It should not quietly fill in a customer name, a promise or a date that it cannot establish.

Test that behavior deliberately. Give the workflow an incomplete example and see whether the gap remains visible. A demo built only around complete inputs does not tell you how the system behaves during an ordinary messy workday.

Keep completion and intention separate

A prepared message is not a sent message. An accepted request is not always a completed task. Decide what evidence the workflow needs before it reports success, such as a record in the destination tool or a confirmed action result.

If a step fails, the team needs to know which part is complete and which part still needs attention. Repeating an entire workflow can create duplicate messages or records. Recovery should consider what has already happened.

Start with one owner and one review path

Choose an owner for the first workflow and make the escalation path visible. Review a small set of real examples together, including missing information and a failed tool step. Update the instructions when the team discovers a boundary that was not clear.

At Be Human, access and approvals belong in the implementation conversation. Bring the decisions you want to retain and the work you want help preparing. A familiar chat interface can make the system easy to use, while the boundaries behind it keep responsibilities clear.