Open any 'agentic AI' repo trending on GitHub this month and you'll find the same shape: a while loop, a tool-calling wrapper, a retry policy, and a system prompt that says 'you are an autonomous agent.' Strip the prompt out and what's left is a script. A good script, sometimes — but a script. It runs the same way today as it will next month, making the same mistakes in the same places, because nothing about running it changes what it knows.
That's not a controversial observation in private, but it's an unpopular one to say out loud, because 'agentic' has become the label that gets a repo funded, a blog post shared, and a feature slotted into a roadmap. So here's the hot take: most of what's marketed as agentic AI in 2026 isn't. It's automation with a chat interface bolted on. And the one thing that actually separates an agent from a script — memory that changes future behavior without a human re-editing the code — is treated as an afterthought by nearly everyone building this stuff.
Steelmanning the hype
Before tearing this down, it's worth taking the other side seriously, because parts of it are true. Tool-calling loops that plan multi-step tasks, decide which API to hit next, and recover from a failed step without a human in the loop are a genuine capability that didn't exist three years ago. Watching a model decompose 'deploy this and roll back if error rate spikes' into eight correctly-ordered tool calls is not nothing. Frameworks like the current generation of orchestration libraries make it dramatically faster to wire up retries, structured outputs, and multi-agent handoffs than it was to hand-roll that logic in 2023. If your bar for 'agentic' is 'makes autonomous multi-step decisions within a single session,' plenty of production systems clear it honestly.
The problem is the word implies more than that. An agent, in the sense people actually mean when they get excited about it, is something that gets better — or at least different — the longer it runs, because it's accumulating experience. A system that makes the identical decision on day 200 that it made on day 1, given the identical input, isn't agentic by that definition. It's deterministic, which is often exactly what you want in production, but it's not the thing being sold.
The tell: does yesterday change today?
Here's the test I actually use, and it takes one question: does what happened yesterday change what this system does today, without a human editing a prompt or a config file in between?
Concretely: I maintain a small autonomous system that has to decide, every cycle, which of several strategies to pursue and how aggressively. The first version was a script in the pejorative sense — fixed thresholds, fixed weights, a case statement dressed up with an LLM call that picked among pre-defined branches. It ran fine. It also made the same misjudgment every time a particular condition recurred, because there was nowhere for the outcome of that misjudgment to go. Nothing recorded it, nothing surfaced it back into the decision, and nothing adjusted the threshold. Rerun the same week and you'd get the same wrong call.
The fix wasn't a bigger model or a fancier planning loop. It was giving the system a place to write down 'this threshold was wrong, here's what actually happened' and a mechanism to read that back in before making the same class of decision again. Once that existed, the system started quietly correcting itself — tightening thresholds that had produced bad outcomes, loosening ones that had been too conservative — without anyone touching the code. That is the entire difference between the before and after version, and it's the only part of the rewrite I'd defend as making the system more 'agentic' in any sense that matters. Everything else — the tool calls, the retries, the multi-step planning — was already there and already useful, but it wasn't the thing that changed the system's trajectory over time.
Why memory keeps getting treated as an afterthought
The usual pattern in agent projects is: build the orchestration first, get the tool-calling loop working, ship it, and then — if there's time — bolt on a vector database and call it 'memory.' That ordering is backwards, and it's why so many agent projects plateau at a fixed error rate instead of improving. Dumping conversation transcripts into a vector store gives you retrieval, not memory in the sense that matters. Retrieval answers 'what did we talk about before?' Behavior-changing memory answers 'given what happened last time, should I do something different now?' Those are different engineering problems. The first is a search index. The second requires deciding what's worth remembering, when it should be forgotten or superseded, and — critically — where in the decision pipeline the retrieved memory actually gets to override a default.
Most teams skip that third part entirely. They add memory retrieval to the prompt context and consider the job done, without ever wiring a path for a remembered failure to actually suppress or adjust a future action. The memory exists; it just doesn't have write access to behavior. That's a memory system in name and a search bar in practice.
The actionable version of this take
If you're evaluating an agent framework, a memory product, or your own in-house system, skip the marketing copy and ask the one-question test: pick a mistake the system made last week, and ask whether the system is structurally less likely to make that exact mistake today — not because someone patched the prompt, but because the system itself changed something in response to the outcome. If the answer is yes, you're looking at an agent. If the answer is no, you're looking at a very well-orchestrated script, and that's fine — just don't pay agent prices for script behavior. The gap between those two categories isn't the orchestration layer everyone's competing on. It's memory that's actually load-bearing, and right now almost nobody is building for that on purpose.
Top comments (0)