Within five days, Microsoft, OpenAI and Google presented three different versions of software organized around an agent rather than an application. Microsoft placed documents, communication, software creation and autonomous workflows inside a redesigned Copilot. OpenAI introduced persistent agents that continue working across connected services after a conversation ends. Google launched Gemini 4 Argon for long-running professional tasks across software engineering, finance, law and cybersecurity.
The products differ in maturity and intended use, but they share an important architectural assumption. Users will increasingly describe the result they need to an agent, which will then decide which applications, data sources and specialized tools should be involved. If that becomes a common way of working, enterprise applications will continue performing much of the work while gradually surrendering the interface through which users initiate and understand it.
Microsoft wants Copilot to organize the working day
Microsoft’s new Copilot is built around three connected areas. Home combines AI chat with email, calendars, workplace updates and the applications inside Microsoft 365. Code allows employees to create and share internal software using the technology behind GitHub Copilot. Autopilot can monitor activity and complete recurring processes across Microsoft and third-party services.
The product is designed to absorb work that previously began inside separate applications. An employee can arrive with a request, use Copilot to collect the relevant context, create a small application if the process requires one and delegate its continued execution to Autopilot. Microsoft still benefits when Word, Excel, Outlook or Teams performs part of the job, but those products become components inside a broader experience rather than separate destinations.
This helps explain why Satya Nadella has described Copilot as a new operating system for work and why Microsoft is comparing its ambitions with the influence Office had during the PC era. The comparison concerns control over the working environment. An operating system does not perform every task itself; it provides the layer through which other capabilities are accessed, coordinated and governed.
OpenAI’s Dots pursue a similar position from outside the traditional enterprise-software stack. OpenAI describes them as always-on agents capable of assuming an ongoing responsibility, working across applications and returning when human input is required. Google’s Gemini 4 Argon adds the model capacity required for longer professional workflows involving several documents, systems and decisions. Across all three announcements, the interaction is moving from selecting software toward assigning work.
The application remains, while its interface recedes
Salesforce has described the possible result more explicitly than most AI companies. In its architecture for the “agentic enterprise”, it expects applications to remain systems of record while evolving from monolithic interfaces into “headless” capabilities that agents can call through APIs and events.
Consider a sales manager trying to identify accounts at risk and decide where the team should intervene. That process may require customer records from Salesforce, recent conversations from Gong, product-usage data from another platform and messages drafted through Outlook. Today, the manager or an analyst moves between those systems and assembles the answer. An agent can instead collect the necessary information, apply the company’s rules and use each product when its capabilities are needed.
The CRM continues to store the customer history and enforce access permissions. The conversation platform still provides its analysis, while the communication system sends the approved message. Their operational value remains intact, although the user may experience the entire process through Copilot, a Dot or an agent embedded elsewhere.
This distinction matters because the most dramatic predictions about AI replacing SaaS overlook what enterprise applications contain. Their value comes from proprietary data, transaction histories, compliance controls, specialized business logic and years of integration with the rest of the organization. Those assets cannot be reproduced by adding a conversational interface. What an agent can do is reorganize access to them, reducing the need for people to navigate each product directly.
Software is being redesigned for machine users
The emerging agent infrastructure shows that this is becoming an engineering concern as well as a product vision. The Model Context Protocol allows software to expose tools that a model can discover and invoke, including database queries, API calls and computational operations. Its July 2026 specification added stronger authorization mechanisms and support for long-running tasks, bringing the protocol closer to enterprise requirements.
The Agent2Agent protocol, developed by Google and later donated to the Linux Foundation, addresses coordination between agents created by different vendors. Together, these standards create machine-readable routes through the software stack: MCP allows agents to use tools and data, while A2A allows specialized agents to exchange information and divide work.
Software therefore has to serve two types of user. The human-facing product still needs a comprehensible interface, especially for configuration, review and consequential decisions. Its machine-facing counterpart needs well-described capabilities, structured outputs, predictable failure states, scoped permissions and reliable ways to confirm or reverse an action. Products that expose their value cleanly to agents may be selected more often, even when the person receiving the result never opens them.
That changes the basis of competition. Interface quality has been one of the principal ways SaaS companies differentiate similar underlying functions. In an agent-mediated workflow, integration quality, data structure and operational reliability gain importance because the agent selects capabilities according to what it can discover and use consistently.
Owning the request may matter as much as executing it
In Stratechery, Ben Thompson connects the redesigned Copilot with Microsoft’s earlier attempt to make Teams an operating system for SaaS. His argument is that the agent can become an aggregation layer above individual applications, controlling the point where users express their intent and where completed work is returned.
Enterprise-software companies are responding by trying to control both sides of that relationship. Salesforce is preserving the CRM as a system of record while building Agentforce as the layer that acts across it. SAP CEO Christian Klein has similarly argued that agents depend on the integrated data and business processes inside enterprise platforms, while positioning Joule as the interface through which users access those capabilities.
The eventual structure may therefore contain several competing agents: broad platforms operated by Microsoft, OpenAI and Google, alongside specialized agents built by Salesforce, SAP and individual software providers. The commercial advantage will belong to whichever layer receives enough context and authority to coordinate the complete workflow.
Applications with distinctive data, regulated processes and deeply embedded operational functions will remain difficult to displace. Products whose advantage lies primarily in presenting interchangeable functionality through a convenient interface face a more serious problem. Once an agent can compare, select and invoke that functionality on the user’s behalf, the product can continue serving the customer while losing visibility into the relationship.
The defining SaaS companies built applications where people performed their work. The next major software platforms are trying to become the place where people request that the work be done. If they succeed, much of the existing software stack will survive beneath them, active and commercially important, while becoming progressively harder for its users to see.
