Part 2 of Built to Last: A Practical Series on the Enterprise Context Layer. Part 1 showed a 60-second account summary that catches what 30 minutes of manual prep misses. This post is about the foundation that makes it possible.
Most companies have lived some version of this story. The AI demo looked great, leadership got excited, and the pilot went live. Then production disappointed, quietly, over a couple of months. The answers were thin and reps stopped asking. The pilot didn’t fail loudly enough to make headlines in the company, and so it just faded away.
When that happens, the model usually gets the blame. The team concludes the technology isn’t ready and shelves the effort, thinking maybe a future model will work better. In our experience the real problem sits underneath. The agent was answering from fragments, and the fragments it could reach were the least interesting ones.
Three kinds of data, three different jobs
Think about what you’d want to know before walking into a meeting with your own customer. It sorts into three families.
Core CRM is the history of the relationship. Accounts, contacts, opportunities, products owned, open cases. It tells you what has happened between your company and theirs. It’s the system of record, and it’s where most AI pilots start and stop.
Product usage is what the customer truly does with your platform. Logins, feature adoption, API calls, workspace activity. The customer’s real behavior, recorded continuously, without anyone typing a note into a record.
Engagement signals are who’s paying attention right now. Meeting attendance, email activity, documentation visits, webinar signups. The early, quiet evidence of interest, concern, or a new person entering the picture.
A well-built report can assemble the first family. Patterns and intent only appear when all three sit on one profile. The account summary from Part 1 proved it: the case list came from CRM, but the pullback signal, the expansion pattern, and the new stakeholder all required the join.
What a context layer actually does
So why can’t the agent just query the raw tables? The best way to answer that is to follow the account summary from Part 1 up through the context layer, one layer at a time. On the Salesforce platform, the context layer is Data 360.
Layer 1: the source data. CRM objects sit on one side. Usage events and engagement activity arrive from outside on the other. At this layer they’re just tables. An agent pointed here can read any of them individually and understand none of them together.
Layer 2: identity resolution. This is the layer that makes external data worth having. A usage event knows a workspace ID. A webinar attendance knows an email address. A documentation visit knows a domain. None of them knows a Salesforce account. Identity resolution ties every one of those records to the account, the contacts, and the opportunities they belong to. Skip this layer and the question “how is usage trending for this customer?” has no answer, because nothing in the usage data says which customer it belongs to.
Layer 3: the unified profile and calculated insights. One profile per account that holds the relationship history, the behavior, and the attention signals. This layer also computes the durable measures once, instead of making the agent run statistics on the fly, which is slow and easy to get wrong: health scores, usage trends, limit-hit counts, co-purchase patterns across similar accounts. When Part 1’s summary flagged usage down 40 percent in three weeks, that number came from a calculated trend, ready before anyone asked.
Layer 4: the agents. Everything below exists so this layer can be simple. An agent asks a question against the unified profile, and the answer draws on the whole picture: the history, the behavior, the attention signals, and the computed insights. This is the difference between an agent that recites fields and an agent that tells the rep the meeting is a save, not a check-in.
At every layer, the practical answer to “why not just query the raw tables?” is the same. The raw tables don’t know they’re about the same customer. The well-assembled context layer is what makes them agree.
BUILD THE CONTEXT LAYER BELOW
Core CRM
- Account · ACCT-0093
- 3 won opps · $186K ARR
- Case #7241 · high severity
Product usage
- workspace: ws_4471
- api_calls, feature events
- rate_limit_hit ×9
Engagement signals
- attendee: j.alvarez@…
- docs visits ↑3× / 30d
- webinar signup · Tue
The part most teams get wrong
Teams hear all this and conclude they need a company-wide data cleanup before they can start. A year of data transformation, then AI. That instinct feels responsible, and it’s the single most expensive mistake in this space, because the cleanup delays value and most of it never gets used.
You don’t need all your data to be ready. You need the data under your first use case to be ready. Call prep needs accounts, contacts, opportunities, cases, one usage feed, and a handful of engagement signals. That’s the scope. Wire those in, resolve identity across them, compute the few insights the use case needs, and go live.
Then the economics start working for you. The second use case costs less than the first, because the profile and the plumbing already exist. The third costs less than the second. Every use case leaves the foundation stronger for the next one. Compare that with the pilot-per-department pattern, where every team wires its own agent to its own fragments and nothing compounds.
The foundation outlives the use case
Zoom all the way out and the call prep framing falls away. The context layer you build for one use case is an account intelligence asset for the whole company. Service can draw on it to see revenue context behind a case. Marketing can draw on it to spot expansion-ready accounts. Every future agent, whatever it does and whoever builds it, starts from the same trustworthy picture of the customer.
That’s what “built to last” means in this series. Individual agents will come and go. The durable investment is the layer underneath them, and it serves the whole enterprise rather than one department or one vendor’s roadmap.
We help teams get the data under their first use case ready, without the boil-the-ocean project. And in the next post, we’ll follow this thread somewhere interesting: Salesforce has gone headless, and a foundation built this way lets you choose the intelligence that sits on top of it.