Starting mid-February, I downloaded an instance of a wildly popular open-source agent framework and dove into 10+ hours of daily development. But I quickly realized something felt off — the framework always gave me this nagging sense that I couldn't fully use my strength.
I wasn't content with simple chat interactions or basic task delegation through WhatsApp or messaging apps. I wanted to push into hard territory — using agents to find logical flaws in a philosophy book I'd written, building an intelligence-gathering framework for financial markets, running deep critiques on investment strategies.
What I found was that even with a freshly reset session, before I'd done anything, the agent's context was already packed with nearly 20K tokens. Most of it was system info the framework forced the agent to read — stuff that had nothing to do with my actual task. The SOUL.md personality mechanism was fun at first, but its effects were all over the place. Eventually I decided it worked more like mysticism than engineering.
Sometimes I needed to do something dead simple — insert a block of text at the bottom of a document. In this framework, I had to set up a skill, have the LLM parse the intent, then call a tool to do it. But as the context bloated, the LLM's attention got diluted by walls of irrelevant text, and accuracy kept dropping. Genuinely helpless feeling.
That's when a question started looping in my head: Why can't I just use a script for this? Why does it have to go through an LLM?
When I finally sat down to fix the context management problem, I found out I needed to touch the framework's guts — not just work within the workspace folder. That's when I discovered this thing had over 1.6 million lines of code. Spent hours just trying to trace how context injection worked. By the time I quit the framework, I still hadn't figured out how to turn off the default SOUL.md loading for the main agent — not because it was impossible, but because I realized I'd rather just switch frameworks than burn another day or two on this.Looked at other frameworks after that. All massive. Just figuring out how they worked ate up huge chunks of time, and any planning you did had to bend around the framework's quirks.
After two or three days of just thinking, I decided: build my own from scratch. Lightweight. Minimal. No more compromising under someone else's architecture. Because the more I thought about it, the more I believed that heavy, complex systems are a massive risk for anyone building on top of them.
Here's what went through my head in the days after walking away:
Nobody Knows Which Agent Collaboration Model Is Right
Most agent frameworks today have a specific collaboration pattern baked in. They hardcode how agents should work together. The problem is: nobody can actually say which collaboration model is best, or which one works in which scenario.
Right now the default is agents chatting like humans — discussing, debating, reaching conclusions in a conversation thread. Makes sense if you think about it in human terms. But maybe one day we'll find out that two agents directly editing documents in each other's context is way more efficient and burns fewer tokens than simulated conversation.
Before that second model gets proven at scale, everyone's going to pick the first one. They'll choose a framework that supports it, do heavy customization, hire a team, start a company, build a business on top of it.
That's domestication.
When that framework runs to hundreds of thousands of lines of code, you're locked in. You didn't choose the tool — the tool's paradigm chose how you think, how you build your team, how you run your business. The day that paradigm gets disproven, it's not just the framework that falls apart. Your team structure and business model might go down with it.
The Heavier the Framework, the Faster It Dies
One trend has been really obvious this past year: code is getting cheap.
Building any specific feature is getting easier fast. You can already see where this goes — if you can think through the mechanism and describe what you want clearly enough, the tool will get built. If that's true, then what agent framework vendors sell is losing value whether they like it or not.
To fight that, they polish harder. More features, more integrations, more bells and whistles. But all that polish makes the framework heavier and the codebase bigger.
Here's the catch though. When you ask Claude Code or any LLM to modify a program, the existing code better not be too big. Otherwise you get bugs. Or you burn through insane amounts of tokens. Or the result has weird logic issues that take hours to track down.
**Frameworks getting more complex vs. LLMs being able to build anything from scratch — that tension is only going to get worse. **At some point, users will be sitting on months of sunk cost and realize they have no choice but to walk away from a framework they've been all-in on.
Not Every Nail Needs the AI Hammer
Once some people buy into AI tools, they treat AI like a hammer and see every problem as a nail.But tons of scenarios can be handled 100% by a simple script. Why are we setting up skills and routing through an LLM to trigger something completely deterministic?
Sometimes I think writing a script that chains agent actions with other programs is just simpler, more reliable, and zero risk. But in a lot of frameworks, even that basic thing is hard to pull off. Maybe doable, but you'd have to modify framework code or write glue.
If an Agent Can't Take Over Its Own Framework, the Framework Is Built Wrong
LLMs keep getting stronger. Maybe one day agents will manage their own frameworks. But here's what I keep coming back to: I don't think an agent can fully take over a framework with hundreds of thousands of lines of increasingly complex code. Most frameworks are actually moving further away from that possibility, not closer.
Now flip it. If the core code is 3,000 lines, and after customization it stays under 8,000 — an agent can absolutely handle that. Read through it once, understand the whole thing. Change a file and the blast radius is predictable. Something breaks, roll it back.
"But what can you do with 8,000 lines?"
Run 5 or 10 instances of the same framework on one machine. Each one handles a specific task domain. They talk to each other through files or a database. As long as each instance runs independently, you can hand 5, 10, even 50 of them to an agent for full management. No single instance needs to be complex.
Why Can't We Just Copy and Paste?
If frameworks need to be agent-managed in the future — or even built from scratch by agents — then deployment can't be as painful as it is today.
Why can't it work like PC games twenty years ago? Copy the folder, done, new instance.
Want to experiment with changes? Copy the original, hack away. Crashes? Delete it. Doesn't work? Delete it. Original is still sitting right there.
Maybe the agent framework we actually need looks more like a block in Minecraft than something as polished as Baldur's Gate 3 or Path of Exile 2.
_ Closing_
Maybe we really have gone too far down the complexity road. We forgot how good simple used to feel.Going back to something close to raw simplicity might let us see things we've been blind to.
Egypt was never as glorious after its glory. Rome was never as great after its greatness. Why? Maybe they accumulated too much information. The agent's context got too long.....
Intelligenism Agent Framework (IAF) — This is the minimal agent framework I built. If you're interested, give it a try. The way I use it: I throw the entire program and its docs straight to Claude Code and let it modify whatever it needs. Each IAF unit typically handles 1-2 specific work scenarios.
Top comments (0)