Anvia 1.0 enters release candidate

Today we are releasing Anvia 1.0.0-rc.3, the current release candidate for Anvia v1.

Update, 23 August 2026: Anvia 1.0 is now stable. This article preserves the RC3 milestone and the reasoning behind the v1 architecture.

At the time of this announcement, Anvia v0 remained maintained while teams tested the v1 release candidate. New projects could start on the RC contracts that have since become stable in Anvia 1.0.

This is more than a new version number. It is the point where the runtime contracts we want teams to build on are complete enough to test as one system: agents, models, tools, memory, retrieval, streaming, React, Studio, observability, and evaluation now move together as a synchronized package train.

The release candidate is also a promise about direction. Anvia should make agent execution predictable without taking ownership away from the application. Reaching that boundary required us to change some familiar APIs, including APIs we originally liked.

Why we changed the runtime

The first Anvia releases optimized for getting an agent running quickly. AgentBuilder, prompt request objects, and .send() made a good first experience, but the abstraction became less honest as the runtime grew.

An agent run can now stream, use durable memory, call tools, pause for a person, resume in another process, emit traces, and appear in multiple interfaces. Hiding that lifecycle behind builders and intermediate request objects made ownership harder to see. Different packages also began expressing the same run in slightly different ways.

For v1, we chose explicit boundaries over accumulated convenience:

• Stable behavior belongs in a declarative Agent configuration.
• A run begins directly with generate() or stream().
• Every terminal result is completed, blocked, or suspended for an interaction.
• Provider, memory, transport, and observer lifecycles have visible owners.
• Messages and continuations crossing a network boundary are validated and JSON-safe.
• Packages that share runtime contracts are released at matching versions.

The result is a smaller mental model even though the runtime can do more.

The v1 shape

The main path now looks like ordinary TypeScript:

import { Agent } from '@anvia/core'
import { OpenAIClient } from '@anvia/openai'

const client = new OpenAIClient({
  apiKey: process.env.OPENAI_API_KEY!,
})

const agent = new Agent({
  id: 'support',
  model: client.completionModel({
    modelId: 'gpt-5.6-sol',
    api: 'responses',
  }),
  instructions: 'Answer support questions clearly.',
  maxTurns: 4,
})

const result = await agent.generate({
  prompt: 'Draft a reply for this customer.',
})

if (result.status === 'completed') {
  console.log(result.output)
}

There is no build phase and no prompt request waiting to be sent. The configured agent is the reusable runtime object; the input to generate() is one execution.

That same shape continues as features are added. Tools, context, memory, middleware, and observers are visible in the agent options. Per-run session and limit choices are visible at the execution boundary. Streaming uses the same final result contract instead of inventing a parallel one.

Human decisions are now real runtime state

RC3 completes one of the most important parts of that model: interactions.

An approval or structured question no longer depends on a callback living inside one Node.js process. The run returns a suspended result with a public interaction request and a JSON-safe continuation. Trusted server code can persist that continuation, wait for an authenticated response, and start a linked phase through generate() or stream().

This matters because production decisions rarely happen inside one request. A person may respond from React, Studio, or another service minutes later. The process that began the run may no longer exist. Anvia now preserves that boundary through memory, traces, nested agents, resumable streams, and Client Protocol v3.

The benefit is not only human-in-the-loop support. It is a runtime that tells the truth when work has paused and gives applications an explicit place to enforce identity, authorization, expiry, and atomic claims.

New capabilities without a larger core

The release candidate also adds two packages that demonstrate the v1 package model.

@anvia/browser provides a Docker-backed Chromium runtime with semantic browser tools, a noVNC desktop, Studio integration, and coordinated human control. Browser execution stays an explicit tool capability instead of becoming an invisible privilege of every agent.

@anvia/neo4j adds schema-first GraphRAG with document-scoped graph writes, entity and chunk embeddings, vector and hybrid retrieval, bounded traversal, provenance-linked evidence, and an agent graph-search tool. Applications keep control of their schema and database lifecycle while agents receive a focused retrieval surface.

Both packages are substantial capabilities. Neither required turning Core into a browser framework or a graph database abstraction. That is exactly the architecture we want v1 to protect.

What changes for existing applications

Existing v0 applications do not need to migrate immediately to keep receiving maintenance and bug fixes. When a team is ready to adopt v1, the move is an intentional migration. The largest visible changes are:

• Replace AgentBuilder with new Agent({ ... }).
• Replace .prompt(...).send() with agent.generate({ prompt }) or agent.stream({ prompt }).
• Handle completed, blocked, and suspended results explicitly.
• Configure provider model handles with object options and explicit model IDs.
• Move tools, context, memory, MCP registrations, and observers to their documented v1 boundaries.
• Update every Anvia package together; do not mix v0 packages with the v1 RC train.

The release candidate line may still contain migration work before stable 1.0. Pin exact RC versions in production-like environments and test the full application boundary: types, tools, memory, transports, traces, resumability, and evaluations.

That is real work. We believe it pays back by removing implicit state and package-specific exceptions that would otherwise become harder to change after 1.0.

Why this is a great foundation

The best part of this release is not one new adapter. It is that the pieces now agree.

An agent has one configuration model. A run has one entry point and one set of terminal states. Direct and streamed execution preserve the same identity and results. React and Studio consume the same client protocol. Memory and observers see suspensions instead of losing them. Providers remain replaceable behind explicit capability handles. New tools such as Browser and Neo4j compose without changing the runtime's ownership boundary.

That consistency makes code easier to understand, but it also makes systems easier to operate. Failures are attributable. Human decisions can be resumed safely. Traces can connect linked phases. Applications can decide where data lives and which side effects are allowed.

This is what we wanted the Anvia 1.0 release candidate to prove: a production agent runtime can become more capable without becoming the application around it.

Install the stable packages with pnpm add @anvia/core @anvia/openai, follow the v1 quickstart, review the migration boundary, and read the package changelogs. For newer capabilities, explore @anvia/browser and @anvia/neo4j.