Zypher Agent: a TypeScript agent loop with git checkpoints and MCP built in
A minimal yet powerful framework for creating AI agents with full control over tools, providers, and execution flow.
At a glance
- What is it?
- Zypher Agent is a Deno-first TypeScript framework for building LLM agents that decide their own next steps, ship file and terminal tools by default, and record each run as a git checkpoint. It is a reasonable fit if you want the agent loop exposed rather than hidden behind a hosted abstraction.
- Who is it for?
- Adopt Zypher Agent if you are already on Deno or willing to be, you need MCP servers with OAuth in the same process as your tools, and you want the execution loop visible in your own code rather than owned by a hosted runtime. Do not adopt it if you need npm today, if your deployment target is a Node-only serverless runtime, or if you want a managed service that handles provider failover for you.
- Can I use it commercially?
- Yes. Apache-2.0 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 48 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 problem Zypher Agent is aimed at
Most agent frameworks make a choice for you: either the loop is a black box behind an API call, or you assemble the loop yourself from a model client, a tool dispatcher, and a message history. Zypher Agent sits in between. The README describes it as a reactive loop where the agent decides its next steps from LLM reasoning, as opposed to a workflow where you predefine the sequence. That distinction matters in practice. A workflow is debuggable because the graph is fixed. A reactive loop is more flexible and harder to reason about, so the framework has to give you something back for the lost predictability. Zypher's answer is the checkpoint system and the interceptor hooks. The intended audience is a TypeScript developer who is comfortable reading a Deno codebase and who wants to own the tool layer. If you are looking for a no-code agent builder, this is not it. The quick start is a code block, not a UI, and the primary install path is a JSR import.
What the execution loop actually does
The entry point in the README is createZypherAgent, which takes an object with a model string, a tools array, and an mcpServers array. That object is the whole configuration surface shown in the quick start. The agent then exposes runTask, which accepts a natural language task and returns a stream. The README example consumes it with eachValueFrom from rxjs-for-await, which tells you the return value is an RxJS Observable rather than an async generator. That is a real design decision with consequences. You get RxJS operators for free, so you can debounce, retry, or merge event streams without writing that plumbing. You also take on the RxJS mental model and the rxjs-for-await shim if you want for-await syntax. The stream emits events, and the example simply logs them. The README does not enumerate the event types, so if you need to branch on a specific event kind you will be reading the API reference at jsr.io/@zypher/agent/doc rather than the README. The loop itself is described as reactive and post-inference interceptors are the documented extension point, which suggests the flow is: model call, then interceptor chain, then tool dispatch, then back to the model. That ordering is inferred from the feature list, not stated step by step in the README, so treat it as a hypothesis to confirm in the source.
Git checkpoints as the safety mechanism
The checkpoint feature is the most distinctive item in the feature list. The README says the framework can track, review, and revert agent changes, and the release history includes a separate ui package at v0.3.3 alongside the agent package at v0.9.5. The existence of a UI release line implies a companion surface for inspecting those checkpoints, though the README does not describe it. What the README does not say is how checkpoints interact with your existing repository state. If the agent commits to your working branch, you inherit its commit messages and its history. If it uses a separate ref or a stash-like mechanism, the review flow is cleaner. This is the first thing to check before running the agent against a repository you care about. The feature is genuinely useful for the reactive-loop model: because the agent chooses its own steps, you cannot predict the diff, so a revert point is the practical substitute for a fixed workflow graph. But a checkpoint system that writes to git is also a system that can conflict with your own git operations, and nothing in the README addresses concurrent use or merge conflicts.
Tools, MCP servers, and providers
Tools come from createFileSystemTools, imported from the @zypher/agent/tools subpath, and the README says the set covers file operations, search, and terminal commands. Spreading that call into the tools array is the documented pattern. Custom tools are mentioned as supported but not demonstrated in the README. MCP support is configured through the mcpServers array, which in the example contains a single string naming a server package. The feature list adds that MCP servers get OAuth authentication. That combination is more than most minimal frameworks offer: a string-based server reference plus OAuth handling means you can point at a remote MCP endpoint that requires a token without writing the auth flow yourself. On providers, the README names Anthropic Claude and OpenAI GPT behind a unified interface, and the example model string is claude-sonnet-4-5-20250929. The comment next to it notes that ModelProvider exists for advanced options, but the README does not document that API. If you need per-provider tuning, base URLs, or custom headers, plan on reading the API reference. The unified interface is real, but the README only proves it for one provider.
Getting it running
Installation is Deno-only for now. The README carries a note that npm support is coming soon, and the documented command is deno add jsr:@zypher/agent. The package is published to JSR, and the README links the JSR badge and the generated docs at jsr.io/@zypher/agent/doc. There is no npm install line, no package.json snippet, and no bundler configuration in the README. That is the single biggest adoption constraint, and it is stated plainly rather than buried. After install, the minimal program is the quick start block: import createZypherAgent from @zypher/agent, import createFileSystemTools from @zypher/agent/tools, import eachValueFrom from rxjs-for-await, construct the agent with model, tools, and mcpServers, call runTask with a task string, and iterate the events. There are no environment variable names, no config file format, and no CLI in the README. Credentials for the model providers are not described, so you will need the provider's own documentation for that. The configuration keys visible in the material are exactly three: model, tools, mcpServers.
Where this design will bite you
The Deno dependency is the obvious one. If your application runs on Node, the README gives you no path today, only a promise of npm support. Even with a compatibility layer, the JSR-first packaging and the RxJS event stream mean you are testing a combination the maintainers have not documented for Node. The second issue is the reactive loop itself. A loop that decides its own next steps is harder to cost-control than a fixed pipeline, because the number of model calls depends on what the model decides to do. The feature list mentions configurable timeouts and concurrency protection, which suggests the maintainers know this, but the README does not show the configuration keys for either. You cannot estimate a per-task budget from the README alone. Third, the interceptor system is described as post-inference only. If you need to inspect or modify the prompt before the model call, the documented hook point does not cover that. Fourth, the version numbers tell a story: agent is at 0.9.5 with two patch releases on the same day in February, and the UI package is at 0.3.3. Pre-1.0 across both lines means API churn is a real possibility, and the README does not include a stability statement.
How it differs from LangGraph and the Vercel AI SDK
The closest comparison in the TypeScript ecosystem is LangGraph, which also targets stateful agent execution but takes the opposite stance on control flow. LangGraph asks you to define a graph of nodes and edges, so the execution path is a structure you author and can render. Zypher asks you to hand a task to a loop and react to the event stream. If you need to prove to an auditor or a teammate exactly which steps ran, a graph is easier to defend. If your tasks are open-ended and the right sequence is not knowable in advance, the reactive loop avoids the graph-authoring overhead. The other comparison is the Vercel AI SDK, which is provider-agnostic and npm-native, and whose tool-calling primitives are widely used in Next.js applications. The AI SDK gives you the model call and tool plumbing but leaves the agent loop and the checkpointing to you. Zypher bundles those, at the cost of the Deno install path. MCP support is the area where Zypher's positioning is clearest: the README treats MCP servers as a first-class configuration array with OAuth, rather than an add-on you wire up manually.
Maintenance, releases, and the Apache-2.0 terms
The repository is not archived and the last push is dated 2026-07-30, with the most recent agent release at v0.9.5 from February 2026 and a UI release at v0.3.3 from March 2026. That is an active but not fast-moving release cadence, and the gap between the last tagged agent release and the last push suggests work is landing on main between tags. For upgrade cost, the practical concern is the pre-1.0 version number on both packages. A 0.9.x to 0.10 could change the createZypherAgent options object or the event shape, and since the event types are not enumerated in the README, a silent change there would be easy to miss. Pin your JSR dependency and read the release notes before bumping. On licensing, the project is Apache-2.0, which permits commercial use and modification and includes an express patent grant. Apache-2.0 also requires that you preserve the license and notice files and state significant changes if you redistribute a modified version. If you embed the agent in a product you ship, that attribution obligation travels with it. This is a description of the license text, not legal advice; have counsel review it if the distinction matters to your distribution model.
Editorial conclusion
Adopt Zypher Agent if you are already on Deno or willing to be, you need MCP servers with OAuth in the same process as your tools, and you want the execution loop visible in your own code rather than owned by a hosted runtime. Do not adopt it if you need npm today, if your deployment target is a Node-only serverless runtime, or if you want a managed service that handles provider failover for you. Before committing, verify three things against the documentation: that the git checkpoint mechanism behaves correctly in a non-git working directory, that the loop interceptor API is stable across the 0.9.x line, and that the JSR package resolves cleanly under your Deno version.
Community notes