Workflows before agents

Catherine Ives-YimPublished 27 September 2026 · 5 min read

When organisations ask me about AI agents, the most useful thing I can usually tell them is that what they need is not an agent. It is a workflow with AI in it.

That is not a criticism of agents. It is a statement about where most of the value in engineering companies actually lies. Most engineering processes are known. The steps are understood, the order is fixed, and the difficulty is in the volume and the reading, not in deciding what to do next. For that kind of work, a well-designed workflow is cheaper, more reliable, easier to test and easier to trust than an autonomous agent.

The difference, briefly

In the previous article, What an agent actually is, and isn't, I described a spectrum from assistants, through workflows, to autonomous agents.

A workflow is a sequence of steps designed by people, where some steps use AI. The process decides what happens next.

An agent decides for itself what to do next, based on what it has found so far.

The distinction matters because it determines who is responsible for the path the work takes. In a workflow, your engineers designed the path and can inspect it. In an agent, the model chooses the path, and you inspect it afterwards.

The test: can you write the steps down?

The simplest way to decide is to try to write the process as a numbered list.

If you can, and the list is mostly the same each time, build a workflow. Classifying incoming service tickets, extracting facts from test reports, summarising a month of field data, checking a bill of materials against a list of known vulnerabilities, drafting a standard report from a template: these are all processes whose steps you know. The AI's job is to do the reading and writing within each step, at a volume and speed no team could match.

If you cannot, because the next step genuinely depends on what the last one revealed, consider an agent. Investigating why a particular unit is failing is a good example. Whether you next look at the firmware history, the build record or the telemetry depends on what you have just found. That is judgement about the path, and it is what agents are for.

In my experience, the first category is far larger than the second in most engineering companies.

Why workflows win by default

Predictability. A workflow does the same thing every time. When something goes wrong, you know which step failed. An agent may take a different route each time, which makes failures harder to reproduce.

Testability. Each step of a workflow can be tested on its own, with known inputs and expected outputs. Testing an agent means testing every route it might take.

Cost. A workflow uses AI only where it is needed, once per step. An agent reasons at every turn of its loop and rereads material as it goes, which can multiply the cost several times over for the same result.

Control. Human approval points can be placed exactly where they belong in a workflow. In an agent, deciding when to stop and ask is itself part of what has to be designed and tested.

Trust. Engineers and auditors can read a workflow and understand it. That matters when the output feeds a compliance file or a safety decision.

A workflow I run

For an environmental monitoring system I designed, which tracks aircraft movements and noise for a local community, I built automated daily, weekly and monthly digests. Each one follows a fixed process: collect the data, deduplicate it, enrich it with aircraft type and weather, classify noise impact, summarise, and send.

Nothing in that process needs an agent. The steps never change. What changes is the data. It has run reliably because it is simple, and every stage can be checked independently.

The same pattern applies directly to engineering. A weekly digest of service tickets, as I described in Closing the loop, is a workflow: gather, classify, count, compare with last week, flag what changed, summarise. It is the right first step towards the most valuable level of AI in an engineering company, and it does not need autonomy to deliver it.

When agents are worth it

Agents earn their place where three things are true:

The path cannot be known in advance. Each step depends on what the previous one found.
The information is spread across several places. The agent's value is in choosing where to look.
A person reviews the outcome. Either the agent only reads, or its conclusions are checked before anything happens.

Fault investigation, root-cause analysis, assessing the impact of an unfamiliar change, and exploring a large and poorly documented codebase all fit. I describe five such agents in Agents at work in engineering.

Workflows with agents inside them

The most practical designs often combine both. A workflow provides the overall structure and the approval points, and an agent is used for one step that genuinely needs judgement.

For example: a workflow receives a new cluster of field faults, gathers the affected units and their records, then hands the investigation step to an agent. The agent explores and reports its findings with evidence. The workflow then drafts the investigation report for an engineer to review, as described in AI drafts, engineers decide.

The agent has freedom where freedom helps, and the workflow keeps everything else predictable. That is also the natural place to start building the guardrails I discuss in Guardrails: autonomy is earned.

Four things worth taking seriously

For engineering leaders: before commissioning an agent, ask whether the process could be written as a list of steps. If it can, you probably want a workflow.

For anyone buying AI systems: be wary of autonomy offered as a feature. It is a cost and a risk as well as a capability. Ask what it buys you that a workflow would not.

For technical teams: build workflows first, and introduce agents for individual steps that need judgement. It is far easier to add autonomy than to take it away.

For everyone: most of the value of AI in engineering is not in autonomy. It is in doing reliably, at volume, the reading and writing that nobody has time for.

I would be interested to hear which processes in your organisation you could write as a list of steps, and which genuinely need judgement at every turn.