An AI agent can know exactly how a business works and still lack the authority to act. Workflow knowledge explains the steps; authority defines whether the agent may draft, recommend, approve or execute each one.
At 8:17 on Monday morning, Lena, the fictional owner of a small commercial cleaning company in Manchester, stared at a payment approval on her laptop while her coffee went cold. The agent had matched the invoice to the right supplier, checked it against the agreed rate and prepared the payment exactly as her bookkeeper would.
Then it sent the payment.
Lena had never authorised it to move money. Worse, the supplier’s account details had changed in the latest email, and no one had confirmed the change by phone. If the message was fraudulent, the money was already heading to the wrong account. Payroll was due later that week.
The agent had followed the workflow accurately. That was the problem.
A correct process can still produce an unauthorised action
Businesses often document workflows as sequences: receive an invoice, match it to a purchase order, check the amount, approve it and schedule payment. An agent trained on that sequence can reproduce the mechanics.
The document rarely captures who may cross each boundary.
A finance assistant might prepare a payment but lack permission to release it. A manager might approve routine invoices but need a second sign-off above a defined amount. A bookkeeper might update supplier records only after completing a separate verification step.
Those distinctions may live in job titles, software permissions, habits and quiet exceptions. They are obvious to the people who have worked together for years. They are invisible to an agent unless someone states them plainly and enforces them technically.
This matters beyond finance. A customer-support agent may know the refund policy without having permission to issue a refund. A sales agent may understand discount rules without being allowed to change a contract. A coding agent may know how deployments work without having authority to push to production.
The gap appears whenever “what happens next” is mistaken for “what this system may do next.”
Define authority at the action level
A vague instruction such as “ask before important actions” leaves the hardest decision unresolved. What counts as important: sending a draft email, changing a customer record, cancelling an order or releasing a payment?
Wix’s announced agent platform offers a useful framing. It learns an SMB’s workflows, coordinates specialised agents and asks owners to approve important actions. The approval principle is sensible, but each business still has to decide where those approval points belong.
A practical authority map should classify individual actions:
- The agent may read approved records and gather context.
- The agent may draft an output for a named person to review.
- The agent may recommend a decision and show the evidence behind it.
- The agent may execute low-risk, reversible actions within defined limits.
- The agent must stop when an action changes money, access, legal commitments or production systems without the required approval.
“May execute” also needs conditions. Which account can the agent use? What value limit applies? Does a changed bank detail, delivery address or contract term force a stop? Who can approve, and must the approval happen inside the controlled system?
This resembles the distinction between productivity and autonomous capability in an engineering manager’s paused AI coding rollout. Knowing that a tool completes tasks faster says little about the consequences when it acts independently.
Build stops for uncertainty and changed conditions
Lena’s agent needed more than an approval button. It needed a rule that treated changed supplier details as a new risk condition, regardless of how familiar the invoice looked.
With payroll exposed, Lena called her bank and supplier. For the purposes of this illustrative scene, the payment was stopped before settlement. The narrow escape changed her rollout plan that afternoon.
She removed payment execution from the agent’s permissions. It could still collect invoices, compare records, identify discrepancies and prepare payment details. A person had to verify any account change through a separate channel, then release the payment.
That boundary reduced autonomy, but preserved most of the useful work.
The same design principle applies elsewhere. Give agents a defined route for uncertainty: stop, preserve the current state, explain what triggered the stop and send the decision to a named owner. Silence, missing data or conflicting instructions should reduce authority rather than invite the agent to improvise.
Audit records matter too. For every consequential action, retain the source information, the rule applied, the agent’s proposed action, the approving person and the final result. Without that chain, a business may know what happened while remaining unable to establish why. Maya’s missing audit trail shows how quickly that evidence gap can threaten an otherwise promising trial.
Test the boundary before expanding access
Start with one workflow and mark every point where the agent changes the outside world. Drafting a message changes nothing until it is sent. Preparing a refund changes nothing until funds move. Generating code changes nothing until it reaches a live system.
For each boundary, test three cases: the normal request, a request with changed sensitive details and a request containing incomplete or conflicting information. Confirm that the agent stops in the second and third cases, identifies the reason and routes the decision correctly.
On Tuesday morning, Lena’s payment queue looked almost the same. The invoices were matched, discrepancies were highlighted and payments were ready for review. One changed account number sat behind a clear warning, waiting for her bookkeeper rather than moving money on its own.
That pause was the control the workflow had been missing.
Comments
No comments yet.