Deuz SDK: Durable Memory, Compaction and Checkpoints for TypeScript Agents
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.
At a glance
- What is it?
- Deuz SDK is an MIT-licensed, zero-runtime-dependency TypeScript framework that bundles long-term memory, context compaction, crash-resumable checkpoints and MCP tool calling behind one streaming API. The interesting part is not the provider list; it is the decision to make clock, randomness, fetch and keys injected rather than ambient.
- Who is it for?
- Adopt Deuz SDK if you are already writing the surrounding machinery yourself: memory extraction and reconciliation, compaction on a long run, checkpoints in your own Postgres or Redis, and MCP OAuth. Skip it if your agents are single-turn calls with no persistence, because the seam injection and store configuration cost more than they return.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 34 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Deuz SDK targets: everything after the model call
The README opens with a claim worth taking literally: calling a model is a solved problem, and what is not solved is everything around it. The listed items are remembering a user across sessions, staying inside a context window on turn forty, asking a human before an irreversible action, resuming after the process dies mid-run, and connecting a tool server without hand-rolling OAuth. That list is the product definition. Deuz SDK is aimed at engineers who already have a working prototype and are now hitting the second set of problems, the ones that appear when a run lasts longer than a single request or outlives a single process.
The audience implied by the install instructions is narrower than the topic list suggests. Node 22 or any edge runtime with fetch is the floor, and the optional peers (zod or another Standard Schema library, the MCP SDK, react, pg or redis, unpdf, mammoth, xlsx, playwright, OpenTelemetry) tell you the framework expects you to already know which of these you need. This is not a framework for someone writing their first agent. It is for someone who has written the memory pipeline once, badly, and does not want to write it again.
One canonical delta stream, and why that choice carries the rest
The README states the design rule directly: normalize provider bytes to a canonical delta stream first. Everything downstream (retry, failover, resume, budgets, sub-agents, typed UI events) then operates on one representation rather than per-provider branches. The README's own sentence about this is cut off mid-word in the supplied material, so the full consequence is not documented here, but the shape of the argument is clear enough: if the stream is canonical before any feature touches it, those features do not need to know which provider produced the bytes.
The README claims 28 chat providers across four wires. Four wires for 28 providers is the concrete payoff of normalizing early: provider-specific code is confined to adapters, and the feature surface above it is written once. Whether that holds for every provider is not something the README demonstrates, and a provider whose streaming semantics do not map cleanly onto the canonical delta type would be where the abstraction leaks. That is the thing to probe if you depend on an unusual model.
The second structural decision is dependency injection of the ambient surface. Clock, randomness, fetch, keys and logging are all injected, with zero runtime dependencies in @deuz-sdk/core. The stated benefit is that the same code runs on Node, Bun, Deno and the edge, and that tests stay deterministic. The second half is the more interesting claim: a framework that reads the clock and calls fetch directly is hard to test without global stubbing, and injecting both is what makes deterministic tests possible rather than aspirational.
Memory as a pipeline, not a message array
The README is explicit that the memory feature is not a message array. It describes a pipeline that extracts durable facts from a conversation, reconciles them against existing knowledge using add, update or delete rather than blind appends, scores them for importance, expires them, and recalls relevant ones on the next call. The reconciliation step is the part that separates this from naive vector-store stuffing: appending every extracted fact eventually produces contradictions, and the README's design acknowledges that by making deletion a first-class operation.
The configuration surface is shown in the README example. The memory key takes a seams object with store, embedder and llm, a scope with userId, a recall object with topK, maxChars and expandLinks, and a writePolicy set to 'each-turn'. Those five knobs are where the behaviour actually lives. topK of 6 with maxChars of 2000 is a budget decision, not a relevance decision, and expandLinks of 1 means a recalled fact can pull in one linked neighbour. writePolicy 'each-turn' means extraction runs on every turn, which is a cost decision the README does not quantify.
The storage options are stated as a vector store, a Postgres table or an Obsidian vault, and the README separately lists SQLite, Redis and Postgres packs behind the memory, chat, session and run seams. An Obsidian vault as a memory backend is an unusual choice and the README does not explain the read and write path for it, so treat that option as underdocumented in the supplied material.
Compaction, and the retry that happens when it is not enough
Compaction is enabled with a single option: compaction: 'auto' alongside maxSteps. The README describes what it does when the window fills: prune stale tool output, drop old reasoning, and fold the earliest turns into a single running summary that gets updated rather than a stack that grows. The distinction between an updated summary block and an accumulating stack of summaries matters for context accounting, because the former has a bounded size and the latter does not.
The more consequential behaviour is the failure path. When a provider rejects a request as too long anyway, the loop force-compacts and retries that step instead of failing the run. This is a recovery mechanism for the case where the framework's own estimate of the window was wrong, which is the realistic case when providers change limits or when a single tool result is enormous. The README does not state how many times the loop will force-compact before giving up, and that bound is worth knowing before you rely on it for a long-running job.
Compaction interacts with the memory pipeline in a way the README does not address. If old turns are folded into a summary while the memory pipeline is extracting durable facts on each turn, the two mechanisms are both deciding what survives. The README presents them as separate features and does not describe how they coordinate, so the interaction is unverified here.
Getting it running: install, providers, stores and the agent skill
Install is two commands. npm install @deuz-sdk/core for the runtime, and npm install @deuz-sdk/react if you want useChat, useObject and the headless UI. The README's provider example imports createAnthropic from the @deuz-sdk/core/anthropic subpath and passes apiKey. The streaming call is streamChat, which the README says returns synchronously and never throws, with failures arriving as typed stream parts. You consume res.textStream and await res.usage separately.
The full example in the README shows the shape of a production call. It imports generateText and handoff from @deuz-sdk/core, promptInjectionGuardrail and maxOutputLength from @deuz-sdk/core/guardrails, and createPostgresStores from @deuz-sdk/core/stores/postgres. The call passes maxSteps: 8, a tools object built from handoff({ billing, support }) plus search, a guardrails object with onInput and onOutput, an mcp array containing a URL, a chat object with store, chatId and scope, a session object with store and runId, and a runtimeContext carrying tenantId and db. The README's comment on runtimeContext is that it travels with the call rather than being a per-request closure.
For agents that read code, npx skills add Deuz-AI/Deuz-SDK installs two Agent Skills. The README describes them as gated rather than merely written: every @deuz-sdk symbol is resolved against the real export table on every commit, every code example is compiled against the built package, and a freshness check fails when the version or the locked API contract moves. The README also reports that nine build tasks were given to agents without the skill first, producing 19 imaginary imports across 8 of 9 answers. That is the README's own account of its motivation, not an independent measurement.
Where the framework gets in the way
The injection model is the largest constraint. Because clock, randomness, fetch, keys and logging are all injected, you cannot drop this into an existing codebase that assumes global fetch and expect the same behaviour. The README presents injection as the reason the same code runs across Node, Bun, Deno and the edge, which is true, but it also means every seam you use has to be wired. The memory example alone requires a store, an embedder and an llm.
Zero runtime dependencies in core does not mean zero dependencies in practice. The optional peer list is long, and the postgres example pulls in pg through createPostgresStores. If you use memory, chat, session and run seams together against Postgres, you are maintaining a database schema that the framework expects. The README does not describe migrations for those tables in the supplied material.
The provider count is a surface-area claim, not a compatibility guarantee. Four wires covering 28 providers means some providers are almost certainly mapped onto a wire that does not match their native semantics exactly. If you are using a model with unusual tool-calling or streaming behaviour, verify it against the export table rather than assuming parity.
Finally, the README's own framing sets an expectation: this is infrastructure on the road, a vehicle and not the destination. That is an honest statement, and it also means the framework is not trying to solve the agent design problem for you. Planning, CodeAct sandboxes and verifyStep are shipped, but the README does not describe their failure modes.
Against the Vercel AI SDK, and what the migration path implies
The README links a migration document titled Coming from the Vercel AI SDK, and describes a second Agent Skill called migrate-from-ai-sdk as the verified name-by-name port from ai and @ai-sdk/*. That framing tells you the intended comparison. The Vercel AI SDK gives you generateText and streamText with provider adapters; Deuz SDK's README positions its two differentiators as memory that outlives the session and compaction that keeps a long run alive, with durable checkpoints, guardrails and MCP OAuth as supporting features.
The practical difference is where state lives. In the Vercel AI SDK model, a long run is your problem: you persist messages, you decide when to trim, you handle the crash. Deuz SDK puts step checkpoints in your database and offers resumeFromCheckpoint later, with the README explicitly noting there is no workflow vendor involved. That is a real architectural difference, not a naming one, and it is the reason the migration is described as name-by-name rather than conceptual.
The cost of the difference is coupling. If you adopt the memory, chat, session and run seams, your database schema becomes part of your framework dependency. Migrating away from Deuz SDK later means migrating that state. The README does not discuss export or migration paths for the stored data.
Licence, upgrade surface and what to check before adopting
The licence is MIT, and the npm badge in the README points at the same. MIT permits commercial use and modification with attribution and no warranty. That is the whole of what can be said here; nothing in the supplied material suggests dual licensing, a contributor agreement or a commercial tier, but the absence of a stated CLA is not the same as the absence of one.
The upgrade surface is visible in the version history. v2.0.0 landed on 2026-08-10, three days after v1.9.0 on 2026-07-28, and v1.8.0 was labelled Autonomous Agent Runtime on 2026-07-22. Three minor or major releases in under a month, with a major version bump at the end, is a fast-moving API. The README's freshness check for the Agent Skills, which fails when the version or the locked API contract moves, is a signal that the maintainers expect the contract to move and have built tooling around that expectation.
What to verify first, concretely. Check that the subpaths you plan to import exist in the current export table, since the README claims 53 subpaths and the skill is gated against them. Confirm which store pack matches your database, since the README lists SQLite, Redis and Postgres and the example uses createPostgresStores. And if you are on a model that is not Claude, GPT, Gemini, Grok, Mistral or DeepSeek, confirm which of the four wires it maps to before you build on it. Those three checks are cheap and they cover the places where the README's claims are broadest.
Editorial conclusion
Adopt Deuz SDK if you are already writing the surrounding machinery yourself: memory extraction and reconciliation, compaction on a long run, checkpoints in your own Postgres or Redis, and MCP OAuth. Skip it if your agents are single-turn calls with no persistence, because the seam injection and store configuration cost more than they return. Before committing, verify the export table for the subpaths you need, confirm which store pack matches your database, and check that the provider wire for your model is among the four the README describes. The migration skill, if you are coming from the Vercel AI SDK, is the cheapest way to see how much of your current code has a name-by-name equivalent.
Community notes