Why Your Company Needs a Context Graph (and How to Build It) — Gil Feig, Merge
Gil Feig, co-founder and CTO of Merge, explains why agents need a company-wide context graph rather than a few MCP connections. Using the question of which customers were upset last week, he shows why live API lookups fail across large datasets and why synced local copies, routing, summarization, skills, memory, and traceable provenance are needed to build a reliable company brain.
Gil Feig, co-founder and CTO of Merge, argues that every company needs a context graph, which he frames as a company brain rather than a literal graph database. His core claim is that connecting a few MCP servers to an agent is not enough. Live API lookups break down once questions span large datasets, so a serious context layer has to combine synced data, live calls, routing, summarization, and encoded company knowledge in the form of skills and memory, all with traceable provenance. He is explicit that the talk avoids specific product recommendations and focuses on architecture and structure.
What a context graph contains
Feig defines the company brain as four kinds of input. The first is third-party data from systems like NetSuite or Jira. The second is structured context, which includes data from other third parties and material your team deliberately places in the context layer, such as static documents that should always reach the agent. The third is memory, which forms through use: things users explicitly tell the agent to remember, and things the agent decides on its own are worth retaining. The fourth is skills, which he calls a very important part of the graph and which carry the company’s own definitions and processes.
Why live lookups fail at scale
His running example is the question ‘why was customer A upset last week?’ A single MCP connection to Zendesk handles this well. The agent pulls the customer’s tickets, sees that a sync was broken, and reports the three tickets filed. The problem appears when the question widens to ‘which customers were upset last week?’ or ’last year?’ The agent would have to load every ticket in that window, pulling roughly a hundred at a time, until it times out.
Feig’s diagnosis is that the access patterns of most SaaS APIs are built for record-level retrieval, not analysis. In theory a vendor could expose a semantic endpoint where you ask in English which customers were upset, but vendors have little incentive to build that, since vectorizing data costs them money and a richer query surface means customers visit their platform less. The conclusion is that you cannot rely on MCP live lookups for anything that requires semantic search or analysis across a large corpus. You need to sync a copy of the data locally into a vector database, which he notes AI can help build relatively easily. The real work lies in deciding how to store data in this layer and how to retrieve from it.
Live calls are not obsolete. A question like ‘what is this customer’s billing status in Stripe’ is a single-entity lookup and a single action, and MCP handles that well. The rule he offers is simple: if the task is a simple lookup, go live; if it requires semantic search or analysis over a vast dataset, sync a copy.
Router, summarizer, and the role of skills
Once both synced and live data are available, the system needs coordination. A router decides at the start where an incoming prompt should go. After retrieval, a summarizer condenses the synced and live results before they return to the agent, because dumping a massive volume of raw retrieved context back into the model is not workable.
Feig’s point about memory and skills is that retrieving context is itself an expression of company principles. ‘Upset’ means something different at each company. For one business it might mean a count of opened tickets. For another, the tickets might be positive, and the real signal of customer happiness lives in Qualtrics survey data that the company always consults first. Skills encode these determinations, such as how to decide whether a customer is happy. Therefore the agent should consult its skills and memory before deciding which synced or live sources to query, then summarize and return the result. He summarizes the flow as: prompt arrives, gets routed, the agent checks memory and skills, consults the appropriate cache or live sources, and then summarizes and responds.
He is emphatic that there is no magic here. If you understand the calculation you need within your own use case, the system is deterministic enough to build. His open-tickets example, which summarized each customer’s tickets and assigned a status, would have been impractical with live lookups alone but was simple against a local store. Real answers usually mix live and cached lookups.
Four tiers of context
Feig organizes context into four tiers. The first is prompts, skills, and memory, which drive decisions about where data should come from. The second is live API calls, which are easier to build, simpler to add, and cheaper to run than synced context, so they should be preferred for simple retrievals. The third is cached or synced data, which is essential for semantic and complex deep questions but harder to set up, more expensive because it requires a vector database and continuous syncing, and harder to keep current. The fourth is derived context, meaning summaries or other artifacts generated from pulled data and stored in the structured layer. For example, when a customer’s full ticket set arrives, the system can store a summary of it so that common future questions do not require re-fetching and re-summarizing everything.
The decision flowchart
Feig walks through a decision flow for each incoming query. The system first asks whether a skill or memory matches. If one does and it needs no external data, the system generates a response directly. If no match exists, or the matched skill needs external data, the system moves to data selection. It checks the cache or synced store and asks whether the data is fresh and within SLA. If yes, the cached context is used. If not, it calls the live API. The system loops through these retrievals until it has enough context. Once sufficient, it may store a memory of what it discovered, then generates the response.
Traceability and provenance
The final section, which he presents as seemingly unimportant at first, is traceability. Every piece of data should retain where it came from, when it was fetched, under which ID and scopes, who accessed it, which permissions were used, whether it was transformed, and what the original looked like. For synced data in vector stores, this information belongs in metadata attached to each record. He compares this to the way ChatGPT and similar interfaces cite sources at the end of an answer, and argues this matters more when a system makes business-critical decisions on data that may be stale. Invalidation rules should be explicit, such as treating data older than a month as unusable. Provenance is also essential for debugging, because something will eventually go wrong.
Worked example: an Acme status update
Feig applies the framework to a request for a one-paragraph status update on customer Acme, including renewal risk and last support interaction. The system checks the cache for an account summary, assuming no skill applies. If the summary is missing or stale, it calls the CRM live. It then queries the ticketing system for the last support interaction, using cache if within SLA and otherwise a live call. It limits the pull to five tickets, since full history risks timeouts. Finally, it generates a derived summary, stores it, and returns the answer.
Key takeaways
Feig closes with four points. Tools are not context: a context graph must reason across the whole company, including data, business processes, and documented behaviors such as how complaints get routed. More data is not always better, so the goal is fresh, high-quality data pulled only as needed, structured so it can be accessed efficiently. Every answer must be traceable, so that a bad AI decision can be explained. Merge’s products, which he mentions at the end, cover an LLM router called Gateway, Unified for syncing third-party data, and Agent Handler for prebuilt live MCP connections with governed identity and provenance built in.