How to build a context graph from the systems you already have
Which system holds which part of a context graph, how the same customer is matched across them, and how the graph stays current, without moving data out of the ERP.
You build a context graph from existing systems by reading the ERP, CRM, inbox, shared drives and spreadsheets where they are, matching the same customer, product and policy across them to one identity, and keeping a pointer back to the source of every fact. The systems stay where they are. Nobody moves to a new database.
That is the short answer. This note covers the part most explanations skip: which system usually holds which piece, what goes wrong when you copy it across naively, and how the graph stays current once it exists. What a context graph is, and the six steps we follow to build one for a task, are in what is a context graph for AI agents.
Where the pieces already live
Most of what an agent needs for one piece of work already exists. It is spread over five or six systems, each holding a different part, and each with its own way of being wrong.
| System | What it usually holds for one task | What goes wrong if you copy it naively |
|---|---|---|
| ERP | Customers, items, prices, orders, routings, stock, invoices | Prices and stock change daily, so a copy is stale by the next morning |
| CRM | Accounts, contacts, deals, stages, the history of contact | The same company exists two or three times, spelled differently from the ERP |
| Orders, change requests, and most decisions and the reasons behind them | The decision is in a thread, not a field, and the thread names the customer in its own way | |
| Spreadsheets and shared drives | Quoting sheets, planning sheets, price lists, procedures | Several versions of the same sheet, with no record of which one is current |
| Chat | Quick approvals and exceptions ("fine, ship it Friday") | Nothing ties the message to the order it was about |
| Call notes | What the customer asked for and what was promised | Free text, with no link to the account or the deal |
None of these systems is wrong on its own terms. The ERP is right about prices and the inbox is right about what was agreed. The trouble starts when an agent has to combine them and cannot tell that "ACME NV", "Acme" and "acme-group.be" are one customer.
Step one is matching identities, before anything else
Matching records that describe the same thing is an old problem. Statisticians call it record linkage, and Fellegi and Sunter set out the standard approach in 1969: compare two records field by field and decide one of three things. They are the same, they are different, or there is not enough evidence to say.
That third outcome matters most in practice. Clear matches can be linked by rule, and clear non matches can be left apart. The uncertain pairs go to a person who knows the customers, once, and the answer is kept so the same question is not asked again.
It has to come first because everything else attaches to identities. A decision trace about a discount points at a customer. If that customer is three records, the trace sits on one of them and the other two look like customers with no history. On our own platform, the graph holds each company, person and deal once, however many systems name it, and every record stays linked to where it came from.
The effect can be large. At a deep-tech company selling into hospitals, a partner spreadsheet of about 2,700 companies collapsed to 64 ranked accounts once the territory was modelled from government sources and linked to the CRM.
Keep the systems of record, read from them
The ERP stays the place where prices and orders are kept, and the CRM stays the place where deals are kept. The context graph reads from them. People keep working where they work today.
In practice that means one pipeline per system. Each pipeline reads the records, maps them to the kinds of things in the ontology (customer, order, quote, policy) and links them to the identities already in the graph. On ours, each pipeline is also matched to Atlas, our model of the world outside, so a customer in the CRM and the same company in a public registry meet at one node.
Two things to agree before the first pipeline runs:
- Who may see what. Everyone in the workspace sees everything that was brought in, even records the source system would have hidden from them. Our trust page says this plainly: connect only the data that everyone in the workspace may see.
- Which system wins. When the ERP and the CRM disagree on a customer's address, one of them is the source of truth for that field. Write it down per field, not per system.
How the graph stays current
A context graph that is a week old is worse than none, because an agent will act on it with confidence. Not every fact changes at the same speed, so not every fact needs the same treatment.
| How often it changes | Examples | How to keep it current |
|---|---|---|
| Many times a day | Stock, the production queue, order status | Read changes as they happen, or check the source at the moment the agent needs it |
| Daily to weekly | Prices, open quotes, deal stages | A regular sync, with the time of the last read stored on each fact |
| Rarely | Customers, products, routings, rules | A sync is enough, but each change should replace the old value and keep it as history |
For databases that support it, change data capture is the usual way to read changes as they happen. Tools like Debezium read the database's own change log, so they capture every change, including deletes, without adding a "last updated" column. Many business systems only offer an API, and then a scheduled read is the honest option.
Whatever the method, each fact should carry two things: the source it came from and when it was read. That is what lets an agent, or a person checking its work, see that a price is from this morning and a routing is from last month.
Where decisions live today, and how they get into the graph
Systems of record keep what was decided. They rarely keep why. Foundation Capital's example is a renewal that closed at a discount above policy: the CRM has the discount, while the reasons sit in incident tickets, an escalation and an earlier approval in a thread.
You don't need to dig up every past decision before you start. Two sources are worth it:
- Going forward, each decision an agent or a person makes in the work becomes a trace: what was decided, about which things, on what evidence, under which rule, by whom and when.
- Looking back, only the exceptions that still set precedent, such as a standing discount for one customer or an agreed delivery rule. A person confirms each one before it counts.
An agent can propose a trace from an email thread. It becomes an accepted fact only when a person or an agreed rule promotes it. Otherwise the graph fills with guesses that look like history.
What it does not need
- A data migration. The ERP and the CRM stay as they are.
- A new tool for the team to fill in. If people have to enter data twice, the graph will be out of date within a month.
- All your systems on day one. Start with the systems one piece of work needs. For an order confirmation at a manufacturer, that is the ERP, the inbox and the quoting sheet.
- Clean data first. Duplicates and conflicts are what the matching step is for. Waiting for clean data usually means never starting.
Questions people ask
Do I need to migrate my data to build a context graph?
No. The systems of record stay where they are and keep being used. The graph reads from them through one pipeline per system and keeps a link from every fact back to its source.
Which system should I connect first?
The ones the first piece of work needs, and no more. Pick the task first, then list where its facts live. For most order and quoting work that is the ERP, the inbox and one or two spreadsheets.
How does a context graph stay up to date?
Fast changing facts like stock and order status are read as they change or checked at the moment of use. Slower facts are synced on a schedule. Every fact keeps its source and the time it was read, and a new value replaces the old one while keeping it as history.
What about data that only lives in email and calls?
Orders and decisions in email can be read and linked to the customer and order they are about. Decisions found that way are proposed by an agent and accepted by a person before they count as fact.
Is a context graph the same as a knowledge graph?
No. A knowledge graph holds what exists and how it connects. A context graph is the slice one task needs, with current state and the decisions behind it. The full comparison is in context graph vs knowledge graph vs ontology.
How long does it take?
It depends on how many systems the first piece of work touches and how messy the identities are. How we plan it is in how long AI implementation takes.
