The semantic layer for Salesforce CRM data.
Trusted, curated context that every agent, tool, and prompt can rely on.
Between your AI and your data.
Demand is rapidly increasing for AI tools and agents to access your Salesforce data. But CRM data isn't agent-ready. It requires a curated semantic layer to define what the data means, assemble it live from your records, who can see what, and deliver it the same way to every tool and agent that asks.
Where people and agents work
Agentforce 
Claude 
ChatGPT 
Slack 
Teams 
Any AI agent Surfaces
ContextWorks
Business domains
A specific set per team or agent, bundled together
Salesforce records
queried live with enforcement of permissions, field-level security, and sharing rules
Your choice of surfaces
The same full context, every time, to everywhere your users and agents work.
Your choice of AI
It delivers to your tools today, and your agents of tomorrow.
Full context, built by the people who know the data.
Entities
The records, curated
Briefs
The knowledge that isn't in any field
Skills
How the work gets done
Ownership
Maintained by the business
One definition, every surface
Built once, read everywhere
How ContextWorks responds.
When an agent or AI tool requests Salesforce data, the request goes through ContextWorks. It resolves what is being asked for, queries the records, efficiently computes the metrics and enrichments, and returns a properly formatted response with the instructions attached. Because the assembly and computation happen inside Salesforce, the agent receives complete information rather than raw data to work through, which saves time and tokens for every user.
- 01
An MCP tool request is made
- 02
Salesforce MCP Server routes it to ContextWorks
- 03
ContextWorks resolves the domain and the requested item
- 04
It queries Salesforce records
- 05
It computes metrics and elements
- 06
It renders the output, instructions included
Example MCP Request
No copy
Nothing is duplicated into a second store.
No sync
No job to schedule and monitor.
No index
No vector store, no embeddings to generate.
Always real-time
Every query runs against the actual CRM records.
Operational context of the CRM data.
A semantic layer normally sits over modelled data in a lake or warehouse and defines metrics: what revenue means, what churn means, consistently, for analytics and for agents. That is useful and powerful, but just part of what ContextWorks provides.
ContextWorks sits directly over the CRM object model and defines what an agent receives when it opens an Account or an Opportunity: which fields, what each one means, which related records to include, which metrics and enrichments to calculate, and the instructions that go with all of it.
ContextWorks over the CRM
- Defines which fields, and what each one means
- Runs over the operational records themselves
- Answers what should an agent know about this deal
- Realtime data
A semantic layer over a warehouse
- Defines measures and dimensions
- Runs over data that was modelled and loaded
- Answers what does revenue mean
- Loaded and synced, not realtime
The two are additive, not alternatives. A metric layer makes the numbers in a dashboard agree. ContextWorks makes the record an agent is looking at mean something. An org running both enjoys the benefits of an analytics vocabulary and an operational context, working side by side for different use cases.
What Salesforce gives you, and what we addHow ContextWorks is delivered.
Define the context once, and deliver it through multiple mechanisms — the same catalog, the same fields, the same instructions, the same permissions, whichever tool is asking.
One configuration. Five surfaces, each generated from it.
MCP
MCP tools to view, update and create CRM records.
Agentforce
Actions and ready-made AgentScript.
Prompt Builder
Grounding for a prompt template.
Flow
Invocable actions for automation.
Apex
A public API for your own code.
What connecting each one looks like, step by step.
DeployExtend the context with deeper aggregation and computation.
An enrichment brings your own analysis onto a record — a scoring model, an external risk signal, an aggregate the object does not contain. It's included in the payload with instructions attached, so an agent knows what the number is and what it means.
What an enrichment can add
Records, a computed scalar, or content — with instructions.
Enrichment sources
Apex, Flow, invocable actions, Data 360 elements, and external data.
Added security
Records an enrichment returns are re-queried as the calling user before rendering.
Build on this, not instead of it.
If your team is already building agents, this is not a competing project. A public Apex API and invocable actions mean an effort already in flight consumes the context layer rather than rebuilding it.
// Assemble the same payload an agent would receive,
// as the running user, from your own code.
String payload = ctxl.ContextAPI.render(
new ctxl.ContextRequest()
.domain('Customer Success')
.entity('Account 360')
.recordId(acct.Id)
.format('markdown')
);The same assembly, not a second one
Code that calls the API receives the same payload the MCP server and the Agentforce action receive, under the same permissions. There is no separate path to keep in step.
Invocable actions for the no-code path
Flow gets the same capability through invocable actions, so an automated step and a hand-written class read the same definitions.
Semantic schema, available for integration and portability.
Your definitions export. They come out as a portable bundle you can move between orgs or keep outside the platform, and as an Apache Ossie semantic model for tools that read the standard — the vendor-neutral interchange format Salesforce itself contributes to.
ContextWorks JSON
A portable bundle of your configuration. Move it between sandbox and production, or keep a copy outside the platform.
Apache Ossie YAML
A semantic model in the vendor-neutral interchange format, for any tool that reads the standard.
