Ask an agent “what’s going on with the Acme account?” and watch what it does. It fetches the account record. Then the opportunities, then the contacts, then the recent activity, then the cases. On each one it requests the standard fields, which may or may not be the ones your team uses, and then works out for itself how the pieces fit. Eight or nine requests later it has an answer. Ask again tomorrow, or ask as a different user, and it may put the pieces together differently.
The problem isn’t the agent. It’s what the agent was handed. Salesforce hands back records, and a record is the wrong shape for an agent to read.
What a record is
A record is one row in one Salesforce object: an account, an opportunity, a contact, a task. It holds that object’s fields and nothing else. Records relate to each other through lookup fields, so an opportunity points at its account, a contact role points at its opportunity and its contact, and an activity points at whatever it was logged against. The business picture of one customer is spread across dozens of these rows in a handful of objects.
The Salesforce UI mostly maps one page to one record. A record page shows that row’s fields, with related lists underneath that link out to other rows. A rep builds the full picture by clicking through them, skipping the fields they know are dead and carrying years of context to the rest.
A record is an atomic unit of data, not a full business item. “The Acme account” as a sales leader means it is the account row plus its open opportunities, the people involved, the recent activity, the open cases and the coming renewal, read with the knowledge of which fields and which rows count. None of that is on the account record. And no record carries what its fields mean. “Amount” is a number. Whether it is ACV or TCV, and whether finance trusts it, lives in someone’s head.
This is how most Salesforce data for AI agents is delivered today: one row at a time. An agent asked for a record gets that row with its standard fields, then goes looking for the related rows one object at a time, and decides for itself which fields and which rows matter. It brings none of the context a rep brings, and it treats whatever it is given as relevant.
What an entity is
An entity is a curated and assembled view of one Salesforce object, decided in advance by someone who knows the business: which fields an agent gets for an account, in what order, what each one means, which related records travel with it, and which summary numbers stand in for rows it would otherwise have to count. It is a definition, not a copy of the data. The data is fetched live from Salesforce every time it is asked for.
When an agent asks about the Acme account, here is what it receives instead of the record:
- The fields that matter, in the order they matter. 25 fields instead of the 180 on the object, with the forecast amount near the top and the dead ones absent.
- A short instruction beside each value. “ACV, not TCV. The number finance uses.” “Lags the integration by a day.” The guidance sits next to the value it explains, so the agent never has to match a rule in a prompt to a field in a response.
- Rollups already computed. Open pipeline, stalled deals, days since last activity, calculated before the agent sees anything and filtered the way your team filters them.
- Related records already chosen. The three open opportunities and the last five activities, not every child row ever created.
- Computed signals added in. Values that live in no field, such as a health score or the result of a Flow or an Apex class, calculated before the response and delivered beside the fields they describe.
All of it arrives in one response. The agent reads it the way a rep reads a well-designed page, except that the context the rep carries in their head is written down beside the data.
One definition, every agent
The same definition serves whatever is asking. An Agentforce agent, a rep using Claude or ChatGPT, a prompt template, a Flow: each receives the Acme account assembled the same way from the same definition, so two agents can’t give two readings of the same deal. When RevOps changes what qualified means at 2pm, every agent reads the new version on its next call. There is no prompt to update and nothing to deploy.
Where to look
The next time one of your agents answers a question about an account, look at exactly what it received. If it received the record, the answer was a guess about which parts of it mattered. See what an entity looks like when it reaches an agent.
