Studio
Studio is how you see a Shiro run. It is not a second orchestrator. With shiro dev it
becomes a local debugger: type prompts in the terminal, stream SDK events over WebSocket, and
inspect timelines, graphs, tools, approvals, memory, metrics, and raw traces.
When no agent is connected, Studio automatically uses Demo Mode with built-in sample traces.
If Tracing is the source of truth, Studio is the workspace built on top of it.
Why Studio exists#
Text logs answer “did something fail?” They rarely answer:
- Which provider call requested this tool?
- Did approval pause the run before
issueRefund? - What memory was loaded before the second model call?
- Which handoff changed the active agent?
What Studio is (and is not)#
| Studio is | Studio is not |
|---|---|
| A live observer of agent runs | An execution engine |
| A timeline + graph + inspectors | A replacement for your app UI |
| Demo Mode when offline | A static marketing demo only |
Launching Studio#
pnpm add -D @shiro-sdk/cli
pnpm exec shiro dev --port 3001This starts:
- Studio UI (
http://localhost:3001) - Runtime WebSocket hub (
ws://127.0.0.1:4317by default) - Your browser (unless
--no-open)
Connecting an agent (Live Mode)#
In your agent process:
import { Agent, Engine, TraceManager, connectStudio } from "@shiro-sdk/core";
import { OpenAIPlugin } from "@shiro-sdk/openai";
const studio = await connectStudio({ agentName: "Assistant" });
const events = new TraceManager({ events: studio });
const engine = new Engine({ events });
engine.use(
new OpenAIPlugin({
apiKey: process.env.OPENAI_API_KEY!,
model: "gpt-5",
})
);
const agent = new Agent({
name: "Assistant",
instructions: "Be helpful.",
provider: "openai",
});
studio.bind(async (prompt) => engine.execute(agent, prompt));Set SHIRO_STUDIO_URL (scaffolded projects do this via shiro init templates). When the agent
connects, Studio switches from Demo Mode to Live Mode automatically.
Type a prompt in the Studio terminal:
> Plan me a 5 day trip to Japan.Studio sends the prompt to the bound agent, streams lifecycle events, and updates every panel.
Workspace layout#
| Area | Role |
|---|---|
| Terminal | Primary interaction — prompts + streamed output |
| Sidebar | Jump to Sessions, Runs, Tracing, Graph, … |
| Run explorer | Current / loaded runs |
| Metrics | Tokens, cost, latency, provider/tool timings |
| Execution log | Chronological event lines for the selected run |
| Timeline | Ordered spans (provider, tool, handoff, …) |
| Execution graph | Live nodes + active path |
| Tool inspector | Arguments, result, duration, status, errors |
| Memory | Session ops with before → after when available |
| Trace viewer | Expandable / searchable JSON for the run |
Demo Mode#
If the runtime hub has no agent clients, Studio loads demo traces automatically and shows a Demo Mode badge. Connecting an agent flips the badge to Live Mode without restarting UI.
Architecture#
RuntimeProvider
→ EventTransport (WebSocket today; replaceable for cloud)
→ Reducer
→ Studio UI panelsUI components never import mock JSON directly for live work. Demo traces remain available as a fallback transport.