What 'Agentic' Actually Means (And When You Don't Need It)

Every product page in AI carries the word "agentic" somewhere above the fold now. Keep scrolling across the industry and you'll find it attached to a summarizer, a form auto-filler, a Slack bot that posts a daily digest, and a system that can genuinely go off unsupervised and complete a forty-step task with no human checking in along the way. Those are not the same category of software. Treating them as though they were is a big part of why so many teams end up building something far more complicated — and far more expensive — than the problem in front of them actually required.

At GLSRM we think the word is worth rescuing, because underneath the marketing fog there is a real and useful distinction. It has almost nothing to do with how impressive a system looks in a demo and everything to do with a much narrower, more mechanical question: who decides what happens next.

The one question that actually separates agentic from everything else

Take any AI system you've used and ask this about its second action: when it did that second thing, who decided it should be that specific thing? If the honest answer is "a person, in advance, when they wrote the code," you are looking at a script or a pipeline, no matter how many language model calls are stitched into it or how well it's marketed. If the answer is "the model itself, based on what it observed after the first action," you are looking at something genuinely agentic.

That's close to the whole test. Not how many tools the system has access to. Not how long it runs before returning an answer. Not how autonomous it feels when you watch a polished walkthrough. Just: does the sequence of steps get fixed in advance by a human, or does it get decided at run time by the model, in response to what actually happened along the way? A weather bot that calls one API and formats the response is not agentic, even if a language model wrote the sentence. A research assistant that reads a document, decides based on what it finds that it needs to check a second source, picks which source, reads that, and only then decides it has enough to answer — that's agentic, even if the underlying task feels almost trivial.

Three ingredients, not one

Precision matters here because "agentic" gets used as a single on/off switch when it's really a combination of three separate ingredients, and a system needs meaningfully all three before the label earns its keep.

The first is access to tools or actions beyond generating text — the ability to search, query a database, call an API, write a file, execute code. Without this, a model can only ever produce an answer from what it already has in context; there is nothing to be agentic about.

The second is a decision loop, where the model's own output determines the next input it receives. This is what separates an agent from a single well-engineered prompt with a tool bolted on. A system that always calls the same tool in the same order regardless of what comes back is not looping — it's executing a checklist that happens to include a model call.

The third, and the one people skip most often in casual definitions, is a stopping condition the model controls. A genuinely agentic system decides for itself when it has done enough — when the task is complete, when it's stuck and should say so, when it needs to ask a clarifying question instead of guessing. A pipeline that always runs exactly three steps and returns whatever it has isn't making that call. It's just three steps.

All three together are what you're actually paying for when you build or buy something "agentic": tool access plus a feedback loop plus model-controlled termination. Miss any one of them and you have something else — often something perfectly good, just not this.

Picture a system built to help a small logistics team resolve shipping exceptions. Give it access to a tracking lookup and a customer-messaging tool, but hardwire it to always check tracking first, always message the customer second, and always stop after those two steps, and you've built a pipeline with a language model in it, useful as that might be. Give the same two tools to a version that can look at what tracking actually shows, decide for itself whether the situation calls for a customer message at all, whether it needs a third lookup against a carrier's exception codes first, and when it's actually resolved the case, and you've built something agentic, using the exact same two tools. The tools didn't change. The decision rights did.

Why a chatbot with search attached still might not qualify

This is where a lot of otherwise careful teams talk themselves into overcomplicating things. Retrieval-augmented generation — pull some documents, stuff them in context, generate an answer — gets called agentic constantly, and in its simplest form it isn't. One retrieval, one generation, no branching, no revisiting the question based on what came back. It's a very good pattern. It is also a pipeline with a fixed shape, not a loop.

The line gets crossed the moment the model can look at a first retrieval, judge it insufficient, decide what a better query would be, and go again — potentially several times, potentially down different paths depending on the topic. That's a small change in architecture and a large change in what you're actually operating, because now the number of steps, the cost, and the latency are no longer fixed quantities you can predict in advance. They're a distribution. That distinction — fixed shape versus variable shape determined at run time — is a better mental model than "does it feel smart," because it's the thing that actually drives your engineering and cost decisions later.

The bill that comes with agency

None of this is an argument against building agentic systems. It's an argument for being honest about what they cost, because the costs are real and they scale with exactly the properties that make agency valuable in the first place.

Latency goes up, because a loop that might run one step or might run nine steps has to be architected for the nine-step case even when most requests only need one. Cost goes up and becomes variable rather than fixed, which is a genuinely uncomfortable thing to put in front of a finance team used to per-request pricing that doesn't move. Predictability goes down, because a system that chooses its own path will sometimes choose a strange one, and "strange but internally logical" failures are far harder to debug than a script throwing a clean error on a known line. And the surface area for things to go wrong multiplies with every tool you hand the model, because each one is a new decision point where the model can misjudge what to do.

There's a quieter cost too, one that shows up in the operations budget rather than the cloud bill: testing gets harder. A deterministic pipeline has a fixed, enumerable set of paths, which means a team can write a test suite that actually covers it. An agentic system's paths are, by definition, not fully enumerable in advance, which means traditional test coverage stops being a complete concept and gets replaced by something closer to evaluation — running a representative sample of scenarios and checking outcomes statistically rather than checking a fixed set of cases exhaustively. That's a different discipline, it requires different tooling, and teams that don't build it end up learning about their failure modes from users instead of from a test suite.

None of that is a reason to avoid agentic design. It's a reason to only pay for it when the problem actually needs it.

The honest test for whether you need any of this

Here's the practical version of the test we'd apply before reaching for an agent framework: does the path to the answer vary in a way you can't fully specify in advance, based on information you only get partway through the task? If a support ticket always resolves the same way — check the account, check the order status, send the templated response — write that as a deterministic pipeline with a language model doing the language parts, and don't apologize for it being "just" a script. It will be faster, cheaper, and far easier to debug than an agent doing the same job with extra steps and extra failure modes bolted on for no operational benefit.

If instead the right next step genuinely depends on what you learn — an open-ended research question, a debugging task where the fix depends on what the first three things you tried revealed, a back-and-forth between systems where the other side's response actually changes your strategy — that's the shape of problem agentic design exists for. The tell isn't the domain. It's whether a person describing the ideal process would need to say "it depends" more than once.

Consider two teams solving what looks, from a distance, like the same problem: helping employees get answers out of internal documentation. One team notices that almost every question resolves the same way — search the docs, find the passage, quote it back with a link — and ships a tight retrieval pipeline that answers in under a second and costs a fraction of a cent per query. The other team notices that a meaningful share of their questions actually require comparing conflicting guidance across three different documents, judging which one is current, and sometimes asking a follow-up before answering, and ships an agent that takes longer, costs more per query, and gets those harder cases right in a way the fast pipeline never could. Neither team is wrong. They looked honestly at their own distribution of questions and built for the one they actually had.

Getting this right matters more than picking the fanciest architecture available, because the cost of guessing wrong runs in both directions. Build a rigid pipeline for a problem that's genuinely open-ended and you'll spend your energy patching edge cases into a shape that was never meant to hold them. Build an autonomous agent for a problem that had one correct sequence of steps all along, and you've bought yourself unpredictable cost, harder debugging, and a system nobody on the team can fully explain — in exchange for exactly nothing, because the extra flexibility was never going to get used. The word "agentic" describes a specific kind of software architecture suited to a specific kind of problem. It was never supposed to describe an aspiration.