To automate business operations with AI agents, start from an outcome you can state in one sentence ("every customer invoice is paid or escalated within forty-five days"), give an agent a system in which that outcome's actions exist as permissioned tools, and let the agent pursue the outcome while a person handles the exceptions it raises. That is a different method from the one you used for workflow automation, where you mapped a path and built triggers along it.
The two are complementary. Workflows are the right tool where the path is fixed and the volume is high; agents are the right tool where the path varies with the situation and the outcome is what matters. Most of the mistakes in early agent projects come from using the workflow method (map every step, then hand the map to the agent) and most of the successes come from stating the outcome, governing the system, and measuring how often a person had to step in.
The misconception: more automation means more workflows
Operations teams that have spent five years building workflow automation tend to approach agents the same way: map the process, identify each step, and configure an agent to do the steps. It feels rigorous. It also produces agents that are brittle in exactly the way the workflows were, because the map is still the thing being executed, and the map is wrong the moment a customer does something the map did not anticipate.
A workflow encodes the path. An agent pursues an outcome, choosing the path from the tools it has and the state it finds. When a supplier replies to a purchase order with a partial delivery date, a workflow needs a branch someone thought to build; an agent reads the reply, updates the expected date, tells the person who cares, and carries on. The difference is not intelligence. It is that the agent was given the outcome and a set of tools, rather than a path.
So the first change of method is to stop starting from the process map. Start from what you want to be true at the end of the week.
Start from the outcome, not the task
An outcome is a sentence about the state of the business that can be checked. It names a set of records, a condition, and a time. Tasks describe activity; outcomes describe results. The table shows the difference for four common operations, and the third column is what the agent needs to be allowed to do to pursue each outcome.
| Task-shaped request | Outcome-shaped request | Actions the agent needs |
|---|---|---|
| Send reminder emails on day 1, 7 and 14 | Every invoice is paid or with a person for a decision within forty-five days of issue | Search invoices by balance due, send reminders and statements, pause, create tasks |
| Check stock levels every Friday | Nothing on the active list drops below its reorder point without a purchase order raised or a person told | Read stock and reorder points, draft purchase orders, ask above a spend limit |
| Reply to enquiries within two hours | Every enquiry has a quote, a booked call, or a named person on it by the end of the day | Read the inbox, draft quotes, book calendar slots, assign tasks |
| Log supplier delays | Every job this week has a confirmed delivery date or a flagged risk by Monday noon | Read supplier mail and orders, update expected dates, flag jobs, notify owners |
The left column is how workflows are specified. The middle column is how agents should be. The right column is the permission set, and it is deliberately narrow: only the actions the outcome requires.
Writing the outcome sentence is harder than it looks and worth the hour. If you cannot say how you would check it, it is not an outcome yet. If it needs the phrase "and use judgement", you have found the part a person keeps.
Give the agent a governed system, not a login
The second change of method concerns what you hand the agent. The temptation is a user account in the existing system and a long prompt. That gives you an agent that can see everything, do anything the account can do, and leave no trace distinct from a person's. The alternative is a system that treats the agent as a client acting for a named person, with four properties.
- Actions as tools. The operations the outcome needs exist as defined, typed actions the agent can discover and call, with inputs and a result, rather than screens to be driven. The Model Context Protocol is the open standard for this, and any compatible agent can use tools published through it.
- Permissions on every call. The tools offered to the agent are filtered by the role of the person it acts for, and each call is checked again when it runs. The agent of someone who cannot approve a purchase order cannot approve one either.
- A budget. Where the system's own AI does the reasoning, spend is capped per integration so a badly stated outcome cannot run up a bill.
- A log. Every call, with its inputs and result, attributed to the person the agent acted for, so that reviewing the agent's week is the same task as reviewing a colleague's.
The MCP specification itself says servers must validate inputs and implement access controls, and that clients should keep a person able to see and deny tool calls. The current guidance from both Anthropic and OpenAI for their own products points the same way: review the permissions a connected server asks for, keep approval on for tools that change data, and only connect to servers you trust. A governed system is what makes that advice practical rather than a warning to ignore.
The method, in six steps
- State the outcomeOne sentence, checkable, with a time bound. Write down the exceptions you expect and who owns each.
- Run it by hand for a weekThe person who does the job today writes down what they did and why. That page is the policy the agent will follow, and it is usually shorter than anyone expected.
- Scope the toolsList only the actions the outcome needs. Give the agent those, under the permissions of the person it acts for, and nothing else.
- Hand it over with reviewThe agent runs the outcome; a person reviews every action for a week, then only the exceptions. Correct the policy, not the agent.
- Measure exceptionsCount how often a person had to step in, and how far from the outcome the record was when they did. Reminders sent is not a metric.
- WidenWhen the first outcome has been boring for a month, add the next one. Reuse the same governance; only the outcome and the tool list change.
The order matters. Teams that skip the second step end up writing the policy in the prompt from memory, and the agent inherits every gap in that memory. Teams that skip the third step give the agent the whole system and then spend the review period worrying instead of reviewing.
Measure exceptions, not tasks
Workflow automation is measured in tasks: runs completed, emails sent, records updated. Those numbers go up when the automation works and also when it is wrong, which is why they are so comforting and so useless. An agent pursuing an outcome should be measured by the residue it leaves for people.
Three numbers cover most operations. The share of outcomes completed with no person involved, which should rise. The number of exceptions per week, which should fall and then stay flat at the level your business genuinely produces. And the lag on each exception: how far from the outcome the record was when a person saw it. If invoices reach a person at forty days overdue rather than fourteen, the policy is late, not the person.
Where workflows still belong
None of this retires workflow automation. A fixed path at high volume with no judgement in it is still best encoded as a workflow: a webhook that files an order, a nightly export, a rule that routes a form submission. The decision table sets out when to reach for which, and the third row is the common case.
| Situation | Reach for | Because |
|---|---|---|
| Fixed path, high volume, no judgement | A workflow | It is cheaper, faster and fully predictable, and there is nothing for an agent to decide |
| The path varies with what the agent finds; the outcome is what matters | An agent | Branches you did not anticipate are handled by reading the situation rather than by a missing rule |
| A fixed trigger followed by a judgement | A workflow that starts an agent | The trigger is reliable and the follow-up needs reading, choosing and asking |
| Money leaving, commitments to customers, anything irreversible | An agent that prepares and a person who approves | The cost of a wrong action outweighs the cost of a pause |
The question is never which is better. It is whether the path is known in advance and whether the step contains a judgement.
A worked example
Here is the stock outcome from the table above, stated as a standing request to an agent connected to a Sois workspace, where stock, suppliers, purchase orders and tasks are one record exposed as tools. The operations lead has set a spend limit and named the supplier on each item.
- Reading stock levels against reorder points on the active list
- Six items below threshold; usual supplier and last price found for each
- Four purchase orders drafted and sent within the spend limit
- Two purchase orders held: over the limit, awaiting your approval
- Expected delivery dates recorded from supplier confirmations
- One item flagged: supplier out of stock, alternative not on record
The agent used the stock, supplier, purchase order and task tools the operations lead's role allows. It spent nothing above the limit and stopped on the one thing the policy did not cover.
The exceptions are the output. Two approvals and one sourcing decision are what the operations lead sees; the four routine orders exist in the record as if a person had raised them, and the Monday review is the log. In Sois the agent connected is whichever one the lead already uses, signed in once over OAuth and acting within their role, and when that agent does the reasoning Sois performs no AI on their behalf and charges nothing for it. The method does not depend on Sois; it depends on the four properties above being true of whatever system the agent acts in.
Questions people ask
Should I replace my workflow automation with AI agents?
No. Keep workflows for fixed paths at volume, use agents where the path varies and the outcome is what matters, and use a workflow to start an agent where a reliable trigger is followed by a judgement.
How do I know an operation is ready to hand to an agent?
You can state the outcome in one checkable sentence, you have run it by hand for a week and written down the policy, and the system exposes only the actions the outcome needs under the permissions of the person the agent acts for.
What should I measure once an agent is running an operation?
The share of outcomes completed without a person, the number of exceptions per week, and how far from the outcome each exception was when a person saw it. Counts of actions taken tell you the agent is busy, not that it is right.
Does the agent need to be the vendor's own?
Not if the system speaks an open protocol. Any MCP client, including Claude and ChatGPT, can connect and act within the user's permissions. A system that only works with its own assistant limits you to the features that assistant was given.
- Model Context Protocol specification: tools servers must validate inputs and enforce access controls; clients should keep a person able to deny tool calls and log usage
- Anthropic: getting started with custom connectors using remote MCP connect only trusted servers, review requested scopes, approve tool use
- Sois documentation: the workspace MCP server the workspace as an MCP server; your own agent connects and does the reasoning
- Sois: security and the permission layer permissions enforced when tools are offered and again when they run; spend limits per integration; agent activity logged
This article is reviewed when the products it describes change. Next scheduled review: 4 December 2026.