Uvi donne aux agents IA un contexte d’entreprise, mais le plus difficile est de préserver la fiabilité des décisions

Uvi fournit aux agents IA un contexte d’entreprise au moyen d’un système récemment financé qui modélise les décisions, et pas seulement les documents. La startup de Tel Aviv affirme que cette couche manquante pousse les agents à perdre du temps, consommer des tokens et agir sur la base d’éléments fragmentés.

L’entreprise a levé un tour de table d’amorçage de 7,5 millions de dollars mené par CT Innovations, avec la participation de Cardumen Capital, Manu VC et 91 Ventures. Uvi prévoit d’agrandir ses équipes aux États-Unis, ainsi que ses activités de développement produit et commerciales.

Cette annonce est importante, car connecter un agent à Slack, Jira, GitHub et à des bases de données internes ne crée pas automatiquement une compréhension de l’organisation. Model Context Protocol, ou MCP, peut donner accès à ces systèmes. Les logiciels de recherche peuvent trouver des fichiers pertinents. Aucune de ces approches ne reconstitue nécessairement les raisons d’une décision ni ne détermine si elle s’applique toujours.

Uvi entend s’approprier cette couche de reconstitution. Son produit crée ce que l’entreprise appelle un Decision Graph, qui relie les décisions à leurs responsables, déclencheurs, obstacles, dépendances et éléments probants.

Cela place Uvi face à une stratégie répandue dans les entreprises : connecter davantage de sources, récupérer davantage de texte et laisser le modèle inférer le reste. Uvi soutient que cette approche facture à répétition aux entreprises la redécouverte de relations que leurs employés comprennent déjà.

La proposition arrive à point nommé, mais ses questions les plus difficiles restent sans réponse. Les graphes de décisions doivent rester à jour, préserver les autorisations, représenter les preuves contradictoires et distinguer une décision valide d’une décision abandonnée. Si ces contrôles échouent, un contexte structuré peut donner à une réponse incorrecte une apparence d’autorité accrue.

Uvi donne aux agents IA un contexte d’entreprise grâce à un Decision Graph

Uvi vend une carte persistante du raisonnement organisationnel plutôt qu’une interface supplémentaire de recherche dans les documents de l’entreprise.

Selon le rapport original sur le contexte d’entreprise, Uvi a été fondée en 2023 par son PDG Gilad Salinger et son directeur technique Dror Wolmer. L’entreprise a d’abord exercé sous le nom de Naboo.

Son argument central part d’un problème familier aux entreprises. Les connaissances importantes résident rarement dans un seul système ou dans un document soigneusement tenu à jour.

Une décision produit peut commencer dans une conversation Slack. Sa mise en œuvre apparaît dans une pull request, tandis que Jira enregistre la tâche comme terminée. Un incident ultérieur provoque un retour en arrière, mais le ticket d’origine demeure fermé.

Un agent classique peut récupérer chacun de ces éléments. Il doit encore déterminer quel enregistrement reflète l’état actuel et pourquoi l’équipe a changé de cap.

Uvi indique que son Decision Graph représente les décisions comme des objets de premier ordre. Chaque décision peut inclure un responsable, un événement déclencheur, des obstacles, des dépendances, un statut et des liens vers des sources justificatives.

Cette approche diffère de celle qui traite l’organisation comme une collection de passages sémantiquement similaires. Un index vectoriel représente le texte selon une similarité mathématique. Il ne représente pas intrinsèquement la responsabilité, la causalité, l’approbation ni la séquence à l’origine d’une décision.

Uvi décrit une architecture à deux niveaux derrière son produit. Le premier est un Topic Graph, qui indexe les informations dans les systèmes de l’entreprise et résout les connexions entre personnes, dépôts, tickets et services.

Le second niveau est le Decision Graph. Il applique les définitions privées d’une organisation aux relations découvertes en dessous.

Par exemple, une entreprise peut définir « livré » comme du code fusionné dans une branche de production. Une autre peut exiger une disponibilité complète pour les clients, une supervision finalisée et une approbation formelle.

Ces définitions influencent la réponse à une question opérationnelle élémentaire. Un agent ne peut pas identifier de manière fiable une livraison bloquée s’il ne comprend pas ce que signifie être prêt pour une livraison dans cette entreprise.

Uvi indique que des spécialistes travaillent avec les clients afin d’encoder ces concepts et jalons décisionnels. Le graphe devient ensuite accessible aux agents via GraphQL ou un serveur MCP.

GraphQL prend en charge les requêtes structurées provenant d’applications qui savent déjà quels champs et quelles relations elles recherchent. MCP fournit une connexion standardisée par laquelle un agent peut exprimer une intention et demander un contexte pertinent.

L’entreprise affirme que le produit peut se connecter à des systèmes tels que GitHub, GitLab, Jira, Linear, Slack, Confluence, Notion, Datadog et Splunk. Il prend également en charge des services internes contenant un état spécifique à l’activité.

Cette conception vise les questions qui exigent plusieurs jointures. Un agent de livraison peut demander quelles approbations restent ouvertes, qui en est responsable et quel événement lèvera chaque obstacle.

Un agent de gestion d’incident peut demander pourquoi un feature flag a changé et quel engagement client a influencé ce choix. La recherche peut retrouver des mentions du flag. Un graphe de décisions cherche à reconstituer la chaîne ayant produit son état actuel.

Cette distinction explique pourquoi Uvi se présente comme une infrastructure sous-jacente aux agents existants. L’entreprise ne demande pas aux organisations de remplacer Claude, Gemini, GPT ou leurs interfaces d’agents internes.

Uvi veut plutôt que les entreprises construisent une fois leur contexte organisationnel et l’exposent à plusieurs modèles. L’entreprise affirme que les modèles évolueront plus vite que la signification sous-jacente des systèmes de l’entreprise.

Il s’agit d’une frontière architecturale attrayante. Elle sépare le choix du modèle du travail de définition de la responsabilité, du vocabulaire opérationnel et de l’historique des décisions.

Elle crée également une responsabilité importante. La couche de contexte partagée devient une dépendance pour chaque agent qui s’y appuie.

Davantage de connecteurs n’expliquent pas pourquoi une décision a été prise

La pression pèse sur les équipes qui ont traité l’accès aux données comme s’il s’agissait du même problème que la compréhension de l’organisation.

Anthropic a présenté Model Context Protocol en novembre 2024 comme une norme ouverte reliant les systèmes d’IA aux outils et sources de données. MCP a réduit la nécessité de concevoir un modèle d’intégration distinct pour chaque assistant et application.

Cette normalisation a résolu un important problème d’interface. Un agent peut découvrir les outils disponibles, demander des informations et invoquer des actions prises en charge par un protocole commun.

MCP ne détermine pas la signification des termes internes d’une entreprise. Il ne détermine pas non plus si un ticket fermé a été remplacé par un retour en arrière discuté ailleurs.

L’argument d’Uvi commence là où s’arrête le connecteur. L’accès donne davantage d’éléments à l’agent, tandis que la couche de raisonnement tente de les organiser autour de l’intention opérationnelle.

Cette différence devient importante lorsqu’un agent passe de la synthèse à l’action. Un assistant de recherche peut renvoyer plusieurs documents et laisser une personne résoudre leurs incohérences.

Un agent autonome doit choisir quel enregistrement croire avant de modifier une configuration, d’escalader un obstacle ou de mettre à jour un workflow client. Ce choix exige à la fois du contexte et de l’autorité.

La génération augmentée par récupération traditionnelle, ou RAG, récupère des éléments liés à une requête et les fournit à un modèle. Elle fonctionne bien lorsque la réponse figure dans un document que le système de récupération peut identifier.

Les tâches d’entreprise dépendent souvent de relations qu’aucun document n’énonce directement. La réponse émerge d’un ticket, d’un changement de code, d’une conversation, de données de télémétrie et de la définition de l’achèvement propre à l’entreprise.

Le projet GraphRAG de Microsoft illustre l’évolution plus large du secteur au-delà des fragments de texte isolés. GraphRAG combine extraction de texte, analyse de réseau, prompting et synthèse afin de construire des représentations plus riches d’un jeu de données.

Microsoft prend également en charge des fournisseurs de contexte fondés sur les graphes, qui récupèrent des sous-graphes connectés plutôt que des passages isolés. Son intégration Neo4j associe recherche vectorielle, recherche plein texte, recherche hybride et parcours de graphe.

Ces développements valident une partie de la prémisse d’Uvi. Les relations peuvent apporter des informations que la recherche par similarité seule ne détecte pas.

Ils montrent toutefois également qu’Uvi entre dans un domaine technique actif plutôt que de créer une catégorie incontestée. Les entreprises peuvent combiner des bases de données de graphes, des frameworks d’agents, des plateformes de recherche et des pipelines de données personnalisés.

Uvi doit donc prouver que la modélisation des décisions apporte plus de valeur qu’un système GraphRAG bien conçu. L’entreprise doit aussi démontrer que sa couche gérée coûte moins cher à exploiter qu’une solution interne.

La ligne de concurrence ne se résume pas à Uvi contre RAG. La plupart des systèmes d’entreprise sérieux continueront à utiliser plusieurs méthodes de récupération.

La recherche documentaire demeure utile pour les politiques, les rapports et les spécifications. La récupération vectorielle reste utile lorsque les utilisateurs ne connaissent pas le vocabulaire pertinent. La mémoire conversationnelle peut préserver les préférences et les interactions récentes.

Un graphe de décisions répond à un besoin différent. Il doit identifier les choix, les dépendances et les responsabilités qui déterminent ce qu’un agent peut faire en toute sécurité ensuite.

L’architecture probable combine ces couches. Un agent pourrait utiliser la recherche pour localiser les éléments justificatifs, un graphe pour parcourir les dépendances et les systèmes sources pour vérifier l’état en temps réel.

Cette combinaison exerce une pression sur les fournisseurs de recherche d’entreprise et les équipes de plateformes internes. Renvoyer des liens pertinents ne satisfait plus tous les workflows d’agents.

Les produits de recherche devront proposer des modèles de relations plus riches, une application plus stricte des autorisations et des sorties conçues pour des machines qui exécutent des actions. Les équipes internes font face à la même exigence tout en maintenant des connecteurs et pipelines de données personnalisés.

L’opportunité d’Uvi repose sur sa capacité à rendre cette complexité réutilisable. Son défi consiste à prouver qu’un fournisseur spécialisé peut comprendre avec suffisamment de précision le langage opérationnel privé de chaque client.

Le mécanisme dépend de jointures en temps réel, de l’intention et des autorisations

L’avantage technique d’Uvi dépendra moins de la terminologie des graphes que de la capacité de ses relations à rester à jour et correctement circonscrites.

Le workflow proposé par le produit commence par l’indexation des informations à travers les systèmes opérationnels. Il identifie les liens explicites, par exemple un ticket Jira référencé dans une pull request.

Il tente également de résoudre les relations implicites. Celles-ci peuvent inclure différents noms pour un même service, des employés représentés par plusieurs comptes ou des expressions internes décrivant un même processus de livraison.

La résolution d’entités consiste à associer ces références à des identités cohérentes. Sans cela, le graphe peut traiter une personne, un dépôt ou une fonctionnalité comme plusieurs objets sans rapport.

L’étape suivante introduit une signification propre à l’entreprise. Uvi indique qu’un spécialiste travaille avec le client pour définir des concepts tels que responsable, obstacle, déployer, approbation et livré.

Cette intervention humaine est notable. Le système ne suppose pas qu’un modèle généraliste puisse déduire chaque règle opérationnelle à partir de communications brutes.

L’approche rappelle le travail nécessaire pour construire une base de connaissances fiable. Une mémoire organisationnelle utile dépend de définitions, de provenance, de maintenance et de limites d’accès.

Uvi rend ensuite le graphe résultant interrogeable. Un agent peut demander une chaîne structurée comprenant des décisions, des responsables, des statuts, des dépendances et des éléments justificatifs.

Cette sortie diffère d’une liste classée de documents. Elle donne à l’agent un objet opérationnel plus restreint pouvant guider son étape suivante.

Considérez une version qui semble terminée dans un outil de suivi de projet. Un dépôt de code montre que la pull request correspondante a été fusionnée, mais les données de monitoring enregistrent une hausse des erreurs après le déploiement.

Une conversation ultérieure indique que le déploiement s’est arrêté à une disponibilité partielle. Le graphe de décision doit relier ces événements et empêcher un agent de décrire la version comme terminée.

L’intention modifie également le contexte nécessaire. L’examen de l’architecture de la version requiert des documents de conception, des informations sur les dépendances et les arbitrages historiques.

Le diagnostic d’un déploiement défaillant requiert une télémétrie récente, les détails du rollback, le code modifié et les responsables actuels. Les deux requêtes mentionnent la même version, mais elles nécessitent des éléments de preuve différents.

Uvi affirme que sa couche restreint le graphe en fonction de la tâche. Si cela fonctionne, l’agent reçoit moins de contenu non pertinent et consacre moins de tours de modèle à explorer des sources déconnectées.

L’entreprise fait état de gains de performance substantiels sur son site web. Uvi indique avoir remporté 97 requêtes sur 100 dans des comparaisons directes face à un système GPT compatible MCP lors d’un benchmark de Global-e.

Elle affirme également une vitesse deux fois supérieure à celle des références RAG et une réduction par huit du coût des requêtes par rapport à un agent développé en interne utilisant le même modèle. Il s’agit de résultats rapportés par le fournisseur, et non de benchmarks indépendants.

Les documents publiés ne fournissent pas suffisamment de détails méthodologiques pour généraliser ces résultats à l’ensemble des entreprises. Le choix des charges de travail, la préparation du graphe, l’évaluation des réponses, la complexité des sources et la configuration de référence peuvent influencer matériellement les résultats.

Le benchmark pointe néanmoins vers la bonne unité de mesure. Les entreprises devraient comparer les systèmes selon l’exactitude des réponses, la latence, le nombre total d’appels au modèle et le temps de vérification humaine.

Un nombre réduit de tokens signifie peu de chose si les employés doivent examiner chaque réponse. Une grande précision de récupération d’information compte également peu lorsqu’un agent manque l’état actuel d’une décision.

La sécurité constitue l’autre mécanisme central. Uvi affirme pouvoir fonctionner sur site ou dans un cloud privé virtuel contrôlé par le client.

L’entreprise indique également que les permissions sont appliquées lors de la récupération. Un agent ne devrait recevoir que les informations accessibles à la personne à l’origine de la demande.

Ce contrôle est important parce que les graphes créent des chemins indirects vers des faits sensibles. Un utilisateur peut ne pas avoir accès à un document confidentiel tout en pouvant en déduire le contenu à travers des nœuds connectés.

Un déploiement sécurisé doit protéger le matériel sous-jacent ainsi que les relations qui en sont dérivées. La simple existence d’un projet, d’un responsable ou d’une dépendance cachés peut révéler des informations sensibles.

Les permissions au niveau des sources peuvent aussi entrer en conflit. Un canal Slack, un dépôt et un outil de suivi de projet peuvent attribuer des droits différents à la même personne.

La couche de raisonnement doit calculer l’intersection valide sans divulguer de contexte restreint. Elle doit répéter ce calcul dès que les rôles, l’appartenance à des groupes ou les permissions des sources changent.

Le cas d’usage d’entreprise d’Uvi dépend donc de quatre capacités qui doivent fonctionner ensemble : une ingestion fraîche, une résolution précise des entités, une sélection consciente de la tâche et une récupération préservant les permissions. Une faiblesse dans l’une de ces couches peut compromettre la réponse finale.

Un graphe de décision peut préserver les erreurs aussi facilement que les connaissances

Le risque le plus important d’Uvi est qu’un contexte structuré puisse transformer une mémoire organisationnelle incertaine en instructions machine formulées avec assurance.

Les décisions d’entreprise constituent rarement des dossiers nets. Les équipes ne sont pas toujours d’accord, les exceptions s’accumulent et les contournements temporaires survivent au-delà de la période prévue.

Un chef de produit peut approuver une version dans un canal tandis qu’un responsable de la sécurité la bloque ailleurs. Le résultat final peut dépendre d’une conversation non documentée entre dirigeants.

Un graphe doit représenter cette incertitude au lieu de forcer chaque artefact dans un état définitif unique. Sinon, le résultat paraîtra cohérent tout en dissimulant un conflit réel.

L’entreprise affirme également que son système reconstruit des raisonnements qui n’ont jamais été explicitement consignés. C’est utile, mais cela introduit une frontière d’inférence que les acheteurs devraient examiner attentivement.

Une relation étayée par une référence de ticket diffère de l’interprétation par un modèle de plusieurs conversations. Les deux peuvent apparaître comme des arêtes dans un graphe, mais elles n’ont pas le même poids probant.

Les entreprises doivent savoir quels liens proviennent directement des enregistrements sources. Elles ont également besoin de scores de confiance, d’horodatages et de parcours de révision pour les relations inférées.

La validité d’une décision évolue au fil du temps. Une exception d’urgence peut expirer, un service peut passer d’une équipe à une autre et une politique d’approbation peut être remplacée.

Le graphe doit conserver l’historique sans confondre une ancienne règle avec la règle actuelle. Il doit également expliquer pourquoi l’état actuel a remplacé les éléments de preuve antérieurs.

Une ingestion fraîche ne résout pas ce problème à elle seule. Un nouveau message peut être récent tout en restant non officiel, spéculatif ou incorrect.

L’autorité compte autant que la récence. Le système doit distinguer un décideur responsable d’un participant qui discute d’issues possibles.

Ces problèmes compliquent l’évaluation. Un benchmark peut vérifier si le système renvoie la réponse attendue, mais la réponse attendue elle-même peut être contestée.

Les clients devraient intégrer à leurs évaluations des cas contradictoires, des décisions révoquées, des relations confidentielles et des enregistrements délibérément obsolètes. Des questions simples sur des projets bien documentés ne révéleront pas les modes de défaillance du système.

Ils devraient également tester la manière dont Uvi gère les éléments de preuve manquants. Un système sûr devrait exposer l’incertitude plutôt qu’inventer la raison non documentée d’une décision.

Une révision humaine reste nécessaire pour les actions importantes. Un graphe peut réduire l’exploration, mais il ne devrait pas supprimer les contrôles d’approbation pour les changements en production, les engagements financiers ou les décisions de sécurité.

C’est là qu’une base d’ingénierie consultable reste précieuse. Les personnes doivent pouvoir accéder aux artefacts sous-jacents lorsqu’elles examinent l’action proposée par un agent.

Le verrouillage fournisseur soulève une autre inquiétude. Uvi soutient que les entreprises devraient posséder une couche de contexte unique fonctionnant avec différents modèles.

Cette portabilité n’a de valeur que si les clients peuvent exporter les données du graphe, les définitions, la provenance et les enregistrements d’évaluation. Changer de modèle est facile par rapport à la reconstruction de plusieurs années de connaissances opérationnelles encodées.

Le modèle de déploiement mérite également un examen attentif. L’exécution dans l’environnement du client réduit certaines expositions de données, mais elle ne garantit pas automatiquement un comportement sécurisé.

Les acheteurs devraient examiner les accès administratifs, les identifiants des connecteurs, la journalisation, les processus de mise à jour, le chiffrement et la réponse aux incidents. Ils devraient également vérifier le comportement des permissions dans chaque source intégrée.

Les affirmations d’Uvi concernant son benchmark méritent le même examen rigoureux. Les résultats rapportés indiquent un potentiel, mais n’établissent pas les performances dans différentes organisations ou différents flux de travail.

Un client appliquant des pratiques cohérentes de gestion des tickets présente un environnement différent de celui d’une entreprise qui s’appuie sur des messages privés et des approbations informelles. La qualité du graphe reflétera ces habitudes opérationnelles.

Cette limite n’invalide pas le produit. Elle précise ce qu’Uvi vend réellement.

L’entreprise n’installe pas simplement une base de données. Elle aide une entreprise à formaliser la manière dont les décisions, la responsabilité, les preuves et les permissions sont reliées.

Ce processus peut créer de la valeur avant même qu’un agent n’agisse. Il peut également révéler à quel point les connaissances essentielles restent informelles ou inaccessibles.

Le risque consiste à traiter le graphe obtenu comme une vérité objective. Il vaut mieux le comprendre comme un modèle opérationnel maintenu, avec des sources explicites et des incertitudes non résolues.

Trois signaux montreront si la couche de contexte d’Uvi fonctionne

Uvi doit désormais prouver que son modèle de décision reste exact en production, se transfère entre les agents et résiste à un examen de la sécurité d’entreprise.

Le premier signal est une évaluation indépendante. Uvi a publié des exemples clients et des comparaisons menées par le fournisseur, y compris son résultat rapporté avec Global-e.

La prochaine étape est un benchmark reproductible comprenant des questions documentées, des références, des règles d’évaluation, la latence, l’utilisation des modèles et la préparation du graphe. Une validation externe rendrait les affirmations d’efficacité plus faciles à évaluer.

Le benchmark devrait tester davantage que la récupération d’information. Il devrait inclure des questions nécessitant plusieurs systèmes, des états changeants, des preuves contradictoires et des limites de permissions.

Un résultat significatif renforcerait l’affirmation d’Uvi selon laquelle les décisions structurées surpassent l’exploration pilotée par connecteurs. Des résultats faibles suggéreraient que la préparation personnalisée du graphe contribue davantage que l’architecture générale.

Le deuxième signal est une adoption durable par les clients au-delà des pilotes contrôlés. Uvi cite Melio et Global-e comme utilisateurs en production et affiche des déclarations de leurs dirigeants.

Les futures études de cas devraient expliquer quels agents utilisent le graphe, quelles actions ils prennent en charge et à quelle fréquence les employés annulent leurs conclusions. Elles devraient également faire état du travail de maintenance requis après le déploiement.

Une adoption sur plusieurs interfaces d’agents soutiendrait la position d’Uvi indépendante des modèles. Elle montrerait qu’une couche de contexte unique peut servir des assistants de codage, des agents de workflow et des applications internes.

Un usage limité à une seule expérience de recherche affaiblirait cette affirmation. Cela pourrait indiquer que le graphe fonctionne bien pour la découverte de connaissances, mais pas pour l’action opérationnelle.

Le troisième signal concerne la réaction des plus grandes plateformes. Microsoft, Anthropic, les fournisseurs cloud, les entreprises de bases de données orientées graphes et les fournisseurs de recherche d’entreprise occupent déjà des couches adjacentes.

Ils peuvent combiner connecteurs, récupération par graphe, hébergement de modèles, permissions et frameworks d’agents. Certains clients préféreront cette pile intégrée à un autre fournisseur spécialisé.

Uvi doit établir un avantage durable en matière de modélisation des décisions, de vitesse de déploiement ou de précision opérationnelle. Le nombre de connecteurs ne suffira pas à protéger sa position.

Le tour de seed de 7,5 millions de dollars de l’entreprise lui donne les ressources nécessaires pour rechercher cette preuve. Il ne tranche pas la question de savoir si la couche de raisonnement deviendra une catégorie distincte de logiciels d’entreprise.

Les acheteurs devraient surveiller l’apparition d’une documentation plus claire concernant les mises à jour du graphe, les relations inférées, les contrôles d’accès et la portabilité des données. Ces détails comptent davantage qu’une démonstration soignée.

Ils devraient également demander comment le système se comporte lorsque les preuves sont contradictoires. Une réponse utile doit montrer les sources, préserver l’incertitude et identifier qui peut résoudre le désaccord.

Pour les développeurs, l’arrivée d’Uvi renforce une leçon architecturale plus large. L’accès aux outils, la récupération d’information, la mémoire et le contexte organisationnel résolvent des problèmes liés, mais distincts.

MCP peut connecter un agent aux systèmes de l’entreprise. RAG peut trouver du texte pertinent. La récupération par graphe peut révéler des entités liées. Un modèle de décision maintenu peut ajouter la responsabilité, la causalité et l’état opérationnel.

Aucune couche unique ne garantit une action correcte. Les agents de production ont besoin de toutes ces capacités, ainsi que d’évaluations et de contrôles humains.

Pour les acheteurs d’entreprise, la question immédiate est pratique. Identifiez un flux de travail où les employés reconstruisent à plusieurs reprises la même chaîne de décision à travers plusieurs systèmes.

Mesurez les appels actuels au modèle, le délai, le taux d’erreur et l’effort de révision. Testez ensuite si un graphe maintenu améliore le flux de travail complet plutôt qu’un ensemble de réponses sélectionnées.

Uvi donne aux agents d’IA un contexte d’entreprise en convertissant des enregistrements dispersés en un récit structuré de la manière dont le travail avance. Son avenir dépend de la fiabilité de ce récit une fois la démonstration terminée.

Avant de laisser un agent agir sur la mémoire organisationnelle, posez trois questions : peut-il montrer les preuves, peut-il respecter chaque permission et peut-il admettre l’incertitude ?