The Sales Close Agent Retirement Isn’t a Feature Swap. It’s a Platform Move.

Solution architect reviewing AI sales agent configuration dashboards on a dual-monitor workstation

A Dynamics 365 Sales architect who spent March configuring the Sales Close Agent for a client’s inside sales team is about to find out that work has an expiration date. September 30, 2026 is the last day anyone can stand up a new instance of the agent. October 30 is the day every existing instance, configured playbooks and all, gets pulled from every environment where it runs. Neither date has gotten much attention outside Microsoft’s own deprecation notes, and the Sales Close Agent retirement comes with a single sentence of guidance: create an instance of Sales Development Agent instead. For a solution architect who built engagement rules, email cadences and knowledge sources around the old agent, that sentence undersells how different the replacement actually is.

Solution architect reviewing sales automation agent configuration on a dual-monitor workstation

What the Sales Close Agent actually does today

Sales Close Agent, still labeled a production-ready preview, was built to run high-velocity, low-complexity deals without a seller touching them until something goes wrong. It works against accounts, contacts, leads and opportunities that match target-customer criteria an admin defines during setup, then sends templated outreach email pulled together from a configured profile, product catalog and a set of knowledge sources. Everything about the agent lives inside Dataverse and Copilot Studio: admins configure it through a settings page inside the Sales Hub, security is granted through custom or out-of-the-box Salesperson roles, and every run is tracked as a record in the msdyn_salesagentrun entity, filterable by status (active, completed, failure) and viewable through standard model-driven views like “Opportunities from Sales Close Agent.”

The mechanics underneath are more rigid than most admins expect once they read past the marketing description. The agent caps outreach at 20 emails per ten-minute window, specifically to control AI credit consumption rather than deliverability. Follow-up cadence is fixed at up to four emails over three weeks and isn’t configurable without a support ticket to Microsoft. If a customer goes quiet, the agent auto-closes the record as lost; if it detects an objection past its comfort level, it escalates to a human seller with full interaction history attached to the record’s timeline. None of that is unreasonable for a first-generation automation feature. It’s also all going away in a matter of weeks, and unlike most Dynamics 365 retirements, this one comes with no in-product migration wizard.

The Sales Close Agent retirement doesn’t come with a migration path

Sales Development Agent, the named successor, doesn’t live in Dynamics 365 Sales at all. It’s a Microsoft Agent 365 offering, deployed and configured from inside Microsoft Teams, currently gated behind the Frontier preview program and requiring an organization to have opted into Microsoft 365’s Targeted Release track for the relevant users, or the whole tenant. That single prerequisite is worth checking before anything else, because an architect who assumes the replacement will simply appear in the Power Platform admin center the way Sales Close Agent did will instead find nothing there to configure. The agent is deployed from the Teams Store or the Microsoft 365 Copilot agent store, and every bit of its setup happens conversationally: you tell it, in a Teams chat, to define a playbook, share sample emails so it can match your tone, upload product documentation as PDFs or Office files, and set a send window such as weekdays between nine and five Pacific.

That configuration model is a real structural difference, not just a change of interface. Sales Close Agent’s behavior comes from admin console pages: profile, product details, target customers, email delivery, email content, knowledge sources, each with its own screen and its own “avoid edits after publishing” warning. Sales Development Agent’s behavior comes from four looser components (playbook, guidelines, product knowledge, and settings) assembled through natural-language instructions inside a chat thread, then validated by uploading a test prospect list and running simulated conversations before typing “go live.” An architecture team used to documenting agent configuration as a set of screenshots from admin pages will need a different documentation approach entirely, since there’s no settings UI to screenshot.

Reconnecting it to Dynamics 365 isn’t automatic either

If Dynamics 365 is the system of record, Sales Development Agent doesn’t sync with it by default. Connecting the two is an explicit, multi-step process: assign the agent a Sales license in the Microsoft 365 admin center, add it to the Dynamics 365 Sales instance with a Salesperson role through the Power Platform admin center, enable the Dataverse Model Context Protocol server in that environment, publish that MCP server using VS Code or the Agent 365 CLI, and then wait for a Global Administrator or AI Administrator to approve the resulting server request before the agent can pull prospect lists from Dataverse or write engagement history back to lead records. That approval step alone means CRM integration for the new agent isn’t something a Sales Hub admin can finish alone; it requires a security decision from someone with tenant-level access, on a timeline that doesn’t care whether your old agent is a week from deletion.

Team collaborating around a Teams-based AI agent configuration screen with sales pipeline data

What this means for a migration plan

Treat this less like a version upgrade and more like standing up a new integration on a deadline. There is no data or configuration carryover: target-customer criteria, product catalog mappings and knowledge source references built into Sales Close Agent don’t transfer, because the two agents don’t share a configuration schema. Prospect data for the new agent needs to arrive as a CSV or Excel file with specific column requirements (email, company name, product, first name, with optional language and country columns for its 22 supported languages), which is a different intake format than anything the old agent’s target-customer configuration expected. And because the replacement currently sits behind Frontier and Targeted Release enrollment, the realistic first step for most teams isn’t configuration at all, it’s confirming with the Microsoft 365 admin whether that enrollment exists yet, since a tenant that isn’t enrolled has no path to the replacement on October 30 regardless of how well the rest of the migration is planned.

Worth flagging to any CFO or IT Director signing off on this work: Sales Development Agent, as documented today, runs without a per-action approval step once it’s live, replies only to email threads it personally started, and has no visual reporting dashboard, with campaign and prospect summaries delivered as answers inside a Teams chat instead. None of those are dealbreakers for a lead-qualification workflow, but they are a materially different governance posture than a Dataverse-native agent whose every run is a queryable, reportable Dataverse record. A rollback plan matters here in a way it usually wouldn’t for a routine feature update, since the source system disappears on a fixed date whether or not the destination is ready.

The narrow window that actually matters

Ten days separates today from the last date to create a new Sales Close Agent instance, and forty days separates it from the date every existing instance disappears regardless of migration status. Neither Microsoft’s release-plan entry nor its deprecation notice describes a bridge between the two agents beyond that single line of guidance, which leaves the actual migration work, mapping old configuration intent to new playbook language, resolving the Frontier and Targeted Release prerequisite, and running the MCP server approval chain, entirely on the implementation team. Routeget Technologies has walked several clients through comparable agent-to-agent platform moves inside the Dynamics 365 ecosystem this year, and the pattern holds here too: the teams that treat this as infrastructure work, with its own project plan and its own risk review, come through it in better shape than the teams who wait for the in-product banner to remind them.

#SalesCloseAgent #SalesAIAgents #Agent365 #CRMGovernance #AgentMigration #DataverseMCP

Microsoft Agent 365 Governance Is GA. Is Your Copilot Studio Fleet Ready?

IT director reviewing an AI agent governance dashboard on a large office monitor

When a mid-market manufacturer’s IT Director asked her Power Platform administrators for a simple headcount this spring, how many Copilot Studio agents actually exist across the organization, the answer took three weeks to assemble and still arrived with an asterisk. Some agents had been built by finance analysts using maker licenses nobody remembered granting. A handful had default connections into Dataverse tables holding customer payment history. Nobody could say with confidence who owned any of them once the person who originally built them changed teams or left the company. That scramble is becoming a familiar story across Dynamics 365 and Power Platform shops, and it is exactly why Microsoft Agent 365 governance has become a live budget conversation since the platform reached general availability on May 1, 2026.

IT director reviewing an AI agent governance dashboard on a large office monitor

Agent 365 is Microsoft’s control plane for observing, governing, and securing AI agents across an enterprise, regardless of where those agents were built. It applies to prebuilt Microsoft 365 Copilot agents, agents built in Microsoft Foundry, and, most relevant to this audience, agents built in Copilot Studio. For IT Directors and CIOs who have spent the last eighteen months watching Copilot Studio adoption spread from a handful of IT-sanctioned bots into dozens of business-unit-built agents, Agent 365 is the first serious attempt at a single inventory and policy layer that sits over all of it. Whether it is worth the licensing commitment depends less on the feature list and more on how much organizational work a rollout actually requires, which is the part vendor briefings tend to gloss over.

What Agent 365 governance actually covers

The platform’s job splits into three functions: observing agent activity across apps, endpoints, and cloud services; governing agents through policy-based controls and lifecycle management, meaning admins can install, publish, block, or reassign ownership of an agent directly from a central registry; and securing agents against threats such as over-privileged actions or misuse of connected data sources. Microsoft Defender now assesses the security posture of Foundry and Copilot Studio agents specifically, flagging risky configurations, including agents wired up to Model Context Protocol tools that could open a path to privilege escalation, and surfacing prioritized recommendations rather than a raw vulnerability dump.

The governance layer also introduces a formal approval and publication flow. Before an agent built in Copilot Studio reaches end users, an admin can review its data access, permissions, and security posture from the registry, rather than relying on the maker’s own judgment about what the agent should be allowed to touch. For any IT Director who has inherited a Copilot Studio environment where publication controls were an afterthought, this is the feature that closes the gap between having a data loss prevention policy on paper and actually enforcing it before an agent goes live.

One capability worth flagging separately is shadow AI discovery. Agent 365 uses Microsoft Defender and Intune to identify locally running agents on Windows endpoints that were never provisioned through any sanctioned platform. At GA, this covers agents built on the OpenClaw framework, with support for GitHub Copilot CLI and Claude Code agents promised to follow. It is a genuinely new capability, since most governance conversations to date have focused on what happens inside Copilot Studio or Power Platform, not on the coding agents developers are quietly running on their own laptops. That said, it is worth treating Microsoft’s framing of how widespread this problem actually is with some skepticism. The prevalence figures behind the “agent sprawl” narrative are Microsoft’s own positioning, and no independent study has confirmed how common unmanaged local agents really are on a typical enterprise fleet. Before budgeting for this specific control, it is reasonable to ask your own security team whether they have actually observed it as a problem.

The licensing math is per person, not per agent

Agent 365 is priced at $15 per user per month as a standalone add-on, or bundled at no additional cost inside Microsoft 365 E7, which lists at $99 per user per month and also includes the Entra Suite. The billing model is worth understanding precisely: one Agent 365 license covers every agent that person owns, sponsors, manages, or interacts with, so deploying more agents does not by itself increase the license count. You are licensing the humans accountable for agents, not the agents themselves, which is a more forgiving model than the per-seat-per-bot pricing some competitors use.

The complication is prerequisites. As of June 1, 2026, Agent 365 requires a specific underlying license foundation: Microsoft 365 E5 on its own, or E3 combined with both the Defender and Purview suites, with equivalent tiers defined for frontline, SMB, and education licensing. For an organization still running E3 without the add-on security suites, the real cost of Agent 365 is not the $15 line item. It is the E5 upgrade, or the Defender and Purview additions, that have to happen first. Run the math both ways before presenting a number to finance: E5 plus Copilot plus Agent 365 lands around $105 per user, while E7 covers the same ground at $99. For organizations already leaning toward E5 or E7 for other reasons, Agent 365 is close to free. For organizations still on E3, it is a licensing tier change dressed up as a governance purchase, and that distinction changes who needs to sign off on it.

Abstract illustration of a network of AI agents protected within a security shield, representing agent governance

Governance is an operating model, not a toggle

Microsoft’s own internal rollout, described in its IT organization’s implementation notes, is the most useful data point for what a realistic deployment looks like. Microsoft Digital currently manages more than 500,000 agents across its environment, and the team is candid that its operating model is still incomplete. Their starting point was not turning on policy enforcement. It was building an accurate, centralized inventory, capturing each agent’s name, lifecycle status, type, ID, owner, creation platform, and where it is actually used, with the registry auto-ingesting metadata from Copilot Studio, Power Platform, SharePoint, and Azure AI Foundry.

Just as significant is the administrative structure Microsoft settled on. Rather than assigning agent governance to a single owner, the organization split responsibility across an AI administrator role overseeing the full tenant inventory and lifecycle, an Agent Identity administrator managing identities through Entra Agent ID, and security and compliance teams defining the actual guardrails and approval thresholds. Internally, Microsoft describes agent governance as needing a cross-functional weekly rhythm among IT, security, identity, product, and business unit stakeholders, framing it explicitly as a team sport rather than a single admin’s checklist. Notably, the company also acknowledges that much of its own approval and escalation workflow is still manual, and that programmatic automation is an ongoing engineering effort rather than something that ships finished on day one.

For a CIO evaluating Agent 365, the practical takeaway is to separate the licensing decision from the operating model decision. The license question is a spreadsheet exercise: check your current Microsoft 365 tier against the June 2026 prerequisite list, and compare standalone Agent 365 pricing against an E7 upgrade if you are close to that threshold anyway. The operating model question is harder and cannot be solved by procurement. It requires naming an accountable owner for the agent inventory, deciding who plays the Agent Identity administrator role, and establishing the recurring cross-team review Microsoft itself says was the actual unlock, before the count of Copilot Studio agents in your tenant grows past the point where anyone can govern it from memory.

Routeget Technologies has walked several Dynamics 365 and Power Platform clients through exactly this kind of governance stand-up, usually starting with the same inventory exercise that surprised the IT Director in the opening example. The tooling question tends to resolve quickly once the organizational one is answered honestly.

#Agent365 #CopilotStudio #AIGovernance #ShadowAI #AgenticAI #EnterpriseAI