Chatbot, workflow, or agent? | willdady.com

If you can draw the flowchart, you don't need an agent<br>17 August, 2026<br>ai<br>architecture<br>advice

I've read a lot of vendor websites this year and almost all of them sell agents. Most of them aren't shipping agents. They're shipping a chat window with a couple of tool calls bolted on, or a scheduled job with a prompt in the middle of it.

I'm not being snide about the products. A lot of them are genuinely useful. The problem is the word. "Agent" has been stretched so far that it no longer tells you anything about what you're buying or building, and that vagueness has a price. You pay it in compute you didn't need and latency you can't explain to the business. Worse, a system that used to be boring now fails in ways nobody can reproduce.

The test I use takes about ten seconds. Can you draw the flowchart before you start? Then what you want is a workflow, and paying a language model to walk that flowchart for you is a slow, costly way to get a less reliable result. If the only thing you can describe is what a good outcome looks like, you might have an agent.

Almost everything I get shown fails that test in the same direction. So here's the taxonomy I use when someone on my team says "let's make this an agent".

Three things people call agents

Chatbots

A conversational loop where a human drives every turn. The model responds, the human reads it, the human decides what happens next. Plenty of chatbots have tools now, and that's fine, but the tools don't change the shape of the thing. The human still decides what happens next, judges whether the answer is any good, and cleans up when it isn't.

Chatbots are great. Most of the value people are getting out of LLMs today is chatbots. Just don't put them on the roadmap as an autonomy story, because there's a person in the loop on every single hop.

Workflows

Deterministic steps, known inputs, predictable outputs. Extract the fields, call the API, write the row, send the email. You know the path before you start, which is why you can draw it on a whiteboard and hand it to a junior engineer.

Workflows are where most of the waste lives. If you can draw the flowchart, you don't need a language model to walk it for you. A step function, a queue and a few lambdas will do the same job faster and cheaper, and you get a stack trace when it breaks.

There's a softer version of this mistake that's harder to spot: a workflow where one step involves genuinely fuzzy judgement, like classifying free text or summarising a document. Put the model in that step. Don't hand the model the whole flowchart.

Agents

Outcome based, path opaque. You define what success looks like, you hand over a set of tools, and you accept that you won't know in advance which tools get used or in what order. If it's working well it may also delegate, handing scoped pieces of work to more specialised sub-agents so its own context stays lean.

That last part matters more than people expect. Context runs out, and an agent trying to hold an entire problem in one window degrades badly. One that spawns a narrow specialist, takes the answer back and throws away the noise holds up much better over a long run.

The trigger tells you nothing

Most conversations go sideways here, so I'll be blunt: chat versus cron is plumbing. What makes something an agent is latitude, the freedom to choose its own path to the outcome, with the loop driven by something other than a human.

In Platypus (my own agent platform, more on that later) the same configured agent can be chatted to interactively in the morning and run headlessly on a schedule that night. Same instructions, same tools, same memory. Nobody would argue it's a chatbot at 9am and an agent at 9pm.

Applying the test

Known inputs and specific desired steps means workflow. Clear success criteria with an opaque path means agent. If you find yourself drawing a flowchart with a box in the middle that says "figure it out", split it: the boxes either side are the workflow, the box in the middle is where agency belongs.

I say "might have an agent" deliberately. Some problems fail the flowchart test and still shouldn't be agents, because the cost of a wrong answer is too high to accept a non-deterministic path. That's a separate judgement and I'll come back to it.

What it costs when you get this wrong

Take build-time security scanning. It's the example I reach for because the pitch sounds so reasonable.

An agent that scans the repo and its dependencies on every CI run, works out what's vulnerable, and reports back. Autonomous security, very modern.

It's a workflow, and a solved one. The inputs are known: a lockfile, a source tree, a container image. So are the steps. Snyk and Trivy already do this, they finish in seconds, and they return the same answer twice in a row. Replacing that with a model means paying per token for a slower, less reliable version of a tool you can install with a single line in your pipeline...