Dialect Layer

Before

The company built custom MCPs for Salesforce and Workfront so people could ask Gemini and Claude for data in plain language. Plain questions failed. Someone would ask how many deals included an internal product code this quarter for a pharma client and get back: “Cannot find what you are looking for. Are you sure you are connected to Salesforce?”

The connection was fine. The error sent people looking in the wrong place, and other teams tried their own fixes before the problem was handed to me.

What I did instead

I started with the question itself. It makes sense to anyone at Medscape and almost none of it makes sense to Salesforce. The product code is our shorthand, not the name Salesforce stores. “The client” means something specific in our schema that the model can’t infer. So the model searched for terms that don’t exist and reported the miss as a connection problem.

To translate, I had to learn the target language first. I got on calls with our Salesforce admin and worked through how our terms map to Salesforce’s structure until I could read a question the way Salesforce would.

Then I built a skill for Gemini Enterprise that sits between the user and the MCP. It maps the words people actually use, from casual names for clients and deals to internal product shorthand, onto the Salesforce objects and fields those words refer to. It also gives ambiguous phrases such as “this year” a fixed meaning. The MCP itself is read only, so the skill cannot modify Salesforce records through it.

With the skill in place, the product question resolves cleanly: identify the client, pull its deals for the quarter, and count the ones that include that product.

The key design decision

The skill instructs the model that if a field doesn’t exist or returns nothing, it should name the field and stop. Don’t substitute a guess.

The original error was misleading. “Are you sure you are connected?” pointed people at the one part of the system that was working. A model that guesses would be worse, returning numbers that look right and aren’t.

Naming the missing field turns a dead end into a next step. The user can rephrase, or add the term to their own copy of the skill.

Adoption

The skill went out across the organization. More than 1,000 people have access, and by my estimate a few hundred used it in the past month. The better signal is what happened next: teams took the base skill and extended it with their own vocabulary. People treated it as a template, which is what a dialect problem needs, since every team has its own.

The pattern repeats

Workfront, Adobe’s project management system, has been in use at Medscape for over ten years, and we talk to it in our own way too. Same failure, different dialect. I ran 10 to 15 experiments to find where queries broke and turned the results into a Workfront translation skill, now in pilot.

BigQuery is next. Building the Sales Analyst Agent on a BigQuery MCP is what pointed us toward a translation skill there. It’s in progress.

Known limits

There’s no measured before-and-after success rate. The evidence is the diagnosis work and adoption, not a query accuracy metric. The usage figure is my own estimate, not telemetry. The stop rule is an instruction, not an enforced check, and I haven’t measured how consistently the model follows it. It also treats an empty result the same as a missing field, so a legitimate zero can come back as an error instead of an answer. The mapping is only as current as its last update, and dialects drift as teams rename things. Forked copies also drift from the base, so a fix to my version doesn’t reach the teams running their own.

Stack