Philosophy & Metaphor

We're past the era of monolithic agent frameworks. Just compose blocks.

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.

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. It strictly follows the open Agent Skill standard.

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 install and use day to day.

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

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.