Studio Assistant

The Studio Assistant is an AI helper available from any page in Vertesia Studio. Think of it as a collaborator who knows the product — it can design interactions, draft prompts, build content types, create agents, author processes, and set up databases for you.

It lives behind the small bot icon in the top bar. Click it, a side panel opens, and you're in a chat. The assistant carries context about the page you're on, so asking "help me structure this prompt" on a prompt-editor page does the right thing without you having to explain which prompt.

Where it lives

Top-bar icon — present on every Studio route. Toggles the panel open/closed.
Side panel — mounted inside the Studio module. Shows the conversation, a small config drawer (environment + model), and the streaming stop/new-chat controls.
Per user + project persistence — the selected environment, model, and active agent_run_id are saved in localStorage keyed by studio.assistant.<userId>.<projectId>. Resuming Studio later resumes the same conversation.

How it's built

Under the hood, the assistant is a standard Vertesia agent run targeting the StudioAssistant system interaction. Three things make it feel different from a generic agent:

Skill-driven tools. The assistant ships with only learn_* skills enabled by default (studio_overview, interaction_design, prompt_engineering, content_modeling, agent_creation, …). Calling a skill reads its guidelines and unlocks the actual domain tools. The assistant can't, for example, create a content type before calling learn_content_modeling — the skill's related_tools is what opens that capability.
Route context on every turn. The panel derives a coarse { route_path, resource_type, resource_id } from the current URL and injects it into the conversation. The assistant knows if you're on /studio/interactions/abc123 it's talking about an interaction, and it can fetch that interaction without you pasting the id.
Configurable environment + model. A small config strip lets you pick which execution environment and model drive the assistant. Defaults to the project's default environment. This is the same config surface as agent_runner.

What it's good at

Authoring. "Design an interaction that extracts line items from invoices", "draft a prompt for classifying support tickets", "create a content type for legal contracts". The assistant follows the skill for each task type — e.g. learn_interaction_design before proposing a schema.
Explaining. "What does this prompt do", "why is this agent failing to call the tool I declared", "what are my options for routing in a process". Each domain skill carries the current best-practice guidance.
Orchestrating authoring. "Build me a contract-review process" loads learn_process_design once the assistant has enough context, then drafts, validates, and saves the definition — composing with the other system interactions (sys:ExplainProcess, sys:ProcessAgentNode) rather than competing with them.

Process authoring

For process work, the assistant should load learn_process_design before drafting or changing anything. From there it can:

draft a full process definition from your description;
validate a draft with validate_process;
create or update a draft process definition;
publish only after explicit user confirmation;
explain a selected process, node, or guard through sys:ExplainProcess;
improve process-board layout through LayoutProcessDefinition.

When improving layout from a screenshot, the image is only visual evidence. The assistant still needs the actual process definition and should only touch visual authoring fields: node titles/descriptions, human_description, metadata.phase, metadata.lane, metadata.order, optional visual position metadata, and transition/branch labels. It should not change runtime behavior.

When designing node behavior, the assistant should use real project capabilities. For general open-ended agent work, use sys:GeneralAgent or a custom agent interaction. For normal process worker-agent nodes, let the engine use sys:ProcessAgentNode unless there is a concrete custom interaction contract.

What it's not

Not a replacement for the Agent Runner. For running a production agent against a known interaction, use the Agent Runner — you get the full conversation page, artifacts, observability, and restart/fork controls.
Not for long-running batch work. The side panel is designed for interactive assistance. For a batch job or a scheduled process, author the process and run it.
Not silent. It always uses whichever model you configured; no background usage. If you close the panel mid-turn, the active run continues (Temporal is durable) but the UI disconnects.

Invoking it

Click the bot icon in the top-bar banner.
Keyboard: any Studio page — open the side panel, type. The assistant sees the page context automatically.
From code in the UI: emitStudioAssistant('open' | 'close' | 'toggle') dispatches a studio-assistant:toggle window event. The panel listens. This lets other UI surfaces (e.g. a "Ask the assistant" button on an error banner) open the helper without prop-drilling.

Starting a new chat

The panel has a "New chat" control that creates a fresh agent run and updates the stored agent_run_id. Old runs are durable — their history is preserved in the backend — but won't be revisited through the assistant UI once you start a new one. For anything important, save the output or the agent-run id before starting over.

Steering it

A few patterns make the assistant noticeably more useful:

Tell it what skill to use. "Use learn_interaction_design for this" front-loads the right guidance.
Give it enough context upfront. If you want an interaction designed for a specific use case, state the inputs and expected outputs in the first message.
Ask for tool calls explicitly. "Create the interaction" is clearer than "could you make the interaction". The assistant is happy to narrate; if you want action, ask for action.
Correct it out loud. When it drifts, say so. Skills and tool declarations constrain it, but prompt-level nudges are the cheapest way to steer.