For most of the history of personal computing, using software meant going somewhere. You opened Word, visited Google, launched Photoshop, logged into Salesforce, tapped an app. This sounds trivial because it is so deeply embedded in how we think about software. Behind it sits one of the most important assumptions of the digital age:
The company providing the capability also controls the interface through which you access it.
That interface became extraordinarily valuable. It is where software companies built brands, taught workflows, introduced features, gathered data, sold upgrades and established habits. It is where they owned the relationship with the user.
Artificial intelligence may be beginning to separate those two things. The software may still provide the capability. The interface may belong to someone else.
The agent may already exist
The question emerged during a fairly ordinary discussion about adding artificial intelligence to a software product. There seemed to be two obvious approaches.
The first was the approach appearing almost everywhere: build an agent into the product. Give it access to the application's data and functions. Let the user ask questions, create things, change things and navigate the product through conversation. Take the existing software and give it an intelligent interface.
But there was another possibility. What if we did not build the agent at all?
Not because agents are unimportant, but because the user might already have one. It might be ChatGPT, Claude, Gemini, a future version of Siri, an agent provided by their employer, or a sovereign agent operating entirely within infrastructure they control.
If that agent already understands the user's work, preferences, projects, communication and history, why should every new piece of software ask the human to start another relationship with another artificial intelligence? Perhaps the product needs something else. Not another agent.
A way for agents to use it.
Bring Your Own Agent
Imagine subscribing to a new software service a few years from now. Today the process is familiar: you create an account, configure the application, learn its navigation, import some data, discover where its functions are hidden, and eventually incorporate another interface into your working habits.
Imagine instead that the application offers another option: connect your agent. You authorize access. Your agent discovers what the service can do. And you continue working exactly where you were before.
Perhaps you say: Take the document I received this morning, create a new project from it, analyse it and tell me if anything requires my attention. Your agent retrieves the document. It identifies the appropriate service. The specialist system performs the analysis. Your agent returns with the result. You may never have opened the application. Yet the application may have performed the most valuable work in the entire chain.
This is the idea behind what we might call Bring Your Own Agent. The technical foundations for it are no longer hypothetical.
The Model Context Protocol, or MCP, provides an open standard through which AI applications can connect to external data, tools and workflows. Its documentation describes the idea as something resembling a USB-C connection for AI applications: implement a common interface and different AI systems can connect to it. Other standards are developing around agent-to-agent communication, discovery, identity and authorization.
The precise protocols will change. Some will disappear. Others will emerge. The more important development is architectural:
Software is becoming callable by machines.
From applications to capabilities
This changes what an application is.
To a human, a software product might appear as a collection of screens, menus, tables, forms and buttons. To an agent, the same product could appear as a collection of capabilities: retrieve information, analyse a document, create a project, compare alternatives, calculate a result, modify a record, generate a report, submit an action.
The graphical interface is one representation of those capabilities. It is no longer necessarily the capability itself.
For decades, software architecture often placed the human interface at the centre. The user clicked a button. The button initiated an operation. The result appeared on another screen. An agent-native architecture reverses some of that thinking. The operation becomes the primary object. Different interfaces can invoke it: the application's traditional graphical interface, its own AI assistant, ChatGPT, an enterprise agent, or an interface that does not yet exist.
The application stops asking how its own AI should use the product. It starts asking:
How should any authorized intelligence use our capabilities?
The agent does not need to belong to the application
Many current AI strategies may be solving the wrong problem. We are putting copilots everywhere. Every application is acquiring a text box. Every service wants its own conversation. Every company seems to be creating an assistant with a slightly different name.
There are good reasons for this. A specialised agent can understand its domain deeply. It can interact closely with the graphical interface. It can provide an excellent experience for users who spend their day inside the application. And not everyone will arrive with an external agent.
But there is something strange about the assumption that humans will maintain dozens of separate relationships with dozens of artificial intelligences. Humans do not particularly want fifty assistants.
They want assistance.
Once an agent knows how I work, what I am responsible for, which projects matter to me, whom I work with, what I have already decided and what happened yesterday, switching to an application-specific assistant carries a cost. Context has to be reconstructed. Intent has to be explained again. The relationship starts from zero.
A sufficiently capable personal or organisational agent changes that equation. It already has the context. The new application merely contributes another capability.
The software disappears, but the value remains
This produces a superficially alarming possibility for software companies. Their applications may become less visible.
Imagine asking: What needs my attention this morning? The answer could require information from your calendar, email, accounting system, project management software and several specialist applications. You may see none of them. Your agent sees them.
Later you say: The revised proposal is in my email. Update the project, check the numbers and tell me if anything material changed. Several software products might participate. From your perspective, there was only one interface: the agent.
This does not mean those underlying products became less valuable. Quite possibly the opposite. A specialist system might perform calculations that a general-purpose model should never attempt itself. A financial system might enforce accounting rules. An engineering system might perform deterministic simulations. A legal database might provide authoritative source material. A scientific system might apply validated models.
The agent orchestrates. The specialist systems know. That distinction could become one of the defining characteristics of the next software architecture.
The return of headless software
The web gradually separated content from presentation. APIs later separated software capabilities from individual interfaces. Headless commerce separated storefronts from commerce infrastructure. Cloud services turned entire categories of technology into programmable building blocks. Agents extend the same idea one step further. They potentially separate human intent from application interaction.
An API allowed one piece of software to call another. An agent allows a human to express an objective without necessarily specifying which software should perform each step. That is a different kind of delegation. The user might no longer choose the application for every operation. The agent might.
Discovery becomes service discovery
This raises another question: how will software be discovered?
Today, software companies spend enormous effort becoming destinations. Search engine optimization, advertising, content marketing, landing pages, app stores, product tours, free trials, user onboarding. All of these mechanisms assume that a human discovers software and decides to interact with it.
An agentic ecosystem introduces another potential customer: the machine acting for the customer.
Imagine saying: Find a service capable of doing this analysis. My data must remain in Switzerland, it must provide an audit trail, and it must cost less than fifty francs per month. An agent could discover compatible services, inspect their capabilities, compare prices, evaluate jurisdiction and data-processing constraints, ask which standards they support, perhaps even test them. Then it could present a recommendation: this service meets your requirements; would you like to authorize it? Yes. Done.
Software discovery begins to resemble service discovery. The website does not disappear. But it may no longer be the only front door.
Interface lock-in weakens
For much of the SaaS era, competitive advantage has been partly built through interface ownership. Once a company persuades users to live inside its product, switching becomes expensive. Users learn the workflows. Organisations build procedures around them. Data accumulates. Integrations accumulate. Muscle memory accumulates. The interface itself becomes part of the moat.
Agents could weaken some of this. If I can express the same intent to my agent regardless of which underlying service performs the task, changing providers becomes easier. Instead of learning another application, I authorize another capability.
That does not eliminate switching costs. Data models matter. History matters. Integrations matter. Regulation matters. Trust matters enormously. But interface familiarity becomes a weaker form of lock-in. Other forms of differentiation become stronger: accuracy, domain knowledge, unique data, reliability, auditability, price, latency, privacy, jurisdiction, interoperability, trust.
In that world, the best software company may not necessarily be the company with the most addictive interface. It may be the company providing the capability that agents most confidently choose.
The dangerous concentration above the applications
Bring Your Own Agent sounds liberating. It could reduce dependency on individual applications. It might simply move the dependency one level upward.
If one agent mediates my email, calendar, documents, purchases, finances, communication, research and professional software, that agent occupies an extraordinarily powerful position. It sees my intent before the services do. It decides which services to call. It decides what information to present. It may decide what information not to present. It learns my preferences. It remembers my history. Eventually, it may influence which products I buy and which companies receive my business.
The browser became an important gateway to the web. Search engines became gateways to information. Mobile operating systems became gateways to applications. The personal agent could become a gateway to digital capability itself.
So the great platform battle of the agentic era may not be about who builds the largest number of AI features. It may be about something much more valuable:
Who owns the agent?
Sovereignty moves with the control point
That question has consequences far beyond consumer convenience.
Consider an organisation whose employees use an external agent to access internal systems. Where does organisational context accumulate? Who stores the agent's memory? Who determines which services it prefers? Who can inspect its decisions? Who controls its identity? Who can revoke its authority? Which jurisdiction governs the infrastructure? What happens when the provider changes its terms? And what happens when someone wants to move to another agent?
We already understand data portability reasonably well.
Agent portability may become equally important.
Can I take the accumulated working context of my agent with me? Its permissions? Its history? Its understanding of my preferences? Its relationships with services? If not, we may create one of the strongest forms of digital lock-in we have ever seen. The application lock-in of the SaaS era could look modest compared with an agent that has accumulated five years of someone's digital life.
Identity becomes infrastructure
There is another reason this transition will take longer than demonstrations suggest. Giving an AI access to information is relatively easy. Giving it authority is not.
There is an enormous difference between show me the current numbers and change them. There is an even larger difference between draft the transaction and execute it. Agents therefore require something more sophisticated than traditional application permissions.
A useful system needs to understand who the human is, which agent is acting, for whom it is acting, what the human has authorized, for how long, and for which context. It needs to know which actions can happen autonomously, which can only be proposed, which require explicit confirmation, which require stronger authentication, and what exactly happened afterwards.
This suggests that some of the most important infrastructure of the agentic era may not be conversational at all. It may be profoundly boring: identity, authorization, scopes, policy, audit trails, transactions, reversibility, provenance. These are the systems that turn an impressive demonstration into infrastructure people can trust.
Not every interface should disappear
The arrival of agents does not imply the death of graphical interfaces. Spreadsheets did not disappear when databases arrived. Websites did not disappear when mobile apps arrived. Command lines survived graphical operating systems. Each interface is good at different things.
Language is remarkably efficient for expressing intent. It is often terrible for inspecting complex state. Try understanding hundreds of interdependent values through conversation alone. A table is better. A chart may be better. A drawing may be essential. Sometimes the correct response from an agent will therefore be: here is the relevant interface.
The future may not be conversational software. It may be fluid software. Intent begins in language. The system invokes specialised capabilities. Visual interfaces appear when they are useful. The user manipulates something directly. The agent observes the change. The conversation continues. The distinction between using the agent and using the application begins to dissolve.
The application becomes a projection
This suggests a different way of designing software. Instead of building an application and later adding an AI layer, build a coherent domain system first. Its capabilities should be explicit. Its permissions should be explicit. Its state should be machine-readable. Its operations should be deterministic wherever possible. Its consequential actions should be governed. Then project interfaces onto it.
One projection is the traditional web application. One is mobile. One is the product's own assistant. One is an external agent. One may be an automated workflow. The interface becomes replaceable. The domain remains.
That is a resilient architecture because it avoids making a prediction about which AI company wins. ChatGPT might dominate. Gemini might. Apple could make the operating system itself the natural home of the personal agent. Enterprises may prefer agents they operate themselves. Open-source systems may create an entirely different ecosystem. There will almost certainly be agents we have not imagined yet.
A software company does not need to predict the winner. It needs to make sure the winner can securely use its product.
Build once. Let intelligence arrive.
There is an attractive simplicity to that principle. Do not build your business around somebody else's agent. Do not assume your own agent will become the centre of your customer's digital life either. Build the capability. Describe it clearly. Expose it through open standards. Protect it with strong identity and policy. Make consequential actions auditable. Then allow intelligence to arrive from wherever the customer chooses.
Your own agent can be one of those clients. It does not need to be the only one.
This is not merely an integration strategy. It is a position on technological sovereignty. The customer retains a choice of intelligence. The application retains control of its domain rules. Neither needs to surrender completely to the other.
After the interface
For forty years, we have repeatedly changed the place where humans meet computers. The command line gave way to the graphical desktop. The desktop gave way to the web. The web was joined by the smartphone. Every transition produced companies that mistook the previous interface for the underlying value.
The next transition may be stranger, because this time the interface itself can understand what we want. When that happens, we may stop navigating software in order to operate it. We may simply express intent. Our agent will determine which capabilities are required and negotiate with the systems behind them.
Applications will still exist. Interfaces will still matter. Beautiful software will still be valuable. But the assumption that every digital service must own the human relationship may not survive.
And perhaps the most important question for software companies is therefore no longer how we put an agent inside our product. It is:
How does our product exist in a world where the user already has one?
Because the AI feature may not ultimately live inside your software.
Your software may live inside somebody else's AI.
And if that happens, the last interface we build may not belong to an application at all.
It may belong to us.
Sources
-
Model Context Protocol — Introduction Open standard for connecting AI applications to external data, tools and workflows; the documentation uses a USB-C analogy for a common interface. MCP Introduction
-
Model Context Protocol — Specification Authoritative protocol requirements for hosts, clients and servers exposing tools, resources and prompts. MCP Specification
-
OpenAI — MCP and Connectors Developer documentation for connecting ChatGPT and related applications to MCP servers. OpenAI — MCP
-
OpenAI — Apps in ChatGPT Product announcement of applications that run inside ChatGPT, illustrating an agent-owned interface in front of third-party capabilities. OpenAI — Apps in ChatGPT
-
Anthropic — Introducing the Model Context Protocol Anthropic's announcement of MCP as an open standard for connecting assistants to the systems where data lives. Anthropic — MCP
-
Google Developers Blog — Agent2Agent Protocol Announcement of A2A as an interoperability protocol for agent-to-agent communication. A2A
-
Google Developers Blog — Agentic Resource Discovery Announcement of ARD, an open specification for publishing, discovering and verifying AI capabilities across domains. ARD
-
Apple Developer — App Intents Framework for exposing an application's capabilities to Siri and system intelligence through structured intents and entities. App Intents
-
Apple Developer — Apple Intelligence Documentation of Apple's personal intelligence system and the case for the operating system as a home for the personal agent. Apple Intelligence
-
OWASP — Top 10 for Agentic Applications (2026) Security risks particular to autonomous agents, including identity and privilege abuse, memory and context poisoning, and insecure inter-agent communication. OWASP Agentic Top 10
-
OpenClaw Open-source personal assistant that runs on the operator's own devices, with state held locally rather than in a vendor cloud. OpenClaw