{ "video": { "id": "cSz7aL2nl2U", "title": "Why Your Company Needs a Context Graph (and How to Build It) — Gil Feig, Merge", "duration": 911, "upload_date": null, "channel": "AI Engineer", "source": "AI Engineer", "event_format": "" }, "analysis": { "video_id": "cSz7aL2nl2U", "title": "Why Your Company Needs a Context Graph (and How to Build It) — Gil Feig, Merge", "one_liner": "Connecting a few MCP servers isn't enough: a company context graph needs live lookups for simple retrievals, a locally synced vector copy for semantic or cross-dataset questions, skills that encode how your company actually answers a question, and provenance stored on every piece of data.", "summary": "Gil Feig (co-founder and CTO of Merge) defines a context graph as the 'company brain': third-party data, structured context, memories and skills. Using the question 'Why was customer A upset last week?' versus 'Which customers were upset in the last year?', he shows that live MCP lookups break down because third-party APIs don't support semantic or bulk access, so you have to sync a local copy. He lays out an architecture of router, skills/memory, synced cache, live MCP and summarizer, plus a decision flow that checks the cache against freshness SLAs. He ends on traceability: where data came from, when, under what scopes, and what should invalidate it.", "key_points": [ "A context graph here means a 'company brain' made of third-party data (e.g. NetSuite, Jira), structured context (including static documents always passed to agents), memories, and skills. It is not about nodes and edges.", "Live MCP lookups can answer 'Why was customer A upset last week?' from Zendesk, but 'Which customers were upset in the last year?' means pulling tickets 100 at a time until it times out. Third-party APIs don't support live semantic lookups, and platforms have no incentive to add them because vectorizing costs them money and means you visit their platform less often.", "Use live MCP for simple lookups and single actions (e.g. Stripe for one customer). For semantic lookups or analysis across a vast data set, you have to sync a copy locally into a vector database.", "Architecture flow: the prompt comes in, a router sends it to the right agent, the agent checks memory and skills, then queries the synced cache DB and/or live MCP lookups, and a summarizer condenses the results before returning them, because you can't dump massive retrieved context back to the agent.", "Skills belong in the context layer because 'getting context is a set of company principles and processes in and of itself'. For example, one company may judge customer happiness by Qualtrics survey data rather than ticket counts.", "Four tiers of context: prompt/skills/memory; live API calls (easier to build, cheaper, preferred for simple retrievals); cached data (essential for semantic and complex lookups, but more expensive and harder to keep up to date); and derived context (e.g. storing per-customer ticket summaries so common questions aren't re-looked-up and re-summarized).", "Decision flow: on a skill/memory match, execute it. If external data is needed, check the cache for freshness within SLAs and use it, otherwise call the live API. Loop until there is enough context, optionally store a memory, then respond.", "Provenance: never drop the source. Store it in vector DB metadata, recording where and when it was fetched, under what ID and scopes, who accessed it and with what permissions, whether it was transformed and what it originally looked like, and what should invalidate it (e.g. older than a month)." ], "takeaways": [ "Don't treat a few MCP servers as your context strategy. Sync a local vector copy for any data you need to question semantically or analyse in bulk, and keep live lookups for simple single-record retrievals and actions.", "Encode company-specific definitions and processes (e.g. 'how do we determine if a customer is happy?') as skills the agent checks before choosing where to fetch data.", "Put a router at the front and a summarizer at the back so agents get condensed context rather than raw retrieval dumps. Store derived summaries so common questions don't need re-fetching.", "Set freshness SLAs on cached data and fall back to live APIs when they're exceeded. Cap live pulls (e.g. only the last five tickets) to avoid timeouts.", "Store provenance metadata on every piece of synced data (source, fetch time, scopes, permissions, transformations, invalidation rules) so every answer is traceable when something goes wrong." ], "topics": [ "context engineering", "agents", "mcp", "rag", "vector databases", "memory", "skills", "data provenance" ], "tools": [ "Merge", "Merge Unified", "Merge Agent Handler", "Merge Gateway", "MCP", "Zendesk", "Jira", "NetSuite", "Stripe", "Qualtrics", "ChatGPT", "OpenAI", "Ramp", "Netflix", "Perplexity" ], "quotes": [ { "text": "So, MCP is not fully solving a lot of these problems because the underlying access patterns of the APIs of these other platforms don't support a live look up methodology.", "at": "04:26", "url": "https://www.youtube.com/watch?v=cSz7aL2nl2U&t=266s" }, { "text": "The reason is that getting context is actually a set of company principles and processes in and of itself.", "at": "06:51", "url": "https://www.youtube.com/watch?v=cSz7aL2nl2U&t=411s" }, { "text": "There's no magic here. There really is none. It's all physics", "at": "07:57", "url": "https://www.youtube.com/watch?v=cSz7aL2nl2U&t=477s" }, { "text": "So, key takeaways, tools are not context.", "at": "13:33", "url": "https://www.youtube.com/watch?v=cSz7aL2nl2U&t=813s" } ], "words": 3399 }, "summary_url": "/#cSz7aL2nl2U", "transcript": { "html": "/transcripts/cSz7aL2nl2U.html", "txt": "/transcripts/cSz7aL2nl2U.txt", "vtt": "/transcripts/cSz7aL2nl2U.vtt" } }