Your reps move quickly. Between calls they check the latest on a deal, update the next step, log what the customer said, and move on to the next account. An agent helping them has to work the same way, from the same operational data in Salesforce. A summary built for reporting is the wrong tool for that job.
What the warehouse is good at
Your data team has probably built a semantic layer in the warehouse this year, in Snowflake, Databricks, dbt or Tableau. It holds prebuilt summaries and metrics, with definitions so nobody has to rebuild them: what net revenue means, which tables join, what a metric leaves out. Ask for pipeline coverage by region this quarter and you get the right number.
That is what the warehouse is for: answering questions about the business as a whole, which somebody anticipated and modeled in advance. Keep using it for that.
Why operational work needs the records themselves
Reps don’t work from metrics. They work from the record in front of them: the opportunity, its contacts, the open case, the notes from yesterday’s call. An agent doing the same work needs the same thing.
What’s going on with the Acme renewal? Should I escalate this case? Draft the follow-up for yesterday’s call with the Meridian team.
None of those is a question about a total. Each one needs the details of one customer, as they stand when the rep asks: the close date the rep moved this morning, the contact who replaced the champion, the case that was escalated an hour ago. A warehouse model built for rollups was never shaped to hand an agent that, and copying more detail into it, faster, means paying to rebuild Salesforce somewhere else.
Operational work also changes the record. The agent updates the next step, logs the call, or flags the deal. Those changes belong in Salesforce, where your team will see them, and the next request should read them back immediately.
Why it should read the record as the person asking
Salesforce already decides who can see which accounts and fields. When the agent reads the live record as the signed-in rep, those sharing rules and field-level security apply to the query itself. In the warehouse, the data team has to rebuild those rules by hand and keep them in step with Salesforce. If they drift, an agent can show a rep a margin field that Salesforce would have hidden from them.
The meaning should live there too. Your RevOps team knows the renewal date lags a day and shouldn’t be quoted to a customer, and they should be able to tell the agent that without filing a ticket with the data team.
You need both
The warehouse should keep deciding what “pipeline” adds up to. Something else has to decide what an agent is told when it opens one opportunity to do something about it, and that should come from the live record. Running both does not mean running two of the same thing.
Where ContextWorks fits
ContextWorks is a semantic layer for Salesforce CRM data: record-level, not metric-level. When a rep asks the agent about Acme, the agent receives what your team decided matters about an account, read from Salesforce at that moment, as that rep. For an opportunity, that can mean 22 fields with instructions on how to use them, instead of all 212. Your RevOps team changes those definitions themselves, without a developer.
It does not replace the warehouse, and it covers Salesforce data only. If the agent needs invoice history from your billing system next to the account, that still comes from the warehouse.
The question to ask before you sign off
If someone has shown you a diagram of a context layer for AI agents and asked for your approval, ask one question: when a rep asks the agent to work on a customer, is the agent reading the record as it is right now, as that rep is allowed to see it? If the answer is a summary in the warehouse, you have half of what you need. How ContextWorks builds that view shows the other half.
