Building Effective Agents: Most of Them Should Be Workflows

The distinction that matters is control. In a workflow, you decide the sequence of steps. In an agent, the model decides. Most tasks people build agents for have a known sequence, which means they wanted a workflow.

“Agent” has stretched to cover anything involving a model and a tool call, which makes the word useless for design decisions. The useful line is narrow: does the system follow a path you wrote, or does it choose its own?

That choice determines your testing strategy, your cost, your failure modes and your ability to explain what happened. It is worth making deliberately rather than by default.

Workflows and agents
Start with the simplest thing that works
What an agent needs to be more than a demo
Tool design is where quality comes from
Where the human goes
Somewhere for it to run
How this fits the rest of the stack
FAQ

Workflows and agents

A workflow is a predetermined sequence with model calls in it. Fetch the ticket, classify it, extract fields, look up the customer, draft a reply, route for approval. The steps and their order are code you wrote. The model contributes judgement at specific points.

An agent is given a goal and tools and decides for itself what to do. It observes, chooses an action, sees the result, and repeats until it decides it is finished.

The practical differences are large:

Cost. A workflow makes a known number of model calls. An agent makes an unknown number, and the distribution has a long tail.
Latency. Same shape — bounded versus unbounded.
Testing. A workflow’s steps are individually testable. An agent’s behaviour is emergent, and the same input can take different paths.
Debugging. In a workflow you know which step failed. In an agent you reconstruct a trajectory.
Explaining it. “Step 3 returned the wrong field” versus “it decided to search again”.

None of that makes agents wrong. It makes them a considered choice for problems where the sequence genuinely cannot be known ahead of time.

Start with the simplest thing that works

There is a ladder here, and the right move is to climb it only as far as necessary:

A single model call. Classify, extract, summarise, rewrite. An enormous share of useful applications is exactly this and nothing more.
A call with retrieval. Fetch relevant context first, then one call. Most question-answering over your own documents.
A chain. Several calls where each output feeds the next, with code between them.
A router. One call classifies, then branches to specialised handlers. Cheap and effective for varied input.
Parallel calls with aggregation. Several independent evaluations combined by code.
An agent loop. The model decides its own steps.

Each step up adds capability and adds cost, latency, unpredictability and debugging difficulty. The discipline is to solve the problem at the lowest step that works, and to have evidence before climbing.

The common failure is starting at step 6 because it is the interesting one, then spending weeks constraining the agent back into behaving like the chain you could have written on day one.

What an agent needs to be more than a demo

An agent loop in a notebook is an afternoon. An agent in production needs infrastructure, and this is where most projects stall:

A runtime that stays up, because agents are usually triggered by events rather than by someone watching.
Persistence. Conversation state, task state, results. In a database, not in process memory that a restart discards.
Credentials it can hold safely, for every tool it can call.
Permission boundaries. Which endpoints, which data, which actions. This is the part most often deferred and most important.
Observability. Every step, every tool call, every input and output, retrievable afterwards.
Cost controls. A hard cap on iterations and spend per task.
Idempotency. A retried tool call must not create a second order.

That list is a description of a backend service. The model is one component of it, and typically not the component that takes the longest to get right.

Tool design is where quality comes from

The single highest-leverage thing in an agent build is the interface between the model and its tools. Two functions doing the same job produce very different reliability depending on how they are described.

What works:

Descriptions written for someone with no context. The model has not read your codebase. Say what the tool does, when to use it, and what it returns.
Few, well-chosen tools. Twenty overlapping tools produce worse selection than six clear ones.
Errors that say what to do next. Invalid date format. Use YYYY-MM-DD, for example 2026-08-30. is actionable; ValidationError is not.
Explicit constraints in the schema. Enums rather than free strings for known value sets.
Results that are small and structured. Returning a 50KB blob wastes context and buries the answer.

Test tools in isolation before wiring them to a model. Half the failures attributed to model reasoning turn out to be a tool that returned something ambiguous.

Where the human goes

Autonomy is a spectrum, and the right position depends on what an error costs.

For reversible, low-cost actions — drafting, labelling, summarising, gathering — full autonomy is fine, with review after the fact.

For anything that spends money, sends external communication, deletes data, or changes permissions, the agent should prepare the action and a human should approve it. That is not a lack of ambition; it is the same reason deployment pipelines have approval gates.

A useful design is a confidence-based split: the agent proceeds when it is confident and the action is reversible, and queues for review otherwise. Log both so you can measure where the line should actually sit rather than guessing.

And bound every loop. Maximum iterations, maximum wall-clock time, maximum spend. An agent that has taken forty steps is not about to succeed on step forty-one; it is stuck, and the useful behaviour is to stop and escalate.

Somewhere for it to run

The gap between a working prototype and something a team relies on is almost entirely operational: a runtime that does not stop when a laptop closes, a database for state, secrets managed properly, logs you can search, and a way to deploy a change without downtime.

For agents built as workflows — which, per the argument above, most should be — a workflow tool gives you the orchestration, the triggers, the credential storage and the execution history without writing them. That is a substantial head start over an empty repository.

On RunxBuild, n8n runs as a managed tool with its own plan, environment variables and credentials in the dashboard, custom domains and runtime logs, with a managed Postgres or MySQL alongside for state. When a step needs your own code, it deploys as a service from a repository — Node, Python, Go, Docker — with a build log, a live route and rollback, and the workflow calls it over HTTP. Orchestration and execution stay separate, which is also the cleanest security boundary.

How this fits the rest of the stack

Decide whether the model chooses the steps or you do, and be honest that most tasks have a known sequence. Climb the ladder from a single call only when you have evidence you need to, invest in tool descriptions rather than prompt length, put a human in front of anything expensive or irreversible, and bound every loop. The runtime, state and permissions are the real build — the RunxBuild hosting calculator shows a workflow instance, a database and a service as separate line items.

Useful related references:

FAQ

What is the difference between an AI agent and a workflow?

In a workflow you define the sequence of steps and the model contributes judgement at specific points. In an agent the model decides its own steps based on results. Workflows have bounded cost, latency and testability; agents trade all three for flexibility.

When should I build an agent instead of a workflow?

When the sequence of steps genuinely cannot be known ahead of time — open-ended research, or debugging where each finding determines the next action. If you can draw the flowchart, build the flowchart: it will be cheaper, faster and far easier to debug.

What does an agent need in production?

A runtime that stays up, persistent state in a database, safely held credentials, explicit permission boundaries, full observability of every step and tool call, hard caps on iterations and spend, and idempotent tools so retries do not duplicate actions.

How do I make an agent more reliable?

Improve the tools before the prompt. Write descriptions for someone with no context, keep the tool count small and non-overlapping, return actionable error messages, use enums in schemas for known value sets, and keep results small and structured.

Should agents act autonomously?

It depends on what an error costs. Reversible, low-cost actions can run autonomously with review afterwards. Anything spending money, sending external communication or deleting data should be prepared by the agent and approved by a person.