Own Your Intelligence: A How-To Guide
The calls for owning your intelligence are escalating…
Recently, Alex Karp encouraged enterprises to “own the means of production.” Not long after, Satya Nadella declared that buying intelligence from a frontier lab is like paying twice: once with money, and once with the proprietary knowledge you reveal to make that intelligence useful.
The question everyone is asking: who should own the intelligence at the core of your business?
To be clear, owning your intelligence is not a mandate nor a recommendation to get off the labs. For many workloads, frontier APIs and agents are still the right answer. But across our portfolio, we are seeing more companies building their own AI capabilities for parts of their products, vertically integrating toward owning and shaping their weights.
A few weeks ago, Sequoia brought together a group of AI founders and builders for an event on owning your AI stack. We had Harvey give us the customer-back view. Then Mercor, Langchain, Trajectory, and Fireworks walked us through the technical building blocks in the post-training stack.
Across the talks, a clear playbook emerged.
Why now?
First, the open-weight frontier has moved faster than anticipated. Kimi K3 and GLM 5.2 are extremely good! Training on open models used to be a treadmill… you might’ve spent months fine-tuning, and the next frontier release would erase your gains. Now, you can start from a baseline close to the frontier.
Second, the independent post-training stack has matured. Thanks to companies like Mercor and Fireworks, every company can access the technology stack of a frontier research lab, from training to inference to human or synthetic data. With strong evals, harness engineering, post-training, and online learning, open models can now beat frontier models in specific domains.
A year ago, you chose open weights when performance was something you could sacrifice. Now, it is becoming an existential and strategic question. The newest battleground is for the intelligence layer. Not your weights, not your product.
When should you make the move?
There’s no one-size-fits-all approach. In addition to performance, there may be slices of your product where renting intelligence becomes a constraint because of…
1. Cost. The more successful your AI product, the higher your AI COGS. If inference costs scale directly with usage, owning the model is the best way to protect your margins.
2. Speed. If you’re operating in a domain like coding (tab autocomplete) or cybersecurity, a small distilled custom model might beat a large general one, because speed is so important.
3. Proprietary data. If your feedback, evals, customer interactions, or domain data are what make the system better, you might prefer that data stays within your walls.
4. Controlling your destiny. The app layer and the intelligence layer are starting to merge. The labs are moving up into product, and app companies are moving down into the training loops that define how the product thinks. Owning the product increasingly might mean controlling more of the learning loop and the intelligence itself (h/t Harvey Research, RampLabs, Glean, Factory, and more).
What’s the roadmap?
Assuming you've decided on your strategy for what to own vs. rent, the question becomes: how do you go from zero to one?
Build your team. Don't shoehorn this into a platform team. Owning your intelligence needs people playing offense: building evals, shaping data, experimenting with open models, tuning harnesses, and pushing performance in a domain. Small, de novo teams go very far here, partnering with half a dozen ecosystem partners. Harvey, for example, has done a surprising amount of research with a team of just seven people!
Make the work legible. Every buyer right now is choosing their AI champion. Increasingly, the tiebreaker is published research, benchmarks, or technical posts. If you choose to do wonderful research in-house, share it with the ecosystem.
Execute the technical steps. We’ve laid out a high level framework below.
1/ Evals
Harvey’s Gabe Pereyra said it well: "If you don't have a good benchmark, you can't train models.”
An eval is a set of tasks that measures whether your system can do the work well. Every task contains a prompt, context the model can use, and a grader. Most evals start as a founder squinting at outputs and vibe-checking whether they feel right. The goal is to turn that judgement into something repeatable.
Harvey built its Legal Agent Benchmark by turning real legal work into discrete tasks a model could be tested on. The first iteration includes more than 1,200 agent tasks across 24 legal practice areas, and is evaluated by over 75,000 expert-written rubric criteria.
It’s important to have an eval before making the decision to own your intelligence. Once every forward pass has an eval, deciding which model to use can be a measured decision instead of a guess.
2/ Harness and context engineering
An agent has three parts: the model, the context, and the harness. The harness governs the product logic around the model: routing, retrieval, tools, memory, fallbacks, and traces. Harrison Chase’s simple framing was that "the main job of the harness is to bring context to the model at the right point in time." The more out of distribution the task is for the model, the worse the off-the-shelf harness will be.
A good harness lets you route tasks to the best model for your specific job, reuse the same evals across models, and decide what context and tools an agent gets. It also makes the agent inspectable. You can trace what context went in, which tools were called, and where it got stuck.
3/ Post-training
Post-training covers several techniques. The right one depends on what you’re trying to improve.
Lin Qiao laid it out: if the model is missing facts, you don't need to post-train - just use context or RAG. If the output format or behavior is wrong, use supervised fine-tuning. If the issue is product taste, use preference tuning. If the model needs to improve at a specialized task, use RL. If the model is too slow or expensive, distill it.
The goal is to pick the lightest method that moves your eval. Then serve the model through the same harness and measure quality, latency, and cost as it runs.
4/ Online learning
Once the system has its pieces – evals, harness, and model – the final step is improving that system in production.
Arjun Karanam made a good point: models keep getting smarter, but every session feels like it's their first day on the job. You can put Terence Tao in an accounting firm, but chances are (at least on day 1) he won’t be the best accountant there. What's missing is experience, not intelligence. Agents create that experience as they run.
A trajectory is the path through the task: the context the model saw, the tools and sub-agents it called, the answer it produced, and what the user edited, undid, or retried. Capturing those trajectories in a tool like LangChain's LangSmith is necessary to build a continuous production loop. A failed task becomes an eval. Missing information goes into context or memory. A bad tool response becomes a harness fix.
Final thoughts
Buyer beware: owning your intelligence opens Pandora’s box.
The closed-model stack is simple. You call a frontier model, use an out-of-the-box harness (e.g., Claude Code or Codex), add prompts and context, and ship. That gives you a high floor, but also a lower ceiling.
Owning your stack means taking on more of the system yourself. The production stack becomes your open-source model, custom harness, tools, and context. The development stack becomes your proprietary evals, domain data, and online learning loop.
It is certainly more work! It potentially gives you a lower floor – but it also raises the ceiling.
The labs will keep building the giant brains. We should all use them.
But, in parallel, the best product companies are growing their own little geniuses: fast, opinionated, domain-obsessed, and tuned to the work they see. In a world where more companies take ownership of their own intelligence, the ecosystem flourishes and individuality triumphs.
That’s the promise of a world where companies own their intelligence. And we’re delighted to see the progress from the little guys, the startups that want to bring that world into existence.