Deuz-SDK: Ein TypeScript-Runtime für Agenten, die einen Prozessabsturz überleben sollen

Welches Problem das SDK adressiert

Der README formuliert die Ausgangslage selbst: Einen Modellaufruf abzusetzen gilt als gelöst, ungelöst ist alles darum herum. Genannt werden vier konkrete Aufgaben. Ein Nutzer soll über Sitzungen hinweg erinnert werden. Ein Lauf soll innerhalb des Kontextfensters bleiben, auch im vierzigsten Turn. Vor einem irreversiblen Schritt soll ein Mensch zustimmen. Und ein Lauf soll fortgesetzt werden, wenn der Prozess mitten in der Ausführung stirbt. Dazu kommt die Anbindung eines Tool-Servers, ohne OAuth von Hand zu schreiben.

Die Zielgruppe sind damit nicht Einsteiger, die einen ersten Chatbot verdrahten. Angesprochen sind Teams, die diese vier Probleme bereits einmal selbst gebaut haben und wissen, wie viel Code zwischen einem funktionierenden Prototyp und einem Lauf liegt, der einen Neustart übersteht. Das SDK positioniert sich als Infrastruktur, nicht als Abstraktion über einem einzelnen Anbieter. Der README sagt das ausdrücklich: ein Vehikel, nicht das Ziel.

Kanonischer Delta-Stream als zentrale Designregel

Der README nennt eine Regel, die den größten Teil des Codes erklärt: Provider-Bytes werden zuerst in einen kanonischen Delta-Stream normalisiert. Erst danach setzen Retry, Failover, Resume, Budgets, Sub-Agenten und typisierte UI-Events auf derselben Sprache auf. Das ist der architektonische Kern. Solange jeder Anbieter sein eigenes Ereignisformat liefert, muss jede Querschnittsfunktion pro Anbieter neu geschrieben werden. Mit einer Normalisierungsschicht existiert genau ein Pfad, den ein Wiederholungsversuch oder ein Budgetzähler kennen muss.

Die Kehrseite liegt auf der Hand: Die Normalisierung ist der Ort, an dem anbieterspezifische Feinheiten verloren gehen können. Der README behauptet, dass kein Codepfad den Provider-Stream direkt weiterreicht, was konsistent mit dem Entwurf ist, aber auch bedeutet, dass neue Felder eines Anbieters erst durch die Normalisierung müssen, bevor sie nutzbar sind. Wer ein Anbieter-Feature benötigt, das im kanonischen Delta-Stream keinen Platz hat, wartet auf das SDK oder umgeht es.

Für die Laufzeitumgebung ist die zweite Regel ebenso wichtig: Nichts ist ambient. Uhr, Zufall, fetch, Schlüssel und Logging werden injiziert. Der README begründet das mit Portabilität über Node, Bun, Deno und Edge sowie mit deterministischen Tests. Das ist ein nachvollziehbarer Grund, kostet aber Einrichtungsaufwand an Stellen, an denen andere SDKs einfach die globale Funktion aufrufen.

Memory als Pipeline, nicht als Nachrichtenarray

Der README grenzt das Gedächtnis ausdrücklich von einem Message-Array ab. Beschrieben wird eine Pipeline: Aus einem Gespräch werden dauerhafte Fakten extrahiert, gegen den bestehenden Wissensstand abgeglichen (add, update oder delete, nie blindes Anhängen), nach Wichtigkeit bewertet, mit Ablauf versehen und beim nächsten Aufruf wieder herausgezogen. Als Ablage dienen ein Vector Store, eine Postgres-Tabelle oder ein Obsidian-Vault.

Die Konfiguration im README zeigt die Aufteilung in seams, scope, recall und writePolicy. seams bündelt store, embedder und llm, also genau die drei Bausteine, die die Pipeline austauschbar macht. recall steuert topK, maxChars und expandLinks. writePolicy steht im Beispiel auf each-turn, das heißt, der Abgleich läuft nach jeder Runde. Das ist die aggressivste Einstellung und erzeugt pro Turn zusätzliche Modellaufrufe für Extraktion und Abgleich.

Genau hier liegt die Kostenfrage, die der README nicht beziffert. Jede Schreiboperation verlangt einen LLM-Aufruf, jede Leseeperation eine Einbettung und eine Suche. Wer writePolicy auf each-turn setzt, zahlt das pro Runde. Eine sparsamere Politik wäre plausibel, aber der README nennt keine weiteren Werte, also lässt sich nicht sagen, welche Alternativen der Code akzeptiert.

Kompaktierung: einen laufenden Lauf am Leben halten

Das zweite Alleinstellungsmerkmal ist die Kompaktierung. Laut README werden bei vollem Fenster veraltete Tool-Ausgaben entfernt, altes Reasoning verworfen und die frühesten Turns zu einer einzigen laufenden Zusammenfassung gefaltet. Entscheidend ist die Formulierung, dass dieser Block aktualisiert wird und nicht als Stapel wächst. Ein wachsender Stapel aus Teilzusammenfassungen ist das typische Ergebnis selbstgebauter Lösungen, und er frisst genau das Budget, das er freigeben soll.

Interessanter ist der zweite Teil: Wenn ein Anbieter eine Anfrage trotzdem als zu lang ablehnt, soll die Schleife zwangsweise kompaktieren und den Schritt erneut versuchen, statt den Lauf scheitern zu lassen. Das ist die eigentliche Absicherung, weil die Token-Zählung zwischen SDK und Anbieter immer auseinanderlaufen kann. Der Aufruf im README ist knapp: compaction auf auto, dazu maxSteps.

Was der README offenlässt, ist das Verhalten der Zusammenfassung selbst. Ob die Verdichtung verlustfrei genug ist, um einen langen Lauf inhaltlich korrekt fortzuführen, hängt vom verwendeten Modell und vom Prompt ab. Das SDK garantiert nur, dass der Lauf nicht an der Längengrenze abbricht. Ob er inhaltlich das Richtige tut, ist eine andere Frage, und die Beispiele liefern dazu keine Aussage.

Installation und die kleinste lauffähige Konfiguration

Die Installation ist einzeilig: npm install @deuz-sdk/core für die Laufzeit, optional npm install @deuz-sdk/react für useChat, useObject und die headless UI. Vorausgesetzt wird Node ab Version 22 oder eine Edge-Laufzeit mit fetch. Optionale Peers werden nur bei Nutzung benötigt, genannt werden zod oder eine andere Standard-Schema-Bibliothek, @modelcontextprotocol/sdk, react, pg und redis, unpdf, mammoth und xlsx, playwright sowie @opentelemetry/api.

Das erste Beispiel im README zeigt den kleinsten Fall. createAnthropic bekommt einen apiKey, streamChat erhält model, instructions und prompt und liefert synchron zurück, ohne zu werfen. Fehler kommen als typisierte Stream-Parts. Der Konsum läuft über res.textStream, die Nutzungsdaten über await res.usage. Wer aus einem SDK kommt, in dem ein fehlgeschlagener Aufruf eine Exception wirft, muss sich an dieses Modell gewöhnen.

Das umfangreichere Beispiel verdient Aufmerksamkeit, weil es die Reihenfolge der Bausteine zeigt. generateText bekommt neben model und messages die Optionen maxSteps, tools, guardrails, mcp, chat, session und runtimeContext. Die Stores kommen aus createPostgresStores mit einer connectionString. Bemerkenswert ist runtimeContext: Der Kommentar im README sagt, dass der Kontext mit dem Aufruf reist und nicht als Closure pro Request lebt. Für Multi-Tenant-Anwendungen ist das der Unterschied zwischen einem Parameter und einem versteckten Zustand.

Checkpoints, Freigaben und die Grenze des Modells

Durable Execution wird im README über Schritt-Checkpoints in der eigenen Datenbank beschrieben, fortgesetzt später über resumeFromCheckpoint. Der Punkt ist die Abgrenzung: kein Workflow-Anbieter. Wer bereits Postgres betreibt, bekommt damit eine Wiederaufsetzbarkeit, die an die eigene Infrastruktur gebunden ist, statt an einen externen Dienst. Das ist ein realer Unterschied zu Orchestrierungsplattformen, die den Zustand selbst halten.

Die Kehrseite ist die Verantwortung für das Schema. Checkpoints liegen in der Datenbank des Nutzers, also muss dessen Migration mit der SDK-Version mitwandern. Der README nennt keinen Hinweis darauf, wie sich das Checkpoint-Format zwischen Hauptversionen ändert. Bei einem Sprung wie dem auf 2.0 wäre das die erste Frage, die ein Team klären sollte, bevor es produktive Läufe darauf aufsetzt.

Bei Freigaben nennt der README needsApproval auf jeder Tiefe, HMAC-signierte, ablaufende Tokens und eine Regel, die wichtig ist: Ein fehlendes Votum verweigert. Das ist die sichere Voreinstellung, denn ein Freigabeschritt, der bei fehlender Antwort durchwinkt, ist kein Freigabeschritt. Der Preis ist eine blockierte Ausführung, wenn die Freigabe-Infrastruktur selbst ausfällt. Wer Agenten ohne menschliche Aufsicht betreibt, für den ist dieses Feature kein Vorteil, sondern ein zusätzlicher Zustand, den er nicht will.

MCP-Anbindung und der Unterschied zum Vercel AI SDK

Für Tool-Server nennt der README mcp: [{ url }] als ausreichende Konfiguration, dazu OAuth 2.0, Reconnect, Sampling und Roots. Die Verbindung wird demnach hergestellt, mit Namensräumen versehen und wieder geschlossen. Der Aufwand, der hier eingespart wird, ist der OAuth-Teil, den man sonst von Hand schreibt. Das ist eine der Stellen, an denen das SDK am deutlichsten Arbeit abnimmt.

Als Alternative bietet sich das Vercel AI SDK an, und das SDK behandelt es nicht als Randnotiz: Der README verlinkt eine Migrationsanleitung mit dem Titel Coming from the Vercel AI SDK, und die Agent Skills enthalten einen name-by-name-Port aus ai und @ai-sdk/*. Der Unterschied im Ansatz liegt beim Zustand. Das AI SDK stellt generateText und streamText bereit und überlässt Gedächtnis, Kompaktierung und Wiederaufsetzbarkeit dem Anwender. Deuz zieht diese Themen in das Paket und bezahlt dafür mit Konfigurationsfläche: memory, compaction, session, chat und Stores müssen gesetzt werden.

Wer bereits eine eigene Speicherschicht und eine eigene Kompaktierung betreibt, findet im AI SDK weniger, das mit seiner Lösung konkurriert. Wer diese Schichten noch nicht hat und sie nicht selbst schreiben will, bekommt bei Deuz mehr mitgeliefert. Die Entscheidung hängt also weniger am Modellzugriff, der in beiden Fällen funktioniert, als an der Frage, wer den Zustand besitzt.

Wartung, Lizenz und was vor der Übernahme zu klären ist

Die Lizenz ist MIT, angegeben sowohl in den Repository-Metadaten als auch über das npm-Badge im README. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung des Lizenzhinweises. Eine rechtliche Bewertung ersetzt das nicht, insbesondere dann nicht, wenn der Code in ein Produkt eingebettet und nicht nur als Abhängigkeit verwendet wird.

Zum Wartungsaufwand lässt sich aus dem Material nur begrenzt etwas ableiten. Die Release-Historie zeigt v1.8.0 im Juli, v1.9.0 und v2.0.0 im August, also kurze Abstände und einen Hauptversionssprung innerhalb weniger Wochen. Der README verweist auf einen Changelog unter packages/core/CHANGELOG.md und auf eine Seite zu den Neuerungen in 2.0. Wer den Sprung mitmacht, sollte diese beiden Dokumente lesen, bevor er die Version anhebt, denn ein Hauptversionssprung bei einem Paket, das Checkpoint-Formate in der eigenen Datenbank ablegt, betrifft die eigene Migration.

Ein zweiter Hinweis auf den Reifegrad steht im README selbst, in der Beschreibung der Agent Skills. Dort heißt es, dass neun Bauaufgaben zuerst ohne Skill an Agenten gegeben wurden und das 19 erfundene Importe über acht von neun Antworten erzeugte. Diese Zahl beschreibt die Fehlerquote von Agenten ohne die Skill-Dateien, nicht die Qualität des SDK. Sie erklärt aber, warum das Projekt so viel Aufwand in gegen die echte Export-Tabelle geprüfte Anleitungen steckt: Die API-Fläche ist mit 53 Subpfaden groß genug, dass ein Modell sie ohne Vorlage nicht zuverlässig trifft. Für ein Team bedeutet das, dass die Lernkurve nicht am Kern liegt, sondern an der Breite der Optionen.

Redaktionelles Fazit

Wer Agenten mit Sitzungsgedächtnis, Freigabeschritten und wiederaufsetzbaren Läufen baut und dafür keinen Workflow-Anbieter einführen will, findet hier die passenden Bausteine. Wer nur einen einzelnen Modellaufruf mit Streaming braucht, trägt mit Memory-Seams, Store-Packs und Guardrails mehr Konfiguration ein, als der Anwendungsfall rechtfertigt. Vor der Übernahme ist zu prüfen, ob die im README gezeigten Signaturen für memory.seams, resumeFromCheckpoint und den Postgres-Store-Pack in der installierten Version tatsächlich exportiert werden, denn nur der Exportpfad entscheidet, ob der eigene Checkpoint-Store angebunden werden kann.

Offizielle Quellen

1. Deuz-AI/Deuz-SDK on GitHub
2. License: MIT
3. Project website
4. README
5. Releases