Omnigraph : moteur graphe lakehouse pour la memoire des agents IA

Les agents IA ont besoin de plus qu’un historique de chat.

Ils ont besoin d’une memoire operationnelle partagee : faits, documents, decisions, traces, taches, branches, revues, politiques et contexte capable de survivre a une session. C’est le probleme que ModernRelay/omnigraph essaie de resoudre.

Omnigraph est une base graphe lakehouse-native sous licence MIT pour l’assemblage de contexte et la coordination multi-agents. Le projet repose sur une idee claire : des flottes d’agents doivent pouvoir lire, ecrire, enrichir, brancher, relire et merger l’etat graphe sans tout mettre dans un prompt fragile ou une seule table mutable.

Le projet combine traversal graphe, recherche vectorielle, recherche full-text, donnees natives object storage, workflows Git-style, deploiement cluster-as-code, politiques Cedar, CLI, serveur HTTP, SDK TypeScript et bridge MCP pour les hotes LLM.

Cette combinaison merite attention parce qu’elle montre une direction importante pour l’infrastructure agents : pas seulement des fenetres de contexte plus grandes, mais des systemes de contexte versionnes.

Ce qu’est Omnigraph

Omnigraph est une base graphe lakehouse pour la memoire agent et l’assemblage de contexte. Le README la decrit comme une couche d’etat operationnel et de coordination pour des flottes d’agents.

Cette phrase est importante. Ce n’est pas seulement un vector store. Ce n’est pas seulement une base graphe. C’est un moteur graphe pense pour des systemes IA ou beaucoup d’agents doivent operer sur une connaissance partagee sans se marcher dessus.

Le design combine :

• stockage et traversal graphe
• branches et merges Git-style
• recherche vectorielle ANN
• full-text search et scoring BM25
• Reciprocal Rank Fusion pour ranking hybride
• deploiement natif object storage via stores compatibles S3
• stockage colonne Lance pour des graphes branchables et time-travelables
• configuration cluster-as-code
• enforcement de politiques Cedar
• surfaces CLI, serveur, SDK TypeScript, HTTP/OpenAPI et MCP

C’est une vraie forme d’infrastructure. Omnigraph essaie de devenir la couche de memoire graphe durable sous les flottes d’agents.

Le probleme : la memoire agent est souvent trop plate

La plupart des systemes de memoire agent sont simples. Ils stockent des chunks, embeddings, resumes ou logs de chat. Cela fonctionne pour des petits workflows, mais se degrade quand la memoire doit avoir une structure.

Le contexte reel d’une entreprise ou d’une equipe engineering est relationnel :

• une personne possede un service
• un service depend d’une base de donnees
• une decision vient d’une reunion
• un ticket a modifie une interface
• un document remplace un autre document
• une experience appartient a un run modele
• un agent a propose un changement qui attend encore revue

Un vector store peut retrouver du texte semantiquement proche, mais il ne modelise pas naturellement ownership, lineage, branches, approvals et historique de merge.

Le pari d’Omnigraph est que les agents longue duree ont besoin d’un graphe de contexte, pas seulement d’une pile de chunks recherchables.

Branches Git-style pour le travail agent

L’une des meilleures idees d’Omnigraph est l’isolation par branche.

Le projet est concu pour des flottes d’agents travaillant sur des branches isolees en parallele. Un agent peut enrichir le graphe sur sa propre branche, puis les changements peuvent etre revus et merges en securite. Cela ressemble a la facon dont les equipes logiciel pensent deja la code review.

Pour la memoire agent, c’est majeur.

Sans branches, une mauvaise extraction ou une relation hallucinee peut polluer la memoire partagee immediatement. Avec des branches, un agent peut ecrire des faits, edges, resumes ou traces proposes dans un espace isole. Un humain, verifieur, politique ou processus aval peut inspecter le changement avant qu’il devienne canonique.

C’est la difference entre “memoire agent comme scratchpad” et “memoire agent comme etat revu”.

Cluster-as-code

Les deploiements Omnigraph sont declares comme des clusters. Un repertoire cluster contient cluster.yaml, fichiers de schema, fichiers de requetes stockees et bundles de politiques Cedar.

Le workflow est volontairement proche de l’infrastructure :

1. omnigraph cluster validate parse et typecheck la declaration.
2. omnigraph cluster plan previsualise ce qui va changer.
3. omnigraph cluster apply converge la realite vers la declaration.
4. omnigraph-server --cluster ... sert les graphes appliques.

Le control plane enregistre l’etat dans un ledger et publie les ressources dans un catalogue content-addressed. Reexecuter apply est cense etre idempotent. Les suppressions destructrices de graphes demandent un artifact d’approbation explicite.

Cette forme parlera aux utilisateurs de Terraform, et c’est positif. La memoire agent ne devrait pas etre un effet de bord runtime mysterieux. Les schemas, requetes, politiques et etats de deploiement doivent etre relisibles.

Retrieval : graphe + vecteur + texte

Le modele de retrieval d’Omnigraph est plus interessant qu’une recherche semantique simple.

La documentation de recherche decrit un runtime de requete ou traversal graphe, recherche vectorielle nearest-neighbor, full-text search, fuzzy matching, scoring BM25 et Reciprocal Rank Fusion peuvent etre combines dans une seule requete.

C’est important parce que l’assemblage de contexte pour agents a souvent besoin de plusieurs modes de retrieval.

Par exemple, un agent peut devoir :

• trouver des documents proches semantiquement d’une question
• classer des correspondances textuelles par pertinence keyword
• traverser d’un document vers son owner, service, projet ou decision
• fusionner ranking vectoriel et lexical
• retourner un graphe de contexte compact plutot que des chunks isoles

Le retrieval hybride est utile parce que similarite vectorielle et pertinence textuelle echouent differemment. Le traversal graphe ajoute la structure manquante.

Securite et gouvernance

Omnigraph integre AWS Cedar pour le controle d’acces attribute-based. La politique est appliquee cote serveur et au niveau moteur pour les chemins d’ecriture mutatifs, afin que serveur HTTP, CLI et SDK embarque puissent partager la meme logique d’autorisation.

Le modele de politique inclut des actions graphe comme read, export, change, schema apply, branch create, branch delete, branch merge et invocation de requetes stockees. Les actions server-scoped couvrent l’acces au registre du cluster.

Le projet fait aussi attention a l’identite acteur. Les ecritures HTTP distantes resolvent l’identite depuis les bearer tokens au niveau du serveur ; les clients ne peuvent pas simplement declarer un autre acteur dans un header ou un body.

C’est le genre de detail qui compte si Omnigraph doit contenir de la connaissance enterprise ou de la memoire agent. Une fois que les agents peuvent ecrire dans un etat partage, identite, auditabilite et permissions deviennent des preoccupations de premier ordre.

Design lakehouse natif object storage

Omnigraph tourne sur des object stores compatibles S3 : AWS S3, Cloudflare R2, Google Cloud Storage via acces compatible S3, MinIO ou RustFS. La couche de stockage utilise Lance, un format colonne qui supporte versioning et blob-as-data.

C’est different d’une base graphe executee comme une seule machine stateful avec toutes les donnees enfermees dedans.

Le design lakehouse-native aligne Omnigraph avec l’infrastructure data moderne : object storage comme substrat durable, serveurs comme compute redemarrable, et etat de deploiement decrit hors du processus.

Pour les equipes avec donnees privees, cela compte aussi operationnellement. Le projet met en avant l’execution sur votre propre infrastructure afin que les donnees restent dans votre store.

Ce que vous pouvez construire

Le README cite plusieurs cas d’usage coherents :

• Company brain : graphe partage de personnes, services, documents, decisions et connaissance organisationnelle.
• Memoire agentique : memoire durable ou les agents ecrivent dans des branches isolees et mergent des changements relus.
• Context graph : traces de decisions et connaissance tacite recuperables avec structure.
• Dev graph : issues, dependances, services et relations de code que les agents de codage peuvent lire et mettre a jour.
• Couche R&D ou ML : experiences et essais ecrits dans des branches versionnees pour training et evaluation.

Le theme commun n’est pas “stocker des embeddings”. C’est “rendre le contexte operationnel”.

Ou MCP intervient

Omnigraph fournit un package serveur MCP pour relier le graphe a des hotes LLM comme Claude et Codex.

C’est important parce qu’un systeme de memoire agent n’est utile que si les agents peuvent vraiment l’atteindre pendant le travail. MCP donne au graphe une surface d’outil standard. Au lieu de copier manuellement le contexte, un agent peut interroger la memoire structuree, recuperer du contexte hybride ou operer via des outils graphe approuves.

Le repo fournit aussi une skill agent omnigraph qui enseigne le playbook aux agents de codage : mode cluster, surfaces de config, evolution de schema, lint de requetes, branches, ecritures de donnees, politique Cedar et pieges courants.

Cela rend le projet tres agent-native. Ce n’est pas seulement du logiciel pour agents ; il inclut des instructions pour que les agents l’operent.

Mon avis

Omnigraph est convaincant parce qu’il traite la memoire agent comme une infrastructure.

Le chemin facile consiste a brancher une base vectorielle sur un agent et appeler cela memoire. Le chemin plus durable consiste a modeliser l’etat comme un graphe, le versionner, le brancher, le relire, le gouverner et le servir depuis une infrastructure controlee.

C’est le chemin que prend Omnigraph.

Le projet reste jeune, et les equipes devraient evaluer sa maturite avec soin avant d’y baser des workflows production. Mais l’architecture va dans une bonne direction : contexte graph-native, stockage lakehouse, branches Git-style, cluster-as-code, enforcement de politiques et acces MCP.

Pour les builders qui travaillent sur systemes multi-agents, knowledge graphs internes, memoire d’agents de codage ou assemblage de contexte enterprise, ModernRelay/omnigraph merite d’etre suivi de pres.