Every technology wave starts with one scarce thing everyone wants.
In the personal-computer era, it was computing power. In the early internet era, it was connectivity and distribution. SaaS turned software into something every company could buy without installing a server in a closet. Cloud computing turned infrastructure into an API. The iPhone put a camera, a GPS, an internet connection, and an app store in everyone's pocket, and mobile became the place to build.
Then AI made intelligence available through an API.
That kicked off the latest gold rush. Everyone raced to build a better model, train on more data, buy more GPUs, and put a chat box into every product.
That race is not over. Models will keep improving. They will get cheaper, faster, and better at reasoning.
But for many everyday agents, the model is no longer the biggest problem.
The agent can write a good email. It can summarize a document. It can explain a chart, draft a reply, plan a project, or call a tool. What it usually cannot do is know which email it should write, what happened with this customer last week, which definition of revenue your company trusts, why the team rejected the obvious plan three months ago, or what you mean when you say, “Handle this like we normally do.”
The intelligence is increasingly available.
The missing ingredient is context.
That is why I believe context is the next gold rush.
Model limitsA better model still cannot know what it was never told

Model improvements matter. But their value depends on the job.
If you are trying to solve a new scientific problem or write extremely difficult code, a more capable model can change what is possible. If you are trying to respond to a customer, recommend the next action, investigate a business metric, or prepare someone for a meeting, the bottleneck is often different.
The agent needs to know the customer. It needs the history. It needs the current state of the business. It needs to understand what happened, in what order, and which details matter now.
Give a brilliant model a generic prompt and it will produce a brilliant generic answer.
Give a less capable model the customer's purchases, support history, recent product activity, preferences, current account state, and the company's actual policies, and it can produce something far more useful.
This is not because intelligence stopped mattering. It is because intelligence without context reaches a ceiling very quickly.
We spent the first part of the AI wave asking, “How smart is the model?”
The next part will be about asking, “What does the model know about this exact situation?”
LighthouseApple is the clearest lighthouse

Apple's AI strategy makes this shift unusually visible.
Apple is not betting that value comes only from owning one model. Its current developer architecture supports Apple models as well as models from other providers (Apple Newsroom). At the same time, Apple keeps pushing the layer it uniquely owns: your apps, messages, photos, on-screen activity, habits, and device state.
Apple describes its approach as combining generative models with personal context. Its developer system asks apps to expose lightweight entities, actions, and domain-specific schemas so Apple Intelligence can understand what content means and use it in the right moment (Apple Developer).
That is the interesting part.
That modularity makes the model layer more replaceable. But almost nobody else has the same permissioned view into a person's digital life across their phone, computer, watch, apps, messages, photos, and daily behavior.
The model is powerful. The context is the moat.
And Apple is showing another important principle: valuable context does not have to mean shipping all of your private data to a random company. Its architecture emphasizes on-device processing and Private Cloud Compute, where data is used to fulfill a request rather than stored by Apple (Apple Support).
That is a preview of where I think the broader market goes.
Context productsCompanies will sell intelligence without selling their data

When I say companies will sell their context, the immediate reaction is obvious:
Great. So every company sells everything it knows about me and privacy goes completely to shit.
That is one possible future. It is also a bad product, a bad security model, and probably an unacceptable business model.
The more interesting future is that companies do not sell their raw data at all. They sell the ability to improve an answer with their context.
Imagine an agent planning a trip for you. An airline knows where you have flown, which seats you choose, whether you check a bag, how often you change flights, and what problems you have had before. A hotel knows what kind of room you prefer. A restaurant platform knows the places you return to, the times you eat, and the kinds of reservations you actually keep.
Today, every one of those companies uses its data inside its own little wall.
In the future, your agent could ask each company to enrich a request. The company would use its private context to improve the result, return only the permitted answer, and charge for the value it added. The raw customer history would not need to leave the company's controlled environment.
The company is not selling a database row.
It is selling better judgment.
This can work for business context too. A logistics company could enrich a supply-chain forecast with what it knows about delays. A payments company could enrich a risk decision. A commerce platform could improve a product recommendation. A data provider could add market context to an investment research question.
The prompt goes in. The context improves the work. A controlled result comes out.
That creates a new asset class for companies: not the data they can export, but the decisions they can improve.
ArchitectureThe context market will need an architecture
This will not work by connecting every agent directly to every company's production database.
It needs a system that makes context useful, composable, measurable, and safe. I believe that system will have three important characteristics:
- 1It will be warehouse-native.
- 2It will be based on an Activity Schema.
- 3It will be orchestrated by an independent third party or open protocol.

Here is why.
1 · Warehouse1. Context will be warehouse-native

Advertising trained us to think of customer context as pixels, page views, and clicks.
That data is useful. It is also thin.
A website can see that someone clicked a pricing page. The company's internal systems may know that the same person is an existing customer, opened three support tickets, attended a training, invited twelve coworkers, downgraded last month, and is currently waiting for a contract change.
The higher-signal story usually lives inside the company.
Much of that story already comes together in the warehouse. That is where companies combine product data, customer records, transactions, marketing, support, billing, and operational systems. It is also where teams clean identities, resolve definitions, correct bad data, and create the trusted logic they already use for reporting and decisions.
If companies want to monetize useful context, rebuilding it from tracking pixels would be ridiculous. The valuable version is the cleaned, governed version they already use to run the business.
This is also the safest boundary. Instead of copying an entire dataset into a new AI vendor, computation can move closer to the governed data. The warehouse can enforce identity, permissions, approved fields, audit logs, and retention rules. Only the minimum context or final result should leave that boundary.
The warehouse becomes more than a place to store history.
It becomes the context engine.
2 · Activity Schema2. Context will be Activity Schema–based
A warehouse full of tables is still not automatically good context.
Dumping thousands of rows, giant documents, or every known fact into a model produces expensive and often terrible results. Context is useful when it is small, structured, and relevant.
The most natural structure is a timeline of meaningful activities:
customer upgraded plan customer invited 12 teammates customer opened support ticket support ticket resolved customer viewed cancellation page customer renewed contract

Each activity has a person or entity, a timestamp, a clear action, and a small set of useful details.
This matters for three reasons.
First, activities are dense. An agent does not need fifty columns of application state when six meaningful events tell the story. That keeps token use and cost low.
Second, time gives the model causality and momentum. A bag of facts says a customer has a support ticket, a renewal, and a cancellation-page view. A timeline shows that the support problem happened before the cancellation concern and that the customer renewed after it was resolved. The order changes the meaning.
Third, activities are composable across companies. Every business has different internal tables, names, and software. But “booked flight,” “checked into hotel,” “purchased product,” “opened ticket,” and “renewed subscription” are understandable building blocks. A shared Activity Schema gives agents one simple grammar for combining context without forcing every company to share its internal data model.
This is why we use the Activity Schema at Polyform. We use it as a foundation for analytics, automations, and AI. Once a company has already turned its messy operational data into a clean sequence of business activities, that same trusted foundation can power context products too.
The work required to make analytics trustworthy is the same work required to make context valuable.
3 · Orchestration3. Context will be independently orchestrated
The final piece is a trusted middle layer.
An agent cannot be allowed to send arbitrary prompts into a company's private context and slowly extract the underlying data. A company also cannot grade its own context, make unlimited claims about its value, and return an answer nobody can audit.
Something has to coordinate the exchange.
That could be a third-party platform. It could eventually be an open protocol with certified operators. Either way, the job is larger than moving data from one API to another.
The orchestrator has to:
- ✓Verify the user's identity and permission.
- ✓Decide which context providers are relevant.
- ✓Block prompts designed to extract private data.
- ✓Send only the minimum necessary request.
- ✓Combine context from multiple providers.
- ✓Filter the result for privacy and policy violations.
- ✓Record what was used without recording everything that was seen.
- ✓Measure whether each source actually improved the answer.
- ✓Handle payment for the value created.

Quality measurement will be especially important.
Every company thinks its data is valuable. A lot of it is stale, duplicated, badly defined, or useless outside the workflow that created it. The market needs a way to learn which context blocks improve which kinds of decisions.
Did the airline context materially improve the itinerary? Did the payments context catch fraud without increasing false positives? Did the commerce context produce recommendations the customer actually accepted?
Over time, the orchestrator can score context by usefulness, freshness, coverage, and reliability. Companies with high-quality context earn more. Companies with a pile of unstructured garbage do not.
That gives businesses a new reason to clean and structure their data: better data will not just improve their own analytics. It can become a product.
The flowWhat the context economy could look like
The future flow is surprisingly simple:
user asks an agent for an outcome
↓
orchestrator finds relevant context providers
↓
approved prompts go to each provider's governed environment
↓
private warehouse context enriches the work
↓
safe results are combined and returned
↓
providers are paid for measurable value

The raw data does not have to be pooled into one enormous surveillance database. The agent does not need permanent access to every system. Each provider can contribute only the minimum useful context, under a specific permission, for a specific purpose.
There are hard problems here. Prompt injection, consent, identity, revocation, competition, pricing, auditing, and output privacy all need real solutions. “The data never leaves” is not magic if a malicious person can reconstruct the data from the answers. Safe context products will need strict query controls, aggregation, privacy budgets, monitoring, and clear user permission.
I do not think these problems make the market impossible.
I think solving them is the market.
The assetThe companies sitting on gold may not know it yet

The first AI gold rush was about building the intelligence.
The next one will be about supplying the intelligence with a useful view of the world.
Companies already have that view. It is sitting in warehouses, product logs, support systems, transactions, and years of operational history. Most of it is messy. Much of it is trapped. Almost none of it is packaged so an outside agent can use it safely.
The winners will be the companies that turn that history into clean, permissioned, high-signal activities. They will make it available through a trusted orchestration layer. And they will sell better outcomes without selling the underlying data.
Models will become commodities faster than context will.
The companies that own useful context—and learn how to activate it safely—will own the next gold rush.
