Por que sua empresa precisa de um grafo de contexto (e como construí-lo) — Gil Feig, Merge

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Why Your Company Needs a Context Graph (and How to Build It) — Gil Feig, Merge · Canal: AI Engineer · 15:09 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Dados, bancos de dados e embeddings, Engenharia de prompts e contexto

Resumo

Gil Feig explica que um grafo de contexto reúne dados, processos, skills, memórias e ferramentas para ajudar agentes a responder com informações relevantes sobre toda a empresa. Consultas simples podem usar APIs em tempo real, mas análises semânticas sobre grandes conjuntos de dados exigem sincronizar os dados em uma camada local. Um router, um summarizer e estratégias de seleção ajudam a combinar os dados sem sobrecarregar o agente. Feig também enfatiza que cada dado precisa ter origem, data de coleta, permissões e critérios de invalidação rastreáveis.

Pontos-chave

• Um grafo de contexto vai além de conectar ferramentas: inclui dados, processos da empresa, skills e memórias.
• MCP e consultas em tempo real funcionam bem para buscas simples e ações específicas.
• Para consultas semânticas ou análises sobre grandes volumes de dados, é necessário sincronizar uma cópia local dos dados.
• A camada de contexto pode combinar consultas em tempo real, dados sincronizados ou em cache e contexto derivado.
• Skills ajudam o agente a seguir os processos da empresa e a decidir onde buscar informações.
• Um router direciona as solicitações, e um summarizer combina e resume o contexto reunido.
• A seleção de dados deve considerar se o conteúdo em cache ainda está atualizado segundo os SLAs.
• Cada dado deve manter sua origem, data de coleta, identificadores, permissões, transformações e critérios de invalidação.
• Mais dados nem sempre são melhores: é preferível fornecer apenas dados relevantes, atuais e de boa qualidade.

Capítulos

Início	Capítulo	Resumo
00:12	O que é um grafo de contexto	Gil Feig apresenta a proposta de reunir dados de terceiros, contexto estruturado, memórias e skills em uma camada para a empresa.
03:23	Quando sincronizar dados em vez de consultar APIs	O exemplo de consultas sobre tickets mostra por que buscas semânticas em grandes conjuntos de dados exigem uma cópia sincronizada, enquanto consultas simples podem continuar em tempo real.
05:58	Router, summarizer, memórias e skills	A palestra descreve como direcionar solicitações, combinar dados em cache e dados em tempo real e aplicar os processos da empresa registrados em skills.
08:39	As camadas de contexto e a seleção de dados	Feig diferencia prompt, skills e memória, chamadas de API, dados em cache e contexto derivado, e apresenta critérios para escolher entre eles.
11:21	Rastreabilidade e proveniência	O palestrante recomenda registrar a origem, a data de coleta, as permissões e as condições que invalidam cada dado.
12:59	Exemplo prático e principais conclusões	Um pedido de status de cliente ilustra a combinação de dados em cache, consultas em tempo real e resumos derivados, seguida pelas recomendações finais.

Citações

O grafo de contexto da sua empresa consiste em muitos componentes diferentes. — 02:18

Você precisa de uma camada de sincronização por cima disso. — 04:55

Contexto é tudo o que é passado ao agente. — 08:39

Ferramentas não são contexto. — 13:33

Toda resposta precisa ser rastreável. — 14:04

Conceitos e entidades

• Context Graph (conceito): Camada que reúne dados, processos, skills, memórias e ferramentas para fornecer contexto aos agentes de uma empresa.
• MCP (conceito): Forma de conectar agentes a ferramentas e sistemas, adequada no exemplo a consultas simples feitas diretamente às APIs.
• context layer (conceito): Camada que organiza diferentes fontes e modalidades de contexto, como dados em tempo real, dados sincronizados e contexto derivado.
• skills (conceito): Instruções que registram processos e princípios da empresa e orientam o agente sobre como realizar tarefas ou buscar dados.
• memory (conceito): Informações que o agente ou seus usuários decidem preservar para uso posterior.
• traceability and provenance (conceito): Registro da origem, coleta, permissões e transformações dos dados para verificar de onde vieram e se continuam válidos.
• merge (empresa): Empresa apresentada por Gil Feig como provedora de infraestrutura para conectar sistemas e viabilizar IA empresarial.
• Gil Feig (pessoa): Co-fundador e CTO da Merge, que apresenta a palestra sobre grafos de contexto.
• Zendesk (ferramenta): Sistema de suporte usado como exemplo de fonte de tickets de clientes.
• Jira (ferramenta): Plataforma citada como exemplo de sistema de terceiros cujos dados podem ser consultados.
• Stripe (ferramenta): Plataforma usada como exemplo de sistema adequado a consultas simples e pontuais por API.
• Gateway (ferramenta): Produto da Merge descrito na palestra como um roteador de LLM.
• Unified (ferramenta): Produto da Merge que ajuda a sincronizar dados de plataformas de terceiros.
• Agent Handler (ferramenta): Produto da Merge que oferece conexões MCP pré-configuradas com ferramentas.

Tradução completa (pt-BR)

00:12 Certo. Obrigado a todos por virem. Meu nome é Gil Feyg. Sou cofundador e CTO da Merge. A Merge ajuda empresas a criar IA pronta para produção com muita facilidade. Somos a infraestrutura de conexão que faz tudo funcionar em conjunto. Hoje vou falar sobre por que você precisa de um grafo de contexto e como construí-lo. O que não vou fazer é falar sobre tecnologias específicas que você deveria usar. Você pode conversar com seu agent sobre isso. Ele vai ajudar. Há muitas tecnologias boas que podem dar suporte a isso. O foco aqui é

00:42 por que você precisa de um grafo de contexto e, em um nível mais alto, como estruturá-lo, quais devem ser seus componentes e como as coisas se juntam para construir o melhor cérebro possível para a sua empresa. A propósito, se você ainda não pegou um boné, minha equipe está circulando e distribuindo bonés. Está escrito “bem conectado”. Então, vamos começar. Não vou falar muito sobre a Merge, mas aqui vai uma breve apresentação. Temos mais de 400 clientes corporativos, como OpenAI, Ramp, Netflix e Perplexity, e muitas empresas

01:14 de vários setores nos usam tanto para casos de uso internos de IA quanto para casos voltados aos clientes. Temos três produtos diferentes — Unified, Agent Handler e Gateway — que abrangem muitos dos componentes disso. Fomos fundados há 6 anos por mim e pelo meu cofundador Shen Shi. Captamos três rodadas de investimento. Temos 130 funcionários nas três cidades mais bonitas do mundo. Certo. Aqui vai uma breve agenda. Primeiro, vamos falar sobre o que é um grafo de contexto e por que é tão importante que toda empresa tenha

01:44 um. Vamos abordar as diferentes camadas de contexto: que tipos de dados e que tipos de lógica da sua empresa devem entrar no seu grafo. Vamos falar sobre a estratégia de seleção de contexto. Como escolhemos o conteúdo mais relevante para nossos agents, ou os contextos mais relevantes para eles, em cada momento? Rastreabilidade e proveniência: como sabemos de onde vieram esses dados, quem os solicitou, de quando são, se estão atualizados e tudo mais? Por fim, algumas conclusões importantes. No final, vou ficar por aqui caso vocês tenham perguntas. Sintam-se à vontade para vir falar comigo depois.

02:18 Certo. Então, o que é um grafo de contexto nesta palestra? Não vamos entrar nos nós e nas arestas que conectam cada nó em uma infraestrutura de grafo propriamente dita. Vamos falar sobre o cérebro da empresa. O grafo de contexto da sua empresa é composto por muitos elementos diferentes. Ele inclui dados de terceiros. Quais são os outros sistemas que vocês usam, como NetSuite e Jira? Inclui contexto estruturado. Isso pode ser dados recebidos de outros serviços de terceiros. Também pode ser dados que vocês incluíram na

02:50 camada de contexto. Coisas como documentos estáticos que vocês querem que sejam sempre passados aos seus agents. Temos memórias. São coisas que se formam. Todos conhecemos a memória: coisas que se formam enquanto vocês usam o agent, pedem que ele se lembre de algo ou coisas que o agent considera que deve lembrar por conta própria. Também temos skills. As skills são uma parte muito, muito importante do seu grafo de contexto, e já vamos chegar a isso. Certo. Estou vendo algumas fotos. Beleza. Vamos em frente. Vamos passar por um exemplo. Vamos usar esse exemplo para mostrar por que

03:23 não basta simplesmente conectar um servidor MCP ou alguns servidores MCP e encerrar o assunto. Vamos fazer esta pergunta simples. Um dos seus funcionários ou clientes pergunta ao agent: “Por que o cliente A ficou chateado na semana passada?” É uma pergunta bem simples de responder. O agent vai até o sistema de tickets do Zendesk, ao qual tem acesso, e verifica: “Quais tickets esse cliente abriu na semana passada?” Ótimo. Vemos que a sincronização da API estava com problemas e temos detalhes específicos

03:53 sobre o que deu errado. Também vemos que o cliente abriu três tickets no total, e assim por diante. Ótimo, isso responde à pergunta. Mas e se quisermos ir além? E se quisermos perguntar: “Quais clientes ficaram chateados na semana passada?” Isso fica muito mais difícil, porque agora o agent precisa carregar todos os tickets do Zendesk que foram abertos na última semana. E se perguntarmos: “Quais clientes ficaram chateados no último ano?” Deveríamos conseguir responder. Nosso agent deveria conseguir responder, mas não consegue se tiver que consultar e buscar tickets em tempo real, 100 de cada vez, milhares e milhares deles, até a solicitação expirar. Aí, simplesmente, ele não consegue responder à pergunta.

04:23 Então, o MCP não está resolvendo completamente muitos desses problemas, porque os padrões de acesso subjacentes das APIs dessas outras plataformas não dão suporte a uma abordagem de consulta em tempo real. Se fosse possível fazer uma pergunta semântica ao seu sistema de tickets — se o Jira disponibilizasse um endpoint que permitisse consultar em inglês, por exemplo: “Quais clientes ficaram chateados na semana passada?” — e ele retornasse esses dados, seria ótimo. Mas nenhuma plataforma tem incentivo para fazer isso, porque custa dinheiro vetorizar os dados e isso faz com que você não precise

04:55 acessar a plataforma deles com tanta frequência. Então, você precisa de uma camada de sincronização por cima disso. Não dá para usar apenas o MCP para fazer consultas em tempo real quando você quer se aprofundar ou fazer perguntas semânticas; é preciso sincronizar uma cópia dos dados localmente. Certo? Isso não se aplica a tudo. Você pode ter consultas estáticas, por exemplo, ao Stripe. Sempre vamos perguntar ao Stripe sobre um cliente específico. Sempre vamos realizar uma única ação no Stripe. Isso pode ser feito com MCP, em tempo real. Mas, se você precisar de qualquer tipo de consulta semântica, ou de qualquer tipo de análise

05:28 que vá além de uma consulta simples, de uma pergunta simples, e exija analisar um conjunto de dados amplo, você precisa sincronizar uma cópia. Isso passa a ser a próxima parte da camada de sincronização da sua camada de contexto. Assim, você tem seus MCPs e suas consultas em tempo real, além das consultas com dados sincronizados ou em cache. Você importa os dados de um serviço de terceiros e os coloca em um banco de dados vetorial local. Mais uma vez, a IA pode criar esse banco de dados vetorial para você com relativa facilidade. Você precisa definir a estratégia de armazenamento dos dados na camada de contexto e de

05:58 recuperação deles nessa camada sincronizada e em cache. Esse é o próximo componente. Mas o problema seguinte é: certo, agora temos todos esses dados relevantes. Estamos consultando nosso banco de dados vetorial para obter dados semânticos e fazendo consultas em tempo real para buscar outros dados que talvez queiramos incluir. Agora, precisamos reunir tudo isso, porque não podemos simplesmente despejar uma quantidade enorme de contexto recuperado de volta no agent. É aí que introduzimos o roteador e o sumarizador. No início, o roteador encaminha as coisas para o lugar certo. O prompt chega e ele decide quem deve lidar com aquilo e para onde deve ser enviado.

06:31 Depois que todos esses dados são reunidos, o sumarizador pega os dados do contexto sincronizado e do contexto em tempo real, resume tudo e envia o resultado de volta ao agent que enviou o prompt. Mas vocês devem ter notado que há uma coisa aqui sobre a qual ainda não falamos: memória e skills. Elas podem ficar separadas. Por que são importantes para a sua camada de contexto? Porque obter contexto é, por si só, um conjunto de princípios e processos da empresa. Por exemplo, qual cliente

07:02 estar chateado na semana passada pode significar algo muito diferente para uma empresa em comparação com outra. Pode ser o número de chamados abertos. Mas e se esses chamados fossem positivos? E se, na verdade, não usássemos um sistema de chamados e soubéssemos que, para avaliar a satisfação dos clientes, precisamos sempre consultar primeiro o Qualtrics e ver os dados das pesquisas, porque é assim que nossa empresa funciona? Somos diferentes. É por isso que as skills são importantes, porque você precisa de skills como: como determinamos se um cliente está satisfeito? Então, agora seu agent deve primeiro verificar as skills antes de consultar a camada sincronizada e, em seguida, a camada em tempo real para descobrir quais dados obter e então

07:34 resumi-los e retorná-los. Então, o fluxo é: o prompt chega, é encaminhado para o agent certo. O agent verifica se tem alguma memória ou skill associada à pergunta ou à tarefa em questão. Com base nisso, ele sabe onde procurar no banco de dados do cache sincronizado e nas consultas ao MCP em tempo real; resume e envia de volta. Não há mágica aqui. De verdade, não há. É tudo física: desde que você saiba como calcular dentro do seu próprio caso de uso, está tudo certo. Esse fluxo que vimos, com o número

08:07 de chamados abertos, mais uma vez, não teria sido possível com consultas em tempo real, mas, com uma consulta local, foi muito simples. Conseguimos basicamente reunir todos os clientes, o número de chamados que cada um tem, resumir os chamados e, então, fornecer um status de cada um. É uma combinação de algumas consultas em tempo real e outras ao cache. Tudo isso se junta aqui para criar dados realmente muito ricos para qualquer pergunta feita. Certo. Há diferentes níveis de contexto, e alguns podem debater se prompt, skills e memória são contexto. Contexto é tudo o que é

08:39 passado para o agent. Vamos colocar tudo isso aqui porque tudo pertence à sua camada de contexto. Então, você tem seu prompt, suas skills e sua memória. Falamos sobre como esses elementos vão realmente determinar onde obter os dados. Você tem chamadas de API em tempo real. São mais fáceis de criar e de adicionar, e mais baratas de executar do que o contexto sincronizado. Portanto, você deve preferi-las quando souber que terá consultas simples e recuperação simples. Dados em cache são absolutamente essenciais se você quiser dados semânticos, consultas complexas e perguntas muito, muito aprofundadas sobre quaisquer dados. Mas lembre-se de que é um pouco mais complicado configurar e construir isso. É mais caro de executar, porque você precisa ter um banco de dados vetorial e precisa sincronizar esses dados continuamente. Então, é mais difícil manter tudo atualizado. E, por último, algo que ainda não discutimos direito: o contexto derivado, que é basicamente qualquer contexto adicional que você cria ao buscar dados de terceiros. Então, isso pode ser: enquanto buscamos todos os chamados em tempo real, sempre que recebemos o conjunto completo de chamados de um cliente, também os resumimos e

09:10 na verdade, armazenamos no nosso contexto armazenado, no nosso contexto armazenado estruturado, um resumo dos dados que buscamos. Assim, no futuro, se tivermos uma pergunta comum, não precisaremos consultar e resumir tudo de novo. Ótimo. Então, esses quatro elementos se juntam. Vocês viram o gráfico que mostra como isso acontece. E esses são os níveis. Aqui está um fluxograma rápido de como isso funciona quando uma consulta ou um prompt chega. A primeira pergunta é: temos uma correspondência de skill ou memória? Se sim, queremos executar essa skill. A skill precisa de dados externos? Se não, apenas geramos uma resposta e a enviamos de volta. Infelizmente, nem sempre é tão fácil. Então, o que acontece se não tivermos uma correspondência de skill ou memória? Não? Bem, então vamos direto para a seleção de dados. E o mesmo vale se essa skill precisar de dados externos. Então, dizemos que sim; a primeira coisa que fazemos é verificar nosso cache ou nosso repositório de dados sincronizados e perguntar: os dados estão atualizados? Estão dentro dos nossos SLAs? Podemos usar esses dados porque são considerados suficientemente recentes? Se sim, vamos usar esse contexto do cache. Se não, infelizmente, temos que

09:42 seguir para baixo e chamar a API em tempo real. Agora, quando tivermos contexto suficiente, vamos passar por essas etapas algumas vezes até montar o contexto de que precisamos. Quando tivermos contexto suficiente, talvez queiramos armazenar uma memória do que acabamos de descobrir ou entender; armazenamos isso na memória, geramos a resposta e a enviamos de volta. E, da mesma forma, se não tivermos contexto suficiente — acabei de mostrar isso —, temos que chamar a API em tempo real e então vamos gerar essa resposta para o cliente.

10:14 Vou deixar isso aqui por um segundo. Vejo algumas pessoas olhando e tirando fotos. Certo. Então, a última parte, estamos praticamente no fim: rastreabilidade e proveniência. Não parece importante à primeira vista. Não perca a informação de onde vêm os dados. Armazene-a sempre. Você tem essa informação no MCP. Também a tem em qualquer coisa que sincronize em bancos de dados vetoriais: existe algo chamado metadados. Você deve armazená-la ali. Ela fica associada aos dados. Isso é fundamental. É parecido com a forma como isso aparece no ChatGPT ou em qualquer interface que você esteja usando: quando ele apresenta um fato ou diz algo, no final informa que há três fontes e inclui links para a origem. Isso é ainda mais importante quando você toma decisões empresariais críticas com base nesses dados. Quando os dados são versionados, quando podem ficar desatualizados, quando você deixa o sistema tomar uma decisão com base em dados que sincronizou há um ano. Você não quer isso. Então, precisa saber de onde os dados vieram. Onde os buscamos? Quando os buscamos? Com qual ID e quais escopos? Quem acessou os dados? Quais permissões foram usadas para acessá-los? Eles foram transformados? Como eram originalmente

10:49 ? E, por último, o que deve invalidá-los? Pode ser a idade, por exemplo. Se os dados tiverem mais de um mês, não queremos considerá-los de forma alguma. Isso é muito importante para exibir na sua plataforma e, se não for para exibir na sua plataforma interna ou no que quer que esteja construindo, também é importante para poder investigar quando algo der errado, porque vai dar. Então, juntando tudo, aqui está outro exemplo que poderíamos usar: “Me dê uma atualização de status de um parágrafo sobre nosso cliente Acme. Inclua o risco de renovação e a última interação com o suporte.” Primeiro, vamos verificar

11:21 o cache em busca do resumo da conta. Vamos supor que não haja skills aqui. Então, vamos verificar isso. Se estiver desatualizado ou ausente, vamos chamar o CRM com uma consulta à API em tempo real. Depois, vamos consultar o sistema de chamados para encontrar a última interação com o suporte. Mais uma vez, isso fica em cache se estiver dentro do SLA; caso contrário, talvez seja necessário fazer uma consulta em tempo real. Queremos buscar apenas cinco chamados. Não podemos buscar o histórico completo porque, mais uma vez, com consultas em tempo real, corremos o risco de atingir o tempo limite. E, por último, vamos gerar um resumo derivado. Talvez armazenemos esse resumo derivado e o enviemos de volta.

11:53 Então, os principais aprendizados: ferramentas não são contexto. Um grafo de contexto vai ajudar você a raciocinar considerando a empresa inteira. Não se trata apenas de ferramentas. São dados. São dados sincronizados. São os processos que você tem como empresa. Quem documenta, por exemplo, o que fazemos quando um cliente reclama? Como o sistema sabe que deve sempre encaminhar isso para o lugar certo? Isso é uma skill. Essas são as skills da sua empresa. São seus processos. São seus dados, suas ferramentas e as ações que você precisa realizar. Mais dados nem sempre são melhores. Você quer dados recentes e de alta qualidade. Quer buscar apenas o que precisa. Quando você

12:26 como seria? E, por último, o que deveria invalidá-lo? Isso poderia ser a idade, por exemplo. Os dados têm mais de um mês, não queremos considerá-los de jeito nenhum. Isso é muito importante para exibir na sua plataforma e, se não for para exibir na sua plataforma interna ou seja lá o que você estiver criando, também para poder investigar quando algo der errado, porque vai dar. Então, juntando tudo, aqui está outro exemplo que poderíamos usar. Então, me dê uma atualização de status em um parágrafo sobre nosso cliente Acme. Inclua o risco de renovação e a última interação com o suporte. Primeiro, vamos verificar

12:59 o cache do resumo da conta. Vamos partir do princípio de que não há skills aqui. Então, vamos verificar isso. Se estiver desatualizado ou ausente, vamos consultar o CRM usando uma busca ao vivo pela API. Em seguida, vamos consultar o sistema de tickets para encontrar a última interação com o suporte. Mais uma vez, isso fica em cache se estiver dentro do SLA; caso contrário, talvez seja necessário fazer uma busca ao vivo. Queremos buscar apenas cinco tickets. Não podemos buscar o histórico completo porque, mais uma vez, quando fazemos buscas ao vivo, corremos o risco de atingir o tempo limite. E, por último, vamos gerar um resumo derivado. Podemos armazenar esse resumo derivado e devolvê-lo.

13:33 Então, os principais aprendizados: ferramentas não são contexto. Um context graph vai ajudar você a raciocinar sobre a empresa inteira. Não são apenas ferramentas. São dados. São dados sincronizados. São os processos que vocês têm como empresa. Quem está documentando, sabe, o que fazemos quando um cliente reclama? Como ele sabe para onde encaminhar sempre? Isso é uma skill. Essas são as skills da sua empresa. São os processos de vocês. São os dados de vocês, e são as ferramentas e ações que precisam ser realizadas. Mais dados nem sempre são melhores. Você quer dados atualizados e de alta qualidade. Quer buscar apenas o que precisa. Quando você

14:04 É preciso sincronizar os dados e estruturá-los adequadamente, para que sejam acessados da maneira certa. E, por último, todas as respostas precisam ser rastreáveis. Você não quer ficar numa situação em que sua IA toma uma decisão ruim e você não tem ideia do motivo. Então, para encerrar, vou fazer uma propaganda aqui. A IA empresarial funciona com a gente. Damos suporte a esses recursos para muitas empresas. Temos o Gateway, que é um roteador de LLM. Temos o Unified, que ajuda você a sincronizar dados de terceiros provenientes das plataformas dos seus clientes. E temos o Agent Handler, com conexões MCP ativas

14:36 pré-configuradas para centenas de ferramentas, com identidade governada integrada, incluindo proveniência, e, sim, é só conectar e usar, tanto para casos de uso internos quanto voltados para clientes. Então, se você quiser criar uma camada de contexto simples, fale com a gente. Obrigado a todos por ouvirem.

15:09 [música]

Transcrição original

[00:12] Right. Thank you all for for coming. Um my name is Gil Feyg. I am the co-founder and CTO of Merge. Merge helps companies build production AI very easily. We are the connective infrastructure uh to make everything come together. Uh today I’m going to be talking about why you need a context graph and how to build it. What I’m not going to do is talk about specific technology you should be using. Uh you can talk to your agent about that. It will help you. There’s a lot of good technologies that can back this. Uh the focus of this is

[00:42] uh why you need a context graph and then sort of in a in a higher level how you should structure it, what the components should be, uh and how things come together to build the best possible uh brain for your company. If you haven’t gotten a hat yet, by the way, my team is walking around passing out hats. They’re They say well connected. Um so let’s dive in here. So I’m not going to spend much talking about Merge, but just a quick overview of us. Um we have over 400 enterprise customers, OpenAI, Ramp, Netflix, Perplexity, a lot of companies

[01:14] across the board using us for both internal and customer-facing AI use cases. Uh we have three different products, Unified, Agent Handler, and Gateway that cover a lot of the components of it. Um we were founded 6 years ago by me and my co-founder Shen Shi. We’ve raised three rounds. Uh we’re 130 employees in the three most beautiful cities in the world. All right. So quick agenda here. Step one or number one, we will talk about what a context graph even is and why it’s so important that every company has

[01:44] one. We’ll go into the different tiers of context, what what types of data, what types of of uh sort of logic from your company should be making it into your graph. We’ll talk about context selection strategy. How are we picking the most relevant content for our agents or contexts for our agents at any moment in time? Traceability and provenance. How do we know where that data came from, who requested it, when it when it’s from, is it fresh, all of that. And then lastly, some final key takeaways. At the end, I’ll stick around if you do have any questions. Uh so, feel free to to come up to me afterwards.

[02:18] All right. So, what is a context graph in this talk? We’re not going to go into the nodes and the edges that connect each node in a true graph infrastructure. We’re going to talk about the company brain. Your company context graph consists of a lot of different components. It has third-party data. What are the other systems you use, like NetSuite, uh like like Jira. Um it has structured context. Uh so, that could be uh data coming in from other third parties. That could be data that that you all have put into

[02:50] your context layer. Uh things like things like static documents that you want to always be passed to your agents. We have memories. These are things that are formed. We all know memory, things that are formed as you’re using the agent, telling it to remember things, things that your agent thinks that it should remember on its own. And then we also have skills. Uh and skills are a very very important part of your context graph, which we’ll get to. All right. I see some picture Okay, cool. Uh so, moving on. Let’s get Let’s go through an example here. We’re going to use this example to guide why it’s

[03:23] not it’s not enough to just connect a single MCP server or a couple MCP servers and call it a day. So, let’s ask this simple question. One of one of your employees or or customers asks your agent, “Why was customer A upset last week?” Pretty simple question to answer. The agent goes, it sees it has access to your Zendesk ticketing, and it can check and say, “Hey, what it what tickets were filed by this customer last week?” Great. We saw that they saw that the API sync was broken, um and specific details

[03:53] about what went wrong. We also see the customer filed three tickets total, all of that. Great, that answers that question. But what if we want to extend that? And what if we want to say, “Which customers were upset last week?” That becomes a lot harder because you now have to have your agent load in every single ticket from Zendesk that happened in the last week. What if we’re saying, “Which customers were upset in the last year?” We should be able to answer that. Our agent should be able to answer that, but it can’t if it has to live live look up and pull tickets 100 at a time, thousands and thousands of

[04:23] those until it times out and it just can’t answer the question. 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. If you could ask your ticketing system something semantically, if Jira exposed an endpoint that said, you know, that you could query in English, “Which customers were upset last week?” and it returned that data, that would be great. But no platforms incentivize to do that because it costs them money to vectorize it and it makes it so you don’t have to

[04:55] visit their platform as often. So, you need a sinking layer on top of this. You can’t just use MCP to live look up for things that you want to go deeper into, that you want to semantically question, you need to actually sync a copy of the data locally. Okay? This doesn’t apply to everything. So, you might have you know, let’s say static look ups to Stripe. We’re always going to be asking Stripe a question about a specific customer. We’re always going to be taking a single action in Stripe. That can be MCP. That can be live. But if you need any form of semantic look ups, any form of analysis

[05:28] that is beyond a simple look up, simple question, but requires looking across a a vast data set, you have to sync a copy. So, that becomes the next part of your sinking layer of your of your, uh, context layer. So, you have your MCPs, your live look ups, you have your synced or your cached look ups as well. And that you’re pulling in from a third-party, you’re putting in a vector database locally. Again, AI can build that vector DB for you relatively easily. Uh you got to you got to you know, work on your strategy of how you store data in the context layer and how

[05:58] you retrieve from it uh for that sync to cache layer. Um but that’s sort of the next component here. But the next problem is, all right, now we have all this relevant data. We’re we’re pulling from our vector database to get, you know, semantic data and we’re doing live lookups for other data we might want on top. Now, we need to bring all that data together cuz we can’t just dump a massive amount of retrieved context back to our agent. So, that’s where we introduce the router and the summarizer. The router is sending things to the right place at the beginning. The prompt comes in. It decides where, you know, who should be handling this, where it should be sent.

[06:31] Once that data’s all aggregated in there, our summarizer then takes that data from from the the synced context and from the live context, summarizes it, and sends it back to the agent that sent the prompt over. But you all notice, we have one thing here that we haven’t talked about, and that’s memory and skills. That could live separately. Why is it important for your context layer? The reason is that getting context is actually a set of company principles and processes in and of itself. For example, which customer

[07:02] was upset last week can mean something very different to one company versus another. It could be number of tickets that are opened. Um but actually, what if those tickets were positive? What if actually we don’t use a ticketing system and that we know that for customer happiness, we need to actually always go look at Qualtrics first and see survey data cuz that’s just how our company works. We’re different. That’s why skills are important because you need skills like how do we determine if a customer is happy? So, now your agent should first check the skills before it then goes and starts checking your synced layer, your your uh live layer for what data to get and then

[07:34] summarizing and returning it. So, the flow here is prompt comes in, gets routed to the right agent. The agent looks to see if it has any memory or skills associated with the question or the task at hand. Based on that, it then knows where to look in the synced cache DB and from the live MCP lookups, summarize, send back. There’s no magic here. There really is none. It’s all physics as long as you know how to calculate, you know, within within your own sort of use case, you’re great. This flow here where we looked at the number

[08:07] of open tickets again would not have been possible with live lookups, but with a local lookup it was really simple and we were able to basically gather all customers, number of tickets they have, summarize their tickets, and then give a status on each one. So, it’s a mix of some live lookups, some cache lookups. That’s all coming together here to build really really rich data for any question that gets asked. All right. And so, there are different tiers of context and some might debate whether prompt skills and memory are context. Context is anything that’s

[08:39] being passed into the agent. We’re going to put this all here because they all belong in your context layer. So, you have your prompt skills and memory. We talked about how those are going to really drive the the where do we get data from? You have your live API calls. These are easy easier to build, easier to add on, they’re cheaper to run than synced context. So, you should prefer these when you know you’re going to have simple lookups, simple retrievals. Cached data is absolutely essential if you want that that sort of semantic data, the complex lookups, deep deep

[09:10] questions about about any data. But, keep in mind it’s a little bit more complicated to set up and build. It’s more expensive to run because you have to have a vector database and you’re constantly having to sync that data. So, it is tougher to keep up to date. And then lastly, something we didn’t quite discuss yet is derived context, which is basically any additional context you create when you’re pulling in data from the third party. So, this could be, you You as we’re live pulling in all tickets, we’re also for every time a customer’s full set of tickets comes in, we’re summarizing those and

[09:42] we’re actually storing in our stored context, our structured stored context, we’re storing a summary of the data that we pulled in. So, that in the future, if we have a common question, we don’t have to then also go go re-look up and re-summarize everything. Awesome. So, all four of those come together. You saw the the chart for how they do that. Um and yeah, those are the tiers. So, quick flowchart of how this works when when a query comes in or a prompt comes in. So, first thing here is do we have a skill or memory match? If so, yes, we

[10:14] want to execute that skill. Does the skill need external data? No, then we’re just generating a response and we’re sending that right back. Unfortunately, it’s not always this easy. So, what happens if we don’t have a skill or memory match? No? Well, then let’s go right to to data selection here. Uh and same thing for if that skill needs external data. So, we say yes, the first thing we’re doing is checking our cache or our synced data store and we’re saying, is the data here fresh? Is it within our SLAs? Can we use this data cuz it’s viewed as fresh enough? Yes, then let’s use that cache context. No? Then, unfortunately, we have to go

[10:49] down and we have to call the live API. Now, once we do have enough context, we’re going to loop through these a few times till we build up the context we need. Once we do have enough context, we might want to store a memory of of whatever we just we just discovered or or figured out, uh store that to memory and then generate the response and send it back. And then, same thing here, if we didn’t have enough context, I I just showed that, but we have to call the live API and then we will we will uh generate that response back to the client.

[11:21] I’ll leave it here for a second. I I see some people looking and taking pictures. All right. So, last piece here, pretty much at the end, traceability and provenance. Doesn’t seem important at front up front. Do not drop where the data is coming from. Always store it. You you have that from MCP. You also have that in if for anything you’re syncing in Vector DBs, there’s something called metadata. You want to store it in there. It’s associated with the data. It is critical. It’s similar to, you know, the

[11:53] way that this surface is in ChatGPT or any surface that you’re using is when it tells you a fact or it says something, at the end it says three sources and it links to where it came from. That is even more important when you’re making business critical decisions off of that data. When that data is is versioned, when that data can become outdated, when you’re letting it make a decision on data that it synced a year ago. You don’t want that. So, you need to know where it came from. Where did we fetch it? When did we fetch it? Which is not here. Under what idea under what ID and what scopes? Who accessed the data? What permissions were used to access it? Was it transformed? What did it originally

[12:26] look like? And then lastly, what should invalidate it? That could be age, for example. The data is more than more than a month old, we don’t want to consider this ever. Really important for showing in your platform and if not for showing in your internal platform or whatever you’re building, even for for being able to investigate when something does go wrong, cuz it will. So, putting it all together, here’s another example of one that we might use. So, give me a one paragraph status update on our customer Acme. Include renewal risk and last support interaction. First, we’re going to check

[12:59] the cache for the account summary. We’re going to assume there’s no skills here. So, we’ll check that. If it’s still or missing, we’re going to call the CRM using a live API lookup. Then, we’ll query the ticketing system for the last support interaction. Again, that’s cached if within the SLA, otherwise it might have to do a live lookup. We’re only we only want to pull five tickets. We can’t pull the full history because again, when we have live lookups, we run into timeout risk. And then lastly, we’ll generate a derived summary. We might store that derived summary, and we’ll pass that back.

[13:33] So, key takeaways, tools are not context. A context graph is going to help you reason across the whole company. It’s not just tools. It’s data. It’s synced data. It’s processes that you have as a business. Who is documenting, you know, when a customer complains, what do we do? How does it know to always route to the right place? That is a skill. These It’s your company’s skills. It’s your processes. It’s your data, and it’s your tools and actions you need to take. More data, not always better. You want fresh, high-quality data. You want to pull only what you need. When you do

[14:04] have to sync data, you want to structure it properly, so it’s accessed in the right way. And then lastly, every answer has to be traceable. You do not want to be left in a position where your AI made a bad decision, and you have no idea why it did that. So, last piece, plugging merch here. Enterprise AI runs on us. We power these features for a lot of companies. We have Gateway, which is an LLM router. We have Unified, which helps you sync data from third parties out of your customers’ platforms. And then we have Agent Handler, which is live MCP connections

[14:36] pre-built across hundreds of tools, governed identity all built in, uh including provenance, uh and yeah, it’s plug and play for both internal and customer-facing use cases. So, if you want to build an easy context layer, hit us up. Thank you, everyone, for listening.

[15:09] >> [music]