One more dimension matters for anyone building or buying in this space: who owns the context?
If you take your entire business — every process, every handoff, every piece of tribal knowledge — and feed it into a frontier model provider, you have essentially handed them your business. If they decide to go after your industry Amazon-style, you have handed them the playbook. The safer architecture is to keep the context local and use frontier models as a reasoning layer on top — a chat interface over your own process graph, not a wholesale upload of your organizational DNA.
This is why model-agnostic infrastructure is not a religious position. It is a structural one. You should be able to swap models, run specialized fine-tuned models for specific domains, and keep your organizational knowledge in a system you control. The frontier models are the engine. Your context is the fuel. Don't give someone else your fuel.
I've argued elsewhere that the mesh of specialized agents is the right shape for enterprise execution — and the mesh only works if context is something you own, not something you rent from whichever vendor's terms-of-service haven't bitten you yet. The agents in the mesh need to read and write against a graph that is yours.
The teams that build this layer first will treat frontier models the way smart companies treat AWS regions — useful, swappable, never load-bearing in a way that locks them in. Your moat is the context. Build the system that holds it.
Related Essays
Why Sandboxes Beat Vector RAG for Code Generation
Vector retrieval gives a similarity approximation of context. A sandbox gives the agent the real repository. Stateless, disposable, accurate — the architecture that actually works.
Three Layers of Agent Context, and Most Agents Have Zero
The coding-agent debate is dominated by model capability. Wrong bottleneck. Context splits into structural, navigational, and operational layers — and most agents are missing all three.
Context Engineering Is the Hard Problem
Models keep getting better, but agents without deep codebase and organizational context are just expensive autocomplete. Context engineering is the bottleneck nobody has productized.
Key takeaways
- Your organizational context is the fuel. Frontier models are the engine. Don't give someone else your fuel.
- Model-agnostic infrastructure is not a religious position. It is a structural one.
- Keep context local, swap models freely, and run specialized fine-tunes for specific domains where it pays.
FAQ
Why is uploading your business to a frontier provider risky?
Because if they decide to move into your industry Amazon-style, you have handed them every process, every handoff, and every piece of tribal knowledge that makes your business yours. The context is the moat. Don't give it away.
What does context-local architecture look like?
A chat interface over your own process graph rather than a wholesale upload of your organizational DNA. Frontier models reason on top. Your context lives in a system you control and can swap engines under.