One person asks about an order and receives an answer. Another asks for an issue to be resolved, and the system retrieves information, creates a case and communicates the next step. Both experiences can start in the same chat window, yet they delegate different responsibilities.
The autonomy a product needs depends on the decisions and actions worth delegating, their consequences and the evidence available to delegate them with confidence. My starting point is defining the task we want to solve and the control the person needs to retain.
This guide proposes a way to make that decision across product and engineering: distinguish the interface from the underlying behavior, define action boundaries and evaluate whether autonomy improves the complete outcome.
1. Chatbot, workflow and agent: what actually changes?
A chatbot primarily describes a conversational experience. It may answer through rules, retrieve documents or provide the interface to a system that can take action. A message box does not tell you how much autonomy sits behind it.
A workflow follows a defined path. It can include AI without delegating the overall choice of steps to the model.
An agent can choose steps, use tools and adjust its path based on results. From a product perspective, that flexibility needs a scope we can explain and supervise.
The distinction between predefined paths and dynamic decisions appears in Anthropic’s Building effective agents. I use it as an architectural reference; the practical scopes below are my own analytical tool, not an official classification.
Workflows and agents can also coexist. An agent might investigate an issue inside a process that requires approval before changing an order.
2. Define autonomy for each action
Calling a product “autonomous” leaves too many questions unanswered. I prefer to inventory specific actions and decide the scope of each one.
This scale is a proposal for team discussion. It does not imply that every product should progress through every scope.
| Scope | What the system does | What to define |
|---|---|---|
| Inform | Explain or retrieve information | Available sources, access and handling of uncertainty |
| Propose | Prepare a response or plan | What a person must review before using it |
| Execute with approval | Prepare an action and wait for confirmation | What will change, which item it affects and the consequence |
| Execute within boundaries | Perform previously authorized actions | Verifiable conditions, monitoring and recovery |
| Coordinate a task | Choose steps and tools within an objective | Budget, permissions, stopping conditions and escalation |
The last row describes task organization, not a universal permission. An agent coordinating several steps may still need approval for one of them. Likewise, a fixed workflow may automatically execute a well-defined action.
Autonomy to choose a path and permission to act are related but separate decisions. Documenting them separately helps prevent “can resolve the case” from accidentally becoming “can make any change.”
3. An example: helping with a delayed order
This case is hypothetical and does not report results from a real project.
Imagine a store whose support team receives delivery inquiries. The customer needs to know what is happening and get a useful next step. The team wants to reduce repetitive searches while retaining control over order changes.
A first version could retrieve shipment status and prepare a response with its sources. If the information conflicts, it should recognize that and escalate the case rather than invent a delivery date.
Later, the system could create an internal issue when agreed conditions are met. Changing a delivery address, canceling an order or promising compensation would have different permissions. Each action needs its own product decision and validation with the people responsible for the process.
| Example action | Initial scope I would propose | Reason |
|---|---|---|
| Look up shipment tracking | Read access limited to the authorized order | Obtain context without changing the order |
| Write a response | Draft for review | Check clarity and supporting information before sending |
| Create an internal issue | Approval during the pilot | Evaluate classification and prevent duplicates |
| Change delivery details | Explicit approval of the specific action | A mistake can affect delivery and other people |
| Resolve conflicting information | Escalate to support | There is insufficient basis to act |
If retrieval, classification and proposal always follow the same path, I would start by evaluating a workflow. If investigation requires choosing sources and varying steps by case, I would test a more flexible component. The comparison should consider the customer’s outcome and the team’s work.
4. Design permissions the system can enforce
A prompt instruction helps express intent, but permissions also need controls in the tools and services that execute actions.
OWASP identifies excessive functionality, permissions and autonomy as causes of the vulnerability it calls Excessive Agency. That reference reinforces a design question: are we granting a capability because the task needs it, or because the integration happens to include it?
For the example above, I would propose:
- Scoped access: retrieve only orders available to the authenticated person and their role.
- Specific tools: separate shipment lookup, issue creation and order modification, each with its own validation.
- Understandable confirmation: show the affected order, proposed change and consequence before requesting approval.
- Execution limits: set time, attempt and usage budgets, and define what happens when they are reached.
- Duplicate prevention: check an operation’s result before retrying an action that may already have completed.
- Recovery: provide a way to stop the process, review what happened and correct changes where possible.
I would also separate retrieved content from authorized instructions. A message or document should not be able to grant permissions by itself.
In Trustworthy agents in practice, Anthropic explains that behavior depends on tools and environment as well as the model, and that no single defense guarantees protection against malicious instructions embedded in content. This supports designing controls across several layers.
5. Measure complete resolution, including supervision
A product may complete many actions while leaving people with the difficult work: detecting errors, redoing steps or explaining decisions to customers.
To decide whether to expand autonomy, I would establish a baseline for the current process and examine:
| Product question | Signal I would measure |
|---|---|
| Was the need resolved? | Correctly resolved cases, with criteria reviewed by the team |
| Was total effort reduced? | Execution, review, correction and escalation time |
| Were boundaries respected? | Out-of-scope actions, blocks and skipped approvals |
| What happens on failure? | Incidents, recovery and tasks with no usable exit |
| Is it operationally viable? | Cost per correctly resolved case and supervision workload |
I would review results by case type. A favorable average may hide incorrect answers or additional human work in ambiguous cases.
Agree on continuation criteria before the pilot. If unauthorized changes occur or the team cannot reconstruct an error, I would review the scope before delegating more. A success percentage alone does not explain the severity of failures.
6. Use an autonomy brief before building
This brief connects the product conversation with implementation decisions:
| Field | What to make clear |
|---|---|
| Objective | The task that must be resolved and for whom |
| Allowed context | Data, sources and resources the system may access |
| Actions | What it may retrieve, prepare and modify |
| Approvals | What requires confirmation and who may provide it |
| Boundaries | Time, attempts, usage and scope for each action |
| Uncertainty | When to ask for information, escalate or stop |
| Evidence | What to record for review without retaining unnecessary data |
| Recovery | How to interrupt, correct or return to the usual process |
| Evaluation | Test cases and conditions for expanding or reducing autonomy |
| Owner | Who supervises operations and handles incidents |
I would start with a small set of tasks, representative cases and a scope the team can supervise. I would expand permissions when there is evidence about those specific actions. Some may continue to require approval even when others already run automatically.
Frequently asked questions
Does connecting a chatbot to an API make it an agent?
Not necessarily. It may perform a lookup within a fixed path. Look at who decides the steps, how results are used and which actions are permitted, beyond the system’s marketing name.
Does an agent need full autonomy?
It can choose how to investigate while still requiring approval before taking action. The product goal is to resolve the task with an appropriate scope that users can understand.
When is a workflow enough?
When you can reasonably define the path and its exceptions. Compare it with a more flexible alternative using the same cases and evaluation criteria.
What should a person approve?
In my proposal, actions with significant consequences, actions that are difficult to reverse and actions outside previously authorized scope need an explicit decision. The specific policy should be agreed with the people responsible for the product and process.
For me, connecting product and engineering means turning a promise such as “resolve an issue” into verifiable decisions about access, actions, boundaries and results. That is where autonomy becomes a feature we can design and evaluate.
If you are defining an initiative, continue with the guide to connecting product and artificial intelligence, explore my approach or connect with me on LinkedIn.