Inside @anvia/studio

An agent rarely fails in one obvious place. The prompt may be wrong, a tool may return surprising data, memory may load the wrong turn, or a pipeline may pass a valid value with the wrong meaning. Logs can show the pieces, but they do not always show the run as a system.

@anvia/studio is the local development console for that system. It takes the agents and pipelines an application already owns and exposes them through a browser UI and HTTP runtime.

Start with the same agent

Studio does not ask for a second agent definition or a Studio-specific wrapper. Register the runtime object directly:

import { AgentBuilder } from "@anvia/core"
import { Studio } from "@anvia/studio"

const agent = new AgentBuilder("support", model)
  .name("Support")
  .description("Answers support questions.")
  .instructions("Answer support questions clearly.")
  .build()

new Studio([agent]).start({
  port: 4021,
})

Studio opens a local server and playground around that exact agent. The model, instructions, tools, middleware, memory, and approval policies remain application code. A run in Studio exercises the same runtime boundaries as a run in the product.

That distinction is important. Studio is an inspection layer, not an alternate application framework.

One surface, several views of a run

The Playground is the entry point, but it is only one part of Studio. The runtime exposes focused pages for the information that normally gets scattered across logs and database tables:

• Agents and model selection
• Tool definitions, schemas, and direct handler invocation
• Playground tool calls, interactive approvals, and human questions
• Pipeline graphs, inputs, outputs, and replay
• Static knowledge, dynamic context, and dynamic tools
• Sessions, memory records, and response usage
• Traces and runtime status
• Connected MCP servers and their tools
• Live Sandbox files, processes, ports, and logs

These views are connected by runtime identity. A streamed tool call belongs to a message, the message belongs to a session, and the session can be followed into its trace. Studio preserves those relationships instead of presenting every event as an independent log line.

Streaming is part of the inspector

Studio uses the shared Anvia UI stream protocol internally. Text, mixed message parts, tool arguments, tool results, attachments, human-input requests, cancellation, usage, and errors travel through the same event semantics used by @anvia/react and @anvia/server.

That gives the Playground two useful properties. It can show work while it happens, and the final transcript still matches the ordered result produced by the runtime.

Cancellation persists the partial transcript. Human-input states survive as explicit parts. Completed responses can retain provider, model, token usage, duration, and context metrics for later inspection.

Disposable by default, persistent when needed

The default Studio stores are in memory. That is the right behavior for quick local sessions: start the process, inspect a run, and leave no database behind.

When the work needs to survive a restart, Studio can use SQLite-backed session, trace, pipeline, and run-history stores. It can also discover conversations from an agent's configured memory adapter through the read-only memory inspection contract.

Studio does not turn that store into the product database. The application still chooses production persistence, retention, access control, and deployment topology.

The boundary stays visible

Studio owns the browser UI, local HTTP routes, streaming endpoints, inspectors, and its own optional stores. It does not provide built-in authentication, authorization, or TLS.

That boundary is not cosmetic. Studio can invoke tools, inspect prompts and results, browse memory, and expose live Sandbox state. Bind it to a loopback address and use development credentials and test data. If temporary remote access is unavoidable, protect the entire origin with trusted network controls, TLS, and authentication; that does not make Studio a supported production console.

Direct execution from the Tools view is also distinct from a Playground approval flow. The Tools runner calls the selected handler immediately, even when its metadata says approval is required. Use Playground to test whether an agent-run tool call pauses for approval.

The goal is a clearer development runtime, not a hidden one: the connected surfaces needed to understand an agent system in one place, without moving ownership away from the application. For durable production observability, evaluation history, and operational investigation, use Lens.

Read the Studio guide, @anvia/studio package documentation, and source changelog.