Harrison Chase's "Own Your Intelligence" argument was a recurring theme at Interrupt London last week, and for good reason. As AI systems become more deeply embedded in how businesses operate, organizations need control over the intelligence that makes those systems valuable: their context, behavior, evaluations, and ability to improve over time.
There's an important engineering question that follows: what does it take for an organization to exercise that ownership in practice?
A company can own its models, harnesses, traces, evals, and every line of code in an AI system. But maintaining and improving that system requires something beyond access to the underlying technology. It requires people inside the organization who understand how the system works, why it behaves the way it does, and how to change it safely.
The repository may belong to the company, while the expertise required to evolve the system still sits with a partner, a vendor, or a few people who have since moved on.
As a consultancy, we're part of that equation. We believe our role is to help companies build that expertise internally, so ownership extends beyond the technology to the capability to keep improving it. That's what we mean by owning your implementation.
The AI stack is an artifact of organizational intelligence
Harrison's "Own Your Intelligence" makes the case for controlling the systems that turn general-purpose models into intelligence specific to a business: how those systems behave, how their quality is measured, and how they improve. Making that ownership meaningful requires the engineering capability to put it into practice.
Every agent has models, a harness, context, memory, evals, traces, and feedback loops. People make decisions about all of them. Someone decides what belongs in the context. A failed trace becomes an eval because someone understands why it failed and which change might fix it. Someone restricts a tool or brings a human into a particular decision.
An open, portable stack gives organizations control over those artifacts. The ability to keep producing, evaluating, and changing them is what turns that control into lasting organizational capability.
Organizational intelligence is collective learning
C.K. Prahalad and Gary Hamel defined core competence as collective learning in 1990: skills and technologies coordinated inside the organization. That learning is distributed across people and gets embedded in routines, policies, and structures.
Organizational intelligence includes the written business: policies, contracts, trade secrets, architecture decisions. It also includes what people learn by doing the work. Which exceptions are harmless. Which customer signals change a decision. Which policies everyone quietly works around. Who gets pulled in on a weird case. Over time, an organization develops judgment about hard cases and about what to do when the written process is not enough.
Software has always served this. Business rules become code, approval paths become workflows, databases hold what no one person could. But traditional software is designed around human interpretation. A form gets validated, a claim gets recorded, a ticket gets routed, and then a person reads the notes, applies policy, handles the exception, and decides what happens next.
Agentic AI pushes into that judgment. An agent reads the notes, searches for policy, picks tools, asks for evidence, and decides whether a case follows the workflow or gets escalated.
For that to work, the organization's judgment has to be legible to software. What gets hard coded and what gets left to the model? Where does the agent have authority, and where does a person take over? That work turns organizational learning into executable behavior. Implementing the technology now requires the organization to implement parts of itself.
Open infrastructure and implementation capability work together
Open models, portable evals, and owned traces protect against a provider raising prices, retiring a model, or moving a feature to a more expensive tier. That flexibility matters. It gives organizations options as the technology changes. But exercising those options requires people who understand the system well enough to make changes safely.
A model change introduces a subtle regression in one customer journey. A trace reveals unofficial steps that were never in the process map. A new tool grants an agent more authority than the risk team anticipated. Can the internal team find the failure, diagnose it, and fix it?
If not, the organization still depends on whoever understands the harness, the evals, and the tradeoffs. The code is in the company's GitHub organization and the contract assigns ownership of the deliverables, but every time the system meets a new part of the business, someone else gets called.
Ownership of the artifacts is an important starting point. But when the ability to diagnose failures and improve the system remains external, the organization has yet to develop the full capability that ownership makes possible. And the distinction becomes clearer when you look at what happens inside an engineering team.
At a regulated wealth management firm with thousands of financial advisors, evals stopped a model upgrade that scored better on correctness but made worst-case response time much worse and changed which tools the agent selected. The tradeoff was visible before anything shipped.
Separately, a month of gateway traffic showed that most failures came from one cause: the model guessing repository names. One fix at the gateway removed that failure class for every team at once.
Neither of those was simply a model problem or a framework problem. They required implementation judgment: knowing what to measure, how to interpret the results, and where to intervene.
The people exercising that judgment were the firm's own product engineers. They had written their first evals paired with us. Now they add tools and run evals in CI on their own.
The firm didn't just gain a working system. Its engineers developed the ability to keep making that system better.
Implementation is now part of the core competence
A bank can buy a model. An insurer can buy an orchestration framework. A retailer can buy observability. Those are generic capabilities, and buying them makes sense.
But people inside the company need to be able to decompose a business process, separate the deterministic parts from the model-based parts, specify context, design evals, read traces, set authority boundaries, and change the process when the system reveals it was wrong.
These decisions aren't independent of the business. They require understanding how the organization actually operates, including the exceptions, tradeoffs, and judgment that rarely make it into formal documentation. And that understanding develops through implementation.
Every workflow sharpens the team for the next one. A production failure becomes a new eval. An unexpected tool call reveals a missing boundary. A recurring exception changes how the next workflow gets designed. Those lessons compound. The more capable the internal team becomes, the more effectively the organization can use the infrastructure it owns. It can adopt new models, change frameworks, improve performance, and extend agentic systems into new parts of the business without starting from scratch each time. Open infrastructure makes those choices possible. Internal implementation capability makes them practical.
This does not mean doing everything alone
Insourcing every tool and building an enormous internal AI group would be the wrong lesson. Owning a system doesn't mean never working with outside experts. It means being able to understand, change, and improve the system, with outside expertise used to accelerate the internal team rather than replace it. This is particularly important with agentic AI, where engineering practices are still evolving and production experience is unevenly distributed.
A partner can bring experience with architectures, evaluation strategies, observability, and failure modes that an internal team hasn't encountered yet. That expertise is valuable. But it becomes more valuable when the organization retains what it learns through the engagement.
Our pairing and feedback process exists so knowledge transfers while decisions get made, not in a handoff deck at the end. Our deprecation model means the partner's share of the work shrinks as the client team's ability grows. The goal is a live system the client team can explain, challenge, diagnose, and change. That's a different measure of success than delivering software that works on the day the engagement ends.
Own the ability to keep learning
As more organizational intelligence becomes embedded in AI systems, companies need to preserve their ability to understand, challenge, and improve how that intelligence is put to work.
Open models, portable infrastructure, owned evals, and accessible traces create the foundation for that control. Internal engineering capability makes it actionable.
These are the people who can swap models, change infrastructure, add or remove human review, adjust an agent's authority, or correct the judgment encoded in a system. And with every change, the organization gets better at building the next one. That's why owning your intelligence and owning your implementation belong together.
Own the models when it matters. Own the harness, context, memory, evals, and traces. Keep the stack portable. And build the capability to keep evolving it.
