Zypher Agent: a reactive agent loop with git checkpoints, still JSR only

The loop decides its own next step instead of following a declared graph

The framing difference from most agent libraries is the first thing to understand. Zypher Agent describes itself as an agent rather than a workflow: a reactive loop where the agent chooses the next step based on model reasoning, not a sequence you drew out in advance. Nothing in the setup call asks you to enumerate stages, and nothing in the returned handle lets you inspect a planned sequence afterwards.

What you configure is the surface the loop runs against. `createZypherAgent` takes a model, a tool list, and MCP servers; the model is a string in the quick example, with a ModelProvider option described for advanced cases. Tooling comes from `@zypher/agent/tools`, where `createFileSystemTools()` supplies file operations, search, and terminal commands, and custom tools are supported alongside the built-in set.

The operational guardrails sit next to that: configurable timeouts, concurrency protection, and error handling are listed as part of the production posture rather than left to the caller.

runTask returns an event stream you drain yourself

The quick example does not await a final answer. `agent.runTask` returns task events, and the caller consumes them with `eachValueFrom` from `rxjs-for-await`, logging each one as it arrives. That is a real dependency, and it is not in the framework: your application pulls an rxjs helper to iterate a stream the agent produced.

import { createZypherAgent } from "@zypher/agent";
import { createFileSystemTools } from "@zypher/agent/tools";
import { eachValueFrom } from "rxjs-for-await";

const agent = await createZypherAgent({
  model: "claude-sonnet-4-5-20250929", // Or use ModelProvider for advanced options
  tools: [...createFileSystemTools()],
  mcpServers: ["@modelcontextprotocol/sequentialthinking-server"],
});

// Run task with streaming
const taskEvents = agent.runTask("Implement authentication middleware");

for await (const event of eachValueFrom(taskEvents)) {
  console.log(event);
}

Two details in that snippet carry weight. The MCP server is named as a package string in an array, so servers are resolved by reference rather than configured inline. And the task is passed as a plain sentence, `Implement authentication middleware`, which is the whole input contract the quick start shows.

Checkpoints are git objects, so rollback means reverting

Checkpoint management is built in, and the mechanism named is git. The stated capability is to track, review, and revert agent changes, which puts a version control system between the loop and your working tree. For an agent that edits files, that is a legible audit trail: the diff that the agent produced is something you read before deciding to keep it.

The cost is that the granularity of a revert is whatever git gives you, and the framework does not describe a finer mechanism in the quick start. If an agent made ten edits across five files and only three are wrong, the built-in story is a revert, not a partial undo.

It also means git has to be a real dependency of the deployment, not just of the repository checkout. The repository ships a `CLAUDE.md` and a `.github/` directory alongside `deno.json` and `deno.lock`, so the project expects to be worked on as a real codebase rather than dropped into a scratch directory.

Loop interceptors sit after inference, not before it

The interceptor system is positioned specifically as post-inference. Extensible interceptors customize agent behavior after a model response comes back, which places them on the output side: shaping what the loop does with what the model produced, not rewriting the request before it is sent.

That position makes them the place to add approvals, redaction, or output shaping without wrapping the provider call. It also means they cannot stop the request from being billed or from reaching the model.

The repository ships a dedicated example for this, `examples/loop_interceptor.ts`, alongside `examples/http_error_handling.ts` for transport failures and `examples/coding.ts`. Since the README does not document the interceptor API in prose, the example file is where the actual shape of a custom interceptor has to be read.

MCP servers arrive with OAuth, and the registry points at CoreSpeed

MCP support is native rather than bolted on, and it includes OAuth authentication. Servers are passed as package references in the `mcpServers` array, and the registry behind that resolution is configurable.

The `.env.example` file spells out the variable: `MCP_STORE_BASE_URL`, marked optional, described as an override for private registries, with `https://api.corespeed.ai` as the default. So by default server resolution goes through a CoreSpeed service, and self-hosting that step means setting the variable yourself.

The same file carries a second, larger group of credentials that the quick example never touches: `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY`, `S3_REGION`, `S3_BUCKET_NAME`, plus optional `S3_ENDPOINT` and `S3_CUSTOM_DOMAIN`. The endpoint note is specific about both targets, giving the R2 shape as `https://<account-id>.r2.cloudflarestorage.com` and stating that for S3 the endpoint is generated automatically.

JSR is the only install channel, and two packages version apart

Installation is one line, and the channel note above it is worth reading first:

deno add jsr:@zypher/agent

The note directly above that block says support for npm is coming soon. For a framework meant to live inside applications, that is the constraint that matters most in practice, since npm remains the default assumption for a TypeScript project.

The releases make the same point about maturity. The agent package is published separately from the ui package, and its recent tags are `agent/v0.9.5` and `agent/v0.9.4`, both from 2026-02-08, while `ui/v0.3.3` landed on 2026-03-04. Two independent trains at 0.x means the agent and ui pieces do not share a version number, and pinning one tells you nothing about the other. The last push on the repository is dated 2026-07-30, and the project is not archived.

Editorial conclusion

Zypher Agent fits a Deno codebase that wants an agent embedded in the application rather than a separate workflow runner, and that already reaches its model through Anthropic or OpenAI keys. Check three things first: that JSR is an acceptable install channel given npm support is still listed as coming soon, that the agent package version you pin is a 0.9.x tag while the ui package versions separately, and that you can accept checkpoints as the rollback mechanism instead of a database. Before trusting the production framing, read the examples directory, which is where the http_error_handling.ts and loop_interceptor.ts cases are actually demonstrated.

Frequently asked questions

Official sources

1. corespeed-io/zypher-agent on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases