Skip to main content

​
Build Agents Visually in the Agent Studio Canvas

The Agent Studio is the visual route to building an agent: a canvas where you drag nodes from a palette, wire them, and configure each one in a side panel — no prompt-generation round trip. This guide walks the canvas tour, an end-to-end build with a guardrail and a handoff wired explicitly, the sandbox test loop, and how the canvas hands off to versioning and canary promotion.

​
Prerequisites

  • An Orbit account with an owner, admin, or developer role.
  • A desktop browser — the visual builder is disabled below a desktop-size viewport and the dashboard tells you to switch if your window is too small.
  • An agent idea concrete enough to draw as a graph: entry point, model call, maybe a tool, and where it ends.

​
1. Where the canvas lives — and when to prefer it over the prompt route

Open Agents → Studio tab in the dashboard (/agents?tab=studio). A direct visit to /agents/studio redirects there with the tab pre-selected. Two routes lead to the same agent record:
  • From prompt (Author an AI Agent from a Prompt) — write a plain-English brief; the builder generates a draft prompt, tools, and model pick. Best when you want a scaffold quickly and will tune by hand afterward.
  • Studio canvas (this guide) — you place the nodes and pin each setting yourself. Best when you want to wire specific tools, knowledge bases, or guardrails before anything is deployed, or when you’re building a voice/IVR flow where the node kinds matter.
The Studio is a configuration canvas, not a runtime flow. A banner at the top says it plainly: cards on the canvas configure the agent — system prompt, model, tools, knowledge bases, guardrails. At runtime the agent’s LLM-orchestrated reasoning loop decides which tool to call and when; the edges you draw on the canvas are visual aids, not an execution order. Condition nodes are the one exception the UI flags: the canvas shows an amber warning that branching logic is ignored at runtime until the visual-workflow interpreter ships — Save and Deploy still work, but remove Condition nodes for predictable behavior.

​
2. Canvas tour

The screen has four regions: the toolbar on top, the node palette on the left, the canvas in the middle, and a config panel on the right.

​
The node palette

Drag a node onto the canvas, or click its card for the same result through your keyboard. The palette ships these node kinds: A fresh canvas starts from a default text workflow — User Input → LLM Call → Condition (“needs tool?”) → Tool Call / Response — which is a useful shape to modify rather than a blank page.

​
The config panel

Click a node and the right panel switches from the workflow-level form (workflow name + guardrails) to that node’s settings:
  • LLM Call — model picker with per-model blended cost estimates (~$/1M tokens shown in the option text), a temperature slider, and a system-prompt textarea with a character count and approximate token estimate. If the saved model id isn’t in the live list (e.g. a newer version pin), the picker keeps it as a labelled “saved selection” so an edit never silently downgrades the model.
  • Tool Call — a tool selector fed from GET /agents/tools, so custom tools appear alongside the built-ins.
  • Voice nodes — Play Prompt takes the spoken text; Collect Digits takes the variable to store, digit count, and timeout; Warm Transfer takes a destination name (matched against the agent’s transfer destinations) and a hold message.
The workflow-level form, visible when no node is selected, holds the guardrails block: block PII in responses, block profanity, require human approval, and a max cost per conversation in dollars. These travel with the agent when you save or deploy.

​
Edges, saving, and undo

Connect nodes by dragging from an output handle (bottom of a node) to an input handle (top of the next). Response, Human Handoff, and Warm Transfer are terminal — they have no output handle. Undo/redo, auto-layout, and a reset (restores the default workflow) live in the toolbar. The toolbar’s Save writes the workflow draft without deploying; Deploy does the full publish. Changes mark the canvas unsaved until one of the two lands.

​
3. Build example: knowledge-base agent with a sensitive-words guardrail and human handoff

Build a support agent that answers from your knowledge base, refuses sensitive topics, and hands billing disputes to a human — entirely on the canvas.
  1. Open the Studio tab and press Reset if the canvas isn’t at the default shape, then delete the Condition node (it isn’t executed at runtime and would trigger the warning).
  2. Configure the LLM node. Click LLM Call, pick the model that fits the traffic (Sonnet 4.6 for general support — the picker shows the estimated blended cost per 1M tokens per choice), set temperature ~0.3 for factual retrieval, and write the system prompt: what the agent answers, what it refuses, and when it escalates.
  3. Attach the knowledge base. Drag a Tool Call from the palette, select Search knowledge base in its tool dropdown. At deploy time the Studio extracts the knowledge-base ids and tool ids from the nodes and ships them with the agent — so retrieval actually attaches instead of being silently skipped.
  4. Wire the human escape route. Drag a Human Handoff node, name a destination (support-queue in the Destination field), and connect the LLM node to it so the escape path is visible on the canvas.
  5. Pin the guardrails. Click the canvas to deselect all nodes; the right panel switches to the workflow form. Turn on Block PII in responses and set a max cost per conversation. If you need the stricter word-based screen — e.g. refuse to discuss competitor offers or legal topics — that is the sensitive-words guardrail, configured at the dashboard level and documented in Sensitive words guardrail.
  6. Save, then deploy (next section).
The finished canvas reads top to bottom: User Input → LLM Call → Tool Call (knowledge lookup), with Human Handoff and Response as the two exit cards. Save keeps it as a draft you can reopen from the Agents hub.

​
4. Validate before you deploy — the sandbox test chat

The Test button in the toolbar opens a chat dialog that talks to your deployed agent over a sandbox channel. Save and deploy first — the input is disabled until the agent exists server-side, and the dialog says so.
  • Send a message that should hit the knowledge base (“what does the parking permit cost?”) and confirm the answer grounds in your documents.
  • Send a message the guardrail should block and confirm the refusal path.
  • Send an escalation trigger (“I want to dispute this charge”) and confirm the agent takes the handoff route.
Each turn streams in the dialog; the conversation id is reused while the dialog stays open, so follow-up questions test multi-turn behavior, not isolated turns. Because the test runs against the deployed record with sandbox: true, nothing here touches real customer traffic — but it does exercise the real executor, so a misconfiguration shows up here, not in production.

​
5. Deploy and promote to production

Deploy publishes in two steps behind a single click: it saves the agent record (workflow, model, tools, knowledge-base ids, guardrails) and then calls POST /agents/:id/deploy with the webhook channel, which binds the channel, issues the webhook endpoint, and moves the agent from draft to deployed. Redeploying from the same canvas updates the same agent — the Studio keeps the agent id after the first deploy. From here the canvas hands off to the standard lifecycle:
  1. Every material change you promote becomes a new version — see Agent versions for how saved configurations stack and how to roll back.
  2. Promote through a staged rollout, not straight to 100% — the canary mechanics (stages, regression gates, rollback) are in Safely Roll Out an AI Agent. The same persona simulation and red-team gate from the prompt route apply to canvas-built agents — they validate the same agent record.
  3. Once live, keep the agent honest with Continuous production evals — sampled live traffic is graded against your quality bar so drift is caught on evidence, not complaints.

​
Troubleshooting

​
See also