“Agent” is the word of the moment, and plenty of projects pitched as agents are really workflows with a model in one or two steps. That is not a knock on agents. They are the right tool for some jobs. But picking the wrong shape is expensive in both directions. An agent where a pipeline would do is slower, costlier and harder to trust. A pipeline where you needed an agent turns into an endless pile of special cases.
Here is how we think about the choice.
Two different shapes of software
Workflow automation, or a deterministic pipeline, is a sequence of steps a person designed in advance. Some of those steps might call a model to classify, extract or summarize, but the path through the system is fixed. Given a type of input, you know which steps will run and in what order. You might build it with n8n, a workflow engine like Temporal, or plain code and a queue.
An agent is a loop. The model looks at a goal and the current state, picks a tool to call, reads the result and decides what to do next. It keeps going until it decides it is finished or hits a limit. The path is not known in advance, and two similar inputs can take quite different routes. Frameworks like LangGraph, or the agent SDKs from OpenAI and Anthropic, help with the plumbing, but the core idea is that simple.
The difference that matters is who decides the next step: your code, or the model.
What you trade
Pipelines are predictable. Cost and latency per run are roughly known. You can test each step in isolation, and when something goes wrong the logs tell you exactly which step failed. Auditors like them. Their weakness is rigidity. Every new kind of case means a new branch, and the long tail of odd inputs ends up in an “other” bucket that a person has to clear by hand.
Agents handle variety. They can investigate, try something, notice it did not work and try something else. That flexibility is real and useful. The price is variance. Cost and latency differ from run to run. Failure modes are harder to list in advance. Testing means checking whole trajectories, not single steps. And because the model chooses the actions, you need firmer guardrails around what it is allowed to do.
When a pipeline is the right answer
If you could draw the process as a flowchart today, and the variation is mostly in the inputs rather than in the steps, you want a pipeline. The model does the fuzzy parts, like reading an email or pulling fields from a PDF, and ordinary code does everything else.
Typical examples:
- Extracting line items from invoices and posting them to the accounting system for review.
- Routing inbound tickets or leads by category, urgency and account.
- Enriching CRM records from a fixed set of sources.
- Generating a weekly report from the same queries every Monday.
- Summarizing sales calls and filing the notes against the right deal.
None of these need the model to decide what happens next. They need it to do one step well, reliably, many times over.
When you actually need an agent
You need an agent when the steps depend on what you find along the way. The number of lookups varies. The right next action depends on the last result. A person doing the task would describe it as investigating rather than processing.
- Working out why a customer’s integration is failing by checking logs, configuration, recent changes and the docs.
- Answering a question across a company’s internal knowledge that takes several searches, a follow-up query and a comparison.
- Reconciling records that do not match, where the cause is different every time.
- Preparing a first-pass research brief on a prospect from scattered public and internal sources.
Even here, the agent should have a short list of well-defined tools, a step limit, and a clear way to hand off to a person when it gets stuck.
Most real systems are both
The useful question is rarely agent or pipeline. It is where, inside a pipeline, you need an agent.
Take an inbound support email. A deterministic pipeline receives it, a model step classifies it, and routine cases such as password resets or invoice copies follow a fixed path with templated replies. Cases that need investigation go to an agent with read-only access to the account, the logs and the help center, and a cap on how many steps it can take. The agent produces a draft and a short summary of what it checked. That draft goes to a person for review, and the pipeline writes the approved reply back to the helpdesk.
The agent is a bounded component inside a deterministic shell. You get flexibility where it pays for itself and predictability everywhere else.
It also works the other way round. An agent can call deterministic workflows as tools. Issuing a refund should be a tested function with its own checks and limits, not something the agent improvises with raw API access. The agent decides that a refund is warranted. The workflow decides whether it is allowed, and then carries it out.
A decision checklist
- Can you draw the flowchart today? If yes, start with a pipeline.
- Does the number of steps vary a lot from case to case? That leans toward an agent.
- Is a wrong action costly or hard to undo? Keep that action deterministic, or put a person in front of it.
- Do you need the same output for the same input, for audit or compliance? Use a pipeline for that part.
- Are per-run cost and latency tightly constrained? Use a pipeline, or a tightly bounded agent.
- Is the hard part a long tail of varied, rare cases that currently eat people’s time? That is where agents earn their keep.
- Can you build an evaluation set for it? If you cannot define success, an agent will not fix that.
Start simpler than you think
Our default is to start with the most deterministic design that could work, then add agentic behavior only where there is evidence the pipeline cannot cope. That evidence usually looks like a growing pile of cases landing in the “other” bucket. It is much easier to loosen a pipeline than to tighten an agent.
That is not caution for its own sake. A simple system you can measure is the fastest way to find out where the hard cases actually are. Once you know that, you can put the agent exactly where it is needed and nowhere else.
If you are weighing up an agent against a simpler workflow for a specific problem, we’re glad to think it through with you. Book a discovery call with Kryloq and bring the use case.