Sovereign
intelligence

The economics keep changing

Epoch AI estimates that the cost of reaching a given benchmark performance fell roughly 47% per quarter over 2023–26. Its historical comparison puts that pace ahead of DNA sequencing, compute, lithium batteries and electricity. These are different technologies measured over different periods, not competing products observed in a controlled experiment.

For a CIO, the implication is architectural: a fixed choice of model can become economically outdated while the surrounding implementation is still being rolled out. The relevant question is how much surrounding work must change when the model changes.

Lower inference prices do not automatically lower the total cost of a workflow. Tool usage, retries, integration and human review also count. Measure cost per successfully completed task, alongside quality, before changing the system.

The frontier is moving in two directions

The cost of a particular capability can fall while the best available capability improves. These are separate developments. A cheaper substitute for yesterday’s model is not the same thing as a system that can solve a harder problem today.

The Epoch Capabilities Index brings benchmark results onto a common scale. The snapshot below shows both individual models and the highest score available over time. It provides context for periodic evaluation, but does not establish which model is suitable for a particular business workflow.

A benchmark score is not a percentage of business tasks completed or a promise of productivity. For routine work, a smaller model may be sufficient. For difficult work, assess what the strongest eligible models can do before designing a process around a weaker model’s limitations.

Four terms, four different decisions

Conversations about ‘the AI’ often bundle several decisions together. Separating the layers makes it easier to ask what you are buying, what you are configuring and what you need to control.

The agent is the combined model and harness at work, not an extra piece of software wrapped around them. The environment is what that system can access: documents, applications, databases and other services. Our diagram uses nested boundaries to explain these relationships, not to prescribe a deployment topology.

In an integrated frontier-lab platform, the provider controls both the model and the harness that runs it. You configure and use those layers; you do not necessarily own or control them. That arrangement is a product choice, not a requirement of the architecture: a separate harness can connect to models from different providers.

Access also has a time dimension. Reading a file gives an agent a snapshot. If the file changes, the agent needs to read it again. Connecting a system is only the beginning; useful environments also make current information discoverable and clearly distinguish it from stale material.

Better know-how can improve the same model

The WikiSkill preprint studies how agent experience can become persistent knowledge and reusable skills. In its Gemini-3.5-Flash comparison, average accuracy across five benchmarks rises from 49.5% without skills to 68.1% with WikiSkill: an increase of 18.6 percentage points, with the same inference model.

That is evidence for the value of structured, reusable know-how. It is not a measured uplift from adding proprietary company data, and it should not be presented as a forecast of enterprise performance. The reported results average three independent runs of the skill-evolution process.

The business hypothesis is worth testing: your definitions, worked examples and validated procedures may make an agent more effective on your tasks. A comparison on held-out work can test that hypothesis. More documents do not necessarily produce more accurate results.

Build the environment the company keeps

Owning the model and harness gives a frontier lab two reasons to keep work inside its platform: more model usage and a deeper role in the customer’s operations. Memory, procedures and connections can make the product more useful while also increasing the work required to leave. This creates a commercial incentive for company knowledge to accumulate inside the platform.

The alternative is to make the company’s environment the permanent home for the services agents rely on: MCP tools, long-term memory, knowledge bases, reusable procedures and messaging between agents. In this design, the model and harness access those services; they are not the only place those services or their records exist.

The five areas below turn that principle into enterprise responsibilities. These services can be self-hosted or managed: what matters is control over access, usable records and the ability to change providers. The suggested owners should fit your organisation’s existing accountabilities.

Consider replacing the agent handling a customer request. The replacement can retrieve the same case history, use the same business-system tools and pick up a recorded handoff from another agent. The company retains the shared records and services; the replacement still needs compatible connections, permissions and an evaluation on the work. Active sessions and model behaviour do not automatically transfer. That is the practical independence this architecture aims for: changing the intelligence without recreating the company’s operating context.

What would you lose if you switched provider?

Choose one workflow and name both the current system and a possible replacement. Specify whether the change covers just the model, the harness, or the entire platform. Switching a model within an existing harness is a different exercise from moving the whole workflow.

For each item below, record what would happen in that specific move: it carries over, needs rebuilding, is lost, or remains unknown. Assign an owner and estimate the effort and disruption. An export option is useful evidence only after the exported material has been used successfully in the replacement.

Treat unknowns as unanswered questions, not evidence of portability. Before deciding to switch, run the same held-out work in both systems and compare result quality, review effort and total cost. A dependency may be acceptable when its benefits and replacement costs are understood.