AI agents for operations: do you need an agent, or just a workflow?

The word covers three different designs, and the argument is easier once they are separated.

• A workflow. You decided the steps. Trigger, fetch, transform, write, notify. It runs the same way every time and fails in ways you can predict.
• A workflow with a model step. Same fixed path, but one step calls a model to extract fields from a document, classify a message or draft a reply. The model does one bounded job and the path around it is still yours.
• An agent. A model is given tools and a goal and decides which tool to call next, reads the result, and decides again until it stops. The path is not written in advance.

The second is what most useful operations AI actually is. The system we built for a trading business reads supplier invoices with a vision model, but the pipeline around it is fixed: capture, validation against a schema, a review screen, and a confirmation that writes. That is a workflow with a model in it. The model is a swappable component, and nothing about the design is agentic.

If you can describe the process as a sequence, including the exceptions and what to do with each, you have a workflow. The exceptions are the hard part, not the sequence. An agent is not a way to avoid enumerating them. It is a way to have a model improvise on cases you did not enumerate, which is only attractive when improvising is acceptable.

The design decision that makes AI acceptable inside a finance team is not accuracy. It is that the model never writes. On the invoice system, nothing happens when a photograph is taken. A proposal appears on screen, and stock levels, cost prices and the supplier balance move only when a person presses confirm.

The rule generalises. Models draft, extract, classify and suggest. People approve anything that writes to the books, sends to a customer, or cannot be undone. For an agent this means its tools should be split by consequence. Read tools are given freely. Write tools either do not exist, or they create a proposal that waits for approval. An agent that can call send or pay directly is a different risk class, and one to avoid until you have run it on read-only work for long enough to know how it behaves.

• Draft and review for anything customer-facing. Review is faster than writing from scratch, and slower than nothing, which is the right place to be.
• Default to read-only. Add a write tool only when you can state exactly what it can change and who approves it.
• Make the approval carry weight. A confirm button nobody reads is theatre. Show the proposal and the evidence side by side, as the invoice screen shows the source image beside the extracted lines.
• Escalate rather than guess. Give the agent an explicit way to hand a case to a person, and treat the handoff rate as a metric.

A workflow with a model step costs about the same each time: one call, roughly the same input. An agent does not. It loops, each step re-reads the growing history, and the number of steps depends on the case. The average hides the problem, because the cases that cost the most are often the ones that confuse it.

1. 01Run it on a sample of real cases, including the awkward ones, with every call logged. Choose a sample large enough to include the awkward ones.
2. 02Look at the distribution, not the mean. The expensive tail is what you budget for.
3. 03Cap the number of steps and the spend per task, and define what happens at the cap: stop and hand to a person.
4. 04Match the model to the job. Classification and routing rarely need a frontier model, and a hard extraction from a bad scan does. Where a small model does a step, use it.
5. 05Price at your real volume, using the provider's current published rates. Model prices move, so treat any figure as stale the moment it is written. Keep the model a setting so changing it is cheap.

Also compare it with the alternative. A fixed workflow with a model at one step often does the job at lower and more predictable cost, and it is far easier to test.

When an agent has taken an action, someone will eventually ask what it did and on what basis. If the answer is that it decided, you have a problem the first time it matters. The design needs to produce an answer by construction.

• Log every tool call with its inputs, its outputs and a timestamp, and keep the log somewhere the agent cannot edit. On the trading system, the audit table is append-only: staff can insert and read, and there is no update or delete policy, so the trail cannot be rewritten through the API.
• Scope credentials to the task. An agent that holds an account-wide token inherits everything that token can see. Give it the narrowest access that works, ideally read-only, and keep the broad token in one server process.
• Make writes idempotent. Retried calls are normal, and an agent that retries must not create two records. Use a stable key and find-or-create semantics.
• Keep rules that matter in the database. A constraint holds no matter how the data is written, including by an agent. Application prompts do not.
• Build an evaluation set from real cases, bad ones included, with known-correct answers. Without it a prompt change or a model upgrade is a guess. With it, it is a measurement.

Failure needs a plan as well. Providers rate-limit and have outages, so the pipeline should rotate keys and fail over between providers, and it should say clearly when it is not configured rather than looking as if it found nothing.

Claude, like other major models, can be given tools and will choose when to call them. That is the mechanism behind agents, and it is just as useful in a bounded workflow where you control the loop. For internal systems, an MCP server is one way to expose read tools over your own data with the scoping decided on your side. We build against both Claude and OpenAI and keep the model swappable, because the pipeline around it is where the engineering is.

A caution about our own track record. The AI work on this site is extraction and classification inside fixed pipelines with human confirmation, notably the trading ERP. None of our case studies is an autonomous agent acting on its own, and we would not describe one as proven in production. Treat that as a reason to start small. The controls above matter more than which model sits underneath.