Key concepts

How Studio is organized

Studio uses a small set of concepts that build on each other. Once you understand them, everything else follows.

Organization — your top-level workspace. Everything belongs to an org: members, agents, connections, automations, and logs.
Agent — an AI configured for a specific job: a focused set of tools, clear instructions, and a narrow purpose. Agents are the working surface of Studio. See Agents.
Connection — a tool or service you’ve plugged in (GitHub, Slack, a database, your own API). Credentials are stored once and shared securely. See Connections.
Thread — a conversation session inside an agent. Studio saves the history so you can come back to ongoing work.
Automation — an agent run that fires on a schedule or in response to an event. See Automations.
AI Provider — a configured AI model (Anthropic, Google, OpenRouter, or the Deco AI Gateway) that powers your agents and Decopilot. See AI Providers.
Member — a person in your organization with a role and permissions.

Anatomy of the Studio UI

When you open Studio you land on the home screen: a single chat composer — “What’s on your mind?” — backed by Decopilot, Studio’s built-in assistant, plus a customizable grid of shortcuts to your agents. Just start typing to get going; the conversation you start is saved under Decopilot in the sidebar.

The persistent left sidebar is the same everywhere you go:

Home — the home chat composer.
Library — a file browser for your organization’s shared filesystem. See Library.
Threads — your recent conversations, grouped by agent (Decopilot’s live under “Decopilot”). Click one to resume it; start a new one from Home or the + / “Browse agents” button.
Settings — opens from the bottom of the sidebar; everything that isn’t tied to a single agent.

The agent workspace

Open an agent — or start a thread with one — and the screen splits in two:

Left — chat. Talk to the agent in natural language; it uses its attached tools to do the work. Past messages live here. Above the input sit the model-tier picker and the runtime picker (where the agent runs — see Agents).
Right — a tabbed panel. Which tabs appear depends on the agent:
- Settings — instructions, attached connections, files & skills (shown if you can manage agents)
- Automations — schedules and event triggers (always available)
- Preview — a live preview, for agents backed by a repo or site
- Content — edit pages and sections, for content-backed agents
- Review changes — branch and PR review, for Git-backed agents with an open pull request

Everything you need to use, configure, and monitor a single agent lives on this one screen. See Agents for the full breakdown.

Settings

Everything that isn’t tied to a single agent lives under Settings. Open it from the bottom-left of the sidebar. Inside you’ll find:

Organization — General, Brand Context, AI Providers, Secrets, Buckets
Build — Connections, Agents (the catalog), Automations, Store
Manage — Monitor, Members, Roles, Security (SSO)
Extensions — Plugins
Account — Profile & Preferences

When other pages in these docs say “go to Connections” or “open Monitor,” they mean these Settings sections.

How the protocol works

deco Studio is built on the Model Context Protocol (MCP), an open standard for connecting AI clients to tools and services. You don’t need to understand MCP to use Studio, but knowing the three building blocks helps:

Tools — actions an AI can take (search a database, send an email, create a file)
Resources — read-only data sources that give an AI context (documents, configs, org data)
Prompts — reusable templates for common workflows, with variables you can fill in

Studio sits between your AI clients (like Claude Desktop or Cursor) and your tools, handling authentication, routing, and logging for every request.

How a request flows through Studio

When an agent calls a tool, here’s what happens:

 ┌─────────┐                    ┌──────────────┐                  ┌────────────┐
│ Client  │ ──[authenticate]──▶│  deco Studio │ ──[with creds]──▶│ MCP Server │
│ (Cursor)│                    │              │                  │  (GitHub)  │
└─────────┘ ◀──[response]──────└──────────────┘ ◀─[response]─────└────────────┘
                                      │
                                      └──▶ [audit log]

The client authenticates to Studio
Studio checks whether the client has permission to use the requested tool
Studio retrieves the stored credentials for that connection
Studio forwards the request to the upstream service
Studio logs the invocation — tool, timing, inputs, outputs, and who called it
Studio returns the response to the client

Credentials never leave Studio, every action is logged, and access is consistent regardless of which client made the request.

Why monitoring is built in

Without a control plane, every client manages its own logs — or doesn’t log at all. Studio logs every tool call that flows through the platform, creating a single place to debug failures, watch performance, and audit who accessed what. There’s no extra setup. See Monitoring.