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.
People and agents work wherever they already work. Every surface makes the same call against the same definitions, and the payload is assembled live from your records on every request.
Where people and agents work
Agentforce 
Claude 
ChatGPT 
Slack 
Teams 
Any AI agent Surfaces
ContextWorks
Business domains
A specific set per team or agent, available together
Salesforce records
queried live, in user mode, through field-level security and sharing
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.
How ContextWorks responds.
It assembles the payload from definitions someone already made, and hands it back. Ask the same question twice and you get the same answer twice, because nothing along the way is guessing.
- 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 request path
No copy
Nothing is duplicated into a second store that could disagree with the first.
No sync
No job to schedule, fall behind, or fail quietly overnight.
No index
No vector store, no embeddings of your records, nothing to re-embed when a value changes.
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 not the role ContextWorks fills.
ContextWorks sits directly over the CRM object model and defines what an agent receives when it opens one Account record — which fields, what each one means, which related records travel with it, and who is allowed to see any 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
- Freshness is the record itself
A semantic layer over a warehouse
- Defines measures and dimensions
- Runs over data that was modelled and loaded
- Answers what does revenue mean
- Freshness is whatever the last load was
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 has its analytics vocabulary governed in one place and its operational context governed in the other — and neither is doing the other's job.
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
A server scoped to one domain, for any MCP client.
Agentforce
Actions and a ready-made topic.
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 means as well as what it is.
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 — you keep what you have built and stop hand-maintaining the part underneath it that nobody wanted to own.
// 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 calling the API gets the payload the MCP server and the Agentforce action get, under the same permissions. There is no separate path to keep in step.
Invocable actions for the no-code path
The same capability from Flow, 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.
