Claude Is Already in the Building
Anthropic held their Code with Claude developer conference on May 6 in San Francisco and the headline wasn’t the demos. It was the confirmation that Anthropic has figured out the distribution problem — how to land Claude in enterprises that already run on Microsoft and Salesforce.
That’s the problem most enterprises actually have. Not “should I adopt AI” but “where does this fit in the stack I’ve already committed to.”
What Shipped at Code with Claude
The centerpiece announcement is the Claude Managed Agents platform, which hit public beta on April 8 and expanded significantly in May. The core pitch: a hosted API service for deploying production-grade agents without building your own orchestration infrastructure.
What that means in practice: Anthropic handles session state, credential management, sandboxing, and persistence. You define the agent’s tools and behavior. The platform manages the rest.
The May expansions added the features that actually matter at enterprise scale:
- Dreaming — cross-session memory with reflection and learning, so agents carry context across conversations instead of starting cold each time
- Outcomes — define rubrics to measure whether an agent actually succeeded, not just whether it completed a task
- Multi-agent orchestration — a lead agent can delegate to specialist agents, enabling complex workflows without one monolithic prompt
- Enterprise audit logs — the paper trail regulated industries require before they can touch anything
- Webhooks — integration with external systems without polling
Pricing is token-based plus a $0.08/hour runtime charge when agents are active. Notion, Asana, and Rakuten are among the early production deployments.
The Real Estate Problem
Here’s why “just deploy Claude” isn’t a real enterprise decision.
Microsoft controls the collaboration layer in most large enterprises. M365, Teams, Copilot Studio, Azure DevOps, Entra ID — the toolchain most employees use all day, every day. Enterprise AI budget for developer and productivity tooling overwhelmingly flows through Microsoft relationships.
Salesforce controls customer data and workflow automation for a huge portion of regulated industries. CRM, financial services cloud, healthcare cloud, Agentforce 360 — if your customer interactions happen in Salesforce, your customer-facing AI probably needs to live there too.
These aren’t just vendor relationships. They’re architectural gravity. Enterprise procurement cycles favor extending existing contracts over introducing new vendors. Compliance teams need data residency guarantees that only established enterprise vendors have worked out with regulators. IT governance requires central control over which AI systems touch what data — and that control is easier to enforce through existing platform governance than through a new API relationship.
The naive framing is “Claude vs. Microsoft vs. Salesforce.” That’s not the enterprise decision. The real question is where in a Microsoft-and-Salesforce-shaped enterprise does Claude actually land.
The Plot Twist From the Conference
Claude is already inside both platforms.
Microsoft added Claude to Copilot Studio — Claude Sonnet 4.5, 4.6, and Opus 4.5/4.7 are available for multi-model agent building. Copilot Cowork now includes Opus 4.7 for frontier workloads. If your organization has Copilot Studio licenses, Claude is a configuration choice, not a new vendor approval process.
Salesforce made Claude the foundational model for Agentforce 360 in regulated industries — financial services, healthcare, life sciences. First LLM provider to operate fully within Salesforce’s trust boundary. Data stays in Salesforce-managed VPCs under Salesforce security controls. For organizations where the compliance question is “does this stay inside our Salesforce footprint,” the answer with Claude is yes.
So the question shifts. Not “can I get Claude approved in my enterprise” — it’s already approved if you’re on either platform. The question becomes which door you walk through.

Three Doors, One Enterprise
The decision isn’t which platform wins. It’s which access path fits which problem.
Door 1 — Copilot Studio (Microsoft fabric)
Best for M365-native workflows, internal developer tooling, and organizations where the Microsoft enterprise agreement already covers Copilot Studio licenses. You build Claude-powered agents in the Microsoft orchestration layer, alongside or instead of GPT-4o-based agents. Claude is one model in a multi-model roster — you’re not replacing Microsoft’s orchestration, you’re choosing a different model within it.
The constraint: Claude in Copilot Studio requires the right license tier, not just any M365 subscription. If your organization is on the standard Copilot Studio plan, check whether Claude models are included before you design against them.
Door 2 — Agentforce 360 (Salesforce fabric)
Best for customer-facing processes, regulated pipelines, and CRM-integrated automation where data must stay within Salesforce’s trust boundary. The unique advantage isn’t just the Claude model — it’s that the data governance story is already solved. Your compliance team doesn’t need to approve a new data pathway because there isn’t one. Claude processes data that stays inside Salesforce infrastructure.
CrowdStrike and RBC Wealth Management are among the early deployments. The regulated-industry positioning is deliberate. Anthropic and Salesforce built this specifically for environments where the data movement question stops most AI projects before they start.
Door 3 — Managed Agents API (Anthropic’s orchestration)
Best for cross-platform orchestration, internal tooling that spans multiple systems, and use cases that don’t fit neatly inside either Microsoft’s or Salesforce’s orchestration model. This is where you get the full platform — Dreaming, Outcomes, multi-agent delegation. And crucially, this is where Claude IS the orchestration layer rather than a capability within someone else’s.
The distinction matters. In Doors 1 and 2, Claude is a model choice inside a platform. In Door 3, Claude’s orchestration can call Microsoft APIs, Salesforce APIs, your internal systems, and any MCP-connected service — without being constrained by what either platform’s agent builder exposes.
What Managed Agents Actually Unlocks
The reason Door 3 isn’t redundant with the other two is architectural scope.
Copilot Studio agents live inside the Microsoft fabric. They’re good at tasks that stay there — drafting, searching M365 content, triggering Power Automate flows. When your use case is an internal research agent that pulls from SharePoint, drafts in Teams, and loops back to Jira, Copilot Studio is the right call. The orchestration matches the problem.
Agentforce agents live inside the Salesforce fabric. They’re good at customer interaction workflows, case management, CRM-integrated automation. When the entire loop stays inside Salesforce, Agentforce is right.
The Managed Agents platform is for the loops that cross boundaries.
An agent that monitors your core banking system, identifies anomalies, queries your Salesforce CRM for customer context, drafts a risk summary, and pings a Teams channel — that’s not a Copilot Studio problem and not an Agentforce problem. It’s a cross-platform orchestration problem. The Managed Agents multi-agent delegation model handles it: a lead agent coordinates specialist agents for each domain, each calling the APIs it’s responsible for.
Dreaming and Outcomes matter most in this door. Cross-session memory is irrelevant for a one-shot Copilot Studio completion. For a persistent agent monitoring a financial process across days and weeks, memory and success measurement are table stakes. That’s where Door 3 earns its keep.
MCP is the connector layer that makes this practical. If your Salesforce instance and your Azure services both expose MCP endpoints, a Managed Agent can query both without you building custom integration for each. That’s not theoretical — Salesforce and Microsoft both have MCP support in production.
The Honest Part
Each door comes with its own tax.
The governance problem multiplies. Three simultaneous Claude access paths means three billing relationships, three audit trails, three data residency policies to maintain. Before you enthusiastically adopt all three, figure out who owns the governance layer. The answer isn’t obvious. I wrote about this fight — between Microsoft’s Agent 365 and Salesforce’s MuleSoft Agent Fabric — in The Agent Control Plane War. That piece predates Managed Agents as a third contender. The governance question just got more complicated.
Dreaming has compliance implications before you turn it on. Cross-session memory in a regulated environment means data retention, data classification, and right-to-erasure questions your compliance team hasn’t addressed yet. “The agent remembers what happened last week” sounds like a feature. To your privacy counsel it’s a retention trigger. The audit logs for Managed Agents help — they don’t solve the policy question.
The $0.08/hour runtime fee is easy to underestimate. Always-on agents are always-on billing. Do the math before you architect long-running processes. Token costs are familiar. Runtime charges add a different shape to the cost curve — one that hurts most on idle agents that could have been event-driven instead.
Copilot Studio license requirements aren’t uniform. Not every organization has the tier that includes Claude model access. Check your enterprise agreement before designing against it.
None of this is a reason to avoid Managed Agents or the platform integrations. It’s a reason to go in with the full cost model mapped rather than discovering it in a procurement conversation six months later.
The Question That Actually Matters Now
The enterprise debate about Claude was never “Claude or Microsoft” or “Claude or Salesforce.” Those aren’t binary choices anymore. Claude is available inside both platforms, and there’s now a third path for problems that need direct orchestration.
The question that actually matters is whether your organization is ready to govern three simultaneous Claude entry points — each with different trust boundaries, billing models, and data residency implications — and whether you have the architectural discipline to use each one for the problems it’s actually built for rather than defaulting to whichever door you happened to walk through first.
The real estate that Microsoft and Salesforce own is your existing contract relationships and your compliance team’s established trust in those platforms. Anthropic isn’t trying to replace that. They’re building inside it, and alongside it for the problems that don’t fit.
How you govern a multi-vendor agent fleet — and who ends up owning the control plane — is the question I worked through in The Agent Control Plane War. Which layers of the Salesforce stack are actually load-bearing versus optional is in Salesforce Without the Full Buy-In.
I’m at @orestesgarcia on X and LinkedIn if you’re navigating the same three-door decision in your enterprise — or if the governance tax just got real for you.