The most common reason an AI agent deployment underdelivers is not the technology. It is the data the technology is trying to work with.

Businesses tend to underestimate this part of the project because the CRM feels functional. Records exist. The team uses it every day. Searches return results. From the outside, it looks like the data is there. But there is a difference between a CRM that works well enough for a human who can apply judgment to incomplete or inconsistent records, and a CRM that is ready to power an AI agent that will retrieve and surface that data to external users automatically.

Eric Housh and Zack Terry talked through this directly in a recent episode of AI in Action, noting that one of the reasons the talent placement firm’s Agentforce build went smoothly was that the client came prepared. They knew where their data lived. They knew which fields the agent would need. They had already identified the gaps. That preparation is not typical, and it is worth understanding what it actually involves.

What “Ready” Actually Means

CRM readiness for an AI service agent is not about having a perfect database. It is about having accurate, accessible, consistently structured data in the specific fields the agent will need to do its job.

That is a narrower requirement than it sounds. You do not need every field in every record to be clean. You need the fields the agent will query to be populated accurately across the records it will be working with. The scope of that requirement depends entirely on what the agent is being built to do.

For the talent placement firm, the agent needed to retrieve application status information for candidates who reached out with inquiries. That meant the status field on candidate records needed to be current, accurate, and populated consistently across the contact base. Fields the agent was not going to touch were irrelevant to the readiness question.

Starting with a clear definition of what the agent will do lets you scope the data readiness work precisely rather than embarking on a broad CRM cleanup that takes months and delays the build.

The Fields the Agent Will Query

The first step in the data readiness audit is identifying every field the agent will need to access in order to do its job.

For a status inquiry agent, that typically includes the fields that identify the record, name, email address, account number, or whatever the agent will use to look up the right person, and the fields that contain the information the agent will retrieve and return, current status, stage, relevant dates, or similar.

Map those fields out before you start the build. Then check each one across a representative sample of records. What percentage are populated? Are they populated consistently, using the same values and formats? Are there records where the field exists but contains outdated or inaccurate information?

The answers to those questions tell you how much data cleanup needs to happen before the agent can be trusted to return reliable responses. A field that is populated on 95 percent of records and consistently formatted is ready to use. A field that is populated on 60 percent of records with inconsistent values is not.

The Permissions Problem

Data accuracy is one half of the readiness question. Data accessibility is the other.

In Salesforce, record visibility is controlled by sharing rules, permission sets, profiles, and org-wide defaults. A field can be perfectly accurate in a record that a given user, or a given agent, cannot see. If the agent does not have access to the records it needs to query, it will not be able to retrieve the information, and the responses it returns will be incomplete or incorrect.

The talent placement firm ran into a version of this. Because they were running two brands out of a single Salesforce org, their permission structure was complex. Some records were invisible to certain users depending on how the sharing rules were set up. Before the agent could reliably retrieve candidate information, the team had to audit and resolve the permissions issues that would have blocked it.

That work is not glamorous. But it is necessary. An agent that cannot see the records it needs is an agent that cannot do its job, regardless of how well everything else is configured.

The Translation Layer

Beyond the raw data fields, there is a third category of readiness that is specific to agents handling external-facing communication: the translation layer.

Most CRMs store internal shorthand. Status codes, stage labels, disposition flags, values that make sense to the team that built the process but would be meaningless or alarming to an external user reading them directly. Before an agent can surface that data externally, someone needs to decide what each internal value means in plain language and what the right external-facing response looks like for each scenario.

The talent placement firm had between 20 and 30 internal status codes. Some indicated active consideration. Some indicated the candidate was on hold. Some effectively indicated the candidate was no longer in the running for any roles. For that last category, the raw internal language was not appropriate to surface directly to a candidate. The team had to sit down and write the approved external response for each code, including the ones that were hard to word well.

That translation work is a business task, not a technical one. It requires your team to make deliberate decisions about what you say to external parties in each scenario before the build begins. The agent executes on those decisions. It does not make them. How AI Recruiting Tools Can Automate Candidate Communication Without Losing the Human Touch covers why that translation layer is what separates generic automation from communication that actually holds up.

Data Consistency Across Channels

One issue that surfaces frequently in multi-brand or multi-team orgs is inconsistent data entry practices. Different team members use different values for the same field. Status codes get entered in varying formats. Records created by one team follow different conventions than records created by another.

An AI agent working with inconsistently structured data will return inconsistent responses. If the same status is stored as three different values depending on who entered the record, the agent needs to be able to recognize and handle all three, or the data needs to be normalized before the agent goes live.

This is particularly relevant for businesses running multiple brands or business units out of a single org, which was exactly the situation the talent placement firm was in. Auditing for consistency across teams and entry patterns is part of the readiness work, not something to discover after the agent is deployed.

How to Run the Readiness Audit

The audit does not need to be a months-long project. Scoped correctly, it is a focused piece of work that produces a clear answer: here is what is ready, here is what needs to be fixed, and here is the order in which to address it.

Start by defining exactly what the agent will do. From that definition, identify every data field it will need to access. For each field, check population rate, consistency of values, and accessibility given your current permission structure. Flag anything that falls below the threshold needed for reliable agent performance.

Then look at the translation layer. Document every internal value in the fields the agent will surface externally. For each one, write the approved external-facing response. Get sign-off from the people who own those communication decisions before the build starts.

Finally, resolve the permissions issues. Make sure the agent will have visibility into the records it needs across your full contact base, accounting for any sharing rules or org-wide defaults that might restrict access.

That work, done before the build begins, is what the talent placement firm had largely completed before they engaged Fast Slow Motion. It is why the project moved quickly and the results were immediate. The Crawl Phase: How to Scope an AI Project That Actually Gets Finished covers how to scope the broader build around that foundation.

What Happens If You Skip This

It is worth being direct about what happens when a business deploys an agent without doing the data readiness work first.

The agent returns incomplete or inaccurate responses because the fields it is querying are not consistently populated. Candidates or customers get wrong information, which generates follow-up inquiries rather than reducing them. The team loses confidence in the tool. The deployment gets pulled back or quietly abandoned.

That outcome is not a failure of AI as a technology. It is a failure of preparation. The technology works when the data it is working with is ready. When it is not, the results reflect that directly.

If you want help running the data readiness audit for your business and building the agent on top of a foundation that will support it, Fast Slow Motion works with growing companies to scope and deploy Agentforce implementations that are set up to deliver results from day one. You can reach us at fastslowmotion.com/ai-for-your-business.

Listen to the full podcast episode here.

Related Resources

• How to Use an AI Agent to Handle High-Volume Customer Inquiries in Your Business
• What Is the Agentforce Service Agent and When Should You Use It for External Inquiries?
• The Crawl Phase: How to Scope an AI Project That Actually Gets Finished
• Why Your Team Is Still Answering the Same Customer Emails on Repeat