Loading post…
SalesforceScott NybergExplainer
How AI Agents Get Trusted Customer Context with Data 360 Data Graphs
Summary
Salesforce’s AI Engineering team uses Data 360 data graphs to close the context gap that prevents agents from reliably personalizing customer interactions. The graphs join, aggregate, and apply business logic across fragmented identities, accounts, products, contracts, orders, cases, services, and entitlements, while partitioned data spaces provide a filtered customer-success view. The team designs smaller graphs or multi-graphs around agent access patterns, adds indices, supports semantic or keyword search, and curates context so agents can traverse extensible many-to-many relationships without receiving unnecessary data. Reusable deployment automation and validation practices helped deliver five major releases in six months, with integrations spanning Postman, Apex, Agentforce, and low-code or no-code workflows. Live monitoring later showed P50 performance below 200 milliseconds, compared with an earlier benchmark of about 400 milliseconds.
Context
Agents need trusted context about a customer’s identity, account, products, usage, services, history, and entitlements, but that information may be distributed across many systems with different identifiers. The team’s mission is to turn those disparate data points into a cohesive data product that agents can retrieve at runtime.
Approach / What changed
The team uses Data 360 data graphs to perform joins, aggregation, relationship management, and business logic upfront. It separates the broader identity graph from a filtered customer-success data space, designs graphs around access patterns, uses smaller graphs or multi-graphs with indices, supports semantic and keyword search, and curates context at the appropriate grain. Reusable deployment automation, data validations, and multiple integration paths support further releases and adoption.
Takeaways
Partitioned architecture exposes a filtered customer-success identity view rather than the entire identity universe, helping isolate one customer’s information from another’s and from prospect data.
Graph size involves a performance trade-off: oversized graphs can slow retrieval, while undersized graphs may recreate the aggregation problem through joins at request time.
The team delivered five major releases in six months by automating deployment, reusing data validations, and demonstrating integrations through Postman, Apex, Agentforce, and low-code or no-code environments.
FAQ
How does the architecture prevent unrelated customer data from entering an agent’s context?
The broader identity graph resides in its own data space, while a filtered view is exposed to the customer-success data space. That view is locked down for specific agent-context and outreach use cases.
How are graphs designed when agents may ask unpredictable questions?
The team models extensible many-to-many relationships and supports semantic or keyword search so agents can traverse the graph from different starting points. It also curates and summarizes context rather than returning every interaction, file, attachment, or data point.
What improved the graph’s response performance?
The team first studied agent access patterns, then divided information into smaller graphs or multi-graphs and built indices to retrieve relevant information instead of scanning full tables. Live monitoring later showed P50 performance below 200 milliseconds, compared with an earlier benchmark of about 400 milliseconds.
Source and freshness
- Source
- engineering.salesforce.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.