The right level of abstraction

A few months ago I set out to build a set of AI agents to handle the operational parts of web projects. Pre-build research, mockups, site audits, goal setting and tracking. Work I’ve done by hand for years and know well enough to describe from memory.

I reached for LangChain, because that’s what you’re supposed to reach for. The frameworks, the orchestration layers, the infrastructure that’s meant to make this kind of thing serious. I spent the time, wired it together, and got it working.

Then I looked at what I’d built and realized the framework wasn’t the part that mattered.

What mattered was the process

Years of knowing what a good site audit actually checks for, what pre-build research needs to surface, how to set goals a client will still care about in six months. That knowledge was the asset. Once I could put it on paper, the agents got good. The LangChain layer was sitting between me and a problem I’d already solved in my head, charging interest the whole time.

So I tore it out and rebuilt the same thing with plain context engineering and clear documentation. Same output, often better. Cheaper. Faster to change when I wanted to change something. And maintainable by one person, which matters when you are the one person.

Complexity charges you twice

This is the part I think gets missed, especially for small businesses. Most AI tooling is built for organizations with a team to absorb the complexity. A small operator inherits the complexity without the team. The heavy framework that’s merely inefficient at a company with ten engineers is a real liability when it’s just you, because every layer you add is a layer you alone have to understand, debug, and carry.

It’s a barrier to entry that stops people from starting at all, because they read that they need a stack of infrastructure to do anything useful and decide it’s over their head. Then for the ones who push through, it’s technical debt that punishes them for having started. Most of the time the problem underneath all of it has a simpler answer that nobody’s selling, because there’s no product in telling someone to write things down clearly.

The oldest discipline finally holds

Here’s the part that took me longer to see. Writing your process down isn’t a new idea. Businesses have always known they should document what they do and build it into something repeatable. The reason it rarely stuck is that the documentation was inert. You wrote the process, filed it, and then relied on a person to remember it existed and remember to follow it. That’s the step that always broke.

That step is gone now. The documentation is what runs. You don’t have to remember the workflow, and you don’t even have to remember to do it. Done right, the thing reads the context and executes. The oldest discipline in business, systematize what you do well, finally has a way to hold.

Which is roughly where I’ve landed on all of it. The fundamentals didn’t change. A new model drops every week and the hype moves faster than anyone can act on, but underneath the noise the work is the same as it ever was. Know your process. Write it down. Build at the lowest level that actually solves the problem. For a small business that level is almost always lower than you’re being told, and the discipline to stop building is closer to an edge than a limitation.