Apps over Agents

Apps in the Agent Era: The Agent-Ready Open App

Notes on how the role of applications changes as agents and agentic coding tools become common, and how to design apps for that world.

Background: the app as a destination

For a long time, most apps were built as places you go into to do work. A CRM worked inside the CRM, an ERP inside the ERP, a document tool inside the document tool. The app stored information within itself, kept its features behind its own screens, and controlled the flow of work within its own walls.

In this model, users move between many apps — copying data out of one, switching screens, reorganizing it, and entering it into another. The number of apps grew, but the work did not get simpler. Information scattered, context broke, and people ended up serving as the connective tissue between systems.

The assumptions behind closed apps

Closed apps rest on roughly four assumptions:

• Data lives inside the app. Work records, customer information, documents, processing history, and decision criteria sit in each app's database. Outside access is possible only through a limited API or a custom integration.
• Features are bound to the UI. People use a feature by clicking buttons, choosing menus, and moving between screens. The feature exists, but an agent cannot freely call or compose it.
• The app sees only its own data. Which project the user is working on, which document a decision should rest on, which internal rules apply — all of this lives outside the app.
• AI is bolted on as an add-on. Many apps now add "AI features," but most do little more than use the app's own LLM to make its internal features slightly more convenient.

The four assumptions share one thing: the app still tries to bring the user inside itself.

What changes

The central shift of the agent era is that the center of work moves from the app's screen to the user's context.

Before, the user operated the app directly, and the app was the destination of the work. Now an agent understands the user's goal, calls the features it needs across apps, pulls in data, organizes intermediate results, and produces the final output. The app is no longer a destination; it becomes a provider of capability that the agent draws on. The separate screens and workflows each app once had are absorbed into a single flow that the agent composes by connecting features across many apps.

In one sentence: the user does not go into the app; the app goes into the user's agentic workflow. This is not a matter of adding AI features to an app. It changes what an app fundamentally is.

The Agent-Ready Open App

An app built for this shift is an Agent-Ready Open App: an app that a person can operate directly on screen, but that at the same time exposes its data, features, state, and output openly enough for an agent to understand and use.

Rather than locking information inside, such an app provides clear data structures, APIs, events, a permission model, units of work, and output formats that an agent can use. It also does not try to handle everything with its own LLM; instead it is designed so that its features and output are used within the agent, LLM, work systems, and security environment the customer already runs. Its goal is not to keep the user on screen for as long as possible, but to be called, composed, and reused as well as possible within the user's context.

An Agent-Ready Open App, then, is not an app with AI features bolted on. It is an app designed to be used by an agent.

AOA: Apps over Agents

This layer of apps that runs on top of agents can be called AOA — Apps over Agents.

An agent writes code, reads files, runs commands, generates documents, and calls external tools. But an agent alone does not make a complete work system. What remains is turning the work an agent performs into a flow a person can follow — validating it, recording it, managing permissions, and shaping it into reusable assets. AOA is the layer that handles this.

Apps in the AOA layer provide clear units of capability that an agent can call, turn an agent's results into workflows a person can work with, and — operating within the customer's context — structure and validate output into reusable assets. In short, AOA is less a piece of technology than a product structure: it describes what an app in the agent era should produce.

Relationship to Skills, MCP, and A2A

To place AOA precisely, it helps to separate it from a few adjacent concepts:

• Skills — individual units of capability that an agent performs. Things like summarizing a document or transforming data, usually delivered as a function call or tool invocation. Skills focus on a single function.
• MCP (Model Context Protocol) — a protocol for an agent to exchange data and context with external resources such as file systems, databases, and APIs. It expands what an agent can see.
• A2A (Agent-to-Agent) — the structure for communication, delegation, and collaboration among agents. It lets several agents split up complex work and defines who performs the work.

All three concern how the work is executed. AOA sits above them and concerns what gets produced. It does not compete with them; it uses them to assemble real work output. Even when several agents collaborate over A2A, pull data through MCP, and run features as Skills, it is the app in the AOA layer that structures the result and turns it into an asset.

Design directions

An Agent-Ready Open App is designed along four directions.

Data: from property to a context resource. Instead of keeping data as an internal asset, provide it as structured context that an agent can read again and build on. Not a plain export, but a project-level asset that includes the stages and flow of the work, links to related documents, change history, and metadata an agent can understand.

Features: from buttons to callable capabilities. Instead of keeping features behind the UI, expose them with clear inputs and outputs, as executable tools, through an interface an agent can call directly. A document-generation feature, for example, is designed not as plain text output but as a capability spanning creation, editing, merging, and format conversion.

Output: from one-off artifacts to reusable assets. Output is at once a document a person can read and a JSON structure an agent can read, carrying workflow information and reusable capability definitions. Such output can be reopened, edited, and extended within the customer's agent environment.

The app: from destination to open workflow node. The app does not monopolize the whole workflow. By providing capabilities specialized to a particular domain of work and making their output connectable to other systems, it participates as one node within a larger flow.

Design principles

Stated as principles, the directions above become:

1. Context-first — provide data so that it is used within the customer's full work context.
2. Agent-callable — expose features in a form an agent can call directly.
3. Human-readable and machine-usable — output should be readable and workable by both people and agents.
4. Customer-owned context — ownership of context belongs to the customer, not the app.
5. Open workflow — the app participates as one node rather than monopolizing the workflow.
6. Composable capability — design features as units that compose with other features.
7. Traceable output — output should carry traceable history and provenance.

An example: a document-automation app

Consider a document-automation app. Designed as an Agent-Ready Open App, it is not merely a document editor.

It provides project-level output as a combination of JSON structure, document, and metadata, and exposes the creation, editing, merging, and format conversion of documents as capabilities an agent can call. The agent calls this app to create documents, edit them, and connect them to other systems. A person can still work directly inside the app's screen — but what matters more is that the output leaves the app and keeps being opened and extended within the customer's agent environment.

Summary

In the agent era, an app can no longer remain a closed workspace. The direction of change can be summarized as:

• closed system → open capability
• UI-centric tool → agent-callable tool
• built-in AI features → extensibility grounded in the customer's context
• data lock-in → context provision
• output trapped inside the app → reusable work assets

Named as a single layer, this shift is AOA — Apps over Agents. The agent performs the work; the app in the AOA layer structures, validates, and documents that work into reusable assets.

In the end, competitiveness will be decided not by which app holds the most features inside itself, but by which app is used best within the customer's agentic workflow.