Academy

What "agentic" actually means

The word "agentic" is now on everything — chatbots, if-statements, RAG pipelines. Before you can evaluate any of it, you need the distinction.

The Felesh team 5 min

You open a repository or a vendor’s documentation page. A Python script with a simple while loop is pitched as an “agentic workflow.” A standard Retrieval-Augmented Generation pipeline that searches a vector database is marketed as an “agentic system.” A customer service chatbot executing a hardcoded decision tree is sold as an “autonomous agent.”

The industry has taken a specific architectural concept and stretched it until it covers anything containing an LLM call. When a term means everything, it describes nothing. To evaluate what you are actually deploying, buying, or building, the distinction must be precise.

There is a structural difference between a model generating text and a system operating autonomously. Distinguishing between these patterns requires looking at who — or what — owns the control flow.

Four systems, one question: who decides the next stepA plain LLM call takes text in, returns text out and stops. A workflow runs a switch on a ticket category that a human wrote in advance. An agent loops through perceive, reason and act, and the model decides each turn. An agentic system is two or more agents that pass state to each other by handoff.what runswho decides what happens nextPlain LLM calltext in, text out: summarise a ticketnobody: it stopsWorkflowswitch: billing → queuethe human, in advanceAgentperceive, reason, actthe model, each turnAgentic systemtwo agents pass state alongthe agents, by handoff
Four systems differ in one place: who decides what happens next. In a workflow it is the human; in an agent, the model.

The precise distinctions

Plain LLM calls. The baseline. A stateless function execution. Input text goes in, output text comes out. There is no loop, no memory between executions, and no ability to take action. It is a single-shot transformation, like passing a payload to a summarisation endpoint. The model does exactly what is requested and terminates.

Workflows. This is where the confusion usually begins. In a workflow, a human engineer predefines the execution path. The order of operations, the branching logic, and the available tools are hardcoded in advance.

The LLM is used as a sophisticated functional component within that path — perhaps to categorise an incoming ticket, extract entities from a document, or generate text to slot into predefined steps. The model executes tasks, but it does not decide what happens next. The control flow remains entirely human-authored. If an API call fails, the script handles the error according to human-written fallback logic. The LLM acts as a reasoning engine, but strictly within the boundaries of a switch statement.

A fixed path around one model callTicket #3184 says “charged twice”. The LLM classifier labels it billing. A switch written in advance sends billing to the billing queue. The classifier call times out after 30 seconds; the fallback, also written in advance, retries once and then sends the ticket to queue C.one ticket, one fixed pathticket #3184“charged twice”modelone labelbillingswitchfixed in codebilling → queuetimeout after 30 sfallback: retry once, then queue C
The model only labels the ticket; the switch and its fallback were written before the first ticket arrived.

Agents. An agent operates on a fundamentally different control flow. Instead of following a predetermined path, an agent executes a loop: perceive, reason, act.

It is given a goal, a set of tools, and an environment. It observes the current state, decides which tool to use, evaluates the result of that action, and decides its next step. The crucial nuance is ownership of a scope. An agent is not executing a single one-shot task; it is managing a domain end-to-end.

If an agent attempts to query a database and receives a schema error, it reads the error, infers the correct schema, adjusts its query, and tries again. It decides what to do next based on what it just observed. The control flow is dynamically determined by the model in real time.

One agent run: an error, a correction, a resultFive turns in order. Act: the agent runs SELECT cust_id FROM orders. Observe: the database answers error, no such column cust_id, drawn in rust. Reason: the column is customer_id. Act: it runs SELECT customer_id FROM orders. Observe: 412 rows returned, marked ok. A wire runs from the last turn back to the first, so the loop repeats until the goal is met.one run, five turnsactSELECT cust_id FROM ordersobserveerror: no such column cust_idreasonthe column is customer_idactSELECT customer_id FROM ordersobserve412 rows returned
The agent reads the error, infers the right column and runs the query again: each next action comes from what it just saw.

Agentic systems. This is the structural layer above the individual agent. An agentic system involves two or more agents coordinating to resolve a larger objective. Each agent owns a distinct scope. One agent might specialise in navigating internal documentation and retrieving technical specifications, while a second agent evaluates those specifications against a customer’s requested architecture. They pass state, context, and results between them.

Two agents, one handoff and a verdict backAgent A owns the documents and holds the limit of 600 per minute. It passes that state to agent B, which owns the request for 1,000 per minute and finds it over the limit. The verdict travels back to agent A, which flags the request for review. Each agent keeps its own scope.one goal, two scopesagent Aowns: the documentslimit: 600/minverdict: flag itagent Bowns: the requestasks: 1,000/minover limit: flag
Agent A passes its finding to agent B, which checks it against the request and sends back a verdict; each keeps its own scope.

Framing the terminology

The boundary between these definitions is actively being mapped by practitioners. Anthropic’s “Building Effective Agents” draws this line clearly, distinguishing between strictly orchestrated workflows and autonomous agents based entirely on who controls the routing and next-step logic. For engineering teams looking at the broader structural patterns, Biswas and Talukdar’s Building Agentic AI Systems offers a practical look at how multi-agent coordination is designed and managed in production.

When a software vendor says “agentic,” the immediate engineering question should be: which of these four is it?

Most features marketed as “agentic” are actually LLM-augmented workflows. That is not a technical failure. Workflows are predictable, highly useful, and often exactly what a production use case requires when the cost of a hallucinated action is high.

The failure is lexical. The word is doing marketing work, inflating a standard software sequence into something it is not. Knowing the difference lets you look past the product marketing and evaluate the actual control flow running underneath.

Once the term is pinned down, the next question is how an agent actually thinks inside that loop. That is where the architecture guide picks up.

How an AI agent thinks