Apps — the container that outlived its contents
What happens to software packaging when intent is the interface.
Part 1 ended with a question: what does a system look like when it no longer assumes the user is responsible for remembering structure?
Files and folders were the first answer computing gave to that problem. The app was the second.
Where files organized data, apps organized capability. Instead of scattering functionality across the system, you bundled it — gave it a name, an icon, a launch point. The app became the unit of doing.
That model still dominates everything. Your phone is a grid of apps. Your laptop is a dock of apps. Your browser is a collection of tabs, each one a thin app. The app is so fundamental to how we think about software that it feels more like physics than design.
It isn't.
What the app is actually solving
An app is a bundle of related functionality wrapped in a consistent context.
The key word is consistent. Before apps, using software meant switching between tools that didn't share state, didn't know about each other, and couldn't anticipate what you'd need next. The app gave you a contained environment where tools, data, and interface could cohere around a single purpose.
That coherence was valuable because the system itself couldn't provide it. Someone had to draw the boundary. The developer drew it for you.
So apps are really a solution to a coordination problem — how do you give a user a coherent working context when the underlying system has no model of what they're trying to do?
You hand them a pre-packaged one.
The assumption embedded in that design
The app model assumes that the developer's model of your workflow is close enough to your actual workflow that the packaging holds.
That assumption has always been partially wrong. It was just tolerable.
You want to write a document, paste in a screenshot, annotate it, share a clip, track a comment thread, and log a follow-up task. Those are not separate apps. They are one intent, fragmented across five containers because each container was built by a team that only owned one slice of the workflow.
The app boundary is not a natural boundary. It is an organizational boundary that got exported to the user interface.
What starts to break
The seams show up in predictable places.
1. Context collapse at the boundary. Every time you move between apps, you lose state. You copy a URL. You paste a screenshot. You re-explain the situation in a new interface that has no memory of the last one. The transition tax is so normalized we've stopped calling it friction. We call it workflow.
2. The integration layer becomes its own product. Zapier, IFTTT, Make, n8n — entire companies exist to reconnect apps that never should have been separated. When the glue becomes an industry, the original seams were probably wrong.
3. The modal penalty. Every app is a mode. Switching modes costs attention. The research on task-switching puts the reorientation cost at minutes, not seconds. A knowledge worker switching apps dozens of times per day is paying that tax on every transition, mostly invisibly.
4. Permission as a proxy for trust. Because apps are isolated containers, sharing data between them requires explicit handshakes — OAuth, API keys, export/import. The system has no native concept of "these two contexts are related." You have to manually build that bridge every time.
What an AI-native system does differently
The shift is subtle but structural.
In the current model, capability lives inside containers. You go to the container to access the capability. The app is the address.
In an AI-native model, capability is ambient. You express an intent, and the system assembles the tools. The app, if it exists at all, is an output of that assembly — not a prerequisite for it.
This is already partially visible. When you ask a capable language model to help you draft an email, summarize a document, write code, and then explain what the code does — that is not one app. That is context-aware capability routing happening beneath any single interface. The model doesn't care what "app" the task belongs to.
As agents gain more tool access, this generalizes. The question "which app do I open for this?" starts to dissolve into "what do I need to happen here?"
The three things apps were bundling
To understand what replaces them, it helps to decompose what apps were doing:
1. Context. An app maintained a working state — your open files, your cursor position, your undo history, your preferences. It was a persistent envelope for your in-progress work.
2. Capability. An app gave you access to a specific set of operations — tools, commands, transformations. It was a toolbox for a particular domain.
3. Interface. An app rendered a specific UI for that domain — buttons, menus, canvases. It was a language for interacting with that capability.
In a system where agents maintain context continuously, where capability is addressable without container, and where natural language becomes a primary interface — each of those three things decouples.
Context becomes a system property, not an app property. Capability becomes a graph of services, not a bundle. Interface becomes a rendering decision, not a fixed container.
What fills the space
Not a void. Something more like:
Intent surfaces. Instead of launching an app, you open a surface that's already oriented around what you're doing. The system knows you've been working on a proposal, a project, a conversation — and it assembles the relevant context before you ask.
Composable capability layers. Tools exist independently and get invoked together. Writing assistance, search, computation, external data — these stop being inside different apps and become addressable primitives that get composed on demand.
Persistent agents as long-running contexts. Instead of reopening an app to resume work, an agent maintains the thread. You don't pick up where you left off. The system never put it down.
The app starts to look less like a product and more like a pattern — a temporary, purpose-built interface that assembles when needed and dissolves when not.
The transition state we're in
What exists today is a hybrid that satisfies no one cleanly.
AI assistants live inside apps — browser extensions, chat interfaces, sidebar panels — which means they inherit the context problem they were supposed to solve. You still have to copy and paste. You still have to re-explain. The intelligence is local to the container, which defeats much of the point.
The few systems that break this pattern — OS-level AI integrations, context-aware agents with persistent memory — are early and rough. They hint at the shape without delivering it.
We are in the part of the transition where we are teaching intelligence to work around containers rather than dissolving the containers themselves.
What this implies for the next layer
If files were cognitive scaffolding for data, apps were cognitive scaffolding for capability. Both assumed a user whose working context had to be manually maintained.
The next layer up is the interface itself — how humans and systems communicate intent in the first place. Because once context is ambient and capability is composable, what you're left with is the question of how you express what you want.
That's where the browser lives. And the desktop. And the command line before both of them.
Each one was an answer to: given that the system can do things, how does the human say which things?
The interesting question is what that conversation looks like when the system can finally understand the answer.