---
title: Studio Guide
description: Using the visual agent builder
---

import { Aside, Steps } from '@astrojs/starlight/components';

<Aside type="caution" title="Studio is in development">
  The Studio visual builder is being developed for Astromesh Cloud v0.1.0. The 5-step wizard configuration format (WizardConfig) is fully functional via the API — Studio provides a visual interface for the same configuration.
</Aside>

Astromesh Studio is the visual agent builder at `studio.astromesh.io`. It provides a 5-step wizard for creating and deploying agents without writing YAML or code. Under the hood, it generates the same `WizardConfig` that you can also POST directly to the Cloud API.

## The 5-Step Wizard

<Steps>

1. ## Step 1: Identity & Model

   Configure the agent's name and which LLM it uses.

   **Fields:**
   - **Agent name** — URL-safe identifier (used in API paths and runtime ID)
   - **Display name** — Human-readable label shown in Studio
   - **Primary model** — The LLM to use for responses
   - **Fallback model** — Used if the primary model fails or is unavailable

   **Available models:**

   | Provider | Models |
   |---|---|
   | OpenAI | `gpt-4o`, `gpt-4o-mini`, `gpt-4-turbo` |
   | Anthropic | `claude-3-5-sonnet`, `claude-3-haiku` |
   | Groq | `llama3-8b-8192`, `mixtral-8x7b-32768` |
   | Ollama | `llama3`, `mistral`, `phi3` (platform-hosted, no key required) |

   To use OpenAI or Anthropic models, you need to add a provider key first (see [Authentication](/astromesh/cloud/authentication)).

2. ## Step 2: Prompt & Persona

   Write the system prompt that defines your agent's behavior and personality.

   **Fields:**
   - **System prompt** — The main instruction set for the agent. Supports Jinja2 templating.
   - **Persona** — Short label used in Studio (e.g. "Support Agent", "Data Analyst")

   **Jinja2 variables available in prompts:**

   | Variable | Description |
   |---|---|
   | `{{ session_id }}` | Current session identifier |
   | `{{ context }}` | Context dict passed in the run request |
   | `{{ context.user_id }}` | Example nested context access |
   | `{{ today }}` | Current date |

   **Example system prompt:**
   ```
   You are a helpful support agent for Acme Corp.
   You are speaking with user {{ context.user_id | default('a customer') }}.
   Always be concise, friendly, and professional.
   If you cannot answer a question, direct the user to support@acme.com.
   ```

3. ## Step 3: Tools

   Select which tools the agent can call during a conversation.

   **Available tools:**

   | Tool | Description | Status |
   |---|---|---|
   | `calculator` | Arithmetic and math expressions | Available |
   | `web_search` | Search the web for current information | Available |
   | `weather` | Get current weather by location | Available |
   | `datetime` | Get current date/time in any timezone | Available |
   | `code_interpreter` | Execute Python code snippets | Coming soon |
   | `file_reader` | Read uploaded files | Coming soon |
   | `sql_query` | Query a connected database | Coming soon |
   | `http_request` | Call external REST APIs | Coming soon |

   Tools are managed by the platform's `ToolRegistry`. The agent automatically decides when to call a tool based on the user's query — you don't need to configure invocation logic.

   **MCP Tools:** Custom tools via Model Context Protocol (MCP) are supported in the core runtime. Studio support for MCP tool configuration is coming in a future release.

4. ## Step 4: Memory

   Configure how the agent remembers information across turns in a conversation.

   **Memory type:**

   | Type | Description |
   |---|---|
   | `conversational` | Stores recent chat history (recommended for most agents) |
   | `semantic` | Vector embeddings for long-term knowledge retrieval |
   | `episodic` | Event log of past interactions |

   **Memory strategy (for conversational memory):**

   | Strategy | Description |
   |---|---|
   | `sliding_window` | Keep the last N messages. Fast, predictable cost. |
   | `summary` | Summarize older messages to stay within token limits |
   | `token_budget` | Keep messages until a token budget is reached |

   **Window size:** Number of messages to retain (for `sliding_window`). Default: 20.

   Memory is scoped to `session_id`. Reusing the same `session_id` across calls gives the agent continuity. Using a new `session_id` starts fresh.

5. ## Step 5: Guardrails & Limits

   Add safety filters and resource constraints.

   **Input guardrails** (applied to user messages before the model sees them):

   | Guardrail | Description |
   |---|---|
   | `pii_filter` | Detect and redact personal identifiable information |
   | `prompt_injection` | Block prompt injection attempts |
   | `topic_filter` | Restrict to allowed topics (requires configuration) |

   **Output guardrails** (applied to model responses before returning to the user):

   | Guardrail | Description |
   |---|---|
   | `content_safety` | Filter harmful or inappropriate content |
   | `hallucination_check` | Flag responses with low confidence |
   | `format_validator` | Ensure output matches expected format |

   **Limits:**
   - **Max tokens** — Maximum response length. Default: 1000.
   - **Max iterations** — Maximum tool call loops per request. Default: 5.
   - **Timeout** — Request timeout in seconds. Default: 30.

</Steps>

## Deploying from Studio

After completing the 5-step wizard, click **Deploy** to transition the agent from `draft` to `deployed`. Studio calls `POST /orgs/{'{slug}'}/agents/{'{name}'}/deploy` on your behalf.

Once deployed:
- The agent gets a public endpoint you can copy from Studio
- You can run test queries in the Studio playground (uses `POST .../test`)
- Usage metrics appear on the org dashboard

## Editing a Deployed Agent

To edit a deployed agent in Studio:
1. Open the agent
2. Click **Pause** — this deregisters the agent from the runtime
3. Make your changes in the wizard
4. Click **Deploy** to bring it back online

Changes to the system prompt, tools, or model take effect immediately on the next deploy.

## API Equivalent

Everything Studio does maps directly to Cloud API calls. If you prefer working in code or CI:

```bash
# Create (equivalent to completing the wizard)
curl -X POST "https://api.astromesh.io/api/v1/orgs/$ORG/agents" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{ ... WizardConfig ... }'

# Deploy (equivalent to clicking Deploy)
curl -X POST "https://api.astromesh.io/api/v1/orgs/$ORG/agents/my-bot/deploy" \
  -H "Authorization: Bearer $TOKEN"

# Test in playground (equivalent to Studio playground)
curl -X POST "https://api.astromesh.io/api/v1/orgs/$ORG/agents/my-bot/test" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"query": "Hello", "session_id": "test-1"}'
```

See the [API Reference](/astromesh/cloud/api-reference) for complete documentation.
