La mémoire se souvient. Les compétences codifient. Le fine-tuning réentraîne. Les passerelles routent.
Duplex boucle la boucle.
La plupart des infrastructures d’IA résolvent une partie du travail. Duplex réunit chaque partie en une seule intelligence d’exécution qui ne cesse de s’améliorer pendant qu’elle travaille.
Comparatif à jour au 16 octobre 2026.
Chacun résout une partie.
Les plateformes de mémoire conservent l’information. L’apprentissage de compétences transforme l’expérience en instructions. Le fine-tuning modifie les poids du modèle. Les passerelles d’IA routent les requêtes et appliquent des garde-fous. Duplex réunit le tout, et ne cesse de s’améliorer.
Étape 1 sur 5 : Mémoire
Toutes les capacités, côte à côte.
Choisissez-en un à placer à côté de Duplex, ou voyez-les tous à la fois.
- Natif
- Intégré au fonctionnement même du produit.
- Externe
- Vous le fournissez, ou l’assemblez, à part.
- Non natif
- La documentation du produit ne l’indique pas comme fonction intégrée. Un développement sur mesure reste peut-être possible.
Placer à côté de Duplex :
| Capacité | Duplex | Letta | CopilotKit CLiF | Deeplake Hivemind | Plateformes de mémoireMem0, Zep, AgentCore Memory et Supermemory | Fine-tuning et RFT | Passerelles d’IAPortkey, LiteLLM et similaires |
|---|---|---|---|---|---|---|---|
| Ce qu’est chacun | |||||||
| Ce que c’est | Une intelligence d’exécution aux côtés de votre IA : elle apprend et agit pour vos agents et vos assistants, conformément à vos règles | Une plateforme d’agents avec état, bâtie autour d’une mémoire persistante et d’un apprentissage dans l’espace des tokens | Un pipeline full-stack qui transforme les trajectoires en compétences, évaluations et données d’entraînement | Une mémoire d’agent partagée qui transforme automatiquement les traces en compétences | Contexte persistant, faits, épisodes et graphes de connaissances | Adapter un modèle en l’entraînant | Routage de modèles, fiabilité, garde-fous et observabilité |
| Ce qu’il fait suivre | Contexte, décisions, issues, règles, tâches, compétences et ce qu’il a appris | Mémoire d’agent, conversations, fichiers et compétences | Fils, trajectoires, enseignements, compétences et évaluations | Sessions, souvenirs et compétences, limités à un espace de travail | Faits, messages, résumés, épisodes et relations de graphe | Un nouveau jeu de poids du modèle | Configuration, journaux, politiques de routage et caches |
| Ce qui s’améliore avec l’expérience | Ses prochaines décisions : certitude, routage, recommandations, usage des outils et connaissances réutilisables | Le comportement futur de l’agent, via une mémoire mise à jour et des compétences apprises | Les instructions de l’agent, via des compétences examinées, tirées de vrais workflows | Le comportement de la session suivante, via des compétences distillées | Surtout le contexte fourni au prochain appel du modèle | Les réponses du modèle sous-jacent | Le routage et la fiabilité des requêtes, pas ce que l’agent a appris |
| Savoir ce qui s’est passé, et en apprendre | NatifIl sait ce qui s’est passé, et apprend ce qu’il faut changer ensuite | Les deux sont là, surtout via la mémoire et les compétences dans l’espace des tokens | L’apprentissage est généré à partir de trajectoires stockées | La mémoire partagée est transformée en compétences réutilisables | Surtout de la mémoire ; l’ampleur de l’apprentissage varie selon le fournisseur | Un apprentissage sans mémoire opérationnelle durable | Un contrôle opérationnel sans apprentissage continu |
| Apprentissage | |||||||
| Apprentissage continu sans réentraînement | NatifIl continue d’apprendre, hors des poids de votre modèle | NatifApprentissage dans l’espace des tokens et apprentissage de compétences | NatifApprentissage de compétences ; les données de fine-tuning sont facultatives | NatifApprentissage de compétences à partir de traces | Amélioration par le contexte ; sa profondeur varie selon la plateforme | NonL’entraînement est sa façon d’apprendre | Non natif |
| Adaptation tour par tour | NatifChaque nouveau résultat peut changer aussitôt la décision suivante | La mémoire gérée par l’agent peut changer en continu ; l’apprentissage de compétences suit l’expérience achevée | L’analyse se lance à la main ou selon un calendrier | Les compétences sont distillées en arrière-plan ou en fin de session | Des souvenirs peuvent être ajoutés en continu, mais les récupérer n’est pas s’adapter | Attend la fin d’un entraînement et le déploiement du nouveau modèle | Le routage change aussitôt, mais pas d’après des issues apprises |
| Apprendre des corrections | NatifUne correction change ce que Duplex fait ensuite | Les corrections peuvent mettre à jour la mémoire ou alimenter des compétences apprises | Les modifications des utilisateurs et les actions de l’appli nourrissent son apprentissage | Les corrections et les traces de session peuvent devenir des compétences | Les corrections peuvent être stockées et récupérées comme contexte | Les corrections doivent passer par un jeu de données d’entraînement ou un pipeline de récompense | Généralement journalisées ; l’apprentissage qui en découle est externe |
| Apprendre des issues | NatifSuccès et échecs alimentent directement ce qu’il apprend | Possible via la réflexion sur les trajectoires et des mises à jour gérées par l’agent | Les issues de toute la stack deviennent enseignements, compétences, évaluations et données d’entraînement | Les nouvelles compétences sont tirées des sessions terminées | Les épisodes peuvent être rappelés, mais apprendre des issues reste généralement externe | NatifQuand les issues peuvent être converties en récompenses | Les issues apparaissent dans la télémétrie ; l’apprentissage qui en découle est externe |
| Apprendre des récompenses | NatifUne récompense renforce ce qui a marché et corrige ce qui n’a pas marché | Les récompenses ne sont pas son principal moyen d’apprendre | Peut produire des données de fine-tuning à partir de trajectoires évaluées | Les récompenses ne sont pas son principal moyen d’apprendre | Les récompenses ne sont pas une fonction standard de mémoire | NatifLes récompenses optimisent les poids du modèle | Non natif |
| Le mérite des étapes à l’origine d’un résultat | NatifIl détermine quelles actions antérieures ont mené à un résultat ultérieur | Letta ne le propose pas nativement à l’exécution | L’analyse des trajectoires peut faire émerger des schémas de workflow utiles | L’analyse des traces peut trouver des procédures réutilisables | Non natif | Peut apprendre des corrélations à partir d’exemples d’entraînement, mais ne peut pas remonter d’un résultat en direct jusqu’à ses étapes | Non natif |
| Comment les actions font avancer le travail | NatifIl apprend comment chaque action fait passer le travail d’un état au suivant | L’agent peut le déduire du contexte | Peut transformer des workflows en compétences | Peut capturer des procédures réussies sous forme de compétences | Les épisodes stockés peuvent servir d’exemples | Peut absorber ces schémas pendant l’entraînement | Non natif |
| Prédire ce que fera une action | NatifÀ partir de ce qu’il observe, il prédit ce que fera une action, essaie des alternatives et planifie | Le modèle raisonne sur la mémoire | ExterneLaissé au framework d’agents | Non natif | Non natif | Implicite dans le modèle entraîné, où vous ne pouvez pas le modifier | Non natif |
| De meilleurs choix d’action | NatifLes issues améliorent l’action qu’il choisit ensuite | Le comportement s’améliore via la mémoire et les compétences | Des compétences examinées améliorent les prochaines instructions de l’agent | Des compétences distillées améliorent les procédures suivantes | Le contexte récupéré peut façonner le comportement indirectement | NatifEn optimisant le modèle | Les politiques de routage sont configurées, pas apprises des issues |
| Compétences réutilisables | NatifL’expérience devient des compétences testées avant usage, qui peuvent être mises en pause, rétablies ou retirées | NatifLes trajectoires peuvent devenir des compétences durables qui marchent avec tout modèle | NatifLes trajectoires deviennent des compétences examinées, preuves à l’appui | NatifLes sessions deviennent des fichiers skill.md pour l’espace de travail | Dépend du fournisseur ; en général, pas ce autour de quoi la catégorie est bâtie | Le savoir est absorbé dans les poids, pas empaqueté en compétences portables | Non natif |
| Tester et gérer les compétences | Une compétence est testée avant qu’on s’y fie, et peut être mise en pause, rétablie, retirée ou supprimée définitivement | Les compétences sont des fichiers que vous pouvez inspecter, gérer et versionner | Publiées après relecture humaine, livrées dans une version figée | Les compétences restent des fichiers que vous pouvez inspecter et modifier, liés aux sessions dont elles viennent | En général un cycle de vie par enregistrement, pas par compétence | L’évaluation se fait autour de l’entraînement et du déploiement | Des versions de configuration, pas un cycle de vie pour des compétences apprises |
| Généraliser aux cas voisins | Il étend ce qu’il a appris aux cas voisins et aux nouvelles formulations, et le transpose en compétences qu’il peut réutiliser | Les compétences dans l’espace des tokens généralisent des procédures d’une tâche à l’autre | Les compétences capturent des schémas sur de nombreuses trajectoires de production | Les compétences capturent des schémas récurrents d’une session à l’autre | La récupération sémantique trouve des informations voisines, ce qui n’est pas la même chose que généraliser un comportement | Généralise via les poids entraînés | Les caches sémantiques rapprochent les requêtes similaires, mais n’apprennent pas comment agir |
| Décider et agir | |||||||
| Connaître son degré de certitude | NatifAvant chaque décision, il sait à quel point le cas est connu et quel est son degré de certitude | Surtout le jugement du modèle et la pertinence de la mémoire | Guidé par l’évaluation, pas une mesure en direct de la certitude | La pertinence de la recherche et des compétences, pas une mesure de certitude | Scores de récupération et signaux de pertinence | La confiance du modèle doit être mesurée à part | Santé des fournisseurs, routage et scores de garde-fous, pas une certitude sur la tâche |
| Répondre, passer la main ou refuser | NatifDuplex répond lui-même, appelle votre modèle, utilise un outil ou refuse, conformément à vos règles | L’agent continue généralement via le raisonnement du modèle | ExterneL’agent hôte décide comment agir | ExterneL’agent hôte décide comment agir | ExterneL’application hôte décide comment agir | Le modèle entraîné tourne toujours à chaque requête | Router, réessayer, bloquer ou basculer, sans apprendre des issues |
| Traiter lui-même le travail connu | NatifIl prend lui-même les décisions connues, sans nouvel appel à un modèle de pointe | Le modèle interprète toujours la mémoire ou les compétences | Le modèle lit toujours la compétence apprise | Le modèle lit toujours la compétence apprise | Le modèle lit normalement le contexte récupéré | Le modèle adapté tourne toujours | Un cache peut éviter un appel au modèle, mais un cache n’apprend pas des issues |
| Passer la main sur ce qui est nouveau ou incertain | Le travail nouveau, incertain ou sensible va au bon modèle, au bon outil ou à la bonne personne | L’agent et le modèle décident quand il faut plus d’aide | ExterneLe rôle de l’agent hôte | ExterneLe rôle de l’agent hôte | ExterneLe rôle de l’application | ExterneLe rôle de l’application | Routage et bascule solides entre fournisseurs ; la certitude sur la tâche reste externe |
| Planification, simulation et recommandations | NatifIl prédit la suite, essaie des alternatives, construit des plans et recommande des actions | Surtout via le raisonnement du modèle et les outils de l’agent | ExterneLe rôle de l’agent hôte | ExterneLe rôle de l’agent hôte | La mémoire fournit le contexte ; la planification reste externe | Le modèle planifie peut-être mieux, mais l’état du travail reste externe | Non natif |
| De nombreux agents, qui travaillent ensemble | Il envoie le travail au bon agent, le répartit conformément à vos règles, garde chaque agent dans son périmètre et réunit les résultats | Agents, sous-agents et mémoire partagée sont disponibles | Fonctionne avec les frameworks d’agents pris en charge | Partage les leçons entre agents connectés | Une mémoire partagée peut servir plusieurs agents | Non natif | Certaines routent vers des agents et des outils MCP, mais n’apprennent pas quelle collaboration a marché |
| Apprendre quels outils marchent | Il apprend quels outils marchent, quand les utiliser et à quoi chacun mène | Les compétences et la mémoire peuvent améliorer l’usage des outils | Des trajectoires full-stack capturent les actions des outils et des utilisateurs pour de nouvelles compétences | Les traces d’outils peuvent devenir des procédures réutilisables | Les résultats des outils peuvent être mémorisés | Le comportement des outils peut s’améliorer par l’entraînement | Elles exposent et routent les outils, mais n’apprennent généralement pas de leurs issues |
| Actions d’outils conformes à vos règles | Les outils ne s’exécutent que selon vos règles et vos permissions | Permissions des agents et configuration des outils | Contrôlé par le framework de l’agent hôte | Contrôlé par l’agent de codage hôte | ExterneLaissé à l’application dans les systèmes de mémoire seule | Externe | Routage et garde-fous solides ; le contrôle des actions des agents dépend de l’intégration |
| Streaming | Il diffuse en streaming la sortie du modèle et des outils, chaque étape restant conforme à vos règles | Disponible via les interfaces des agents et des modèles | Disponible via les frameworks d’agents pris en charge | Dépend de l’agent hôte | Dépend du fournisseur | Dépend du fournisseur de modèle | NatifStreaming solide |
| Un travail qui se poursuit | |||||||
| Apprendre de chaque étape, automatiquement | Chaque étape, via MCP + hooks ou les plugins, nourrit une seule boucle d’apprentissage partagée | Le runtime de Letta stocke les conversations et les actions des agents | AG-UI capture les actions des agents et des utilisateurs sous forme de trajectoires full-stack | Les sessions des agents et l’activité des outils sont capturées automatiquement | Des intégrations SDK ou harness capturent messages et événements | Des journaux ou des jeux de données doivent être fournis pour l’entraînement | Requêtes, réponses, coût et latence sont journalisés |
| Le contexte d’une session à l’autre | NatifLe travail, les décisions, les tâches et le contexte qui compte se poursuivent d’une session à l’autre | NatifLes agents persistants gardent leur mémoire d’une conversation à l’autre | Des fils durables conservent les interactions de l’app | NatifLa mémoire partagée survit aux sessions des agents | NatifC’est précisément ce autour de quoi la catégorie est bâtie | Non natif | ExterneEn général |
| Travail de longue durée | NatifLe travail long reste ouvert d’une session et d’un agent à l’autre, avec des points de reprise où revenir, jusqu’à ce qu’il soit terminé ou oublié | Les agents persistants peuvent poursuivre le travail, dont le cycle de vie est fixé par l’agent et l’app | Des fils durables gardent l’historique des interactions | La mémoire de session aide à reprendre le travail | Le contexte peut être récupéré, mais la gestion de l’état des tâches est externe | Non natif | Non natif |
| D’un modèle à l’autre | NatifCe qu’il apprend et votre contexte restent hors du modèle, et suivent le travail d’un fournisseur à l’autre | Solide : la mémoire et les compétences dans l’espace des tokens peuvent survivre à un changement de modèle | Solide : les compétences peuvent être livrées sur les stacks d’agents prises en charge | Solide : les compétences et la mémoire peuvent être réutilisées par différents agents de codage | Généralement solide, car la mémoire ne dépend pas du modèle | Faible : un nouveau modèle de base demande généralement un réentraînement ou une revalidation | Solide pour le routage, mais rien d’appris ne se transmet |
| D’une app et d’un agent à l’autre | Le même travail se poursuit dans Claude, Codex, Cursor, Hermes et vos propres agents | Les agents avec état sont accessibles via des SDK et un MCP hébergé | Les compétences peuvent être livrées via les adaptateurs de frameworks pris en charge | Une mémoire partagée relie Claude Code, Codex, Cursor et d’autres agents | Possible quand les apps partagent la même identité de mémoire | Non natif | Les requêtes peuvent passer par une même passerelle, mais ce que sait chaque app reste externe |
| Confier le travail à un autre agent | Une tâche et son contexte passent à un autre agent que vous autorisez, prêts à continuer | Des agents et des dépôts partagés peuvent soutenir une passation | Des trajectoires partagées et des compétences publiées gardent un comportement cohérent | Les compétences de l’espace de travail transmettent les leçons entre agents | Un autre agent autorisé peut récupérer le contexte partagé | Non natif | Un routage vers des agents et MCP peut exister ; ce que signifie la tâche reste externe |
| Garder le contexte compact | Le contexte reste compact, centré sur les règles, tâches et décisions qui comptent | Organisation de la mémoire, résumés et gestion du contexte sous forme de fichiers | Les trajectoires sont distillées en enseignements et en compétences | Les sessions sont distillées en compétences compactes | Résumés, souvenirs extraits et enregistrements épisodiques | Non natif | Troncature ou mise en cache du prompt, pas un résumé durable de ce qui compte |
| Apprendre des images, de l’audio, de la vidéo et des PDF | Il apprend des images, de l’audio, de la vidéo et des PDF, comme du texte | Dépend du modèle connecté et des outils de l’agent | Dépend des événements de l’app capturés et de la stack de l’agent | Centré surtout sur les sessions et les traces d’outils | Dépend du fournisseur et du modèle | Pris en charge quand le modèle et le service d’entraînement acceptent le média | Transmet surtout les médias pris en charge aux fournisseurs |
| D’un média à l’autre | Une question en mots peut s’appuyer sur ce qui a été appris d’images, d’audio et de vidéo, et les médias peuvent orienter des décisions ultérieures | Dépend du modèle et de la façon dont la mémoire est construite | Hors du champ principal de CLiF | Hors du champ principal de Hivemind | Disponible dans les produits qui indexent plus que du texte | Encodé dans les poids quand l’entraînement le permet | Non natif |
| Personnes, équipes et partage | |||||||
| Pour chaque personne | NatifChaque personne a son propre contexte privé, ses préférences et son apprentissage | Mémoire native par agent et par utilisateur | Possible via les fils de l’app et des conteneurs d’apprentissage | Disponible au niveau personnel ou de l’espace de travail | Mémoire solide par utilisateur ou par acteur | Demande généralement un modèle entraîné ou adapté à part | Clés et budgets par utilisateur ; le comportement personnel est externe |
| Pour chaque équipe | NatifLes équipes partagent l’apprentissage approuvé, et le travail privé reste privé | Dépôts de mémoire partagés et compétences | Les compétences publiées diffusent l’apprentissage de l’équipe | Mémoire et compétences partagées de l’espace de travail | Disponible via des espaces de noms, des graphes ou des stockages partagés | Demande généralement des données d’entraînement et un modèle partagés | Configuration et budgets par équipe |
| Dans toute l’organisation | NatifCe qui marche peut passer d’une personne à l’équipe et à l’organisation, selon vos règles | Les compétences et la mémoire peuvent être partagées dans toute l’organisation | Les compétences examinées peuvent être diffusées sur les agents pris en charge | Les leçons de l’espace de travail peuvent se diffuser entre agents connectés | Une mémoire organisationnelle partagée est possible | Un modèle sur mesure peut encoder un comportement commun pour l’organisation | Routage et garde-fous dans toute l’organisation, sans apprendre des issues |
| Partager entre personnes, sous contrôle | Vous choisissez ce qui est partagé et avec qui, et pouvez le retirer ; tout ce qui est partagé indique de qui il vient | Dépôts partagés et permissions de collaboration | Permissions par projet et par déploiement | Contrôles d’accès de l’espace de travail | Espaces de noms propres au fournisseur, IAM ou permissions de graphe | Contrôles d’accès aux jeux de données et aux modèles | Contrôles par clé, équipe et rôle |
| Protection des contenus partagés | Ce que quelqu’un partage arrive comme information, jamais comme instruction, et ne peut donc pas piloter l’agent d’une autre personne | Repose sur le contexte et les permissions de l’agent | La politique des développeurs et les restrictions d’outils priment sur les compétences | Repose sur la façon dont les compétences se chargent, et sur la confiance dans l’espace de travail | Dépend de l’app et du fournisseur | Les données d’entraînement exigent leurs propres contrôles avant l’entraînement | Les garde-fous peuvent inspecter les entrées partagées, mais la confiance dans ce qu’elles signifient reste externe |
| Contrôle et confiance | |||||||
| Vos règles | Vos règles font partie du fonctionnement de Duplex : elles autorisent, refusent ou limitent des actions réelles | Les instructions et les permissions façonnent le comportement des agents | Les compétences apprises ne peuvent pas passer outre les règles de sécurité du développeur ni les restrictions des outils | Les compétences guident l’agent, mais n’imposent rien par elles-mêmes | Le contexte peut éclairer le comportement, mais n’autorise pas d’actions | Le comportement est façonné par l’entraînement, pas par des règles en direct | Garde-fous solides en entrée et en sortie, et politiques de routage |
| Des règles appliquées avant chaque action | NatifLes hooks vérifient chaque action au regard de vos règles avant son exécution | Dépend du runtime de Letta, des permissions et de l’hôte des outils | Reste du ressort de l’app hôte et du framework d’agents | Reste du ressort de l’agent hôte | La mémoire fournit le contexte, mais n’autorise pas d’actions extérieures | Externe | Solide pour les requêtes et les réponses qui passent par la passerelle |
| Des personnes dans la boucle | Une personne confirme les actions que vous choisissez, et ce que Duplex apprend peut être examiné et annulé | Les utilisateurs peuvent inspecter et gérer la mémoire et les compétences | Un examen solide avant la publication des compétences apprises | Les compétences peuvent être inspectées et modifiées avant réutilisation | Défini par l’app | Examen de l’entraînement, évaluation et approbation avant déploiement | Les workflows d’approbation varient selon la passerelle |
| Un historique vérifiable | Un historique de chaque décision, de son origine et de ce qu’il en est advenu, qui ne peut pas être modifié en silence | Conversations persistantes, mémoire et état des agents | Des enseignements étayés par des preuves, et leurs trajectoires sources | Des compétences liées aux sessions, et des traces stockées | Historique, traçabilité des sources et contrôles d’audit varient selon le fournisseur | Entraînements, jeux de données, métriques de récompense et versions de modèle | Journaux solides des requêtes, réponses, coûts et politiques |
| Des reçus vérifiables | Les décisions, les compétences et les suppressions peuvent s’accompagner de reçus vérifiables | Souvenirs et compétences versionnés | Liens vers les preuves et révisions exactes des compétences | Fichiers de compétences liés à leurs sessions d’origine | La traçabilité des sources varie selon le fournisseur | Évaluation du modèle et rapports d’entraînement | Journaux et résultats de garde-fous, pas des reçus de ce qui a été appris |
| Annuler exactement ce qui a été appris | NatifUn changement appris peut être annulé exactement, sans rien réentraîner | Les compétences et les souvenirs peuvent être modifiés ou restaurés via des versions | Les compétences publiées peuvent être révisées ou retirées | Les fichiers de compétences peuvent être modifiés ou supprimés | Les souvenirs peuvent être supprimés, mais le comportement construit dessus n’est pas exactement inversé | Revenir en arrière sur toute une version du modèle, ou réentraîner sans l’échantillon | La configuration et les entrées de cache peuvent être supprimées ; il n’y a rien d’appris à inverser |
| Un oubli qui atteint tout ce qui est bâti dessus | Supprimer quelque chose supprime aussi ce qui en est issu : le contexte, tout ce qui en a été partagé et l’apprentissage lié | La mémoire et les compétences sont nettoyées via les fichiers et les versions | Suppose de retirer les enseignements, compétences et ressources dérivées concernés | Suppose de retirer les sessions et les compétences générées concernées | Supprime généralement des enregistrements ; les résumés dérivés et les copies ailleurs demandent un traitement à part | Exige un désapprentissage machine ou un réentraînement | Les journaux et les caches suivent leur propre durée de conservation |
| Garder les clients séparés | Chaque utilisateur, équipe, organisation et client reste séparé, dans chaque intégration et dans tout ce qu’il partage | Permissions dans le cloud et en auto-hébergement | Isolation par projet et par déploiement | Mémoire et compétences limitées à un espace de travail | Isolation par utilisateur, acteur, espace de noms, graphe ou IAM | IAM cloud et limites d’accès aux modèles | Isolation mature par clé, équipe, budget et rôle |
| D’où vient tout ce qui a été appris | Pour tout ce qu’il a appris, vous voyez sa source, sa portée et jusqu’où on peut s’y fier | La mémoire et les compétences restent inspectables | Les enseignements et les compétences restent liés aux trajectoires dont ils sont issus | Les compétences peuvent renvoyer à leurs sessions d’origine | Solide dans les produits à graphe temporel ; variable ailleurs | Lignage des jeux de données et métadonnées d’entraînement | Lignage des requêtes et des fournisseurs |
| Où il tourne et se connecte | |||||||
| Tout fournisseur de modèle | Une seule intelligence pour OpenAI, Anthropic, Google, AWS et les modèles compatibles | Un harness d’agents qui fonctionne avec tout modèle | Fonctionne avec les frameworks d’agents et les modèles pris en charge | Fonctionne avec plusieurs agents de codage et leurs modèles | Généralement indépendant du modèle | Généralement lié au modèle adapté et au fournisseur d’entraînement | NatifL’abstraction des fournisseurs est ce que la catégorie fait de mieux |
| MCP | NatifVia MCP + hooks, Duplex prend part à chaque étape de vos agents | Le MCP hébergé permet à d’autres agents de créer des agents Letta avec état et de leur envoyer des messages | Les compétences peuvent atteindre des agents et des serveurs MCP via des intégrations | Se connecte aux principaux agents de codage ; la manière varie selon le client | Disponible dans plusieurs produits, dont Supermemory et AgentCore | Non natif | De plus en plus natif |
| Hooks et plugins | NatifDes plugins pour Claude, Codex, Cursor et Hermes, et des hooks qui font intervenir Duplex à chaque étape et vérifient les actions d’outils sensibles | Intégration via SDK, CLI et runtime d’agents | AG-UI et adaptateurs de frameworks | Capture automatique des sessions des agents de codage | Intégrations SDK et MCP | La collecte des données doit être construite à part | Intégration via SDK et proxy, pas des hooks qui apprennent des sessions des agents |
| Votre cloud, ou auto-hébergé | Vareon cloud, votre cloud ou sans cloud : cloud privé, votre propre compte, auto-hébergé ou isolé du réseau | Cloud, et un serveur d’app auto-hébergé | Intelligence hébergée dans le cloud et auto-hébergée | Intégration locale à l’agent ; les options de déploiement varient | Propre au fournisseur ; des options open source et gérées existent | Entraînement dans le cloud et inférence hébergée | Les options hébergées et auto-hébergées varient selon la passerelle |
| Sans cloud : isolé du réseau | Conçu pour les déploiements d’où rien ne doit sortir, avec des modèles locaux, des dépendances locales et votre propre fournisseur d’identité | Possible avec une stack auto-hébergée et des dépendances locales | Possible avec une stack auto-hébergée et des dépendances locales | Dépend du déploiement choisi et des services de modèle | Dépend de la plateforme | Limité aux services qui permettent l’entraînement et l’inférence hors ligne | Disponible avec des passerelles auto-hébergées et des fournisseurs locaux |
| Coût, vitesse et adéquation | |||||||
| Comment il réduit le coût des modèles | Duplex traite lui-même le travail connu, sans appel répété à un modèle de pointe | Un meilleur contexte et de meilleures compétences améliorent les résultats, mais le modèle tourne toujours | De meilleures compétences réduisent les échecs et les reprises, mais le modèle tourne toujours | De meilleures compétences réduisent les erreurs répétées, mais le modèle tourne toujours | Un meilleur contexte réduit les répétitions, mais ajoute une récupération et appelle toujours le modèle | Un modèle adapté plus petit peut offrir la qualité dont vous avez besoin | Mise en cache, modèles moins chers, traitement par lots et choix du fournisseur |
| Comment il réduit la latence | Les décisions dont il est sûr reviennent vite ; le travail incertain va toujours à votre modèle de pointe | Un contexte mieux organisé peut réduire le raisonnement superflu | Les compétences rendent l’exécution plus directe | Les compétences abrègent les redécouvertes | Récupération plus rapide et contexte plus réduit | Dépend du modèle adapté | Mise en cache, répartition de charge et choix du fournisseur |
| Survit à une mise à niveau du modèle | OuiL’apprentissage, le contexte, les tâches et les règles restent hors de tout modèle particulier | OuiLa mémoire et les compétences sont délibérément indépendantes du modèle | OuiLes compétences et les trajectoires restent hors des poids du modèle | OuiLes compétences survivent à un changement d’agent de codage ou de modèle | OuiLe contexte stocké ne dépend pas du modèle | La personnalisation appartient à un seul checkpoint du modèle, elle ne se transfère donc pas automatiquement | La configuration du routage survit, mais aucun comportement appris n’est conservé |
| Fine-tuning nécessaire | NonLe fine-tuning devient une étape supplémentaire facultative | Non | NonPas pour les compétences ; CLiF peut aussi produire des données de fine-tuning | Non | Non | Oui | Non |
| Idéal pour | Les organisations qui ont besoin que leurs agents d’IA apprennent, agissent selon des règles, fassent avancer le travail et s’améliorent d’un modèle à l’autre, comme un seul système | Les équipes qui construisent des agents persistants qui s’améliorent seuls, autour de la mémoire et des compétences dans l’espace des tokens | Les équipes produit qui transforment de vrais workflows d’utilisateurs en compétences examinées, en évaluations et en ressources d’entraînement | Les équipes qui veulent que leurs agents de codage partagent leurs sessions et réutilisent les leçons automatiquement | Les apps qui ont surtout besoin d’un contexte utilisateur ou métier durable et pertinent | Les tâches stables et à fort volume où le modèle lui-même doit être spécialisé | Les équipes qui ont surtout besoin d’abstraction des fournisseurs, de fiabilité, de garde-fous et de maîtrise des coûts |
Une seule boucle fermée.
Avec Duplex, le contexte, l’apprentissage, les compétences et vos règles forment une seule boucle, qui tourne pendant que le travail se fait.
Duplex comprend la tâche en cours, et ramène le contexte qui compte.
Étape 1 sur 8 : La tâche
Pourquoi c’est important.
Un modèle d’IA peut être intelligent sans jamais acquérir d’expérience dans votre travail.
Un système de mémoire montre au modèle ce qui s’est passé avant, mais il ne décide pas de ce qui doit changer. Un système de compétences emballe une leçon, mais le modèle doit encore la lire et la suivre. Le fine-tuning modifie le modèle, via un cycle d’entraînement plus lent et difficile à annuler. Une passerelle contrôle le trafic, mais n’apprend pas quelle décision a mené à la meilleure issue.
Duplex transforme l’expérience en amélioration pendant qu’il travaille, conformément à vos règles.
Cela construit un autre type d’actif. Chaque correction confirmée, chaque workflow réussi, chaque résultat d’outil utile et chaque tâche terminée renforce l’intelligence autour de votre modèle, et rien de tout cela n’est enfermé chez un seul fournisseur de modèles.
L’essentiel.
- MémoireDonne un passé à un agent.
- CompétencesDonne à un agent des instructions réutilisables.
- Fine-tuningDonne à un modèle d’autres poids.
- PasserellesDonnent à une stack d’IA le contrôle du trafic.
- DuplexDonne à tout le système d’agents le pouvoir de transmettre l’expérience, d’apprendre des résultats, d’agir conformément à vos règles et de s’améliorer d’un modèle à l’autre, au fil du temps.
Parmi les produits et catégories étudiés, Duplex est le seul conçu pour combiner :
- Le contexte d’une session à l’autre
- L’apprentissage continu à partir des issues
- L’apprentissage à partir des corrections et des récompenses
- Le mérite des étapes à l’origine d’un résultat
- Apprendre comment les actions font avancer le travail, et prédire la suite
- Des décisions qui connaissent leur degré de certitude
- Passer la main au bon modèle, au bon outil ou à la bonne personne
- Un travail long qui se poursuit
- L’apprentissage pour chaque personne, équipe et organisation
- Vos règles, appliquées avant chaque action
- Actions d’outils conformes à vos règles
- Partager entre personnes, sous contrôle
- Annuler exactement ce qui a été appris
- Un oubli qui atteint tout ce qui est bâti dessus
- L’origine de tout ce qui a été appris, avec des reçus
- MCP + hooks, et des plugins pour les assistants que vous utilisez
- La continuité d’un modèle et d’une app à l’autre
- Votre cloud, auto-hébergé ou isolé du réseau
- Moins d’appels au modèle, car le travail connu reçoit une réponse directe
Duplex rend vos systèmes d’IA meilleurs dans leur travail à chaque expérience.
Les sources.
Les pages produit et la documentation sur lesquelles repose ce comparatif.
- Letta : apprentissage de compétences →
- Letta : MCP hébergé →
- CopilotKit : présentation de CLiF →
- CopilotKit : apprendre automatiquement →
- Deeplake Hivemind →
- Supermemory →
- Mem0 : mémoire en graphe →
- Zep : mémoire d’agent →
- Amazon Bedrock AgentCore Memory →
- Reinforcement fine-tuning sur Amazon Bedrock →
- Passerelle d’IA Portkey →
- Passerelle d’IA LiteLLM →
Comparatif à jour au 16 octobre 2026.
Voyez Duplex sur votre propre travail.
Comparez là où ça compte : un pilote applique Duplex à votre propre travail, avec des indicateurs convenus avant son lancement.