Over the past year, the way I use most of my software has changed. I depend on a meeting recorder, a notes app, email, a calendar and an issue tracker as much as I ever did. What has changed is where I read and reason about what they contain. I now rarely do that inside the applications themselves. I ask an agent, usually Claude or Codex, and the agent retrieves what it needs from them. The meeting recorder still records every call, but I can't remember the last time I read one of its generated summaries.
Everyone I know who works through agents for most of the day has made the same shift, and that group is growing quickly. The shift changes which parts of an application its users value, and it creates demand for a kind of product that individuals have never had a reason to buy: data infrastructure of their own.
1. The vertical bundle
Most productivity software is vertical. It serves one domain, such as meetings, email or notes, and within that domain it does three different jobs. It captures data: it records and transcribes a call, receives a message, or accepts a note. It stores that data in a model organized around the domain's central object, so a meeting app stores meetings, and attendees, transcripts and action items are fields of a meeting. And it reasons over the stored data: it produces summaries, extracts action items, ranks the inbox, and more recently offers a chat interface for asking questions about the domain.
These three jobs were sold together for good reasons. Reasoning over data was expensive to build, and it was usually specific to the domain. It also worked best close to the data, because the vendor controlled the schema and could build features against it directly. For most of the history of software, someone who wanted useful meeting summaries had no realistic option other than the meeting app that held the transcripts. The reasoning had to sit where the data was.
2. What changes when users bring their own models
General-purpose models break that coupling. A capable agent summarizes a meeting or answers a question about it as well as the application's built-in features do. On questions that span domains, it has an advantage the application can't match. "What did I commit to on the call with this investor, and have I followed up?" depends on the transcript, the email thread that followed, and possibly a note written weeks earlier. No single vertical application holds all of that.
Capture stays with the vendor. It is real engineering: accurate transcription, speaker attribution, reliable sync, the edge cases of a mail protocol. Reasoning leaves. Everything a person does to make sense of their own data moves to the agent they choose, and the reasoning that crosses domains, which no vertical application could offer, moves there first. Figure 1 summarizes the shift.
| Function | Under the vertical bundle | When the user works through an agent |
|---|---|---|
| Capture | Vertical application | Vertical application |
| Storage | Vertical application | Vertical application, mirrored to wherever the user reasons |
| Reasoning within one domain | Vertical application | The user's agent |
| Reasoning across domains | Generally unavailable | The user's agent, limited by what data it can reach and how well that data is organized |
Figure 1. Where each function of a vertical application lives, before and after users have general-purpose agents. Capture stays with the vendor. Reasoning moves to the user, and cross-domain reasoning becomes possible for the first time, limited only by whether the underlying data is accessible and connected.
What remains of the vertical application is a sensor. It instruments one part of a person's life and produces a reliable record of it. Good sensors are hard to build and worth paying for, and a sensor business has different economics from a business that owns the place where its users think.
3. The position of vertical vendors
Vertical vendors know this, and their recent product decisions point in two directions at once.
On one side, several now expose their data to external agents. Granola offers MCP access to meeting notes because its users asked to bring their meetings into the agents they already use. On the other side, the same companies are building their own agents. Linear and Granola both have one, and so do most of the applications I use. An in-app agent keeps the user inside the product, where engagement and retention are measured and where pricing is justified. An external interface does the opposite.
Both responses are rational, and the result is a predictable compromise. The external interface is usually present but limited: paginated tightly, restricted to a subset of records, or scoped by key types that make bulk access awkward. Meanwhile the in-app agent gets the prominent position in the product.
In-app agents face a ceiling that better models won't raise, because of how the data is organized. A meeting application's schema has the meeting as its root entity. Everything else, including people, follow-ups and related documents, is modeled as an attribute or attachment of a meeting. But many of the questions people actually ask have a different root. "What do I owe this person?" is rooted in the person. "Where does this project stand?" is rooted in the project. Answering them requires a model in which people and projects are first-class entities that span sources. A vertical application can add integrations and import email or calendar data, but the imported data will still hang off its own central object, because that object is what the product is built around. The limit follows from being vertical.
There's also a duplication cost. Every vertical vendor is building roughly the same agent, with the same retrieval, the same chat interface and the same summarization, each scoped to a single domain. From the user's position, this produces many partial assistants and no complete one.
4. Why direct connections are not sufficient
If vertical applications are sensors and the user's agent does the reasoning, the obvious approach is to connect each agent directly to each source, for example through MCP. Many people who use agents heavily already work this way, and it shows what's possible. It also has costs that grow quickly.
The first is the number of integrations. With S sources and A agents, direct connection requires on the order of S × A configured integrations. Adding a source means configuring it in every agent, and adopting a new agent means reconnecting every source. Figure 2 shows the difference with a shared intermediate layer, which needs S + A.
Figure 2. Integration count for direct connection versus a shared intermediate layer. The count is the smaller of the two costs. The larger one, discussed below, is that under (a) each agent must reconstruct its understanding of the data in every session.
The second cost is more significant. When an agent reads raw sources directly, it has to do all the interpretive work at query time, inside a single context window. It has to determine that the person named in a transcript is the same person who sent a particular email and appears in a particular note. It has to work out which documents concern the same project, page through each source within the vendor's rate limits, and decide what's relevant. All of that work is discarded when the session ends. The next session repeats it, and another agent repeats it independently, often reaching a slightly different answer. The work is expensive, it isn't reproducible, and it's capped by how much raw material fits in a context window.
Organizations hit the same problem with their operational data and solved it the same way. Companies don't ask each analyst to reconstruct the state of the business from production databases. They consolidate the data, compute a shared model of it once (entities, relationships, definitions), and let many consumers query that model. The interpretive work becomes a maintained asset.
5. What the missing layer does
The layer between a person's sources and their agents needs to do four things. Figure 3 shows them as a reference architecture.
It aggregates. Data from every source the user connects is ingested into one store, under the user's control, without regard to whether the source is nominally personal or professional.
It derives structure and meaning from the aggregate, and the derivation takes two forms. Some of it is deterministic: identity resolution across sources, an ontology of people, organizations and projects, and temporal ordering of events. This produces stable structure that agents can rely on without re-inferring it. Some of it is model-based and therefore non-deterministic: signal extraction that identifies open commitments, changes in status, or items that are likely to matter. The two forms depend on each other. Signal extraction is far more reliable over resolved entities than over raw text, and the deterministic layer becomes more useful when signals are attached to it.
It is horizontal by construction. No source is privileged in the schema, and a new source is added by writing an adapter that maps it into the shared ontology. Much of the value comes from relationships between records in different sources, so each additional source raises the value of the ones already connected.
It delivers through interfaces that don't assume a particular client, such as MCP, a command-line tool or an API, so that whatever agent the user adopts next can query the derived model.
Figure 3. A reference architecture for the layer described in this section. Sources and clients sit outside it and are expected to change. The adapters, the store, the derivation stage and the interfaces make up the infrastructure itself.
Both ends of this arrangement change constantly. In the past year I have changed the agent I use most more than once, and the set of applications I use as sources changes every few months. What persists across those changes is the user and the user's data. A layer that holds the data and its derived model, independent of any particular source or client, is the part that doesn't have to be rebuilt each time. That is what makes it infrastructure.
6. A category with a different customer
Organizations have bought data infrastructure for a long time. What's new is the customer. Individuals have rarely bought infrastructure, because their applications provided it implicitly. Each vertical application acted as its own small warehouse and its own analytics layer, and the user never had to think about either. That arrangement worked as long as the reasoning happened inside the application. Once reasoning moves to an agent the user controls, the data and its derived structure have to be organized from the user's side as well.
I call this category consumer infrastructure, where the consumer is the person consuming the tools, at work and everywhere else. The line between personal and professional tooling has become hard to draw. The same agent, with the same need for context, is used on a work codebase in the afternoon and a personal project in the evening. What defines the category is that the end user controls the scope of the data and the choice of tools.
The shift parallels something I wrote about earlier this year in the context of software engineering. Directing a large amount of execution used to require a large organization, and agents have made it available to small teams and individuals. Data infrastructure is following the same path. The function that once justified a dedicated data team inside a company becomes something an individual needs, because individuals are now coordinating work at a scale that used to require one.
7. Adjacent approaches
Several groups are working near this problem, and each is constrained by where it started.
Model providers are adding memory and connectors to their assistants. This is the most capable adjacent effort, but the resulting context is tied to one provider's assistant, and most people who use agents heavily use more than one. Connector and integration platforms make data movable, but they mostly move data without building a shared model of it, so the interpretive work is still left to the agent at query time. Memory and retrieval services for developers are genuine infrastructure, but they're sold to application builders and scoped to one application's users. Vertical vendors, as discussed above, are building agents bounded by their own schema. A user-side layer starts from the user and treats every source and every client as interchangeable.
8. Risks
Vertical vendors could restrict external access, and a user-side layer depends on interfaces it doesn't control. The pressure runs the other way, because users now treat export as a requirement, but the dependency is real. A single model provider could build a cross-source layer good enough that users consolidate on that provider's assistant. That would solve aggregation and reintroduce lock-in one level up, which is exactly what people are avoiding by using several models. Individuals might also be reluctant to pay for something described as infrastructure, even if they value what it enables. And holding a person's data across every source raises the bar on trust, security and transparency well above what most consumer software has had to meet.
9. Building the layer
This is the layer we're building at Nessie. It already ingests a user's sources, including meeting tools, email, Apple Notes, Obsidian and the session histories of the AI tools they use, into one store, and exposes them through MCP and a command-line interface so any agent the user works with can query them. We're now building the ontology and signal extraction on top of that store. New sources are added as adapters into the same model, which is what horizontal means in practice for us.
The vertical applications people rely on will be valued for how well they capture, and the user's own agents will be where reasoning happens. The layer between them is still missing, and it's what we're building.