What is Agent Mode? Microsoft, Cursor, GitHub Copilot, and OpenAI in 2026

Bottom line. Three different product classes are shipping under the Agent Mode brand in 2026: Microsoft 365 Copilot for productivity-suite agents, Cursor for developer-IDE agents, and GitHub Copilot Coding Agent for code-platform agents (Microsoft 365 Copilot agents). The procurement decision is not a feature comparison across the three, because they are not substitutes. The decision is which class fits the in-house workflow, which stack already runs in production, and where the budget for it sits. Treating the three as comparable line items is the most-common 2026 enterprise procurement error in agentic AI.

Why “Agent Mode” stopped being a feature and became three categories

In 2024 and into early 2025, “agent mode” was a feature toggle. A chat product would let the model take a few autonomous steps (call a tool, read a file, write to a sandbox) before returning to the user. By mid-2025 the toggle had a recognisable shape: same chat surface, slightly more autonomy, single product. By 2026 the term has split. Three vendors, Microsoft, Cursor, and GitHub, each ship a product mode they call “Agent Mode,” each anchored in a different surface, each operating on a different data model, each selling into a different budget centre. The brand is the same; the products are not.

The split matters for enterprise IT because procurement teams treat brand as the procurement primitive. A vendor walks in claiming “we ship Agent Mode,” a competing vendor walks in claiming the same, and the buying motion compresses the two onto a feature-matrix that compares the wrong things. It is the agentic-AI equivalent of comparing “the cloud” across hyperscalers as if AWS Lambda and Azure Synapse were the same product. They share a category label and almost nothing else.

The publication’s read on the 2026 vendor landscape is that the brand collision is structural, not transient. Microsoft has too much marketing investment in Agent Mode as the brand for Microsoft 365 Copilot’s autonomous tier to retire it. Cursor is building category leadership in IDE-class agents under the same name. GitHub’s Copilot Coding Agent is rolling out under “agent” framing across the platform. OpenAI is the partial outlier: its Agents SDK is positioned as a developer platform rather than as an Agent Mode toggle inside ChatGPT, but the platform-versus-mode distinction is itself part of the procurement story rather than a way out of it.

What follows is the operational shape of each of the three Agent Modes, the fourth-wave platform layer (Anthropic and OpenAI) that competes for adjacent budget without using the term, and a three-question decision tree that resolves which class an enterprise should buy.

Microsoft 365 Copilot Agent Mode: productivity-suite class

Microsoft 365 Copilot Agent Mode operates inside the Microsoft 365 surface (Outlook, Teams, Word, Excel, SharePoint) against Microsoft Graph as the data substrate (Microsoft 365 Copilot agents documentation). Agents are authored in Copilot Studio (the tenant-scoped low-code builder) or shipped by Microsoft as first-party agents like the Researcher and Analyst variants Microsoft documented in 2026. The runtime is the Microsoft Graph permission model: an agent can read what the invoking user can read, can write where the invoking user can write, and is governed by the same conditional-access and DLP policies that the M365 tenant already enforces.

The surface defines the procurement story. Microsoft 365 Copilot Agent Mode is sold against M365 E3 / E5 licensing as an add-on and is consumed through tools the in-house workforce already uses daily. The buying budget is productivity-software licensing, not engineering tooling. The success metric is hours-saved on knowledge-worker workflows that were already happening in M365 (drafting status updates from Teams threads, summarising long Outlook chains, populating an Excel sheet from a SharePoint document set), not net-new automation outside the suite. The integration cost is low because the agent inherits the tenant’s identity, permission, and DLP plane already in place.

The constraints are also defined by the surface. Microsoft 365 Copilot Agent Mode is not the right primitive for code generation against a private repo (the repo is rarely on the Graph), it is not the right primitive for IDE-resident multi-file edits (no IDE), and it is not the right primitive for a deployment that needs to operate against non-Microsoft data sources without significant connector work. Enterprises trying to bend M365 Copilot Agent Mode into developer or platform-engineering use cases are typically bidding against the wrong product class; the Microsoft Copilot vs Salesforce Agentforce comparison is the head-to-head against the closest productivity-suite competitor.

The pricing posture in 2026 is per-seat with consumption-style add-ons for high-volume agent invocations (our-estimate on the relative weight of seat versus consumption, because Microsoft’s pricing has been moving on roughly quarterly cadence and the steady-state mix is not yet visible). The headline number for procurement is that Microsoft 365 Copilot Agent Mode does not have a dominant per-action cost in the way an IDE-class agent does; the dominant cost is the seat licence layered on top of the existing M365 contract.

Cursor Agent Mode: developer-IDE class

Cursor’s Agent Mode operates inside the Cursor IDE (a fork of VS Code) against a developer’s open repository (Cursor.com). The product layers two related autonomies: Composer for synchronous multi-file edits coordinated by the developer, and Agent Mode for asynchronous longer-horizon tasks where the IDE itself drives a sequence of file reads, edits, and tool calls under a model the developer has selected. Model selection is a first-class primitive: the developer chooses Claude, GPT, or Gemini per task, with the IDE acting as the orchestration layer (Cursor model docs).

The surface is the IDE; the procurement story flows from there. Cursor is sold as a per-developer subscription and is paid out of the developer-tools budget, the same budget that pays for JetBrains, GitHub Copilot, or VS Code extensions. The success metric is throughput on individual-developer workflows: how quickly a senior engineer can land a refactor, how quickly a junior engineer can ramp on a new codebase, how quickly an architect can prototype a service. The integration cost is low for individual developers (install the IDE, point at a repo) and rises sharply when the deployment is institution-wide because the model-portability story produces governance, security, and per-model cost questions that a single-vendor IDE plug-in does not raise.

The constraints follow the IDE substrate. Cursor’s Agent Mode is not the right primitive for a workflow that lives outside the IDE: a code review that has to land as a GitHub pull request with CI runs, an autonomous task that has to operate without a developer at the keyboard, or an agent that has to integrate with the corporate identity provider in the same way a platform-class agent must. The model-portable architecture is a feature for individual developers and a procurement question at scale: which models are approved for which classes of work, who signs off on data leaving the tenant boundary when a Cursor model invocation happens, and what observability layer captures the per-model traces. The Cursor vs GitHub Copilot comparison is the head-to-head against the closest developer-tools competitor.

The pricing posture in 2026 is per-seat with usage tiers tied to the model selection. The developer’s choice of model materially affects the per-seat consumption, and the contract typically includes a fast-iteration clause because Cursor’s pricing has moved on roughly bi-monthly cadence over the past year (our-estimate on the cadence specifically; Cursor’s pricing page is the live source). Enterprises evaluating Cursor at scale should treat the per-seat number as a floor, not a forecast, and run a 90-day actual-usage baseline before committing to a multi-year SKU.

GitHub Copilot Coding Agent: code-platform class

GitHub Copilot Coding Agent operates inside the GitHub platform (repository, issues, pull requests, Actions) as a first-party agent that responds to a GitHub issue or PR by opening a branch, committing changes, running CI, and engaging with reviewer comments (GitHub Copilot features). Where Cursor’s agent lives in an IDE, GitHub’s lives in the platform. The agent is invoked with a GitHub-native event (an issue assignment, a PR comment) and produces a GitHub-native artifact (a pull request with CI runs and reviewer responses). The runtime is GitHub Actions and the GitHub repository permission model.

The surface defines the procurement story. GitHub Copilot Coding Agent is sold against the GitHub Enterprise contract (Copilot Business or Copilot Enterprise tiers) and is paid out of the developer-platform budget, often the same budget centre that pays for the source-control system itself. The success metric is throughput at the platform level: PR cycle time, issue-to-merge latency, the share of routine maintenance tasks (dependency upgrades, documentation refresh, test coverage gaps) that the agent handles without a human in the keyboard. The integration cost for an existing GitHub Enterprise tenant is low. The agent inherits the tenant’s identity, permission, branch-protection, and SAST/DAST policy already configured, and rises only when the in-house platform is not GitHub.

The constraints follow the platform substrate. GitHub Copilot Coding Agent is not the right primitive for an enterprise on GitLab, Bitbucket, or a self-hosted source-control system that is not GitHub; the platform-native surface is the value. It is not the right primitive for IDE-resident multi-file authoring during active development; that is Cursor’s surface. And it is not the right primitive for productivity-suite work outside source control, because the platform is, definitionally, source control. Procurement teams that buy GitHub Copilot Coding Agent expecting it to substitute for Cursor (or vice versa) are buying across categories that are adjacent rather than substitutable.

The pricing posture in 2026 is per-developer-seat layered on top of the GitHub Enterprise contract, with the agent’s CI usage flowing through the existing GitHub Actions consumption model. The headline number for procurement is the marginal CI minutes the agent consumes; an asynchronous coding agent that opens many PRs per developer per day will materially shift Actions billing in a way the equivalent IDE-class agent does not. The contract should include a 60-to-90-day baseline and an Actions-budget cap during the pilot phase. The deployment patterns map onto the pilot-to-production framework the publication has covered for adjacent agent deployments.

The fourth wave: agent platforms, not Agent Modes

A fourth class is shipping through 2026 and competes for adjacent enterprise budget without using the Agent Mode brand: agent platforms.

Anthropic’s Claude Managed Agents entered public beta in April 2026 as a platform for building custom agents on the Claude foundation: a managed runtime, a tool-integration layer, and the per-agent identity primitives that the non-human-identity playbook covered in detail. OpenAI’s Agents SDK is positioned similarly as the developer substrate for building agents inside or outside the ChatGPT product surface (OpenAI Agents). Both compete with the three Agent Modes for adjacent budget (platform engineering, internal-platform-team time, the build-versus-buy axis) without overlapping their surface.

The procurement question they raise is different. The three Agent Modes ask “which surface does my workflow live in?” The agent platforms ask “is my workflow well-served by any of those surfaces, or do we need to build a custom agent against the foundation model directly?” An enterprise that has answered the first question with “none of the three surfaces fit our workflow” is, by exclusion, in the platform-class buying motion. The architectural commitment is materially larger: not a per-seat licence layered on an existing tenant, but a build commitment from a platform-engineering team operating against identity, governance, and detection primitives that the platform layer does not ship out of the box.

The buying signal that distinguishes the platform-class from the Agent Mode classes is the question of who the agent’s principal identity belongs to. In Microsoft 365 Copilot Agent Mode, the principal is the M365 user. In Cursor, the principal is the developer at the keyboard. In GitHub Copilot Coding Agent, the principal is the GitHub user who triggered the agent. In a platform-class deployment, the agent has its own principal identity that the in-house IAM extension model has to model directly. That distinction is the one the non-human-identity playbook and the related agent-identity architecture piece work through; it is the procurement-fork that separates a per-seat decision from a platform-engineering decision.

The procurement decision tree

The three-question tree resolves which Agent Mode (or platform-class agent) fits a given enterprise procurement.

Question 1: which workflow is the agent supposed to enter? If the workflow lives inside the productivity surface (Outlook chains, Excel modelling, Teams updates, SharePoint document sets), the answer is productivity-class (Microsoft 365 Copilot Agent Mode). If the workflow lives inside an IDE during active development (multi-file refactors, codebase navigation, prototype-to-PR), the answer is IDE-class (Cursor). If the workflow lives inside a code platform’s pull-request and CI loop (autonomous PR opening, issue-to-merge), the answer is platform-class (GitHub Copilot Coding Agent). If the workflow does not live cleanly in any of those surfaces, the answer is platform substrate (Anthropic Managed Agents, OpenAI Agents SDK).

Question 2: what is the in-house tool stack? The Agent Mode that fits the workflow has to fit the existing stack. An enterprise running Microsoft 365 across the workforce buys productivity-class Agent Mode at low integration cost. An enterprise on Google Workspace has the same workflow shape but a different stack; buying Microsoft 365 Copilot Agent Mode in that stack is a stack-migration project, not an Agent Mode purchase. An enterprise on GitLab or Bitbucket buys GitHub Copilot Coding Agent only if the buying motion includes a GitHub migration; otherwise the equivalent product on the in-house platform (or a platform-class agent) is the buy. The decision tree’s second cut is the stack-fit; misalignment here is what produces the multi-million-dollar deployments that show up as failed procurements in the 18-month retrospective.

Question 3: where does the budget sit? Productivity-class is paid out of M365 licensing. IDE-class is paid out of developer-tools budget. Platform-class is paid out of developer-platform / source-control budget. Platform-substrate is paid out of platform-engineering or AI-platform budget. Misalignment between the buying motion and the budget centre is the leading indicator that the deployment will struggle past pilot. The buying CIO has approved the spend, but the operational owner has different success metrics, different incentives, and different reporting lines. The CFO business-case framework walks the budget-alignment question in detail; the short version for the procurement decision is that the budget centre should match the success metric, and the success metric should match the workflow.

The three questions, taken in order, resolve the Agent Mode purchase to a single product class with high reliability. They do not resolve the within-class vendor choice (productivity-class has Microsoft and a small set of partial substitutes, IDE-class has Cursor and the closest competitors, platform-class has GitHub and the closest competitors), but they prevent the cross-category procurement error that defines most 2026 Agent Mode buying motions.

What the term “Agent Mode” obscures

The brand collision has a specific procurement consequence. When three vendors ship a product called Agent Mode and a procurement team asks for a feature comparison, the natural document is a matrix with the three products as columns and a list of features as rows. The matrix is built and the team picks the product that scores highest on the most rows.

The matrix is structurally wrong because the rows are not features; they are surface-specific capabilities. “Multi-file edits” is a feature for Cursor and not a feature for Microsoft 365 Copilot Agent Mode because Microsoft 365 Copilot Agent Mode does not operate on a multi-file repository as its substrate. “Outlook chain summarisation” is a feature for Microsoft 365 Copilot Agent Mode and not a feature for Cursor because Cursor does not operate on Outlook. The matrix produces a winner only because rows where one product has nothing to evaluate against are scored as zero rather than as not-applicable; the winner is the product whose surface happens to overlap most with the chosen feature list. This is not a comparison; it is a category-confusion artifact.

The corrective is structural. Procurement teams running an Agent Mode evaluation should produce three artifacts before the matrix: a workflow map (what does the in-house workflow actually look like), a stack map (what tools and platforms does it currently run on), and a budget map (where does the spend sit and what is the operational owner’s success metric). The three maps determine the class of agent that is in-scope for the comparison. Only then does a within-class matrix produce a useful decision.

The structural framing also clarifies what to ignore. Vendor-supplied feature comparisons across the three product classes (productivity, IDE, platform) are marketing artifacts. They are not procurement inputs. A vendor whose primary product is an IDE-class agent has every reason to draw a comparison against productivity-class and platform-class on rows their product is built to win; the same is true in the other direction. The within-class matrix is the procurement input. The cross-class comparison is the marketing collateral.

The Holding-up note

The primary claim of this piece (that Agent Mode is the same brand-name shipping in three different product classes in 2026: productivity-suite, developer-IDE, code-platform, and that the procurement decision is a class-fit question rather than a feature-comparison question) is logged at AM-141 on the Holding-up ledger on a 60-day review cadence. Three kinds of evidence would move the verdict:

1. Brand consolidation. If Microsoft, Cursor, or GitHub retired the Agent Mode brand or repositioned it under a different umbrella name, the three-class framing this piece asserts would simplify into a different shape. The 2026 trajectory is the opposite (all three vendors are deepening the brand commitment), but the verdict would update if that changed.
2. Cross-class substitutability. If a productivity-class agent shipped a credible IDE substrate, or a platform-class agent shipped credible productivity-suite integration, the categories would start to overlap. The vendor signals as of mid-2026 are that the surfaces are deepening rather than blurring; substantial change in that direction would update the verdict.
3. Platform-class entry into the Agent Mode brand. If Anthropic or OpenAI shipped a product called Agent Mode that occupied the platform-substrate position, the four-class framing would compress into a coherent four-Agent-Mode story. As of 7 May 2026 neither vendor has done this; the platforms are positioned distinctly. The verdict would update if that changed.

The next review of this claim is scheduled 6 Jul 2026.