Today we’re introducing a new product: ContextWorks, the record-level semantic layer for Salesforce CRM data.
The short version: it makes your Salesforce data agent-ready. Curated, explained, and governed, so every answer is trusted, whichever person, AI tool, or agent is asking.
The longer version starts with a problem you’ve probably already experienced.
CRM data wasn’t built for agents
Objects carry hundreds of fields, and a plethora of relationships between them. What they don’t carry is semantics — the guidance that tells an AI which fields matter, what they mean, or how to use them.
And it’s worse than not knowing. The problem is AI producing confidently wrong answers, and a lack of consistency between one answer and the next. End users get a poor experience and more questions than answers.
So one of three things happens.
Open it all up and chaos ensues. Every tool gets everything, and none of them read it the same way. Ask two of them the same question and you get two different answers, then spend the meeting working out which one to trust.
Lock it down and you’re stuck. AI access isn’t allowed, and the business goes without. Never out of obstruction, but out of necessity — the only option on the table was total exposure.
Hardcode it and you get headaches. A developer writes a field list into a prompt. It works for a month. Then a stage gets renamed, and it drifts, separately on every surface.
The fourth option: ContextWorks
Curate what’s exposed. Explain what it means. Enforce permissions per user. Leave the data where it is.
ContextWorks sits between your Salesforce records and whatever AI you use. The people who know the business — RevOps, sales ops, marketing ops — define what an agent should receive when it opens an Account or an Opportunity, what additional knowledge is required, and how processes should be executed.
Here’s what that means in practice.
1. Answers you can trust, every time
Every answer is built from the same definitions, by the same method. Nothing is inferred at runtime. The numbers change when the data changes — not because an agent read a different field, guessed at a filter, or interpreted a stage differently than it did yesterday.
One place to manage context for every agent and tool, instead of a definition hand-written per agent.
2. Full context: data, semantics, and process
Most approaches stop at data: a field list, a schema, a query result. ContextWorks delivers three things.
- Entities — the records. Curated fields, rollups, related data, computed signals, assembled into one view. 212 fields become the 22 that matter, with instructions.
- Briefs — the institutional knowledge. How you segment, what a stage means, your brand voice.
- Skills — how your team does the work, so every agent does it the same way.
A field list can’t tell an agent that a health score below 60 warrants outreach, that renewal dates lag a day because they come from an integration, or that “Partner” here means reseller. That’s the knowledge people apply every day, but absent from the data itself.
3. Enforced, governed, and observable
Enforced. Field-level security and sharing are applied to the query itself, not filtered afterward. Every request runs as the person asking. Two users on the same record get different payloads, correctly, with no per-user setup. Nothing is copied, synced, or indexed.
Governed. Versioned definitions with one-action rollback. Each business function owns its own context. Write controls can be enabled, with curation of what can and cannot be updated. Change logs record every update to the context layer, and definitions are portable to other systems in the standards-based Apache Ossie schema.
Observable. See exactly what an agent will receive for a record, as a given user, before anything is connected. Then watch what agents are requesting, the performance, quality and health of what is delivered, and any FLS, assembly, or configuration issues.
ContextWorks lets the security team say yes, because everything is governed by enterprise controls — and lets them see exactly what agents are requesting and receiving.
4. Built by your people who know the business
ContextWorks is an application, not a dev project. Point-and-click, no code, initialized from your existing Salesforce setup rather than a blank canvas.
The person who knows what qualified means is usually not the person who can change how an agent interprets it. ContextWorks closes that gap: the team that owns the knowledge owns the definition. Change a definition, not a prompt. No developer, no deployments, no tickets.
5. Works with whatever AI you choose
Agentforce, Claude, ChatGPT, Prompt Builder, Flow, Apex, any MCP client. One set of definitions behind all of them. ContextWorks never calls a model — it returns markdown or JSON, so anything that reads text reads the context. It improves the experience of your AI tools and the effectiveness of your agents, whichever ones you pick.
Built on Salesforce, alongside what Salesforce provides
ContextWorks is a 100% native Salesforce application. Works with Agentforce and Salesforce Hosted MCP Servers, which give AI tools and agents secure, OAuth-based access to your org, with every request running as the user through field-level security and sharing. That solves the connection.
What it doesn’t solve is what the agent should receive once it’s connected. Permissions decide what a user may see. Nothing decides what an agent should see for a given job, what each value means, or how to use it.
That’s the layer ContextWorks adds, natively on the platform: which fields, what they mean, and how to use them.
The results
Same org, same user, same question, native sObject MCP versus a curated ContextWorks domain: half the tokens, one tenth the tool calls, and four times faster to the answer. And not just the same answer, but better, more complete answers.
