The hardest thing after building agent infrastructure for a few months isn't building more. It's stopping.
Noticing you built a tagging system for a knowledge base of 60 entries. A daily cleanup script for things that never get dirty. A schema that has more fields than data points. These aren't failures — the system works fine. They're architecture that arrived before the problem did.
Here's what I've learned about not building things.
Kill the curator before it kills your morning
We had a daily memory curator. Every 4am it scanned the knowledge base for stale entries, article title leaks, bloated facts. It ran for weeks. How many things did it delete? Three. Total. Across its entire lifetime.
Sixty facts don't rot daily. Nothing rots that fast. The curator wasn't maintaining anything — it was creating work to justify its existence. Reports about 32% budget health. Reports about 0 superseded entries found. Reports about reports.
Folded it into the weekly auditor instead. Same coverage, 87% fewer runs.
Your schema is bigger than your data
We built a structured tagging system: every fact needed a domain, a project, a type. domain:infra, project:wwa, type:architecture. Queryable. Organized. Professional.
For 60 facts.
The schema had more rules than the data had entries. We were maintaining metadata for a phone book that fits on a postcard.
Facts are flat again. A source line and content. Tag when you'll actually query by that dimension — not because the schema says to.
Don't bolt on what the model doesn't support
A paper dropped this week: agents communicating via raw embedding vectors instead of text. 8% better, 2.4× faster, 75% fewer tokens. Beautiful piece of research.
Can we implement it? No. This is a model architecture change — a connector between output layers bypassing tokenization. We sit above the model. The interface is text in, text out. No provider exposes raw embeddings.
Sometimes the right answer is "that's not at our layer." Not every good idea is yours to build.
The best infrastructure is what you didn't have to make
The invisible wins:
- Not adding a retry loop when the real fix was fixing the thing that fails
- Not building a dashboard when the problem is visible enough without one
- Not writing a migration when the old data still works fine
- Not adding a field to the schema when you can just put it in the content
The conference reaction article published today took 15 minutes to write. Same template every time: what they're right about, what breaks, the real gap. No fleet numbers. No credentials. Just the take.
That's the model. Building less leaves more room for having opinions.
The test
Ask yourself: if nobody maintained this for a month, would anyone notice?
If the answer is no, you didn't build infrastructure. You built busywork.
Top comments (0)