Agentic Systems in Plain English

Agentic is the most abused word in software right now. Vendors bolt it onto chatbots. Engineers wince when they hear it. Operators get pitched agentic AI the way they were pitched blockchain in 2018, and most of them cannot get a straight answer to the only question that matters: what does this thing actually do when nobody is watching it? I build these systems for a living. Vandoko MIP runs on them, and Tool-Bag exists to govern them. So this is the plain-English version, written for the person who signs the checks and the engineer reading over their shoulder: what an agent is, what it is not, and when one will earn its keep versus quietly lose to a cron job.

An agent is a loop, not a personality

Strip away the marketing and an agent is three things wired into a loop: a goal, a set of tools, and memory. The whole idea fits in six lines of pseudocode:

while the goal is unmet and the budget holds:
    look at the current state
    decide the next action
    call a tool
    read what came back
    write what mattered to memory

The model is not the agent. The model is the decision step inside the loop. The loop is what makes it an agent: it acts, observes the result of its own action, and decides again with that result in hand. Memory that persists across iterations. Tools that touch the real world. A goal it can check itself against. A budget that stops it. Remove any one of those and you are looking at something else wearing the costume.

This framing matters because every property people want or fear in agents comes from the loop, not the model. Autonomy is the loop running without a human between iterations. Drift is the loop making a bad call and then compounding it. Runaway cost is a loop without a budget. When you evaluate an agent, you are evaluating loop design, and most of the people selling agentic anything cannot describe their loop. Ask anyway. The silence is informative.

What an agent is not

An agent is not a chatbot with a new name. If a system takes one input, makes one model call, and returns one output, it is an API call with good marketing. That is not an insult. Single calls are cheap, fast, and predictable, and they are the right answer for most jobs. But nothing loops, nothing decides, and nothing acts on the world. Renaming it does not change what it is.

A workflow is not an agent either, and this is the distinction that costs real money when it gets blurred. A workflow is a fixed sequence a human designed in advance: pull the data, transform it, summarize it, send it. The path is known before the run starts, which means the failure modes are known too. An agent chooses its own path at runtime based on what it finds along the way. That flexibility is the entire value and the entire risk, and you pay for it three times: in tokens, in latency, and in the engineering it takes to contain it. Calling a workflow an agent does not make it smarter. It just makes the invoice bigger.

When the cron job wins

My honest decision order is the opposite of every vendor pitch I have sat through, and I have sat through plenty.

If the task is identical every run, schedule it. A cron job running a known script is cheaper, faster, and more reliable than any agent, and when it breaks, it breaks loudly instead of creatively. Creative failure is the agent specialty. You do not want it anywhere near a task a shell script already handles.

If the task branches in ways you can list, build a workflow. Deterministic steps, with model calls inside the steps where judgment is genuinely needed. You get the language understanding without surrendering control of the path. Most of what gets sold as agentic today is this, and that is fine, because most of the time it is the right call.

Reach for an agent only when the path cannot be known in advance, when the next step genuinely depends on what the last step uncovered, and when supervising a loop costs less than paying a person to do the navigating. That is a narrower set of problems than the market wants you to believe. It is also a real set, and when you hit one, nothing else works as well.

Two systems, two different answers

Vandoko MIP, my market intelligence platform now in live beta at vandoko.ai, is a deliberate mix, and the mix is the lesson. It combines the Scrapey-Do engine for collection, On-the-Map for geography, and Vandoko-AI for analysis. Collection belongs to schedules, because gathering market data is work you want boring, repeatable, and timestamped. Judgment belongs to loops, because what does this mean for this market and what is worth looking at next is not a question a fixed script can answer before the run starts. The boring parts stay boring on purpose. That is not a compromise. That is the design.

Tool-Bag is the lived example from the governance side. It is my multi-model distribution and governance layer: 14 plugins, 108 skills, a Docker MCP Gateway, and 12 CI workflows orchestrating Claude, Codex, and Gemini. I built it because the moment loops touch real systems, the interesting question stops being how smart the model is and becomes who said this loop could touch that. An agent without governance is an intern with root access. Tool-Bag exists so the answer to who approved this is never a shrug.

It is also built for a specific person: the expert who has the context and knows exactly what they need but does not code. That person was always the point. The agent supplies the hands. The expert supplies the judgment. The governance layer keeps both honest.

Five questions that end the pitch

If you sign the checks, you do not need to read the code. You need five questions.

First: what is the loop? Make them walk you through one full iteration, state to decision to action to result. If the explanation collapses into a demo, there is no loop.

Second: what tools can it call, and what is it blocked from calling? The blocked list is the revealing one. A vendor who never thought about it has never thought about your downside.

Third: what stops it? A budget, a step limit, a confidence floor, a human gate. Something has to be the brake, and the seller should name it without checking their notes.

Fourth: where does memory live, and who can read it? An agent that remembers things about your business is a data store, with every obligation that implies.

Fifth: why is this not a cron job? If they cannot answer that one cleanly, you have your answer, and it is the cheaper one.

See the loops running

None of this is theoretical for me. The loop, the workflow, and the cron job all run inside systems I own, and the scars informed every opinion above. The record of what they produce is at /work. If you are weighing agent versus workflow versus scheduler for a real problem in your shop, that is exactly the conversation I like having. Bring the problem, not the buzzword.