What is Studio
An extensible platform for connecting context, organizing work, and running agents
Studio is the platform for organizing and executing work with AI agents. Connect your tools and data, turn requests into tasks, and give agents a workspace where they can carry the work through to a reviewable result.
Studio is useful for software teams, internal automation, and custom workflows. Storefront is one application of this platform: its Site Editor runs inside Studio, while its framework and editing guides belong to Storefront.
The platform does not prescribe what you build. A team can use the same workspace to investigate a support issue, develop an internal app, or make a repository change. Connections supply the context; agents and tasks carry the work; MCP Apps provide an interface when a conversation alone is not enough.
Three connected parts
Bring context into the work
Connections make external systems available through MCP. A connection can expose a repository, a business system, a data source, or a server you build. Attach the relevant tools and files to an agent so it can act with the context your workflow needs.
You choose which tools an agent can use. This keeps a focused workflow close to the systems it needs, with the connection's credentials and access managed in your organization. See Agents to define a role and select its tools.
Signals and objectives describe the upstream side of the workflow: identify something worth doing and decide how it relates to your goals. Their availability is documented separately below.
Organize and interact with the work
Tasks provide a place to describe the outcome, track progress, and steer execution. Comments preserve decisions and feedback alongside the work.
Studio can also host rich interfaces through MCP Apps. Build an app when your workflow needs more than a chat message: a dashboard, an editor, or an interactive review. The MCP Apps guide explains the reusable extension model.
Execute and deliver
Agents use the tools and execution environment appropriate to a task. For repository work, a sandbox can provide a checkout, a dev server, and a preview. The result can be a branch and a pull request your team reviews before it ships.
Read Architecture for the execution environments and Reviews and QA for the delivery workflow.
The complete signals → objectives → tasks loop is still evolving. Tasks are in daily use; signals are becoming continuous; objectives are planned. Workflows and delivery keeps these states explicit.
A task, from context to review
Consider a team building a support-triage interface. The work needs a repository, a knowledge base, and tools that can read the original support requests.
- Connect the context. Add the relevant MCP connections and give the agent the tools and documents it needs for this task.
- Describe the outcome. Ask for a view that groups urgent requests first and preserves links to the original records. Specify who will use it and how the team will check that it works.
- Work with the agent. Follow the task on the board and add comments when the requirements need clarification. For code changes, the execution environment provides the checkout and tools needed to run the app.
- Review the result. Inspect the running preview, checks, and branch or pull request. Your team decides when the change is ready to deliver.
The task keeps the request and the conversation together, so the next person can understand why the result looks the way it does. Writing a task explains how to make the outcome checkable, and Reviews and QA covers the delivery process.
Tools can have an interface
An agent can use a tool's structured result directly. People often need a different way to work with the same data: a table they can filter, an editor, or an interactive review.
An MCP App connects these two surfaces:
- A tool provides a capability and its structured result.
- A resource serves the app's HTML interface. The tool identifies that resource through its UI metadata.
- Studio, as the host, loads the app and passes in the tool input and result. The app can also send messages back to the conversation.
| Request | Priority | Status |
|---|---|---|
| Account access | High | Needs review |
| Billing question | Normal | Assigned |
| Setup guidance | Normal | New |
Structured tool resultJSON
{
"requests": [
{
"subject": "Account access",
"priority": "High",
"status": "Needs review"
},
{
"subject": "Billing question",
"priority": "Normal",
"status": "Assigned"
},
{
"subject": "Setup guidance",
"priority": "Normal",
"status": "New"
}
]
}The support view is one example; the extension model is also useful for dashboards, review tools, and custom internal workflows. Start with Building tools, then Resources and Building MCP Apps to connect a tool to its interface.
The Site Editor uses this extension model for websites. Its Blocks configuration, visual-editing, and publishing guides live under Storefront, alongside the framework that powers the site.
The main concepts
- Organization: members, access, connections, and shared settings.
- Project: the context for a site, repository, integration, or other piece of work.
- Task: an outcome to execute, review, and complete.
- Connection: an MCP integration that makes tools and context available.
- MCP App: a rich interface for interacting with a tool or workflow inside Studio.
See Core concepts for the product surfaces and Project structure for an extension's code layout.
Choose your starting point
| Goal | Start here |
|---|---|
| Use Studio and connect a tool | Quickstart |
| Create an agent with a focused role | Agents |
| Organize work and deliver changes | Tasks and the board |
| Build an integration or a rich interface | Build MCP Apps |
| Run Studio on your own infrastructure | Self-hosting |
| Build or operate a site with Blocks | Storefront |
Run Studio
Use studio.decocms.com, the desktop app described in the Quickstart, or a self-hosted deployment. The open-source repository contains the platform implementation.