Rent the model, own the loop: the build-versus-buy line for AI
A new AI framework launches roughly every week, each one promising to handle the agent loop, the memory, and the tools so you can focus on your product. The pull to adopt one on day one is real. Building feels like reinventing wheels. But the framework you adopt before you understand your problem is the thing you'll be fighting a year from now.
Start by separating the layers, because build-versus-buy has a different answer for each.
The model you rent. Nobody reading this is training a foundation model, and you shouldn't want to. That's the commodity, the part where the providers compete and you pick the best one for the job and abstract it so you can swap it. Buying here is the premise, not really a decision.
The harness you own. The loop that calls the model, manages context, and runs the tools, that's your product's actual logic, and it's smaller than people think. The core loop is about fifty lines. You own it because the harness is where your differentiation and control live. A framework that owns it for you hides exactly the parts, context management, tool design, the verification oracle, that you most need to see and shape. You'll debug those parts eventually. Far better to debug code you wrote than abstractions you adopted.
The infrastructure in between is where build-versus-buy is a genuine question. Observability tooling, eval harnesses, a vector store, the gateway your calls route through, these are real decisions, and the answer is often "buy or use an open tool," because reinventing a tracing system or an embedding index is the distraction, not the product. You build the thin layer that is uniquely yours and you buy the plumbing that everyone needs.
The framework trap
Heavy agent frameworks fit in eventually, just later than most teams reach for them. Adopting one before you understand your problem means you inherit its opinions about how agents should work before you've formed your own, and you take on its lock-in as the price of a head start you didn't need. Frameworks are genuinely valuable once you've hit the specific wall they're built to solve, multi-agent orchestration at real complexity, a tracing and retry story you don't want to build, a large tool ecosystem you'd otherwise assemble by hand. The signal to adopt one is "I keep building the thing this framework provides and it's slowing me down," not "I'm starting an agent project and frameworks exist."
Call this anti-premature-framework, not anti-framework in general. The same instinct that says don't stand up a vector database for ten thousand vectors says don't adopt a sixty-abstraction agent platform to run a loop you could have written and understood in an afternoon.
Lock-in is credit you're borrowing against
Every dependency is credit today and lock-in tomorrow, and the trade is fine as long as you make it deliberately. The thin-harness philosophy is just being deliberate: own a small core that calls the model through an abstraction, keep the providers swappable so a deprecation or a withdrawal is a config change rather than a rewrite, and add heavy external machinery only when a real wall forces it. The payoff is portability. When the model you built on gets retired, or a provider vanishes, or the framework you bet on stalls, the thin harness lets you move, and the thick platform you adopted early is the anchor you now have to cut loose first.
The whole argument comes down to one line: own the thin layer that is your product, rent the commodity underneath, and adopt the heavy machinery in the middle only when you've earned the need. The model is a commodity, getting cheaper and more interchangeable by the month. The harness is yours, small to build and dangerous to not understand. And the framework is a tool you grow into, not a foundation you start on. It's the same ladder that governs every other decision on this blog, applied to the biggest architectural choice you'll make: what to build, and what to let someone else build for you.