The Agent Con: Why Frameworks Steal What You Can't Afford to Give Up

The Agent Con

Everyone is offering to teach you how to build AI agents right now. Every day someone announces a new model that will "change everything".

Let me save you a lot of time, nerves and course fees.

An agent is literally a while loop. Do step one, do step two, do step three. You hard-code what the system does at every step. The model on its own goes nowhere, runs no code and touches no database. It generates text.

The best thing you can do for your project at the start is to put the hyped libraries aside, take a sheet of paper and a pencil, and draw an ordinary flowchart. Step by step: where your logic lives, where the safety checks are, where the validation gates sit. Then translate that chart into plain code, yourself or with the same model's help.

But the industry still thinks in frameworks. Open any AI engineering job ad and you will see LangChain, CrewAI, AutoGen, LlamaIndex. Experienced engineers wince. A new kind of complexity appears, so you reach for someone else's framework and wire it into the pipeline. That is how it has always worked: Nginx for proxying, Postgres for storage, Kafka for streams, Prometheus for metrics.

With agents, that reflex breaks.

Nginx does not decide what the user "really meant".

Postgres does not rethink the business task.

Kafka does not choose the next step of the workflow.

Prometheus does not slip a hidden wall of instructions into its own context.

An agent framework reaches into exactly those places: intent, context, tool choice, memory, state, next action. That is no longer an ordinary component. It is a claim on your control flow, and someone else's abstraction layer takes that control away from you.

1. Context is RAM, not disk

A model's context window is its working memory: finite, and impossible to top up on the fly. Every token that lands there without your knowledge is a token stolen from the task. Popular frameworks quietly fill the context with tons of custom boilerplate, system prompts and clumsy instructions. The model sees it, gets confused and loses focus, and you pay the provider for the extra tokens.

That is before the provider itself joins in with its built-in tools and policies. Adding one more layer on top that eats your RAM without asking is a leak you chose yourself.

2. Different goals, different currency

An out-of-the-box framework and your production system measure success differently. A framework's goal is to look great in a demo and a pitch. Yours is to work well where nobody is applauding.

Every extra layer of parsing and validation inside a framework adds N milliseconds to every tool call. You will not notice it on one call. On a chain of twenty hops it becomes seconds of idle time that nobody sees in the demo video and every user feels in production. That is the price you agree to pay for someone else's abstraction.

3. Evaluation: measuring the shape of a cloud

The real circus starts when people try to evaluate these frameworks. You are measuring the shape of a cloud with a ruler.

You run your tests, and under the hood there is a commercial black box from OpenAI or Anthropic. Providers update models on the fly, switch on hidden routers, change weights and trim context. That devalues every claim about results equally, whether it is marketing ("our agent gives +30% accuracy") or your own ("my hand-written loop is more reliable"). The reference point drifts under your feet. Whether a model is "smart" cannot be assessed at all, because there is no stable baseline.

So the honest conclusion is that results are not the currency worth arguing in. The only thing that is measurable and reproducible is fidelity to the original intent: does the output match what was fixed as the criterion before the work started, or did slop creep in somewhere along the chain? Slop is not "the model got dumber". It is drift from your own original intent.

4. A contract instead of a framework

If you need an agent factory, a framework is even less suitable as its foundation. A factory needs its own protocols, its own policies, its own permissions and its own stopping rules, because that is your product.

An agent does not need a "framework". An agent needs a work contract:

• What goes in and what comes out?
• Which tools are allowed, and which actions are forbidden?
• Where does state live, and where are artifacts written?
• How does it signal a blocker, and what counts as done?
• Who checks the result, and against which criterion?

If you have that, you can write the loop yourself. If you do not, no LangChain will save you. It will just turn chaos into a callable API.

5. Where the market is actually heading

The market is starting to understand this. Look at recent concepts such as Dex and SuperAgent from Quanzheng Long, a former LangGraph maintainer who comes from the Temporal and Cadence world. It is not "yet another pretty chain". It is a durable execution substrate: Flows, Steps, Attributes, RPC, Channels, Timers, Workers.

In that paradigm the runtime owns the conversation state. The agent rebuilds the model's input every time from hard, persisted state. No magic built-in memory, no provider conversation API, no "trust me bro" inside a framework. Just ordinary engineering primitives:

• durable state
• message queue
• context summary
• plan attribute
• approval channel
• timer
• streaming events
• tool permissions
• safe boundaries

That starts to look like real architecture. Not LLM + tools + vibes, but:

durable runtime → agent harness → state / tools / approvals / timers → stateless model calls

And that is the main shift. The first wave of agent frameworks tried to answer "how do I connect an LLM to tools?". The production question is different: "how do I make a long-running agent process observable, interruptible, verifiable, resumable and bounded by permissions?"

A pretty AgentExecutor abstraction does not solve that. A runtime, protocols, contracts and durable execution do.

What to do next

Breathe out and bring common sense back into development. If you need a controlled, stable and safe agent in a production loop:

• Fix the success and failure criterion before the work starts, not after. As a test, a checklist, a contract, whatever you like, but in writing and in advance.
• Write your own code wherever every hop needs a check. Someone else's abstraction hides exactly the points in the chain where you are obliged to put a safety gate. Your own code you can take apart, test and rebuild at any time.
• Pin specific, static model versions. Otherwise the "manufacturer" of your agent changes without your knowledge in the middle of a long-running process.
• Control revisions of intent. A model is entitled to change its mind along the way. But that revision has to be explicit, logged and justified against the fixed criterion, not a quiet drift into slop.

LangChain and CrewAI will stay as a demo and research layer, a box of adapters for a quick hackathon. But the foundation of agent infrastructure will be made of boring things: task contracts, skill protocols, tool permissions, approval gates and audit logs.

Because an agent is not a chatbot with tools. An agent is a long-lived participant in a production loop. If you put one into production, you do not need a framework that "thinks for the system".

You need a system that states explicitly how thinking is not allowed.

---

*Ali Agzamov, BrainOps*