Most CRM agents fail the same way: they reason over stale data. We built AI agents on the ZoomInfo MCP server to fix that at the source. Inside Dynamics 365 Sales, they research accounts with live ZoomInfo data, write branded pre-call briefs, and add verified contacts to the CRM.

The failure is familiar. The demo looks great. Then a seller asks about a real account, the agent names a contact who left months ago, and nobody trusts it again. After 20+ years in enterprise sales, including roles at Microsoft and Spotify, I know one wrong answer is usually enough.

We presented this build with ZoomInfo at "Better Data, Better Agents" on August 18, 2026. Our thesis: agent logic was never the hard part. Data grounding is. This post covers what we built, how the pieces fit, and the rules that made the agents reliable enough to write to a CRM.

What is the ZoomInfo MCP server?

The ZoomInfo MCP server is ZoomInfo's Model Context Protocol server. It gives AI agents access to ZoomInfo company and contact search, enrichment, account research, and buying signals. It is read-only by design. Agents can pull research from it, but it does not write anything back to your CRM.

That read-only design is a strength, not a gap. It keeps the data source clean and puts the decision about what lands in your CRM with the system you control. In our build, that system is Microsoft Copilot Studio writing to Dynamics 365. Visit ZoomInfo partner page

What we built with ZoomInfo MCP and Copilot Studio

We built AI agents that live in the Copilot pane of Dynamics 365 Sales, the place sellers already work. Five pieces make it run:

From inside an account record, a seller can:

1. Look up any company. Ask a question and get an answer grounded in ZoomInfo without leaving the CRM.

2. Get a pre-call brief. "Brief me on [account] before my call" researches the company and the people in the meeting.

3. Turn the brief into a document. The agent builds a branded Word doc in OneDrive and writes the link onto the account record, so the next person finds it.

4. Fill in the buying committee. "Find contacts we can sell to and add them to the CRM" finds the people you don't have yet and creates them as linked contacts.

5. Draft the follow-up. The agent creates an Outlook draft. The seller reviews it and sends it.

We verified all five live, end to end, inside Dynamics 365.

ZoomInfo reads, Dynamics writes

The most important design decision was a clean split of responsibilities. ZoomInfo reads. Dynamics writes. The agent connects the two.

Here is how a single request moves through the system:

1. The seller asks a question in the Copilot pane of a Dynamics 365 account record.

2. Copilot routes the request to the right agent.

3. The agent reads from the ZoomInfo MCP server: company research, contact enrichment, signals.

4. The agent writes the results into Dynamics 365 through Dataverse: new contacts, links on the record.

5. The agent produces the output in Microsoft 365: a branded Word brief or an Outlook draft.

Neither product goes from research to CRM record on its own. The ZoomInfo MCP server does not write to your CRM. Dynamics does not know what changed in the market last month. The agent closes that gap, and that gap is where the value is. Most teams have not built it yet.

Two agents, one job each

We built two purpose-built agents instead of one assistant that does everything:

• Meeting Prep researches the account and the attendees, writes the brief, builds the Word document, and files the link on the record.

• White Space finds the buying committee members you are missing and adds them to the CRM as verified contacts.

Our rule: open-ended assistants are fine for exploring, but anything that writes to your CRM gets narrow, action-specific instructions. Split agents by the job they do, never by the person using them.

This matters most for enterprise sales teams. A buying committee can span many roles across several business units. Multithreading into that committee only works if the contacts in the CRM are real, current, and linked to the right account.

How we tested ZoomInfo MCP data for accuracy

The whole point of grounding is that the agent does not make things up. So we tested for it directly.

Every contact the agent added to Dynamics 365 matched ZoomInfo's record character for character. We checked by enriching the same people independently and comparing the results. Email, title, and company link were identical.

The freshness data comes along with each record too:

• An accuracy score

• When ZoomInfo last updated the record

• When the record was last validated

One contact we tested had been updated recently but last validated two years earlier. Verified is not a yes-or-no. A good agent shows the seller that difference instead of hiding it, so the seller can decide how much to trust a record before they reach out.

Six rules that made the agents reliable

Good data coming in is half of grounding. The other half is what the agent is allowed to claim. These are the rules we learned the hard way.

1. Name what the agent must never do. We described our three service lines clearly. Asked what to sell a large retailer, the agent still read their tech stack and proposed services we don't offer. A description is not a boundary. A short list of things the agent must never offer fixed it. After the fix, it gave an honest "this isn't a fit."

2. "I couldn't check" is not "nothing exists." The agent once told a seller no CRM record existed. The record did exist; the lookup had failed. A seller who hears "no record" assumes nobody has worked the account. Now the agent only says a record is missing after a lookup actually ran and came back empty. It checks by ID, then by name. A failed lookup is reported as "I couldn't read the CRM."

3. The document has to agree with the chat. In chat, the agent correctly said an account was not a fit. The Word brief it produced next recommended three things to sell them. The fit rule lived in one part of the instructions and the document template in another. We moved the rule inside the document instructions. The file is what gets forwarded a week later, with none of the conversation around it.

4. Write in the words sellers use. "Who can we sell to at this account" was not recognized, because the agent's description used discovery language. Every routing failure we hit was a vocabulary gap, not a logic gap. Also: in Dynamics, each message is handled on its own. Name the account in every request.

5. Give the agent a closed list, not a description. Telling the agent to avoid default heading styles did not work. A list of the only formatting elements it may use did. When an agent keeps drifting, replace the description with an allowlist.

6. Check whether a fault follows the content or the display. Letters seemed to vanish from generated documents. The agent was fine. The browser was failing to load part of one font, and the PDF export was complete and correct.

Bonus: store the ZoomInfo company ID on every Dynamics account. The agent goes straight from a CRM record to the right ZoomInfo company with no name matching. That one convention removes a whole category of "wrong company" errors.

What you need to run ZoomInfo MCP in Dynamics 365

To build this yourself, you need:

• A ZoomInfo subscription with GTM MCP access and bulk credits

• Microsoft Copilot Studio

• Dynamics 365 Sales

• A Microsoft 365 Copilot licence for the Word, OneDrive, and Outlook steps. The tools connect without it but fail when called.

• A consistent link between CRM records and ZoomInfo, such as the ZoomInfo company ID stored on every account

On permissions: the ZoomInfo tool runs as the person asking, not the person who built the agent. Each seller sees only what their own ZoomInfo access allows. Each user connects each tool once, on first use. Email is draft only. The agent never sends.

On cost: it depends on usage. ZoomInfo search is free to use. Enriching a company or contact uses bulk credits, and re-enriching the same record within a year does not use credits again. The practical way to budget is to run a small, known set of requests and measure the change in your credit balance before rolling out to the team.

ZoomInfo MCP FAQ

Does the ZoomInfo MCP server write to my CRM?

No. The ZoomInfo MCP server is read-only by design. In this build, an agent in Microsoft Copilot Studio does the writing through Dataverse, so you control exactly what lands in Dynamics 365 and where. ZoomInfo also offers a separate native Dynamics app for field-level enrichment. That is a different product with a different job.

How is this different from Microsoft's built-in sales agents?

Microsoft's agents reason over the data you give them. This build changes what data they reason over. Grounding the agents in current ZoomInfo company and contact data means the research reflects the market today, not what was typed into the CRM years ago. The two approaches are complementary.

How fast is a pre-call brief?

Think tens of seconds, not instant. The agent routes the request, calls ZoomInfo, writes to the CRM, and builds a document. The trade is a brief your sellers can trust.

Does this pattern work with other CRMs?

The pattern carries over: a read-only data source, an agent layer that writes, and a stable ID linking the two. The specific tools in our build are ZoomInfo, Copilot Studio, and Dynamics 365.

Watch the full session

The full "Better Data, Better Agents" webinar, including the live demo inside Dynamics 365, is below.

Speakers:

• Mike Cangialosi, Senior Solutions Consultant, ZoomInfo

• Leila Ergul Demir, Founder, Partner UP

• Willy Hernandez, Head of GTM Engineering, Partner UP

Willy led the technical build.

Partner UP is a GTM Engineering Studio and a ZoomInfo Solutions Partner. We design and implement the GTM systems that enterprise sales teams run, measure, and scale, including agents grounded in the data your sellers depend on. If you want agents like these working on your own CRM data, contact us.