The challenge is not just answering: it is acting
An agent can summarize a request correctly and still take an action the company did not authorize. Updating a customer record, sending a proposal or closing a support ticket has different consequences from drafting a response. When AI gains access to business systems, the question expands from “Is this a good answer?” to “Should this action happen?”.
For managers, the challenge is turning that distinction into operational rules. Who sets the boundaries? Who reviews exceptions? How can the process be stopped? We recommend answering these questions before the pilot, together with the people who know the day-to-day work. Autonomy should be an explicit decision about each activity, not a generic setting applied across the entire company.
Start with the simplest path
Anthropic distinguishes workflows with predefined steps from agents that dynamically decide how to use tools. Its architecture guide recommends increasing complexity only when necessary. This distinction helps prevent a predictable sequence of checks from becoming an open-ended model decision without a clear reason.
In practice, map the process first: input, lookup, interpretation, proposed action and execution. Identify where ambiguity requires interpretation and where a deterministic rule is sufficient. A system can use AI to understand a message and conventional code to validate required fields. Every step does not need to be delegated to the same component.
Separate three levels of action
As a starting point, we propose three levels. At the first, the agent only retrieves authorized information and prepares suggestions. At the second, it performs bounded, reversible actions, such as adding an internal label. At the third, it prepares sensitive actions but waits for explicit approval before executing them. This classification is a design proposal, not a universal standard.
The classification depends on context. A label can change a support request's priority and affect a customer, so “reversible” does not mean “risk-free”. For each action, record the potential impact, the scope of data access, the person responsible and the stopping condition. If the team cannot explain how to detect and correct an error, keep execution supervised.
A hypothetical example: a commercial request
Imagine a distributor receiving requests to change delivery deadlines by email. This is a hypothetical example, not an NM Solutions customer case. The agent reads the message, identifies the order and retrieves permitted data. It then prepares a summary of the request, the records consulted and any missing information.
If the identifier does not match a valid order, the workflow sends the case for review rather than guessing. If the order is valid, the agent can draft a preliminary response. Changing the deadline and sending the customer a message remain separate actions: the responsible person sees exactly what will change and approves or rejects that specific proposal.
After approval, an integration executes the change and records the outcome. If the order system is unavailable, the request stays pending. The customer does not receive a false confirmation. Repeated attempts must also be recognized: resending a message or retrying a call should not create a second change or an unintended duplicate message.
Approval must be useful, not symbolic
A screen offering only “approve” and “reject” transfers work without providing context. We recommend showing the original request, relevant data, the proposed action and its expected effect. If the proposal changes after review, the previous authorization should not automatically apply to a different action.
OWASP links excessive agency to functionality, permissions and freedom of action beyond what is needed. Mitigations include limiting tools and access and requiring human approval for high-impact actions. These controls must exist in the system executing the action, not only in the instructions sent to the model.
Messages, documents and retrieved pages should also be treated as data, not as authorization to change the process. External text may try to induce the agent to perform another task. Access rules, independent validation and oversight help reduce exposure, but they do not eliminate every risk.
Measure quality before expanding autonomy
Before the pilot, record how the team works today. Track total handling time, rework, routing errors and the number of cases requiring specialist review. During testing, also measure cost per completed case, rejected proposals, integration failures and review effort. A fast response that needs extensive correction may not improve operations.
Agree on advancement and suspension criteria with the process owners. Test incomplete, contradictory and repeated requests alongside the easy examples. Do not let an aggregate accuracy rate hide serious errors in a particular category. Expanding the scope should depend on evidence and the team's capacity to oversee the change.
A responsible first step
Choose a process with clear boundaries, an available owner and a verifiable way to assess the outcome. Keep a manual path for exceptions and document who can stop the agent. The initial goal is not to eliminate all human involvement, but to discover where automation helps without quietly transferring risk.
NM Solutions helps map processes, integrations and action boundaries to structure AI initiatives connected to business operations. If your company is exploring this path, a diagnostic conversation can help define the scope of the first pilot.