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 config. You've also introduced a security control that can hallucinate. It can invent a vulnerability that isn't there and cost you a day, or miss one that is and wave it through to production. Failing an audit would be the cheap version of that.
The agent shaped problem sits alongside that workflow. It's triage and remediation. Given fourteen new criticals this morning, which ones actually reach production code paths? Which are transitive dependencies nobody imports? Which need a patch now, which can be suppressed with a comment explaining why, which need to go to the platform team because the fix means a runtime upgrade? Then draft the pull request.
That work is ambiguous, context dependent, and currently done by a senior engineer with a coffee and a bad attitude on a Monday morning. There's no flowchart for it, which makes it a decent agent.
Notice what happened there. The deterministic scanner didn't go away. It became a tool the agent calls. That's usually the right architecture and it's the one people skip past when they're excited.
What an agent needs
Agency comes first: freedom to reach the goal using whatever tools, skills and context it has available. If your prompt encodes the exact sequence of steps, you've written a workflow in the least maintainable language available.
Then tools, meaning the ability to change something in the world. An agent with no tools produces very expensive opinions. Teams skimp here, usually because integration work is unglamorous, and then wonder why the agent talks a great deal and changes nothing. MCP has been genuinely useful to me: read access to repositories, database schemas, a project board. Boring work, and most of the real capability comes out of it.
Delegation is the third, so the agent can hand scoped work to a specialist and keep its own reasoning uncluttered.
Nothing on that list has anything to do with how the agent gets started.
The one I rely on
The example I keep pointing at is small and unglamorous, which is why I like it.
I run a research agent in Platypus on an hourly cron. It decides what to look into based on what it already knows and what it's seen recently, runs web searches, and writes results into my Obsidian vault through MCP. Nobody steers it and there's no fixed path. The outcome is defined ("keep my notes current on these areas, don't duplicate what's already there") and the route it takes to get there is its own business.
By the time I sit down, there are draft notes waiting. Some are useless. Most give me a starting point instead of a blank page, which is the actual value: it moved the work from creation to editing.
Two honest limitations. Sometimes it gets things wrong, so I read everything before I act on it. And I keep it firmly on the draft side of the line. Anything with consequences, whether that's merging a PR, touching production, or sending something to a human who isn't me, stays a draft and review flow. That's a design decision, and better models won't change it. How much autonomy I hand over scales with how easily I can undo the result.
What I'd tell you if you're deciding where to spend
Start with the shape of the problem, before anyone in the room says the word "AI". For each candidate on your list, ask whether you can specify the steps or only the success criteria. That one question will reclassify half the items on most roadmaps, and the reclassification usually saves money.
The agent is often sitting alongside your workflows rather than replacing them. The pattern from the security example repeats everywhere: the pipeline stays deterministic and the judgement layer above it becomes agentic. Incident response is the same shape, since alerting is deterministic and diagnosis isn't. So is code review, data quality and support triage.
Ask about observability before you ask about capability. You can't debug an agent by reading its output, so you want traces of the tool calls it made and what each run cost you. Working out whether last week's prompt change made things better or just different is harder again, and I'll be upfront: Platypus doesn't do this well yet. It's the gap I trust least in my own product, and it's the first question I'd put to any vendor before signing anything. Teams that can't answer it stop trusting their agents within a month and quietly turn them off.
Then write down your reversibility line, early. Which actions can an agent take unsupervised, which require a human approval step, and which are off limits entirely? That document is worth more than your model choice, and unlike your model choice it won't be obsolete in six months.
Agents are genuinely powerful in ambiguous space, and there's less of that space in your business than the vendors would like you to believe. Everywhere else you're overengineering, and you'll pay for it in cost, latency and reliability.
The word "agent" is doing a lot of marketing work at the moment. Ask what shape the problem is before you spend anything on it.
Top comments (0)