@anvia/core

@anvia/core is Anvia's provider-neutral runtime. It owns agents, direct completions, typed tools, resumable human interactions, document utilities, memory contracts, retrieval, pipelines, streaming events, guardrails, skills, MCP registration contracts, evaluations, and the shared message types used by the rest of the SDK.

Use it when application code should describe agent behavior without depending on one model provider. Provider packages such as @anvia/openai, @anvia/anthropic, and @anvia/gemini supply the runnable model objects.

Install

pnpm add @anvia/core zod

zod is a direct dependency of Core, but application code normally imports it when defining tool inputs and structured outputs.

Build a useful agent

import { Agent, createTool } from '@anvia/core'
import { OpenAIClient } from '@anvia/openai'
import { z } from 'zod'

const model = new OpenAIClient({
    apiKey: process.env.OPENAI_API_KEY!,
}).completionModel({
    modelId: 'gpt-5.6-sol',
    api: "responses"
})

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

const supportAgent = new Agent({
  id: 'support',
  model: model,
  instructions: 'Help customers understand their order status.',
  maxTurns: 4,
  tools: [lookupOrder],
})

const response = await supportAgent.generate({
    prompt: 'What is happening with order A123?'
})

if (response.type === 'response') {
  console.log(response.output)
}

The model, credentials, business data, permissions, storage, and deployment remain application-owned. Core coordinates the run around dependencies supplied by the application.

Key features

Capability	Primary entry point	Use it for
Agents	@anvia/core/agent	Stateful model-and-tool loops with instructions and runtime policy
Completions	@anvia/core/completion	Direct model requests, streaming, messages, and parsed results
Tools	@anvia/core/tool	Typed tools, middleware, approvals, structured questions, and dynamic discovery
Documents	@anvia/core/documents	Shared text-document records and deterministic single/batch text chunking
Memory	@anvia/core/memory	Conversation persistence and compaction contracts
Retrieval	@anvia/core/embeddings, @anvia/core/vector-store	Raw-text ingestion, embedding documents, and searching vector indexes
Pipelines	@anvia/core/pipeline	Typed multi-stage workflows, batches, graphs, run events, and named run/stage observability
Media	@anvia/core/image-generation, @anvia/core/speech-generation, @anvia/core/transcription	Provider-neutral media requests
Runtime control	@anvia/core/agent, @anvia/core/guardrails	Lifecycle observation, resumable interactions, and enforced input/output policy
Integration contracts	@anvia/core/mcp, @anvia/core/skills, @anvia/core/observability	MCP registration types, reusable instructions, and run telemetry; MCP connections live in @anvia/mcp
Evaluation	@anvia/core/evals	Typed evaluation suites, metrics, reporters, and CLI output

The root @anvia/core entry point re-exports the most common agent, completion, tool, memory, guardrail, lifecycle, and semantic run/stream event APIs. Prefer a capability subpath when it makes ownership clearer or when the symbol is not available from the root.

Common patterns

Inject provider models

Create provider clients near the server boundary, then pass their completion, embedding, or media models into Core. This keeps credentials and provider-specific configuration outside agent definitions.

Use direct completions for one model call

Choose generateCompletion or streamCompletion when a workflow does not need agent turns or tool execution. See Completions and Structured output.

Keep persistence behind contracts

Agents accept memory stores and retrieval indexes through public contracts. Start with an in-memory implementation during development, then replace it with the adapter that matches production storage. See Memory and Knowledges.

Keep tool authorization in the application

Schemas validate model-produced arguments; they do not authorize a user or tenant. Enforce permissions inside the tool or middleware before accessing product data. See Tool security.

Runtime compatibility

Field	Value
Package format	ESM
TypeScript	Declarations included
Peer dependencies	None declared
Schema library	Zod 4
Runtime boundary	Modern JavaScript runtimes; individual entry points may require runtime-specific capabilities

Core's contracts are broadly portable, but not every entry point has the same environment needs. MCP stdio needs a process-capable server runtime, and web-stream adapters need ReadableStream. File parsing is application-owned and should remain on a trusted runtime appropriate for the selected parser or OCR service.

Continue learning

• Install and setup
• Your first agent
• Agents
• Interactions and continuations
• Tools
• Streaming
• Register agents in Studio
• Inspect tools in Studio

For exact exports and signatures, use the API reference. For release history, read the source changelog.