Performer Composer

Build, configure, and run powerful AI performers visually in Studio.

A Performer is the main runnable unit in DOT. It combines identity, optional skills, model choice, and runtime configuration into something you can actually use.

Most users should start here: open a Registry Performer in Studio, inspect the pieces, then adjust it for the current project.

On this page you'll learn:

What a Performer contains

How to build and configure one in Studio

How to choose models and Dances

When to use standalone performer vs. inside an Act

What a Performer Contains#

Part	What It Does	Required?
Tal	Always-on identity and rules	At least one of Tal or Dances
Dances	Reusable skills and techniques	At least one of Tal or Dances
Model	Preferred provider and model	Needed for execution
Model variant	Execution style or variant	Optional
Runtime config	MCP bindings and related runtime setup	Optional
Execution mode	Direct or safe mode	Set at runtime

┌──────────────────────────────────────┐
│            Performer                 │
│                                      │
│  Tal ──── "Senior BE Engineer"       │
│  Dance ── "PR Review Format"         │
│  Dance ── "Migration Safety"         │
│  Model ── claude-sonnet-4            │
│  Mode ─── Safe                       │
└──────────────────────────────────────┘

The Basic Creation Flow#

Open or add a Performer on the canvas.
Assign a Tal or Dances. At least one is required by the canonical contract.
Choose a model and, if useful, a model variant.
Attach MCP bindings only when the Performer needs specific runtime tools.
Pick direct or safe mode.
Start chatting or use the Performer inside an Act.

Open an existing Registry Performer directly:

dot-studio . --performer performer/@acme/agent-presets/sprint

Adding a Tal#

Tal is the performer's identity layer — a Performer has at most one active Tal at a time.

From Asset Library#

Use when you already have an installed or created Tal:

Open the Asset Library
Find a Tal asset
Drag it onto the selected Performer

Create as a Draft#

Use when you want to author inside Studio:

Experimenting on a project-specific persona
Refining an imported performer into a local variant
Drafting before publishing later

Adding Dances#

Dances are the skill layer. You can attach one Dance or many.

Great uses for Dances:

Dance	Purpose
Review format	Structure reviews consistently
Output convention	Standard JSON or markdown output
Codebase checklist	Project-specific checks
Security heuristics	Compliance and safety rules

How to add them#

Drag installed Dances from the Asset Library
Create or edit local Dance drafts in Studio
Import GitHub Dance bundles through the Asset Library or with dot add owner/repo
Refine imported configurations into project-local variants

Tip: Think of Dances as layers, not replacements. Each one should have a clear job. This is easier to maintain than one giant mixed instruction file.

Example composition#

Daily Engineering Performer
├── Dance: Code Review Format
├── Dance: Migration Safety Checklist
└── Dance: API Response Convention

Choosing a Model#

Studio lets you choose the model per Performer.

{
  "provider": "anthropic",
  "modelId": "claude-sonnet-4"
}

The model is stored as an object, not a single string. If a model is not available in Studio, check the runtime/provider configuration rather than inventing a model id.

Matching models to work:

Work Type	Recommended Model Approach
Planning and review	Stronger reasoning models
Repetitive or lightweight tasks	Faster, cheaper models
Security-sensitive	Most capable model available

Direct Mode vs Safe Mode#

Every Performer can run in either mode:

	Direct Mode	Safe Mode
What happens	Work hits the real project	Work runs in a shadow workspace
Best for	Trusted, low-risk edits	Risky refactors, large edits
Review step	No — changes apply immediately	Yes — you review before applying
Quick iteration	Great	Slower but safer

Standalone Performer vs Inside an Act#

Mode	Use When
Standalone	One role handling one conversation — coding, reviewing, writing
In an Act	The performer is one role inside a larger choreography

What a Good Performer Looks Like#

A great Performer is usually:

Narrow enough to understand
Reusable across tasks
Specific about identity
Selective about Dances
Explicit about tools

Rule of thumb: Avoid making one Performer do everything. If the role or collaboration pattern changes, that's a sign you want another Performer, another Dance, or an Act.

Common Recipes#

Daily Engineering Performer#

Tal ──── Engineering posture (correctness, tests, observability)
Dance ── PR review format
Dance ── Migration safety
Dance ── Testing standards
Model ── claude-sonnet-4

Security Review Performer#

Tal ──── Strict risk & compliance posture
Dance ── Threat modeling
Dance ── Security report format
Model ── Most capable available
Mode ─── Safe (always)

Writing Performer#

Tal ──── Tone, structure, audience awareness
Dance ── Formatting guidelines
Dance ── Source handling
Model ── Strong language model

From Studio Draft to Published Asset#

Studio is great for composing and iterating, but publication flows through the CLI:

Refine configuration in Studio
Save or export the stable Performer asset
Run dot login if you have not published before
Publish with dot publish --kind performer --stage <stage> --name <name>

→ Publishing Assets