Introduction
Anvia is a TypeScript runtime for building provider-agnostic agents and SDK-owned AI workflows.
Anvia is a TypeScript SDK for building agents, tools, structured extraction, retrieval, pipelines, and observability inside your application code.
It is designed for teams that want more structure than raw model calls without giving up ownership of data, permissions, persistence, deployment, and side effects.
Core Primitives
| Primitive | What it does | Start here |
|---|---|---|
| Client | Configures provider access, credentials, base URLs, and provider SDK wiring | Clients and Models |
| Model | Provides a reusable completion or embedding capability | Clients and Models |
| Agent | Runs prompts with instructions, context, tools, hooks, turn limits, and output schemas | Agent Builder |
| Tool | Exposes typed application-owned behavior to agents | Creating Tools |
| Extractor | Converts unstructured text into schema-shaped data | Extractors |
| Pipeline | Composes functions, agents, extractors, and parallel branches | Pipeline Builder |
| Vector Store | Stores and searches embedded documents for retrieval workflows | Vector Stores |
| Observer | Records runs, generations, tool calls, usage, and traces | Observers |
The Basic Shape
Most Anvia workflows follow the same shape:
- Create a provider client.
- Create a reusable model.
- Build an agent around that model.
- Prompt the agent from application code.
- Add tools, history, context, structured output, retrieval, or tracing as the workflow grows.
import { AgentBuilder } from "@anvia/core";
import { OpenAIClient } from "@anvia/openai";
const client = new OpenAIClient({ apiKey });
const model = client.completionModel("gpt-5");
const agent = new AgentBuilder("support", model)
.instructions("Answer support questions clearly and concisely.")
.build();
const response = await agent.prompt("How do I reset my password?").send();
console.log(response.output);Why Anvia
Anvia keeps the runtime small and explicit:
- TypeScript-first APIs and Zod-backed validation
- provider-agnostic model, message, tool, and streaming shapes
- application-owned side effects through tools
- clear boundaries between clients, models, agents, and requests
- testable workflows that can use fake completion models
- optional layers for MCP, skills, retrieval, tracing, and Studio
The SDK does not need to own your database, auth system, queue, retries, or deployment. Keep those in your product code and pass only the model capabilities, context, and tools a workflow needs.
Capabilities
| Capability | Use it when | Docs |
|---|---|---|
| Agents | You need a promptable runtime with instructions, tools, context, and history | Agents |
| Tools | The model needs to call application-owned behavior | Tools |
| History | You need multi-turn conversation state | Messages and History |
| Structured Output | You need schema-shaped data instead of free-form text | Structured Output |
| Pipelines | You need explicit workflow composition | Pipelines |
| Retrieval | You need embeddings, vector search, or dynamic context | Retrieval |
| MCP | You need to connect Model Context Protocol servers | MCP |
| Streaming | You need incremental text, tool, and final events | Streaming Events |
| Observability | You need run, generation, tool, usage, and trace events | Observers |
Where To Start
Choose the path that matches what you are building:
| Goal | First page | Then read |
|---|---|---|
| Run your first agent | Getting Started | Build an Agent |
| Understand the SDK shape | Runtime Boundaries | Clients and Models |
| Persist conversations | Persist Conversations | History |
| Add application actions | Add Tools | Tools on Agents |
| Return typed data | Return Structured Output | Agent Output |
| Compose multi-step workflows | Build a Pipeline | Parallel Branches |
| Add retrieval | Add Retrieval | RAG Context |
| Add traces | Add Observability | Tracing |
| Inspect agents locally | Studio | Run Studio |
Continue with Getting Started for a runnable first agent.