A wave of announcements — Anthropic's Claude and its Cowork-style workspaces, the Model Context Protocol, and Skills — has made one thing obvious: AI is moving from answering questions to doing work. Most of that work is being organized around a single idea: a general-purpose agent that reaches for tools. It is a powerful idea. It is also not the only one.
Underneath the demos, a quieter architectural question is forming. When AI performs real work inside a business, what is the thing that gives that work structure — the interface it happens in, the domain context it depends on, the permissions it must respect, the human who stays in the loop? Today the dominant answer is: the agent. This piece argues there is a second answer that will matter just as much — the application.
The next generation of AI software is unlikely to be defined simply by how many tools an agent can access. The deeper question is how AI, application interfaces, domain context, workflows, permissions and human interaction are assembled into a coherent software environment.
The agent-centric model
In the agent-centric model, a general agent sits at the center. Around it are the things it can reach for: tools and connectors (increasingly via MCP), packaged Skills, documents, memory, and APIs. The interface is a conversation. You describe what you want, the agent decides which tools to call, and the results come back into the chat. Claude, Cowork-style workspaces, and most of today's 'AI that does things' fit this shape.
This is a genuine advance, and MCP and Skills are excellent building blocks. Standardizing how a model discovers and calls tools is exactly the kind of plumbing the ecosystem needed. The point here is not that the agent-centric model is wrong — it is that it answers only part of the question.
What the agent-centric model gets right
- A single, flexible surface can attempt an enormous range of tasks.
- MCP gives tools a common, discoverable calling convention.
- Skills package expertise so it can be reused across tasks.
- It is fast to start: open a chat, connect some tools, and go.
Where the agent-centric model strains
The strain shows up not in the demo but in the second week — when the work is real, repeated, and accountable. Four gaps recur.
- Context is invisible. It accumulates inside the conversation. It is hard to know what the agent is actually operating with — which records, which state, which permissions — and harder to inspect when something goes wrong.
- Discovery is guesswork. A general agent has to infer what it can do here, whether a capability exists, and whether it is allowed to use it.
- Permissions are coarse. They tend to live at the level of a tool or a prompt, not at the level of 'this user, in this record, may do this.'
- The interface is thin. A chat is a wonderful way to express intent and a poor way to show a portfolio, a board, a document, or the state of a deal.
None of these are model problems. They are architecture problems — questions about where interface, context, and permission live.
A different primitive: the application
There is another way to organize the same capabilities. Instead of starting from a general agent that reaches for tools, start from the application — and let AI operate inside it. The application already supplies exactly what the agent-centric model has to reconstruct: an interface, the domain context, the workflows, and the permissions. This is what ADAAS A-OS is built around.
A-OS organizes many of the same AI capabilities around a different architectural primitive: the application rather than the agent.
This is not a rejection of agents. Agents still reason and act. But they do so inside an application's structure, which carries the context and the guardrails — rather than the application being one more tool the agent picks up from a blank conversation.
A worked example: the salesperson and the CRM
Consider a salesperson who wants AI help with a customer. In the agent-centric model, they open a chat and start describing the situation: who the customer is, what stage the deal is in, what was discussed last time, what they are and are not allowed to offer. The agent is capable, but it begins from nothing and depends on the human to narrate the context correctly — every time.
In the application-centric model, the salesperson is already in the CRM, looking at the customer. The application establishes the context: this is the customer, this is the deal stage, these are the past interactions, these are the permitted actions. The AI does not have to be told who the customer is — it can see it, because the application does. The same request — 'draft the follow-up and flag the risk' — lands in a place that already knows what it is about.
The three-display architecture
Because the application is the primitive, A-OS gives every application a consistent, AI-native window made of three coordinated displays. Together they turn 'AI that does things' into an interface you can actually work in.
- Action display — where the user directs the AI and the AI proposes and performs actions. It is the intent-driven surface, but anchored to a specific application rather than a blank chat.
- Primary display — the application's real working surface: the board, the records, the portfolio, the document. It stays in view while the AI operates.
- Meta display — the context panel: the knowledge, entities, state and capabilities the AI is currently working with.
The user can see what the AI can do, what it is working on, and what it knows — at the same time. That is a different experience from watching text scroll past in a conversation.
Context is visible
The Meta display is the quiet centerpiece. In an agent-centric chat, context is something you hope the model is holding correctly. In A-OS, context is on the screen: the customer, the account, the policy, the task the AI is operating inside. When the AI proposes an action, you can see the context it is acting on — and so can an auditor.
Application-centric AI does not just give the AI more context. It makes the context visible, inspectable and governed.
Capabilities are discoverable
Because each application declares its capabilities to the environment, discovery replaces guesswork. Both people and AI can see what is available in the current context: the actions this application exposes, the skills other applications contribute, and the operations the current user or agent is permitted to invoke. A capability is not something the agent has to hope exists — it is something the environment presents, already scoped to who is asking.
A-OS doesn't compete with MCP and Skills — it incorporates them
This is the part that is easy to misread. Application-centric AI is not an alternative to MCP or Skills; it is a home for them. MCP servers and Skills are excellent ways for an application to expose tools and capabilities. A-OS uses them as one of the mechanisms by which an application publishes what it can do — and then adds the interface, the visible context, the discovery, and the composition around them.
MCP and Skills answer 'how does a capability get called?' Application-centric AI answers 'where does that capability live, who can see it, and what does the human experience while it runs?'
Two models, side by side
| Dimension | Agent-centric (Claude, Cowork, general agents) | Application-centric (A-OS) |
|---|---|---|
| Primary unit | The agent | The application |
| Interface | Conversation / chat | Application UI + AI action surface |
| Where context lives | Inside the conversation | On screen, in the interface |
| Context visibility | Largely invisible | Visible and inspectable |
| Capabilities | Tools the agent reaches for | Capabilities the application declares |
| Discovery | Agent infers what it can do | Environment presents what is available |
| Permissions | Tool- and prompt-level | Application- and context-level |
| Domain grounding | Narrated per request | Established by the application |
| MCP / Skills | The core integration model | Incorporated as one mechanism |
| Human role | Directs a general agent | Works in an application, with AI inside it |
Read the table as complementary, not adversarial. Many organizations will use both: agent-centric surfaces for open-ended exploration, and application-centric environments for the repeated, accountable work that runs the business.
Beyond chat
The framing of 'AI that does things' as chat plus tools is a starting point, not the destination. Chat is a superb way to express intent. It is a weak way to show state, to establish who is allowed to do what, and to keep a human oriented while an AI works across a real dataset. The interface question — not just the model question — is what the next few years of enterprise AI will be about.
That is why the application matters. It is where interface, context, workflow and permission already live. Application-centric AI does not throw away the agent; it gives the agent a place to stand.
The rise of application-centric AI
Claude Cowork, MCP and Skills are pushing AI decisively from conversation toward action — and that is the right direction. The open question is how that action is organized. Organize it around a general agent and you get flexibility, at the cost of invisible context and thin interfaces. Organize it around the application and you get visible context, real interfaces, scoped permissions and discoverable capabilities — with MCP and Skills still doing the work underneath.
Agent-centric AI asks how many tools an agent can reach. Application-centric AI asks how AI, interface, context, permissions and people are assembled into software you can trust. A-OS is ADAAS's answer to the second question.