Why I stopped building agent tools
I have a folder full of agent tools I’m quietly proud of and almost never run. A calendar agent. A “read my inbox and draft replies” agent. A research agent that fans out searches and writes a memo. A little army of MCP servers wrapping APIs I use. Each one felt, at the moment I built it, like leverage.
I don’t build them much anymore. Not because they didn’t work — most of them worked fine — but because I kept noticing that the thing I built was the least durable part of the system. This is me trying to explain that honestly: where the cost actually lands, why the effort is mostly glue, and the uncomfortable part — the model underneath improves faster than my code can stay relevant.
Everyone is building the same agent
Open any “I built an agent” post and you’ll find a version of this picture: one model in the middle, wired out to every tool it might ever need.
There’s nothing wrong with this diagram. It’s just that everyone has drawn it. The center node is a foundation model you don’t own. The spokes are integrations against APIs you don’t control. The thing that’s uniquely yours is the wiring — the glue, the prompt, the retry logic, the tool schemas — and it turns out the wiring is the cheapest thing on the canvas to reproduce.
When I’m honest, most of what I shipped was a personalized re-draw of a diagram a million other people were drawing the same week. That’s not a moat. That’s a tutorial everyone finished.
The cost is real, and it keeps moving
The first thing that cooled me on agent tools was watching the unit economics refuse to sit still.
An agent isn’t one model call. It’s a loop: plan, call a tool, read the result, re-plan, call again. A “simple” task fans out into ten or twenty inferences, each dragging the whole transcript along as context. The token bill for one genuinely useful run was routinely 50–100× a single chat message. For a tool I’d run a few times a week, I was maintaining infrastructure to lose money slowly.
The flip side is that the cost floor keeps collapsing under me:
You’d think falling cost is good news for tool-builders, and at the margin it is. But it cuts the other way too: when the expensive, clever scaffolding I wrote to make a weak-but-cheap model behave — the chunking, the routing, the self-consistency tricks — stops being necessary because the next model is both cheaper and smart enough to not need the scaffolding, all that careful work converts straight into dead weight. The cleverness was a tax on the model’s limitations, and the limitations keep getting refunded.
The effort is mostly glue
The part nobody puts in the demo video is the maintenance.
A real agent tool is maybe 10% the interesting idea and 90% the boring scaffolding around it: auth refresh, pagination, rate limits, tool schemas that drift when an API ships a v2, prompt tweaks for the model update that landed on a Tuesday, an eval harness so you notice when a “harmless” prompt change quietly breaks three tasks. None of that is the idea. All of it is the job.
I wasn’t maintaining an agent. I was maintaining a small integration company with one employee and no customers.
And every one of those seams is a place the thing breaks without me touching it. An upstream API changes a field. A model update shifts how it formats tool calls. My code didn’t rot because I wrote it badly; it rotted because everything it depended on moved. For software I run twice a week, that’s a maintenance treadmill I signed up for without reading the terms.
The model is the competitor you didn’t price in
Here’s the realization that actually changed my behaviour.
When you build a tool to patch a model’s weakness, you’re making a bet: this gap will exist long enough to be worth the code. For a long time I assumed those gaps were stable — that “the model can’t reliably do X” was a fact I could build a business of small tools around.
It isn’t. The gap closes, and it closes faster than the build-and-maintain cycle. By the time I’d hardened a tool, written its evals, and made it pleasant to use, a new model release had absorbed the capability natively — usually doing it better than my wrapper, because it learned the behaviour instead of being scripted into it.
The shape of that green line is the whole argument. Your custom tooling is most valuable precisely when the model is worst, and that’s exactly the moment with the shortest shelf life. You’re building scaffolding for a building that’s growing its own floors.
This reframes “keep your code up to date” from a virtue into a liability. Every line I wrote against today’s model is a line I’ll have to reconsider against the next one. Staying current isn’t a one-time port; it’s a standing subscription paid in attention. The faster the models improve — and they’ve improved faster than almost anyone I know predicted — the more that subscription costs, and the less of my original work survives each upgrade.
| Felt like a moat in 2024 | What it became by 2026 |
|---|---|
| A clever prompt-chain that made the model “reason” | One sentence in a system prompt |
| A tool to summarize long documents | Default behaviour, longer context |
| Routing between a cheap and a smart model | The cheap model is now smart |
| A scraper + parser to pull structured data | ”Return JSON matching this schema” |
| A hand-built retry/self-correction loop | Built into the agent runtime |
(Generalized, but every row matches something I actually wrote and later deleted.)
A million all-purpose agents
There’s a strategic version of this too. The market is converging on a single shape — a general assistant that can use tools — and the people best positioned to ship that shape are the labs that make the models and the platforms that own the distribution. They’re shipping the all-purpose agent as the product, with my “spokes” built in.
So if I build the same general agent, I’m competing on the one axis where I’m weakest: I have a worse model, less distribution, and no privileged data, but the same architecture diagram. When ten thousand people and several trillion-dollar companies are all drawing the identical hub-and-spoke, the hub-and-spoke is not where the value is. It’s table stakes that depreciate.
The honest test I started applying: if the next model release would make this tool pointless, it was never the asset — the thing it was a proxy for is.
Research is the leverage, not the wrapper
This is the part that sounds like a platitude until you’ve watched it happen to your own code.
Building a tool answers “how do I get today’s model to do X?” Research answers “what is actually true about how these systems behave, fail, and can be steered?” The first answer expires on the next release. The second compounds. Understanding why an agent loses the thread at long horizons, what makes an eval trustworthy, where models are genuinely unreliable versus just under-prompted — that knowledge survives the model swap that just deleted my wrapper. It’s the thing I carry into the next model instead of rebuilding for it.
I’d rather spend a week understanding a failure mode than a week wrapping an API, because the understanding is still worth something in six months and the wrapper probably isn’t. The leverage was never in being first to glue the model to a calendar. It was in knowing something durable about the model.
What I still build — and what I don’t
This isn’t nihilism, and it isn’t “don’t build.” I build constantly. I just moved up the stack, toward the things the next model release can’t hand me for free.
Concretely, the filter I use now:
- Does it depend on a model gap, or on something I own? A tool that patches a weakness is rented. A tool built on my data, my distribution, or a workflow only I understand is owned. Build the owned kind.
- Will the next release make this better or obsolete? If a smarter model makes my product better — a vertical app, a real workflow, a place with proprietary context — I’m riding the wave. If a smarter model makes my code redundant, I was the wave’s debris. Build the things that get better when the model does.
- Is this glue, or is this judgment? Evals, taste, the specific shape of a domain problem — that’s judgment, and it transfers across models. Auth refresh and pagination is glue, and the platform will eat it.
- Would I run this if it cost me an afternoon a month to maintain? Because it will. If the honest answer is no, I don’t build it — I wait one release and it’s usually a single prompt.
So I still build agents. I just stopped building agent tools as the product — the thin wrappers whose entire value was a gap I was betting would stay open. I let the gaps close on their own, and I spend the saved effort on the parts that don’t depreciate: the data, the taste, the distribution, and a genuine understanding of how these systems actually work.
The wrappers were never the asset. They were a really expensive way to learn that.
← Back to the journal