A few months ago I was on a call with the RevOps lead at one of our customers. We were there to talk about RevWorks. About ten minutes in, she asked something that had nothing to do with it.
“Our reps keep asking to use Claude with Salesforce. Security said no. Is there any way to make that work?”
I’d heard a version of that question before, so after the call I went back and counted. Of five RevWorks customers we asked, five had requested external AI or MCP access to Salesforce. Five had been told no.
That’s the day I started to see what we’d actually built. Here’s the story, in four parts.
The model was never the hard part
RevWorks, our native Salesforce app for sales teams, has been 100% native on Salesforce since 2017. When we added AI to it — deal assessments, pipeline analysis, the daily advisor — the obvious plan was to hand the model the records and ask good questions.
It worked right up until it didn’t. The model would weigh a field nobody had touched since 2019 as heavily as the close date. It would read a picklist value literally when everyone on the sales floor knew it meant something else. It would add up fifty rows and be right most of the time — which, it turns out, is worse than being wrong all the time, because you can’t trust any answer if you can’t tell which ones it got wrong.
Every fix we made had the same shape. Not a better prompt. A better handoff. Fewer fields, in a deliberate order. A sentence attached to each one saying what it meant and how to use it. Rollups computed before the model ever saw them. Related records filtered to the ones that mattered. And because we’re native, every request ran as the user asking, so field-level security and sharing came along without anyone building them.
We built a layer to do all of that, under RevWorks, and then we mostly stopped thinking about it. It was plumbing. The AI features got good, customers used them, and nobody — including us — put the plumbing on a slide. (Which is how plumbing should be, until there’s a probem.)
Five for five
Back to that call.
What struck me wasn’t that security had said no. It was why. In every one of the five cases, the person who refused had asked a perfectly reasonable question — what exactly can this tool see? — and gotten the only honest answer available: everything the user can. Every field on every object. No way to narrow it without writing code. No way to see what the agent would receive before connecting it.
Nobody was being obstructive. The options were bad, so the answer was no.
And the thing sitting under RevWorks was, almost exactly, the thing that would have made the options good. Curate what’s exposed. Explain what it means. Run it as the person asking. Show the payload before anything connects. We’d built it for our own features. The customers were asking for it for every tool.
Someone else was building it by hand
Around the same time, we saw an internal announcement from a very large Salesforce customer. They had stood up a context engineering team — named, funded, with quarterly objectives — whose job was to deliver trusted, curated context to the company’s agents and skills.
Their list of what they needed read like a spec: a central repository, version control, methods for collecting business context, quality control, auditing. I read it twice. They were describing, as a to-do list, the thing we’d been running in production for a year.
When a company puts a function on the org chart, the problem has a budget. Most companies with the same problem will never fund a team for it. That was the moment the business case stopped being a hunch.
And ContextWorks was born
The layer under RevWorks was shaped around what RevWorks needed. A standalone product has to be shaped around what any agent needs, authored by the people who know the business rather than by us. So: a builder a RevOps lead can use without a developer. Instructions at the field level, not just the entity level. Domains, so Sales and Finance can own their own definitions without stepping on each other. Versioning with rollback, because changing what an agent knows while people are using it is where governance gets real. Preview, so you can see exactly what the agent gets before it’s connected. Export, so the definitions are portable.
This meant a new managed package, with a new name. ContextWorks.
RevWorks AI features now interface directly with ContextWorks. Our own AI features read from the same entities you’d define for Claude or for Agentforce. Looking back, building the layer first and the product on top would have been faster. We did it the other way around, and the layer is better for having been proven on a real product, with real revenue teams, before calling it a product.
What I’d tell that RevOps lead now
If your agents’ answers aren’t holding up, look at what you’re handing the model before you look at the model. And if you’ve been told no, the no was reasonable. The options were bad. They’re different now - check out ContextWorks.
Same engine. Same data. Every agent.
