There’s a thing that happens with good infrastructure: it turns invisible. The water comes out of the tap and nobody thinks about the pipes until the day it doesn’t.
Perhaps the most powerful thing we built in the last two years disappeared on us like that. It worked, so we stopped looking at it.
When we added AI to RevWorks — deal assessments, ai chat, pipeline analysis, the daily advisor — we built a layer underneath that decided what the model got to see. Which fields, in what order. Rollups computed first. Related records filtered to the ones that mattered. The business meaning attached to each value, in plain words. Every request assembled live, as the user asking, so their permissions rode along.
Then we built on it. AI feature after feature, at a rapid pace. Nobody demoed the layer. Nobody put it on a slide. It was the pipes.
It took customers asking an unrelated question — why can’t our reps use Claude with Salesforce? — for us to look back at what the pipes had been doing. Here’s what we found.
Hallucination stopped being the thing we debugged
Anyone who ships an LLM feature on business data learns the same lesson in the first month: the model fills gaps. Give it a record with an ambiguous field and it produces a confident reading of it. Give it fifty rows and ask for a total and it gives you one. Give it a stage called “Negotiation” and it assumes it knows what that means in your sales process.
We chased exactly those “bugs” at first, and I remember the moment the pattern clicked. We were debugging an assessment that had called a deal “late stage” when the team considered it early. The stage name was a bit abiguous. The fix wasn’t a better prompt. It was the instructions next to the field: in this org, Negotiation means pricing discussion has started; it does not mean verbal commit.
Every fix after that was the same shape, and every one was upstream of the model. Don’t give it the ambiguous field; give it the twelve that matter. Don’t give it fifty rows; give it the total. Don’t let it guess what Negotiation means; tell it, next to the value, in a sentence a RevOps lead wrote.
Once the layer did that consistently, this whole category of “AI bugs” mostly went away. Not because the model got smarter. Because there was nothing left to fill in, there was no ambiguity. The context was full, so the model didn’t have to invent any.
Fast, because the model wasn’t forced to do all the work
The second thing we took for granted was speed.
An agent that has to discover a record’s shape makes a lot of calls. Describe the object. Query the record. Query the children. Query the parent. Query the contacts. Add things up. Each call is a round trip, and each one is a place to go wrong.
Our layer handed the model one assembled payload. One trip. The rollups were done. The related lists were filtered. The parent was attached. When we finally measured it against the native path — same org, same user, same question — it came out to one tenth the tool calls, half the tokens, and four times faster to the answer.
Users experienced that as “the AI is quick.” We experienced it as not having a performance problem to solve. Neither of us credited the pipes.
Deep, because the context was full
The third thing is the one I’d most undersold. Full context doesn’t just prevent errors. It changes what the model can see and how valuable the interaction is.
When a deal assessment has the open pipeline on the account, the days since the last real activity, the contacts with buying roles and which of them have gone quiet, the stage history, the health signal from the CS platform, and a note that the close date on this stage is usually a placeholder — the model can say something a sales manager would recognize as insight. This deal is stalled on the economic buyer, and the close date is fiction.
Give the same model the raw record and it says the deal is in Negotiation with a close date next month. True, with nothing insightful or additive.
Clarity was never a model capability. It was a function of how much of the picture the model was handed, pre-assembled, with meaning attached.
Configured per customer, which is what made it general
The last thing, and the one that made it a product rather than a feature: none of this was hardcoded.
Every customer’s Salesforce is different. Different stages, different custom fields, different definitions of “open,” different signals that matter. If the layer had been a fixed field list, it would have worked for one customer and been quietly wrong for the rest.
Instead it was configuration. Which fields. What they mean here. Which related records count. What the thresholds are. A RevOps person at each customer could set that, and the AI features read it. The same feature produced a different, correct assessment at every customer, because the context underneath it was theirs.
We thought of that as making RevWorks AI deployable. It was actually the thing that made the layer abstacted and general purpose. If it could carry one customer’s meaning for our revops features, it could carry it for any agent in any business function.
The insight that changed everything
Put those four together — grounded, fast, insightful, configured by the customer — and you have a description of what a context layer is for. We’d built one, proven it on a product real revenue teams used every week, and treated it as plumbing.
The customers asking about Claude were asking for the pipes, not the faucet. They didn’t know that. Neither did we, until we realized the magic of what had been quietly doing the whole time.
That’s ContextWorks. It isn’t new. It’s the part of RevWorks we finally stopped taking for granted.
