Philosophy & Metaphor

We're past the era of hidden prompt blobs. Compose visible behavior, then run it in Studio.

Most AI tools flatten everything into one place: one model, one prompt, one chat box, one pile of hidden rules. That works for a demo, but it breaks down once you need repeatability, team standards, or multi-agent collaboration.

DOT starts from a different assumption:

Core Belief: Good AI behavior is composed, not improvised. We built the package manager for agents.

That is why the docs now start with Studio. The fastest way to understand DOT is to see a Performer or Act on a canvas, inspect its parts, and run it safely.

The Core Bet#

DOT treats AI behavior like a reusable software surface. That means:

Think of it this way: If your team already versions code, templates, infrastructure, and CI policy, DOT argues that your AI operating model deserves the same treatment.

The Package Manager Mental Model#

The metaphor helps explain the different layers without pretending they are all the same thing.

Tal — The Core Identity#

Who is this AI, and what rules always apply?

A Tal is the always-on layer. It holds the identity, posture, and non-negotiable rules.

Examples:

• A senior backend engineer posture
• A careful compliance reviewer
• A product-minded PM assistant
• A design critic with strong accessibility rules

Dance — The Skill Package#

What special skill can this AI use when needed?

A Dance is optional and composable. You can attach one Dance or many. In DOT, Dances are usually SKILL.md bundles sourced from GitHub and attached through Studio or dot add.

Examples:

• Code review format
• Incident response checklist
• Security audit routine
• Structured JSON output convention

Performer — The Composed Instance#

A Performer is the runnable composition. It bundles:

┌─────────────────────────────┐
│         Performer           │
│  ┌───────────────────────┐  │
│  │   Tal (identity)      │  │
│  └───────────────────────┘  │
│  ┌───────────────────────┐  │
│  │   Dance (skill #1)    │  │
│  │   Dance (skill #2)    │  │
│  └───────────────────────┘  │
│  ┌───────────────────────┐  │
│  │   Model target        │  │
│  └───────────────────────┘  │
└─────────────────────────────┘

This is the unit most people open and use day to day. In Studio, a Performer is the thing you chat with directly.

Act — The Ensemble Scene#

An Act is where DOT becomes multi-agent choreography.

Instead of describing a single agent, an Act describes:

• Which performers participate
• How they relate to one another
• What delegation paths exist
• How collaboration should behave at runtime

Common patterns:

• Lead engineer + Implementer
• Planner + Writer + Reviewer
• Incident lead + Specialist worker

In Studio, an Act is a visible collaboration workspace. You can inspect participants, relations, subscriptions, and runtime threads instead of guessing how the collaboration is wired.

Stage (URN Component)#

stage is the third segment of every URN (kind/@owner/stage/name) — not a Studio concept. It represents the repo name or group a set of assets belongs to.

What This Fixes in Practice#

Without DOT, teams usually end up with:

• Enormous hidden prompts nobody wants to touch
• Duplicated conventions across Cursor rules, docs, snippets, and chat history
• Setup that works in one host but not another
• No clear owner for AI behavior changes
• No way to audit what a shared performer actually includes

With DOT, you get a cleaner path:

• Publish a team posture once
• Install it anywhere by URN
• Layer reusable skills instead of re-copying prompt text
• Compose richer workflows in Studio when chat alone isn't enough

The Practical Mental Model#

If you only remember one thing, use this:

Philosophy in One Sentence#

DOT is built on the idea that AI behavior should be portable, inspectable, and shareable — not a secret blob hidden inside one tool.