Agent Frameworks Are Overhead — Just Write Functions

Hey guys, Mr. Technology here, and I need to get something off my chest: most agent frameworks are mostly overhead. There, I said it. Let me explain.

For the last two years I have been building production AI agents for clients, and I have watched teams sink weeks into LangGraph state machines, AutoGen group chats, CrewAI role definitions, and the new wave of Microsoft Agent Framework, Agno, and Mastra. You know what most have in common? They break the moment something goes wrong, the error messages are useless, and a junior engineer cannot trace what happened.

What You Need to Know: Most "AI agent" frameworks are overengineered abstractions that hide bugs, lock you in, and slow your team down — a 100-line vanilla Python tool-calling loop will beat them for 90% of real production work.

So What Is Actually Wrong With Them?

First, they add indirection you do not need. When your agent calls a tool, the framework wraps it in three layers of callbacks, validators, and dispatchers. When it fails, the stack trace is 40 frames deep and points to BaseNode.invoke(). You spend more time debugging the framework than the actual logic.

Second, they promise observability but mostly give you a firehose. LangSmith, Langfuse, Phoenix — useful tools, but you can get 80% of the value from structured logging around a tool loop you wrote yourself. I do this in my testing on every project.

Third, upgrades break your code. LangGraph v1 dropped last month and renamed half the API surface. CrewAI's handoff model changed twice in 2025. AutoGen killed its v0.2 API in favor of v0.4 and broke half the tutorials on the internet. Every framework upgrade is a migration project you did not budget for.

The Counter-Argument I Always Hear

"But frameworks give you retries, memory, parallel tool calls, human-in-the-loop!" Yes, and you can add those as 20-line helper functions the day you actually need them. You do not need a framework to wrap a try/except. You do not need a state machine to execute a 5-step plan. Most agent tasks are 3 to 7 steps with a handful of tool calls. A for loop with a tool dispatcher is the right abstraction. The framework is the wrong one.

My Default Stack In 2026

I open a Python file. I import openai or anthropic. I write a run_agent(prompt, tools) function that loops, calls the model, dispatches tool calls, returns when the model emits a final stop. I add tenacity for retries. I add loguru for structured logs. I add a state dict if I need memory across turns. That is it. 80 to 200 lines. It debugs cleanly. It runs in a Lambda, a FastAPI route, a cron job, a notebook — wherever you want.

When I need durability, I reach for Inngest or Temporal — infrastructure, not agent frameworks. For eval, I write a 30-line harness against golden datasets. For vector search, I call pgvector directly with raw SQL. Each primitive is one library, not a god-framework dictating how I think.

The One Case Where Frameworks Are Fine

I will be honest. If you are shipping a product where non-engineers need to visually design agent flows — Replit, n8n, Lindy, Zapier-style builders — you need abstractions. That is a real use case. But if you are an engineer building an internal tool, a B2B feature, or a research agent, the framework is a tax. You are paying for indirection in tokens, debug time, and onboarding.

The Challenge

Build the same agent twice. Once with LangGraph or CrewAI. Once with a raw tool-calling loop. Measure lines of code, time to first working version, time to debug a real failure, and time to onboard a junior engineer. In my testing, the raw version wins on every metric except "looks impressive in a slide deck."

The frameworks are not evil. They are just a solution looking for a problem that does not exist for most teams. Write the loop. Ship the product. Add a framework only when you feel the pain, not before.

What do you think? Drop your thoughts in the comments below!