What's New in @dcyfr/ai: The v3 Line

The blog went quiet for a few months while engineering capacity shifted elsewhere. The package didn't. @dcyfr/ai, our AI agent harness, kept shipping the whole time, and the v3 line is the result: a major release that turned the harness from "config and providers" into an actual autonomous-agent runtime, then a steady run of security, transport, and tooling work on top of it. This post catches the changelog up. No deep dive, just an honest pass over what landed, grouped by theme, with what it means if you build on it.

The big one: v3.0 made it an agent runtime

The most important thing in the whole line is the first release in it. v3.0 is a major version, and it earns the bump.

Before v3.0, @dcyfr/ai was a solid base layer: a config system, a provider registry with fallback, telemetry, a plugin loader, and a delegation framework. Useful, but it stopped where the interesting part of agent work starts. v3.0 added the runtime pieces that let an agent actually run: remember things, hand off cleanly, and pause for a human when it should.

Three additions define the release.

Session Handoff Chain (@dcyfr/ai/session) replaces single-session handoff with a chain protocol. Multi-hop handoffs preserve conversation history across agent sessions instead of dropping context every time work changes hands. There's a createHandoffChain() factory and a typed HandoffContext snapshot that travels between sessions.

Requires-Confirmation workflow (@dcyfr/ai/delegation) adds a requiresConfirmation flag to the delegation contract and a ConfirmationWorkflow class. Tasks that need human approval enter a pendingConfirmation state and log a confirmation timestamp for the audit trail. This is the structural version of "humans own the what, the agent owns the how": a real gate, not a convention.

User Context Files API (@dcyfr/ai/context) loads workspace context files (about-me, brand-voice, and the like) with progressive disclosure: list what's available without loading it, then lazy-load individual files. Agents get personalized behavior without anyone hardcoding preferences into them.

Alongside those, a minor in the same release brought the Autonomous Agent Runtime, a set of tree-shakeable subpath exports that are the backbone of an unattended agent:

Subpath | What it gives you
@dcyfr/ai/memory | File-first persistent memory (Markdown), SHA-256 dedup, optional SQLite FTS5 hybrid search
@dcyfr/ai/compaction | LLM-powered context compaction + memory compaction (dedup, summarization, stale-fact archival)
@dcyfr/ai/skills | Dynamic skill injection with BM25 search over skill files and trust-level filtering
@dcyfr/ai/mcp | An MCP tool bridge that discovers server tools and adapts them to the runtime
@dcyfr/ai/session | Session manager with trust-level tool policies (full / sandboxed / readonly)
@dcyfr/ai/scheduler | Agent scheduler with a built-in cron parser, webhooks, and quiet hours
@dcyfr/ai/gateway | Platform-agnostic messaging gateway with input sanitization and rate limiting

These subpaths are the parts you'd reach for to build an agent that runs unattended on its own loop: observe, triage, think, act, record. Memory, scheduling, a trust-scoped session, a sanitizing gateway: that's the spine.

The one breaking change is small and optional: DelegationContract now carries an optional handoff_context field, so strict TypeScript consumers may see new optional-property warnings. Existing contracts stay valid. No APIs were removed. The version bump is about scope, not breakage. v3.0 is where the harness crosses from "set up an agent" into "run one over time."

The same release also did some honest naming work: @dcyfr/ai is now described as an AI agent harness (an infrastructure layer) rather than a "framework." Frameworks dictate your application's structure; a harness gives you the runtime pieces and stays out of the way. That's the more accurate description of what it actually is.

Hardening: security, transport, and tooling

Everything after v3.0 is the unglamorous, load-bearing work: the kind that doesn't make a launch graphic but is exactly what you want from a dependency you build production agents on. A few themes ran through the v3.1 → v3.3 releases.

MCP transport got real auth

The standout feature release here is v3.2.0: authenticated Streamable HTTP transport for FastMCP servers. If you're running MCP servers from the harness, you can now serve them over an authenticated HTTP transport rather than being limited to local stdio. That's the difference between "MCP server on my machine" and "MCP server something else can reach, safely."

Security and supply chain

Security work showed up steadily, and some of it mattered to downstream consumers directly:

v3.0.3 removed the unused @mistralai/mistralai dependency. It wasn't imported anywhere (only referenced in a description string) but its presence pulled in a malware advisory (GHSA-3q49-cfcf-g5fm) whose overbroad version range flagged safe installs too. Removing it cleared that alert for downstream projects, dcyfr-labs/dcyfr-labs included.

v3.0.5 strengthened the prototype-pollution sanitizer in the config loader.

v3.2.1 and v3.2.4 cleared static-analysis findings (CodeQL warnings and a batch of SonarCloud reliability bugs), and v3.3.0 / v3.3.1 resolved a CodeQL HIGH in generated config and tightened the version-export path.

v3.3.2 and v3.3.3 kept the run going, clearing a HIGH/MEDIUM undici advisory out of the transitive dependency tree (and fixing the bundled standalone-Next.js example's build along the way).

None of these are headline features. All of them are the reason you can trust the thing.

CLI and tooling

v3.2.2 repaired the published CLI bin layout and folded telemetry into @dcyfr/ai directly, simplifying what consumers install.

v3.3.0 added documentation-parity CI gates: automated checks that keep the package's docs, env example, and config reference in sync with the code, and that fix a stale VERSION export. Docs that can silently drift from the code are docs you eventually can't trust; these gates make drift fail CI instead.

The dependency-currency stream

Less visible but worth naming: a continuous run of dependency bumps across the line kept the runtime SDKs current: Anthropic, OpenAI, Google GenAI, LangChain, and the storage drivers among them, with majors like neo4j and redis moving to their 6.x releases. Each one is a one-line changelog entry. Together they're the difference between a package that ages well and one that quietly rots.

A feature you can build on is only as good as the maintenance under it. The v3.x line spent most of its commits on transport auth, supply-chain hygiene, static-analysis cleanup, and doc-parity gates. That's deliberate. The v3.0 runtime is the capability; everything since is making it safe to depend on.

What changed for you

If you build on @dcyfr/ai, here's the short version of what to do with all this.

Upgrading to v3 is low-risk. No public APIs were removed across the v3.0 jump. The single breaking change is the new optional handoff_context field on DelegationContract. Existing contracts keep working, and strict-mode consumers may see new optional-property warnings, nothing more.

New power is opt-in. The agent-runtime capabilities ship as tree-shakeable subpath exports (@dcyfr/ai/memory, /scheduler, /session, and the rest). Import only what you use; your bundle doesn't pay for the parts you don't.

If you run MCP servers, look at v3.2.0. Authenticated Streamable HTTP transport is the upgrade that lets you serve FastMCP servers beyond local stdio without giving up access control.

If you consume the package downstream, the security fixes are free wins. The mistral-dep removal and prototype-pollution hardening clear real alerts; pulling them in is just an upgrade.

Pin to the current v3.x line. That's where the active work (features and fixes) lives.

Install: npm install @dcyfr/ai@latest to land on the current v3.x release.

Breaking change to know: DelegationContract gained an optional handoff_context?: HandoffContext. If you're on TypeScript strict mode, expect new optional-property hints. No code change is required for existing contracts.

Adopting the runtime: the agent-runtime features are additive subpath exports. Existing AgentRuntime usage is backward compatible; you opt into memory, scheduling, sessions, and the gateway as you need them.

MCP servers: if you serve FastMCP, evaluate moving to the authenticated Streamable HTTP transport added in v3.2.0.

Current latest is 3.3.3. @latest lands you on the most-patched release. v3.3.2 and v3.3.3 are pure hardening on top of v3.3.1: an undici advisory cleared from the transitive tree, no consumer-facing API changes, so there's nothing new to adopt beyond the security wins.

What's next

A few directions I want to be honest about rather than promise hard dates for.

More on the runtime in practice. The v3.0 subpaths are the toolkit; an upcoming series covers how they fit together. Part 2 walks the autonomous-daemon architecture, with the security and cache-economics pieces following it.

Keeping the doc-parity discipline. The v3.3.0 gates are the floor, not the ceiling. The goal is that the published docs are never ahead of or behind the code that ships.

Steady currency over big swings. Expect the dependency stream and the security cleanup to keep going. For a package other projects build on, "boringly current and well-patched" is a feature.

If you want the unabridged version, the CHANGELOG has every entry, and the package page has the current overview.