Why we built Anvia

On May 3, 2026, we opened the first public preview of Anvia. It was small, but the shape of the company we wanted to build was already there: practical infrastructure, developed in the open, that gives product teams more control rather than less.

The important part was not the number of features. It was the boundary around them.

Anvia would own the mechanics of an agent run. Your application would continue to own its data, permissions, persistence, and side effects. We wanted useful runtime primitives without asking teams to move their product into somebody else's framework.

Start with ownership

Our first example looked like ordinary TypeScript. A model adapter, a typed tool, and an agent builder were enough to make a complete tool-using loop.

const lookupOrder = createTool({
  name: "lookup_order",
  description: "Look up an order by id.",
  input: z.object({ orderId: z.string() }),
  execute: async ({ orderId }) => ({
    orderId,
    status: "processing",
  }),
})

const agent = new AgentBuilder("support", model)
  .instructions("Help customers with order questions.")
  .tool(lookupOrder)
  .defaultMaxTurns(4)
  .build()

const response = await agent
  .prompt("What is happening with order A123?")
  .send()

There is no hidden application container in that example. The tool is a function a team can test. The schema is visible. The model can be replaced.

That clarity became our standard for the packages that followed—and for how we decide what belongs in Anvia at all.

Why provider choice matters to us

We do not think a product's architecture should be determined by whichever model was selected first. Providers change quickly, and the right model for one workflow may be wrong for another. Portability matters, but only if it leaves room for providers to be themselves.

Anvia normalizes the parts that an application needs to depend on—messages, streaming events, tool calls, usage, and errors—while adapters can still expose provider capabilities.

This is why the runtime and provider integrations live in separate packages. The core contract stays stable while OpenAI, Anthropic, Gemini, and other providers evolve at their own pace.

Build the runtime, not the product

Agent frameworks can become architecture by accident. A convenient abstraction starts making decisions about storage, routes, queues, and UI until the application is built around the framework instead of the other way around. We did not want Anvia to become another application teams have to build inside.

We chose a narrower job for Anvia:

• Coordinate models, tools, and multi-turn execution
• Keep runtime events typed and observable
• Make structured extraction and pipelines composable
• Let applications bring their own persistence and product rules

That choice is still visible in every later release. Memory is implemented through store contracts. UI state travels through an explicit protocol. Evaluation results have reporters instead of a mandatory backend.

What opening the preview changed

The public preview was not a finished answer. Opening it gave us a foundation we could test alongside the people using it. Once teams started pushing images through tools, rendering live runs in React, persisting longer conversations, and comparing model behavior between releases, the next problems became obvious.

The five stories in this journal follow that path. Each release adds a capability, but more importantly, it reflects the kind of company we are trying to build: close to the work, honest about tradeoffs, and committed to keeping product ownership with our users.

Read the core package documentation and source changelog, or inspect the initial public preview.