Agent Studio

Studio is where agents are built. An agent is one definition: its model, its prompts, its tools, and the settings that shape how it behaves. Studio shows that definition as a single form. Fill it in, test it in the chat next to it, and deploy it. There's nothing about an agent that lives outside it.

To open Studio, click Open Studio on the agent's page. A new agent opens in Studio as soon as you create it.

Production and Dev runs

Every run of an agent is either Production or Dev:

The backend calls the Dev bucket TEST because it shares the same execution-origin axis used by traces, budgets, and cost reports. The UI labels it Dev so it reads as the builder's iteration view rather than a test dataset or test case.

Studio has no Production/Dev toggle. Its Test runs window lists your own Dev runs. Outside Studio, the Executions tab and the Overview's Cost card each have a Production / Dev switch, and only editors can pick Dev; the rest of the agent's metrics read Production only. Production and Dev also have separate spend limits.

The layout

• Header — the agent's name, the save status (Saving…, All changes saved), the version picker, Discard changes, and Deploy.
• Wiring strip — under the header: the agent's model and how many triggers, channels, participants, and contacts reach it.
• Agent configuration — the form in the middle. This is the agent.
• Tool windows — panels around the form, opened from the icon rails: Test chat (right), Integration Configuration (left), and Test runs (bottom). Right-click an icon to move its window to another side.

The agent form

The form has six groups. Instructions and Model & capabilities start open; the others show how many of their settings are on while closed.

Instructions

Model & capabilities

Memory & context

Collaboration

Execution

Output & quality

Human approval

Approval is set per tool. Expand a tool's card in Tools and open Human in the loop to pick the approver, the message they see, and when the request expires. The run pauses before the tool runs until a person approves the call. See Human approval.

Connecting a tool to credentials

Every tool that calls an external service needs an integration connection (a tenant-level config carrying the credential, sandbox routing, and OAuth scopes). You wire credentials by picking a connection, not by pasting auth into the agent:

1. Configure once at the tenant level. In Integrations, set up one or more configs for each integration. Each is a card with its own name, credentials, granted OAuth scopes, and sandboxMode strategy. The same integration can have multiple configs (e.g., "Salesforce — Prod", "Salesforce — Sandbox").
2. Pick the connection for the agent. The first time you add a tool from an integration, its card asks you to Set default credentials. The config you pick applies to every tool from that integration in this agent. You can also pick it in the Integration Configuration window, which lists every integration the agent's tools need and whether it's Connected or Needs setup. When only one config exists, it's picked for you.
3. Override per tool when needed. Click Override on a tool's card to give that one tool a different config — useful when a read-only tool should use a sandbox config while the rest of the agent uses prod.

The picker shows each config with its sandbox status and OAuth scope summary, so it's clear which environment a tool is actually talking to before you deploy.

Placeholders

Placeholders are how data reaches the prompts. Anywhere a template is accepted, you can reference:

{{param.<name>}}    # a parameter
{{sender.<field>}}  # the person who sent the message
{{venue.<field>}}   # the conversation the message came from: the group, or the sender in a DM
{{secret.<NAME>}}   # an organization secret, in tool arguments
<file:…>            # an attached asset (inserted from the asset picker)

You insert these from the prompt editor's placeholder menu rather than hand-typing them, so names always resolve. Placeholders that don't resolve render as empty strings — a common silent bug — so always check the trace if the agent is producing weird output.

Saving & versions

Studio saves as you type. Your edits go into a draft on the server, and the header shows All changes saved once they've landed. Production traffic keeps hitting the deployed version; editing never changes what's live.

To ship, click Deploy. If the draft has changes, the dialog first asks Why this change? and saves the draft as a new version (an immutable revision). It then runs Pre-deploy checks and makes that version live. Discard changes drops the draft and returns the form to the version it started from.

The version picker in the header (Version N, with a LIVE tag on the deployed one) switches between versions and compares them.

Testing from Studio

Test chat runs what the form is showing: your draft, before you deploy it. To test a published version instead, pick it under Run settings → Runs. Each run's full trace lands in Test runs. See Testing for the full guide.

Agents and workflows

An agent is one definition. It doesn't have nodes, steps, or a canvas. When a job needs several agents and tools run in a set order, build a workflow instead. A workflow is a graph, built on a canvas in the workflow builder, and each of its Agent steps runs an existing agent.

Next steps

• Creating Agents — full walkthrough of a new agent
• Tools & Skills — what agents can do
• AI Providers — wiring up the LLM
• Testing — interactive validation