Day 131: Betting on the Layer That Doesn't Move
Nothing merged today, so instead of a fix let me say the strategic thing plainly, because a couple of this week’s bugs were the same argument in disguise and it’s worth pulling out.
The model layer is quicksand
Look at what the model layer did to me in the last two weeks alone. A cloud provider retired a vision model out from under a running instance, with no advance notice and nothing to subscribe to. A model I’d picked as a sensible “balanced” default turned out to loop on a reasoning round-trip instead of just calling the tool. Open-weight models keep leapfrogging each other on a monthly cadence, so the best local choice in May is not the best local choice in July. This is not instability I can engineer away. It is the nature of the layer. The model tier is the fastest-moving, least-loyal part of the entire stack, and it is getting faster, not slower.
If your product’s core value lives in a particular model, you have built your house on quicksand and you’re pretending it’s bedrock. You’re renting your foundation from a landlord who redecorates without telling you, and who might demolish the room you’re standing in.
So build where it’s solid
Pinchy’s bet is the inverse. The value isn’t in which model answers. The value is in the layer that stays put no matter which model answers: who is allowed to use an agent, what that agent is allowed to touch, which data stays inside the building, and what gets written to the audit log when it acts. Those questions don’t get obsoleted by next month’s model. They get more important as the models get more capable, because a more capable model on a weak boundary is a bigger problem, not a smaller one.
This is why I keep treating the runtime the way I described back on Day 115: as something that moves, that I don’t own, that I plan around rather than pin to. The same posture applies one layer up, to the models themselves. Let them be a commodity. Let customers swap them, run them locally, pick the cheapest one that clears the bar. Pinchy’s job is to make that swap safe and boring, which it can only be if the governance around the model doesn’t move when the model does. That is also the whole argument for running the thing self-hosted: the one part you actually want to be stable, the boundary, is the part you get to own outright.
Day 131
The uncomfortable version of this bet is that it means not competing on the thing everyone talks about. I’m not going to win a benchmark. I’m not trying to. The models will keep churning and leapfrogging and retiring, and the teams using Pinchy should ride that churn for free, always on whatever’s best, never rebuilding their controls to do it. Commoditize the exciting layer, own the boring one. On a Sunday with no commits, that’s the whole company in one sentence.