As AI moves from personal assistants into shared organisational workflows, the strategic question is changing. The advantage may not go to companies with access to the most powerful model, but to those that control the system around it.
Most AI strategies still start with the same question: which model should we use? OpenAI, Anthropic, Google, an open-weight model, some combination of them. Technology teams or consultants compare benchmarks. Procurement negotiates licences. Then many wonder whether the decision they made six months ago is already dated.
It's the wrong question, or at least an incomplete one.
Models still matter, and their capability keeps improving. But access to capable models is now widespread, frontier performance is converging on many tasks, and the cost of comparable capability has fallen sharply. Stanford's 2026 AI Index points to this convergence and a rapidly expanding ecosystem of capable systems. If two competitors can buy access to similar reasoning capability, the model can't be the whole advantage.
What increasingly differentiates two organisations' AI systems is everything built around the model: what information it receives, which systems it can touch, what it's permitted to do, what it remembers, how its actions are checked, and when a human has to step in. Call that operating layer the AI harness. As AI moves from a largely single-player experience to a multi-player one, that harness is becoming one of the more strategically important pieces of technology an organisation can control.
From single-player to multi-player
The first wave of generative AI was mostly personal. An employee opens a chat window, asks a question, drafts an email, summarises a document. The employee supplies the context, judges the output, and decides what happens next. Even at scale, with thousands of employees using the same product, their interactions often stay isolated. One person's context lives in their own chat history, not anywhere the system can draw on for the next person.
Dust's Gabriel Hubert has described the shift beyond this as "multiplayer AI", with agents and humans sharing governed access to the same context, artifacts, and goals, rather than each person starting from a blank slate. The distinction matters because a large share of organisational performance depends not on how fast one person finishes a task, but on how well work moves between people and systems.
Take something ordinary: responding to a significant customer proposal. Sales understands the relationship. Finance understands the commercial limits. Legal understands the contractual risk. Operations knows what can actually be delivered. A single-player AI assistant makes each of those people faster individually. A multi-player system can participate in the process itself, pulling the customer's history, flagging the clause that deviates from standard terms, checking the discount against the approval matrix, and routing the exception to the right person before a human even asks.
A worked situation
Say the proposed terms include a 15% discount against a $2M contract, and company policy caps discretionary discounts at 10% without sign-off. In a well-built harness, the agent drafting the proposal response doesn't just write persuasive copy. It checks the discount against the approval matrix, sees it exceeds the threshold, and instead of silently proceeding or silently blocking, it drafts the response and flags the specific clause, attaches the policy reference, and routes an approval request to the named person with the reasoning attached.
If approved, that decision and its rationale become part of the customer's record, so the next agent handling this account, whether renewal, upsell or dispute, knows an exception was made and why. If declined, the agent redrafts within policy rather than resending the same terms.
None of that depends on the model being smarter. It depends on the harness knowing the approval matrix exists, knowing who the named approver is, being able to pause and resume a workflow across a human delay, and keeping a record that the next agent, or the next employee, can actually use. That's the work the model can't do on its own.
What the harness actually has to do
An AI model doesn't know your organisation's approval thresholds, which data source is authoritative versus obsolete, or that certain decisions always need human review. The organisation has to supply that. The harness is the environment that does it: connecting the model to information and tools, controlling permissions, applying policy, recording actions, and governing how the AI interacts with other systems and people.
Two things belong in that definition that are easy to skip past:
-
Data provenance
Permissions tell you what an agent is allowed to touch. Provenance tells you where the information it actually used came from: which record, which version, and whether that source is current or superseded. An agent can be fully within its permissions and still act on stale or wrong data if the harness doesn't track lineage. As agents chain work together, an error introduced by one agent reading an outdated source can propagate through three or four downstream steps before anyone notices. Without provenance tracking, tracing it back to the source is close to impossible.
-
Agent-to-agent trust
Once more than one agent, possibly from different vendors, is involved in a workflow, one agent handing work to another needs some way to verify what that other agent is actually authorised to do, not just assume it. This is closer to an identity and access management problem than a model problem, and it's one most organisations haven't had to solve before because it barely existed in single-player AI.
Put together, a mature harness might let an agent read customer records but not alter them; prepare a refund but require approval above a threshold; query financial data but never export identifiable information; ask a specialist agent for analysis while verifying that agent's credentials; or stop and escalate when confidence drops below an acceptable level, with the reasoning and the source data both on record.
The model provides capability. The harness provides organisational capability. Over time, a well-designed one starts to embody policy, exception handling, trusted sources, and patterns of human judgement that used to live only in manuals and institutional memory.
This is also why "open" matters here, and why it doesn't mean what people assume. Open doesn't mean open source, and it doesn't mean unrestricted access. An enterprise harness should still be tightly controlled. It means the organisation can inspect, govern, modify, and move the important parts of the system: workflows that don't hard-depend on one model, organisational memory that's exportable, tools that connect through documented interfaces, permissions that are visible, and evaluation logic the organisation owns rather than rents.
The rapid adoption of the Model Context Protocol (MCP) is a concrete example of this direction. Originally developed by Anthropic to standardise connections between AI systems and external tools, MCP was adopted across products from competing AI providers through 2025, and in December 2025 Anthropic donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare and Bloomberg. The significance isn't the protocol itself. It's that the ecosystem is starting to separate the intelligence of the model from the infrastructure through which that intelligence connects to the world. That separation is what makes an open harness practically achievable rather than just a preference.
The cost of building it yourself
None of this is free, and the article-length case for control tends to skip past that. Building and maintaining an open, organisation-owned harness means owning integration work, security review, and ongoing maintenance that a vendor-managed platform would otherwise absorb. It's slower to stand up. It requires people who understand both the workflows and the plumbing, which is a specific and currently scarce combination.
The honest trade-off is this: a proprietary, vendor-managed harness gets you moving faster today, with less internal engineering load, and often better out-of-the-box guardrails. An open, organisation-controlled harness costs more up front and takes longer, in exchange for not having your operating logic, the accumulated record of how your organisation actually makes decisions, locked inside one vendor's product.
Which side of that trade-off makes sense depends on how central the workflow is. A low-stakes, generic task, such as drafting internal meeting notes, probably doesn't warrant the investment in openness. A workflow that touches customer commitments, financial exposure, or regulated decisions probably does. Treating every workflow the same way, either all-in on a vendor platform or all-in on building your own, is likely the wrong call in both directions.
The governance case for openness
The business case for an open harness is control, not principle. A model that generates an incorrect paragraph creates one kind of risk. A model that can query databases, alter records, trigger transactions, and hand work to other agents creates another. As agency increases, governance has to move from policy documents into architecture. An organisation needs to know what an agent attempted, what it accessed, why an action was blocked, who approved it, and how a decision moved through the system.
A sufficiently open harness lets those controls be examined and changed. That doesn't automatically make it secure. Open systems can be built badly, and proprietary ones can be built well. The real question isn't "does the platform have guardrails?" It's "can we see where those guardrails are, who controls them, and whether they match our own requirements?"
This matters more in a multi-player setting because failures don't stay contained to one person's conversation. A bad answer in a private chat gets discarded. A bad assumption entering a shared workflow can travel through several agents and departments before anyone catches it, which is exactly why provenance tracking and agent-to-agent verification aren't nice-to-haves once you're past single-player use.
How this plays out in practice
Model selection still matters. Different models perform differently on reasoning, coding, latency, cost and specialist tasks, and some workloads will legitimately favour one model over another. But it's a mistake to let today's model leader become tomorrow's architecture, given how fast that market moves.
The practical shifts:
-
Separate model capability from organisational capability
Keep context, permissions, workflow logic, evaluation, memory, and provenance tracking outside the model layer wherever practical, so a model swap doesn't mean a rebuild.
-
Make organisational intelligence portable
Know exactly where agent instructions, shared memory, approval rules, tool definitions and evaluation criteria live, and get a straight answer from any vendor on what happens to them if you leave.
-
Treat permissions and handoffs as organisational design decisions, not engineering ones
Which agent can do what, when it must escalate, who owns the outcome, and how one agent verifies another's authority should sit with the people who own the workflow, not default to whatever the platform ships with.
-
Weigh openness against the workflow's stakes, not as a blanket policy
Reserve the investment in an owned, inspectable harness for workflows where the accumulated decision logic is actually worth protecting, such as customer commitments, financial exposure and regulated processes, rather than applying it uniformly.
-
Measure the workflow, not just the model
Model benchmarks tell you whether raw capability improved. They don't tell you whether a customer escalation was resolved correctly or whether a procurement decision followed policy. The unit of performance that matters is the business process.
The sharper version of the question to ask a vendor isn't "which model are you using?" It's: if we replaced that model tomorrow, what would we lose? If the answer is some integration work and retraining, the architecture is probably resilient. If the answer is your workflows, your organisational memory, your governance logic, and the record of how hard decisions actually got made, you've outsourced considerably more than a model.
Own the system, not just the model
Every major model release will keep drawing attention, and choosing models well will remain part of building effective AI systems. But access to intelligence and advantage from intelligence are not the same thing. As AI becomes multi-player, the strategic questions move beyond the model itself:
- what context the system receives
- what authority it has
- what it can remember
- which systems it can act on
- how agents verify one another
- where human judgement enters
- who controls the architecture that governs all of it
That is where competitive advantage shifts from the model to the organisation. Not in a model that may be replaced next year, but in the harness that carries the organisation's workflows, permissions, institutional knowledge and decision logic. Companies that control that layer can change models without losing what they have learned, and add new agents without surrendering control.
Those that do not may spend years teaching an AI platform how their organisation works, only to discover they outsourced not just the model, but the organisation’s operating intelligence itself.
