AI Agent Data Context: Document Your Data Before Connecting

On 9 October 2026, LinkedIn Engineering published a post (LinkedIn Engineering, 9 October 2026) describing a shared data context layer, built to help people and AI agents find the right data assets. The layer combines automatically generated dataset profiles with knowledge maintained by teams. Our take: an AI agent data context is a written description of which table is authoritative, which filters are mandatory and which rules already exist. An SME should write it before connecting an agent to its ERP or CRM.

What did LinkedIn put in its data context layer?

According to LinkedIn's post, the generated profile of each dataset describes its purpose, its fields, its join keys and some representative queries. That is the descriptive half of the layer. It tells a reader what a dataset is for and how it connects to others, before anyone runs a query against it.

LinkedIn adds guidance written by humans to those profiles: business definitions, exceptions and data quality issues. Its example is a metric suited to tracking engagement but "unsuitable for financial close". Two other examples of captured rules are "people use partition filters to avoid double-counting" and "a join key may be valid only for data after a particular date".

In a test on one business domain, LinkedIn reports that the rate of acceptable answers rose from 25.9% to 79.5% once the context layer was integrated. In the same test, the median time to get an answer went from 10.7 to 4.7 minutes. These are LinkedIn's own figures, from one domain.

Our take: the useful detail is the kind of rule LinkedIn chose to write down. A partition filter and a date-bound join key are not exotic. Most ERP or CRM systems that have run for years probably carry equivalents, usually in the head of one or two people. That is what an agent cannot guess from a table name.

What does Cryip report about Coinbase's risk agent?

According to Cryip, 8 October 2026, which relays a Coinbase post from its Owning Intelligence series, the LLM-based risk agent is added to the machine learning model and the rules already in place for Onramp. It works downstream of the existing controls, as an extra contextual review of selected transactions.

Our take: in Cryip's relay of the Coinbase post (8 October 2026), the agent arrives last: the model and the rules already existed, and the agent reviews selected transactions downstream of them. For an SME, the equivalent question is what your ERP or CRM already enforces, and whether that is written anywhere before an agent is asked to work next to it.

Do agents need memory or documentation?

On 3 October 2026, the author of the liao.gg blog argued that memory plugins for agents rely on retrieving fragments from a vector database. Retrieval of that kind does not say what is correct, current or missing, the author argues. The conclusion is blunt: "Agents don't need memory. They need documentation."

The recommended alternative is structured documentation that the agent reads before working and updates afterwards. It is limited to what the code cannot show (requirements, decisions, constraints), and facts are rewritten when they change rather than appended. The author presents their own open source tool, Operator, as applying this approach.

Our take: this is a developer's argument about code, and it is one author's position. The parallel with LinkedIn is the part worth keeping. In both cases, what the agent is handed is a maintained description of what is true and what applies, not a stack of retrieved fragments.

What do Microsoft's Dynamics 365 skills assume about your data?

According to Microsoft Message Center notice MC1492151 (mc.merill.net copy, 8 October 2026), Microsoft is rolling out from 8 October 2026 thirty sales and service skills for Copilot experiences, around Dynamics 365 Sales and Customer Service. The notice lists general availability in Cowork, the Frontier programme for Code, and private preview for Autopilot.

Microsoft Learn (30 September 2026) describes the Dynamics 365 Customer Service plugin for Copilot Cowork as a way to delegate case-handling flows: investigate an issue, surface the right records, coordinate actions and trigger next steps. Cowork works within the Dynamics 365 and Microsoft 365 permissions already in place, on live case data. Checkpoints let representatives review and approve field updates and proposed actions before they are saved.

Our take: permissions settle who may see or change a record, and checkpoints put a person in front of the update. Neither says which record to believe when two sources disagree, or which filter must always apply. That description comes from the company's own knowledge.

See also our piece on Copilot Studio versus custom agents in Dynamics.

What should a small company write down first?

Our take: start with three things, in plain language, kept in one place. First, which table or system is authoritative for each figure that matters, for example revenue, stock or open orders. Second, the filters that must always apply, such as excluding cancelled orders or test accounts. Third, the rules your team applies by habit, with their exceptions and the date from which each one holds.

This is closer to LinkedIn's human-written guidance than to its generated profiles. LinkedIn generates its profiles and still adds guidance from people. Someone who knows the business has to write down that one figure suits a dashboard but not a financial close, and rewrite it when that changes.

Keep the document short and give it a named owner. The liao.gg author limits documentation to what the code cannot show and rewrites facts when they change. The same discipline suits a data description. A page that nobody updates becomes a stale source that an agent may follow with confidence.

When the description exists and you move on to the connection itself, MCP explained for connecting AI agents covers how an agent is wired to your tools.

Where does this belong in an ERP or CRM project?

Our take: the description of your data is a deliverable of its own, and it belongs in the scope of an AI integration project in your ERP, ahead of any model choice. It also gives the move from pilot to production something concrete to check against, as discussed in taking an AI pilot in ERP to production.

See also: Anthropic Claude Dashboards: What Your Data Must Supply.