In 2026 there is no enterprise software vendor left without an agent. Microsoft has Copilot agents, Salesforce has Agentforce, SAP has Joule, Atlassian has Rovo, ServiceNow has its AI Agents. Each of them is good at one thing: the system it ships with.

That is also the problem. Your work does not stay inside one system. A customer escalation starts in the CRM, becomes a ticket, needs a Confluence page and ends in a contract change in the ERP. This page sorts the market into four layers, plus the new always-on agents, so you can see which agent covers which part of that path, and where nobody does.

Agents in the work suite

These agents sit where everyone works: documents, chat, wiki, search. They reach the most people and see the widest, but shallowest, slice of the company.

Agents in the business systems

These agents sit in one system of record and act inside its processes. They go deep, and see little outside it unless someone connects it.

Platforms for building your own

When no product agent fits your process, you build one. The hyperscalers and the model providers now sell the plumbing: hosting, memory, identity, tracing.

• Hyperscalers: Amazon Bedrock AgentCore, Gemini Enterprise Agent Platform (Google's agent tooling, formerly under Vertex AI), Azure AI Foundry Agent Service.
• Model providers: Claude Agent SDK, OpenAI Agents SDK.
• Low-code and automation: Copilot Studio, Rovo Studio, UiPath, n8n.
• Open source: LangGraph, CrewAI, Microsoft Agent Framework, and self-hosted personal agents such as OpenClaw.

Which of these fits depends less on features than on who will run it. We compare the three types of personal agent in Personal AI Agents in the Enterprise.

Always-on agents: Microsoft Scout and Autopilots

At Build 2026, Microsoft launched Scout and calls it its first “Autopilot”: an assistant that runs in the background instead of waiting for a prompt. It lives in Microsoft 365, works across inbox, calendar, desktop and browser, and learns how its user works by turning feedback into skills and memories. Users set its permissions and policies, and Microsoft says it runs inside the customer’s tenant with enterprise compliance. Scout is built on the open-source OpenClaw framework; Microsoft positions it as an enterprise-grade version of that model, with a policy conformance system that checks the agent continuously and writes an audit trail for each check. It is available first through Microsoft’s Frontier early-access programme and requires a GitHub Copilot subscription.

Where it fits on this map: Scout is the point where two of these layers meet. It has the reach and persistence of a personal agent like OpenClaw, and the identity, policy and audit controls a suite vendor can add. It also stays a Microsoft 365 agent. It is strongest where your work already lives in Microsoft’s ecosystem; the SAP order and the Jira backlog still come in through connectors and MCP. Expect the other suite vendors to follow with their own always-on agents, which makes the cross-system layer below more important, not less.

The layer that connects them

Here is the point most vendor slides skip. Out of the box, a Copilot agent does not see your SAP order and a Joule agent does not read your Jira backlog. Connectors exist, but somebody has to choose, secure and run them. The value sits in the hand-offs between systems, and that is exactly the part no single product agent owns.

Three building blocks are turning into the standard answer:

• Open interfaces. The Model Context Protocol (MCP) connects an agent to tools and data; Agent2Agent (A2A) lets agents hand work to each other. Vendors are opening up through them: At Team ’26 in May 2026, Atlassian opened its Teamwork Graph to outside agents through the Rovo MCP server (in beta).
• An identity per agent. An agent that acts needs its own identity, an owner and scoped permissions, not a shared service account. Microsoft's Entra Agent ID is one example.
• One registry and audit trail. Somebody has to know which agents exist and what they did. Microsoft Agent 365 and Salesforce's agent oversight in Agentforce 360 are vendor answers, but each covers its own ecosystem best.

What to decide first

• Map the process, not the vendor. Draw one end-to-end process and mark which system each step lives in. That shows which agents you need and where the hand-offs are.
• Use the agent of each system for the work inside it. It knows the data model and the permissions. Do not rebuild what the suite already does well.
• Own the cross-system layer yourself. Interfaces, agent identities and the audit trail are the part you must not hand to one vendor, because it is the part that has to work across all of them.
• Decide who approves what. Reads can run free. Anything that changes a system of record, leaves the company or costs money needs a human approval and a log entry.