Deuz SDK : un runtime TypeScript pour agents qui doivent survivre en production
Zero-dependency TypeScript framework for production AI agents: durable execution, long-term memory, hybrid RAG, MCP tool calling, human-in-the-loop approval, planning and CodeAct sandboxes. One streaming API for Claude, GPT, Gemini, Grok, Mistral and DeepSeek — Node, Bun, Deno, serverless and edge.
En bref
- De quoi s’agit-il ?
- Le SDK Deuz empile exécution durable, mémoire longue durée, RAG hybride et approbation humaine dans un seul paquet sans dépendance à l'exécution. Voici ce qu'il fait réellement, ce qu'il laisse à votre charge, et à qui il ne convient pas.
- À qui s’adresse-t-il ?
- Deuz SDK s'adresse aux équipes TypeScript qui ont déjà écrit deux fois la même boucle d'agent et qui veulent la mémoire, les points de contrôle et les garde-fous dans un paquet unique, sans vendre l'orchestration à un service tiers. Il ne convient pas à qui cherche un framework Python, ni à qui veut un moteur d'exécution durable indépendant du langage.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 34 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème que le SDK prend en charge, et celui qu'il ignore
Le README est explicite sur son point de départ : appeler un modèle est un problème résolu. Ce qui ne l'est pas, c'est ce qui entoure l'appel. Retenir un utilisateur d'une session à l'autre, tenir dans la fenêtre de contexte au quarantième tour, demander validation avant l'action irréversible, reprendre après la mort du processus en pleine exécution, brancher un serveur d'outils sans réécrire OAuth. La cible est donc l'équipe qui a déjà ces morceaux en production, mal, et qui préfère les voir arriver dans une dépendance unique plutôt que dans quatre scripts internes.
La formulation du README mérite d'être citée telle quelle : l'objectif est de faire de l'infrastructure honnête, un véhicule et non une destination. C'est un positionnement modeste, et il faut le prendre au mot. Le SDK ne prétend pas produire un agent autonome fiable. Il fournit les briques qui empêchent une exécution de perdre son état, et il laisse la qualité du raisonnement au modèle que vous branchez.
Ce partage des responsabilités a une conséquence pratique. Si votre problème est que l'agent prend de mauvaises décisions, Deuz SDK n'y répond pas. Si votre problème est que l'agent oublie, dépasse le contexte, ou repart de zéro après un redéploiement, il vise exactement cela.
Normaliser les octets du fournisseur avant tout le reste
Une règle de conception structure le code, d'après la section de construction du README : normaliser les octets du fournisseur en un flux de deltas canonique, avant toute autre chose. Une fois ce point d'entrée unique posé, la reprise sur erreur, le basculement de fournisseur, la reprise après checkpoint, les budgets, les sous-agents et les événements typés destinés à l'interface partagent tous le même langage. Sans cette étape, chacun de ces mécanismes devrait connaître les particularités de chaque fournisseur.
Le SDK revendique 28 fournisseurs de chat répartis sur quatre protocoles, plus les embeddings, les images, la parole, la transcription et la vidéo. Le README donne l'exemple d'un appel Anthropic via `createAnthropic`, mais la même surface couvre Claude, GPT, Gemini, Grok, Mistral et DeepSeek selon la description du dépôt.
Le point qui distingue vraiment l'implémentation est ailleurs : rien n'est ambiant. L'horloge, l'aléa, `fetch`, les clés et la journalisation sont injectés. C'est ce qui permet au même code de tourner sur Node, Bun, Deno et en edge, et c'est aussi ce qui rend les tests déterministes, parce qu'aucun appel réseau implicite ne vient s'intercaler. Ce choix a un coût : vous devez fournir ces dépendances au lieu de les subir, ce qui alourdit le premier appel et allège tous les suivants.
Mémoire : un pipeline, pas un tableau de messages
La mémoire du SDK n'est pas un historique qu'on empile. Le README décrit un pipeline qui extrait des faits durables d'une conversation, les réconcilie avec ce qui est déjà connu en ajout, mise à jour ou suppression, leur attribue un score d'importance, les fait expirer, puis rappelle les pertinents au tour suivant. L'absence d'ajout aveugle est le détail qui compte : sans étape de réconciliation, un agent qui répète la même information trois fois la stocke trois fois.
La configuration tient dans un objet `memory` passé à `generateText`, avec des clés nommées : `seams` regroupe le store, l'embedder et le modèle, `scope` porte l'identifiant utilisateur, `recall` fixe `topK`, `maxChars` et `expandLinks`, et `writePolicy` accepte la valeur `each-turn`. Le stockage repose sur un magasin vectoriel, une table Postgres, ou un coffre Obsidian selon le README.
Deux réserves. D'abord, la réconciliation et le scoring d'importance consomment des appels de modèle, donc la mémoire n'est pas gratuite à l'exécution. Ensuite, le choix d'`expandLinks` à 1 suppose une structure de liens entre faits ; rien dans le matériel fourni ne décrit comment ces liens se forment. C'est un paramètre à vérifier dans la documentation avant de le régler.
Compaction et checkpoints : deux mécanismes distincts
La compaction et les points de contrôle répondent à deux pannes différentes, et le SDK les traite séparément. La compaction gère la fenêtre de contexte : quand elle se remplit, le mécanisme élague les sorties d'outils périmées, retire le raisonnement ancien et replie les premiers tours dans un résumé courant unique, mis à jour plutôt qu'empilé. Elle s'active par `compaction: 'auto'` sur un appel avec `maxSteps`. Le détail intéressant est le comportement en cas de rejet : si un fournisseur refuse la requête comme trop longue malgré tout, la boucle force une compaction et réessaie cette étape au lieu de faire échouer l'exécution.
Les points de contrôle couvrent autre chose : le crash du processus. Le README indique que les checkpoints d'étape sont écrits dans votre base de données, et qu'une reprise ultérieure se fait via `resumeFromCheckpoint`, sans fournisseur de workflow externe. Le SDK ne détient donc pas l'état à votre place, ce qui est un choix défendable pour l'audit et la conformité, mais vous rend responsable de la disponibilité et de la migration de ces tables.
La distinction compte en exploitation. Une compaction ratée se voit dans les journaux et se corrige par la configuration. Un checkpoint perdu se voit en production, quand une reprise ramène l'agent à une étape incohérente. Le second cas demande un schéma de base maîtrisé, pas un réglage.
Mise en route et surface de configuration
L'installation tient en deux commandes : `npm install @deuz-sdk/core` pour le runtime, et `npm install @deuz-sdk/react` en option pour `useChat`, `useObject` et l'interface sans composants. Le socle demande Node 22 ou plus, ou tout runtime edge disposant de `fetch`. Les pairs optionnels ne sont requis que si vous les utilisez : `zod` ou toute bibliothèque Standard Schema, `@modelcontextprotocol/sdk`, `react`, `pg` ou `redis`, `unpdf`, `mammoth`, `xlsx`, `playwright`, `@opentelemetry/api`.
Le premier appel suit la forme donnée par le README : `streamChat` reçoit un `model`, des `instructions` et un `prompt`, renvoie un objet de façon synchrone et ne lève jamais d'exception. Les échecs arrivent comme parties de flux typées. On consomme `res.textStream` avec un `for await`, et `res.usage` donne la consommation. Ce contrat de non-levée est inhabituel et il faut le prévoir dans le code appelant : votre gestion d'erreur se déplace du `try/catch` vers le traitement des parties du flux.
Pour une configuration complète, le README montre un appel à `generateText` qui combine `maxSteps`, `tools` avec `handoff`, `guardrails` avec `onInput` et `onOutput`, `mcp` sous forme de tableau d'URL, `chat` et `session` adossés à des stores Postgres créés par `createPostgresStores`, et `runtimeContext` qui transporte des valeurs comme `tenantId` avec l'appel plutôt que dans une fermeture par requête. Les garde-fous disponibles cités sont `promptInjectionGuardrail` et `maxOutputLength`. Pour les agents de codage, `npx skills add Deuz-AI/Deuz-SDK` installe deux compétences : une guide de construction couvrant les 53 sous-chemins, et un portage nom par nom depuis `ai` et `@ai-sdk/*`.
Ce que le SDK ne résout pas
Le SDK est en TypeScript, et rien dans le matériel fourni n'indique une liaison pour un autre langage. Une équipe Python qui veut ces mêmes garanties devra soit exposer le runtime comme service, soit regarder ailleurs. C'est une contrainte de départ, pas un défaut caché.
La durabilité repose sur votre base. Les points de contrôle vivent dans votre Postgres, Redis ou SQLite via les packs de stores, et le README ne décrit ni schéma de migration, ni stratégie de rétention, ni versionnement des checkpoints. Une montée de version majeure qui change la forme d'un checkpoint vous concerne directement. La version 2.0.0 date du 10 août 2026, la 1.9.0 du 28 juillet 2026, et la 1.8.0 du 22 juillet 2026 : trois publications en moins d'un mois, sur une branche principale active. Ce rythme est un signal à lire avant de figer une dépendance dans un système critique.
La sécurité des approbations mérite aussi un examen. Le README mentionne des jetons signés HMAC avec expiration, et précise qu'une décision manquante vaut refus. Ce dernier point est un bon choix par défaut, mais il implique qu'une panne du canal d'approbation bloque l'exécution au lieu de la laisser passer. À vous de décider si c'est acceptable pour votre charge.
Enfin, la mention des compétences pour agents de codage inclut un chiffre à prendre pour ce qu'il est : neuf tâches de construction données à des agents sans la compétence ont produit 19 imports imaginaires sur 8 réponses sur 9. C'est un argument sur la qualité de la documentation embarquée, pas une mesure de la fiabilité du runtime.
Face au Vercel AI SDK et aux moteurs de workflow
Le README fournit lui-même le point de comparaison, avec un document de migration depuis le Vercel AI SDK et un portage nom par nom depuis `ai` et `@ai-sdk/*`. La différence d'approche tient dans ce qui est inclus. Le Vercel AI SDK fournit l'appel de modèle et la boucle d'outils, et laisse la mémoire, la compaction, les checkpoints et l'approbation à l'application. Deuz SDK les inclut, au prix d'une surface plus large à apprendre et d'un couplage plus fort à ses abstractions : `seams`, `stores`, `guardrails`, `handoff`, `runtimeContext`.
Face à un moteur de workflow durable classique, le partage est inverse. Un tel moteur prend en charge l'orchestration et la reprise, mais ne connaît ni la mémoire conversationnelle, ni la compaction de contexte, ni le rappel d'outils MCP. Le README revendique explicitement l'absence de fournisseur de workflow : les checkpoints restent dans votre base. Vous gagnez l'absence de service tiers à exploiter, vous perdez la supervision et les outils d'exploitation qu'un moteur dédié apporte.
Le choix se joue donc sur une question simple. Si votre pile est déjà TypeScript et que la douleur est dans l'état de l'agent, Deuz SDK remplace plusieurs briques internes. Si votre douleur est l'orchestration de tâches hétérogènes, un moteur de workflow reste plus adapté, et vous brancherez la mémoire par-dessus.
Conclusion éditoriale
Deuz SDK s'adresse aux équipes TypeScript qui ont déjà écrit deux fois la même boucle d'agent et qui veulent la mémoire, les points de contrôle et les garde-fous dans un paquet unique, sans vendre l'orchestration à un service tiers. Il ne convient pas à qui cherche un framework Python, ni à qui veut un moteur d'exécution durable indépendant du langage. Avant d'adopter, vérifiez deux choses concrètes : que votre schéma Postgres accepte les tables de mémoire, de chat, de session et de run décrites dans les packs de stores, et que les 53 sous-chemins exposés couvrent vos fournisseurs. Le paquet est en 2.0.0 depuis le 10 août 2026 et la licence MIT ne porte que sur ce dépôt.
Notes de la communauté