On this page5 sections
Two proposals for the same process often disagree on the label before anyone has designed the work. One says "AI agent." The other says "integration." Both have a clean diagram. Neither says what happens when a request is incomplete, the customer already exists, or the next step needs an approval.
Here's how I sort it out, and how I'd explain the decision to whoever is paying for it.
My starting point is always the same question: what should be different in the business when this process finishes? "We have AI" isn't an outcome. "Every eligible request reaches the right person with the facts they need, and the ones that stall stay visible" is a process you can check.
Split the job into deciding and doing
Almost every automation project hides two different questions.
How do we decide what should happen? Reading a messy request. Comparing options. Chasing down missing information.
How do we make it happen correctly? Updating one exact record. Applying an agreed calculation. Sending one notification, not three.
AI is often good at the first question. It's rarely the right tool for the second. So I let AI investigate and propose, and I let plain, fixed software check permissions, validate the data and make the change. An agent can prepare a proposal. The application decides whether it's allowed.
Anthropic's engineering team makes the same distinction. A workflow follows a predefined path; an agent decides its own path and which tools to use. Their guidance recommends adding that autonomy only when the task justifies the extra cost and unpredictability. Anthropic's workflow and agent guidance
I built the lab below so you can try this on a task of your own. Pick a job, mark which parts are fixed rules and which need judgment, and see where the design lands.
Choose the shape of the work.
Start with a worked example or describe your task. This worksheet suggests a design to test; it does not measure an AI system.
A system cannot choose a useful level of autonomy until the outcome, input, route, and permission boundary are understood.
Next useful step: Write one successful result and one situation in which work must stop.
Four jobs that look alike until you open them up
These are worked examples, not client projects. The thing to watch is where uncertainty enters.
| Job | The predictable part | The part that might need AI | Where I'd start |
|---|---|---|---|
| Reconcile a payment | Match the payment to the record and check its state | Explain an odd discrepancy to a person | Fixed rules, with AI only writing the explanation |
| Route a written request | Known teams and required fields | Read a free-form description and pick a team | AI reads inside a fixed workflow |
| Research a proposed change | Approved sources, a deadline, a deliverable | Decide what to look into next | A bounded agent |
| Watch scheduled work | Expected start, deadline, completion receipt | Summarize a messy failure | Fixed monitoring, AI optional |
Reconciling a payment
The amount, the payment ID and the recorded state are facts. Asking a model whether an order "looks paid" adds guesswork where the business needs a yes or a no.
So the automation matches the payment to its record, spots anything missing or contradictory, and sends the exception to a person. If AI helps at all, it's to write up the evidence for that person. It never decides the payment happened.
I also keep "we found the payment" separate from "the work is done." A payment can exist while the registration or booking behind it is still unfinished. Those are two checks, not one.
Routing a written request
Say requests belong to one of four teams. The destinations are fixed. The descriptions aren't: shorthand, three needs in one message, customers using different words for the same thing.
Here AI earns its place. It reads the text and proposes a team with a reason. The workflow around it checks that the team exists and the required fields are present. An ambiguous request goes to a person instead of getting a confident wrong answer.
Notice what this doesn't need: an agent inventing its own sequence of steps. One bounded reading step inside a fixed path is enough.
Researching a proposed change
You want to know whether swapping a tool will break your current workflow. The first document turns up an export limit, and that changes the next question. Nobody can write the path in advance.
This is where I'd use an agent. I give it the approved sources, the deliverable I want, a limit on how far it can go, and a rule that it must leave a question open when the evidence isn't there. Broad autonomy to research; no autonomy to change anything.
Watching scheduled work
A nightly export should start at a set time and leave a receipt. Noticing it never started is a simple expectation check. No model needed to decide whether an empty log feels fine.
AI can help summarize a failure that spans several systems. But the underlying states stay explicit: expected, started, waiting, done. Otherwise the monitoring becomes one more confident explanation hiding unfinished work.
Write the operating agreement before connecting anything
Before I connect a single tool, I write a one-page agreement for the system. Every line gets a real answer, including "undecided."
- Inputs: which records, documents or events may enter?
- Outcome: what visible result counts as done?
- Authority: which source is allowed to answer each important question?
- Access: what may it read, for this user and this purpose?
- Actions: what can it prepare, what can it do on its own, and what needs a person?
- Stopping: when should it pause, ask, or hand the work to someone?
- Recovery: if it's interrupted halfway, how does it resume without repeating what already happened?
The "actions" line matters most. "Check with me" in a prompt is a suggestion. A tool that physically cannot run without a current approval is a control. The approval guide shows how I build that.
Compare the two proposals on the same work
If you have two proposals, don't compare two demos. Ask both to run the same twenty representative requests, with the same source material and the same definition of success.
Include the awkward ones: an incomplete request, a conflicting source, a duplicate event, a system that's down. For research tasks, include a question the allowed evidence can't answer. Stopping correctly should count as a pass.
Then compare accepted outcomes, not impressive responses. Ten drafts that each need ten minutes of repair are not equal to ten results you'd sign off on. The repair time belongs in the operating cost.
Give the first version a finish line
"Connect our apps to AI" never ends. "Prepare a supported recommendation for each eligible request, route the exceptions to an owner, and record the approved result" has a beginning, an end and a recovery path.
I pick one complete slice, including the handoff and the monitoring, even if the first version handles a narrow set of requests. The first release should teach us one specific thing: whether AI reading improves routing, whether research cuts prep time, or whether the fixed steps run reliably. That evidence decides what gets more autonomy next.
I can't promise a particular saving before we've run the pilot. I can promise you'll know what the system did and why.
Most processes need a fixed automation with AI reading one step, not a free-roaming agent. Agents earn their cost when what they find changes what they do next. Whatever the design, write the operating agreement first, and let the software, not the prompt, enforce which actions need a person.