Every major CRM now ships an agent builder, which turns the old platform question into a new one: not which CRM stores your pipeline best, but which one you would trust to let a model write to it. HubSpot, Salesforce and Microsoft Dynamics 365 Sales answer that very differently. This page compares them on what decides whether an agent survives its first quarter: what you can build, who can stop it, what gets logged, and how the bill works.
Pick the platform by its permission model and its write path, not by how many agents it ships. HubSpot is the fastest base for a small revenue team, Salesforce is the one with real engineering tooling around the agent, and Dynamics 365 Sales is the right answer when the agent has to live inside Microsoft identity and governance.
All three give you the same four ingredients: instructions, tools or actions, grounding data, and a runtime input. The differences that matter are structural. HubSpot exposes reading and writing CRM records as explicit, separately granted actions. Salesforce makes the agent a deployable artifact with a scripting language, a test suite and a session trace. Microsoft composes each sales agent out of skill-based agents in Copilot Studio, each with its own identity in your tenant.
Which CRM is the right base for building custom AI agents in 2026?
The one whose permission model you can explain to the person who owns the pipeline number. That sounds like a dodge. It is the opposite: it is the only criterion that reliably separates these platforms, because their agent-building features have converged and their governance has not.
Each of the three gives an agent a goal in natural language, a set of actions it may call, grounding knowledge, and data at runtime. Where they diverge is the blast radius. HubSpot's agent builder treats "read your HubSpot CRM records" and "write to your HubSpot CRM records" as two separate default actions you add deliberately, per its guide to creating and customizing agents in the agent builder. Salesforce runs agent and prompt execution in the authenticated user's context so sharing rules and field-level security apply, which its hosted MCP server documentation states explicitly. Microsoft provisions a separate Microsoft Entra app registration for every skill-based agent behind a Dynamics sales agent, managed at tenant level.
Those are three genuinely different answers to "who is this agent, and what may it touch". In a CRM build the first question is never which agent to build. It is which object the agent may write to, and what happens to the record if it is wrong.
What does HubSpot's agent builder actually let you build?
A custom agent assembled from four parts, in a visual builder, with credits metered per run.
HubSpot's documentation describes the agent builder as four configuration surfaces: instructions (role, goal, approach and expected output, written as prose), actions, knowledge and inputs. Actions come from three tabs. The HubSpot tab holds typed CRM actions grouped as get data, generate and take action. The Default tab holds three blunt capabilities: browse the web, read your HubSpot CRM records, and write to your HubSpot CRM records. The MCP tab connects the agent to external systems over the Model Context Protocol. Knowledge is standing context the agent always has, such as a knowledge vault, your brand kit or your ICP definitions. Inputs are what changes per run, such as a CRM object.
That split between knowledge and inputs is the most useful idea in HubSpot's model, and worth stealing even if you build elsewhere: standing context goes in knowledge, the thing being judged goes in inputs, and the instructions stay stable across runs.
The access controls are more granular than people expect. Per the same documentation, an agent can be set so that only its owner and super admins edit and run it, or owners and super admins edit while everyone runs, or everyone edits and runs, or a named list of users and teams gets run or run-and-edit rights separately. Creating agents at all requires Super Admin or the agent builder permission, and a Super Admin has to switch on generative AI access, CRM data, customer conversion data, files data and Breeze Assistant in AI settings first.
There is also a shortcut. HubSpot's Breeze Assistant guide documents describing an agent in plain language and having the assistant propose a configuration, including goal, tools and knowledge sources, which you then refine rather than build from scratch. The example prompt in that documentation is an ICP-fit scorer returning high, medium or low fit with a one-sentence reason, keeping low-fit contacts out of the rep queue. That is a fair picture of the sweet spot: a judgement call on one record, written back as a field.
What does Salesforce Agentforce actually let you build?
The same thing, plus an engineering workflow around it: a scripting language, a CLI, an SDK, a test framework and an exportable session trace.
Salesforce's Agentforce APIs and SDKs guide is the clearest single page on what the platform exposes. Agent Script is a scripting language that mixes natural language instructions with programmatic expressions: if/else conditions, transitions, variables, and explicit selection of subagents and actions. Salesforce's stated purpose for it is agent workflows that are predictable and do not rely on interpretation by a large language model, which is a notable thing for a vendor to put in writing. Agentforce DX adds Salesforce CLI and VS Code tooling for authoring, deploying and previewing agents, and there is a Python SDK, an Agent API for talking to a live agent over REST, and an API that exports a unified JSON view of a full agent session trace. One naming change to carry into older material: from April 2026 Salesforce renamed agent topics to subagents, with no change in functionality.
Testing is where the gap to the other two platforms is widest. The same page documents three routes: Testing Center in the UI with CSV definitions and no custom evaluation support, Agentforce DX on the command line with YAML, and the Testing API in code with XML, the latter two supporting custom evaluations. If you want agent tests in a repository and in continuous integration rather than a spreadsheet, this is the only one of the three platforms that documents a path there today.
Salesforce's own architectural guidance is unusually frank. The Architects whitepaper on agentic patterns sets out five agent types (conversational, proactive, ambient, autonomous and collaborative) and gives each a trade-off table naming the costs as well as the gains. For an email SDR agent it claims a first response under five minutes against a human baseline of eight to twenty-four hours and a two to five times increase in lead coverage, while listing lost early relationship-building touchpoints and missed nuanced signals as the price. Those are vendor figures about a vendor product, so read them as design intent rather than benchmark. The useful part is the structure: each pattern is specified with what it gives up.
The architecture underneath is topics and instructions, actions, guardrails and prompt templates, grounded in Data 360 through retrieval-augmented generation, with the Einstein Trust Layer masking sensitive data before instructions reach the model. Salesforce's Agentforce platform page adds the operational surface: Agentforce Observability for tracing agent reasoning, Prompt Builder, batch testing, and more than two hundred pre-built templates, topics and actions across the Customer 360 applications.
What does Microsoft Dynamics 365 Sales with Copilot Studio let you build?
Less from scratch and more by configuration, with the agents assembled from Copilot Studio parts that each get an identity in your tenant.
Microsoft's position is that you start from shipped agents rather than a blank builder. The AI agents in Dynamics 365 Sales overview lists seven, among them a Sales Qualification Agent that researches leads and drafts outreach, a Sales Opportunity Agent for risk and stakeholder research on open deals, a Sales Close Agent that Microsoft describes as managing the end-to-end cycle autonomously including objection handling, and a Sales Research Agent for natural-language questions over sales data.
The structural fact that matters is one level down. Microsoft's page on Copilot Studio agents and Entra app registrations explains that each Dynamics sales agent is composed of multiple skill-based agents in Copilot Studio, and that provisioning one automatically generates an app registration in Microsoft Entra. The Sales Qualification Agent alone provisions twelve, named for what they do: research, competitor, readiness, email validation, outreach, autonomous engagement, stakeholder research, summary synthesis, company resolution and more. Microsoft gives the arithmetic in its own worked example: five Dynamics 365 Sales organisations in a tenant, twelve skill-based agents each, sixty app registrations in Entra.
Read that as a governance statement rather than a complaint. An agent's capabilities become individually addressable, auditable and revocable in the same directory where your employees live. It also means the identity team now has an opinion about your sales rollout.
Customisation runs through Copilot Studio and costs separately. Microsoft's guide to customizing Copilot in Dynamics 365 Sales says you need the Copilot Studio Author role, that custom topics are charged according to the Copilot Studio credits they consume, and that the customisation path through Copilot Studio is a preview feature not meant for production use.
Beyond that, Microsoft publishes a reference architecture for surfacing a custom Copilot Studio agent in a model-driven app through a Power Apps component framework control and the Microsoft 365 Agents SDK. It needs a public client application registered in Entra with the CopilotStudio.Copilots.Invoke delegated permission, and it returns the agent's answer as a named event activity rather than a chat message so your code can parse it. Microsoft's stated reason for preferring it over the simpler route is decoupling: the simpler pattern binds you to the built-in Copilot agent, which can change underneath you.
Two notes from the overview page, because they surface in security review and rarely earlier. Agents are meant to be validated in a sandbox or test environment before production, with a documented import path between environments. And they use the same data processing and storage infrastructure as other Copilot features in Power Platform, which Microsoft says means the data agents use might be processed and stored in regions outside the user's primary region.
How do the three compare on the five things that decide agent readiness?
The fifth criterion does not fit in a card, because it is not a feature: whether the data model under the agent is worth reading at all. An agent grounded in a CRM where lifecycle stage means four things to four teams will produce four confident answers, and no guardrail configuration fixes that.
How does each platform price the agent work?
All three meter the agent's thinking rather than the seat, which makes the trigger a budget decision. HubSpot's agent builder page says the builder is included in Starter, Professional and Enterprise, that workflows consume no credits, and that custom agents consume HubSpot Credits per run in units of work it calls action units, bought in packs up front or pay-as-you-go. Builder test runs consume none, and the run history shows estimated credits per run so you can set limits first. Microsoft charges custom Copilot Studio topics against Copilot Studio credits through consumption-based billing. Salesforce documents the surfaces rather than the rates on the pages read for this comparison, so no per-unit figure is quoted here.
So an agent on a workflow that fires for every new contact is a different commitment from one that fires on closed-won deals, and the time to notice is while you are still choosing the trigger.
Can an external assistant call your CRM's agents, and should it?
Yes on all three platforms, and it is the most interesting capability of the current generation, with one trap.
All three speak the Model Context Protocol. HubSpot exposes an MCP tab in the agent builder so its agents can reach external systems. Dynamics 365 Sales supports MCP so that, as Microsoft's overview puts it, sales tools and actions can surface through other agents and apps rather than only through the Dynamics user interface. Salesforce goes furthest in the other direction: its hosted MCP server documentation describes exposing Agentforce agents and Prompt Builder templates as MCP tools, so an external assistant can delegate a specialised task to an agent you built in Salesforce rather than reconstructing that logic from record queries.
The trap is tool selection. Salesforce's documentation is blunt about it: an external model picks which tool to call based entirely on the tool's name and description, so a vague description means it skips your agent and satisfies the request another way. Its recommendation is a separate, narrowly named MCP tool per task even when several point at the same underlying agent, because "schedule customer meeting" is matched more reliably than "sales agent". Two further constraints: only agents built with the newer Agent Script Builder can be exposed as MCP tools, so legacy agents must be upgraded first, and the agent's required inputs become the tool's parameter schema, so complicated inputs make the tool harder to call correctly.
It also raises a question no vendor page answers for you. If an assistant outside the CRM can invoke an agent inside it, the approval gate has to live with the agent, not with the interface someone used to reach it. Salesforce's answer is execution in the authenticated user's context with sharing rules, field-level security and Trust Layer policies applied. That is the shape of answer to look for on whichever platform you choose.
What about Oracle, SAP and the other enterprise suites?
They have shipped comparable agent studios, and if you already run the suite they are the default rather than a shortlist entry.
Oracle's AI Agent Studio is a design-time environment for creating, validating and deploying agents inside Fusion Cloud Applications, with preconfigured templates you extend by copying rather than editing in place. Its getting-started guide lists a notably complete tool set: a business object tool that can retrieve, update, create or delete Fusion records while adhering to the application's native security and role-based access controls, plus connectors, document tools, email, deep links, external REST and MCP. It documents two things the others handle less explicitly: an optional human approval step insertable at any point in the flow, and agent teams in two shapes, a supervisor that manages other agents or a workflow that runs nodes in a fixed order.
SAP's answer is Joule Studio, an AI-native environment for custom agents, apps and workflows deployed to an SAP-managed runtime. Its methodology, which SAP calls intent-based development, comes in a browser-based low-code flow and a pro-code flow driven from a command line interface with a coding agent connected over MCP. One of the things you can build in it is an n8n workflow, which says something about where SAP thinks the integration layer lives.
Neither belongs on a shortlist against HubSpot for a thirty-person revenue team. Both belong at the top of it if the company already runs Fusion or SAP, because an agent's value comes from the data it can reach.
Which one should you pick, by situation?
Dynamics 365 Sales is the third branch, decided somewhere else entirely: choose it when the organisation already runs Microsoft identity, when the sellers work in Microsoft 365, and when you would rather configure shipped agents than specify your own. Accept in exchange a customisation path that runs through a preview feature, a data residency answer of "possibly outside your primary region", and the identity team on the project from day one.
When is the answer not your CRM at all?
When the agent's job spans systems the CRM does not own, or when the thing being automated is not a judgement.
A native CRM agent is strongest when the data it needs is already in the CRM and the action it takes is a CRM action. Once the work requires enrichment from three vendors, a check against a billing system and a write to a warehouse, the CRM agent becomes a participant rather than the orchestrator, and orchestration belongs in a layer built for it. That decision has its own criteria, covered in our comparison of AI agent orchestration frameworks for RevOps.
The other case is simpler and more common. If you can draw the steps, draw them. A model deciding which of two branches to take when a field value already answers the question is cost and unpredictability bought for nothing. Across more than 30 engagements over the last seven years, the automation that gets switched off is rarely the one that failed loudly. It is the one nobody owned, and an agent is a standing commitment: someone owns the instructions, the action scopes, the credit line and the weekly review of the output.
A reasonable starting shape, whichever platform you land on: one object, one agent, one write, to a staging property that a workflow or a person promotes. Separate the finding from the change. That one rule is what lets you turn an agent on without asking anyone to trust it yet.
Where this fits in the rest of the stack
If the CRM choice itself is the open question, the general comparison is HubSpot against Salesforce. If the platform is settled and the question is how to build and operate the first agent, start with building, testing and monitoring RevOps agents. And if the underlying objects are the real problem, which is more often than anyone wants, begin with HubSpot custom objects and CRM data quality.
FAQ
Which CRM is best for building custom AI agents for sales teams?
There is no single best one. HubSpot gets a working agent live fastest and meters it per run with credits. Salesforce gives the agent a scripting language, a CLI, a Python SDK, three testing routes and an exportable session trace, which is what you want if agents belong in version control. Dynamics 365 Sales wins when the organisation already runs Microsoft identity, because every skill-based agent gets its own Entra app registration.
Can you build a custom AI agent in HubSpot without code?
Yes. HubSpot's agent builder takes instructions as prose, actions from a list, knowledge as standing context and inputs at runtime, and Breeze Assistant can propose a whole configuration from a plain-language description of the agent you want. Custom agents consume HubSpot Credits per run, and builder test runs do not.
How do Dynamics 365 Sales AI agents relate to Copilot Studio?
Each Dynamics sales agent is assembled from skill-based agents in Copilot Studio, and provisioning one creates those automatically along with a Microsoft Entra app registration for each. The Sales Qualification Agent alone provisions twelve. Customising behaviour means working in Copilot Studio with the Copilot Studio Author role, and custom topics are billed through Copilot Studio credits.
Can an external AI assistant use my CRM's agents as tools?
On all three, to different degrees. Salesforce documents exposing Agentforce agents and Prompt Builder templates as MCP tools for external assistants to invoke, with execution running in the authenticated user's context. Dynamics 365 Sales supports MCP so sales tools and actions surface through other agents and apps. HubSpot's agent builder includes an MCP tab for connecting its agents to external systems.
What should you fix before building a CRM agent at all?
The properties the agent will read. An agent grounded in inconsistent lifecycle stages, stale company records or a pipeline where stage definitions differ by team will produce confident answers that disagree with each other. Agent configuration cannot repair a data model, and a per-run credit cost means you pay to generate the disagreement.