What Studio is, what it isn't, and how it's governed.

What Studio is

Studio is an orchestration system for AI agent pipelines. Technical work happens through declarative YAML configuration, validated by contracts, retried by a RALPH loop. The kernel knows nothing about the domain. All business content lives in configs.

Studio is designed on the model of git: a tool you install globally, that lives in a .studio/ folder inside the user's project, that you use daily from the terminal. Not a framework to learn. Not a platform to join. A dev tool.

git init    →  studio init
.git/       →  .studio/
git commit  →  studio run
GitHub      →  Studio Cloud (future)

What Studio is not

• Studio is not an AI agent. Agents are secondary, interchangeable, fallible.

• Studio is not a framework. You don't inherit from a class, you don't implement an interface, you don't learn a DSL. You write YAML.

• Studio is not a platform. The kernel is open source, the hosted API (when it exists) will be optional, content stays in your repo.

• Studio is not a commercial product. The kernel is and will remain a commons.

Political position

Studio is a project explicitly anchored on the left. This mention is not a slogan added to a neutral product, it is the foundation of the project itself. Three principles structure technical and organizational decisions:

Ideological neutrality is neither sought nor claimed.

Why a commons, not a startup

Studio could have been a startup. The product shape lends itself to it, the market exists, demand is rising. The opposite choice is deliberate: an AI agent orchestration kernel, captured by a company, becomes the bottleneck of everything that flows through it. Studio is designed so that it cannot be captured.

Three structural mechanisms ensure this non-capture.

As GitHub, GitLab, and Bitbucket are to git: products built on a free tool without authority over it.

Technical architecture

Studio is a monorepo of seven packages, plus a template system.

@studio/cli          Terminal interface
    │
@studio/engine       Orchestration, state machine, persistence
    │
    ├── @studio/ralph    Execute → validate → retry
    │
    └── @studio/runner   LLM calls, tool plugins, multi-provider
    │
@studio/contracts    Shared types (zero deps)
Templates/           Architectural patterns

Five concepts differentiate Studio from other orchestrators:

• RALPH loop. Execute, validate against the contract, retry with enriched feedback if fail, repeat until success or max attempts. This is what makes pipelines reliable. No stage advances until its output respects its contract.
• Output contracts. Structural validation schemas. Validation is binary, pass or fail. No gray zone, no configurable acceptance score.
• Anti-theatre. Detection of agents that pretend to have done the work without having done it. If a contract requires tool calls and the agent made none, the stage fails regardless of the quality of the text produced.
• Groups. Multi-stage feedback loops. Creation, critique, revision automatic, without human intervention between iterations.
• Tool plugins. .tool.yaml files that define capabilities for agents. Self-documenting, project-scoped, double-gated. Creating a tool requires no code.

Six architectural invariants ensure the system remains coherent:

1. 01The engine is domain-agnostic. All domain comes from YAML.
2. 02ralph does not know runner. The executor is generic.
3. 03runner does not validate, does not retry. That is ralph's job.
4. 04contracts is a leaf package. Zero internal dependencies.
5. 05Tools are in runner, not in engine.
6. 06Prompts are in runner, not in engine.

If a feature can be configured in YAML rather than coded, it is in YAML. This is not a stylistic preference, it is a constitutional rule of the kernel.

Templates

Templates are not finished products. They are architectural patterns that generate complete applications, like create-react-app or create-next-app, but for AI-orchestrated apps.

Five official templates:

A template generates a functional out-of-the-box app: base pipelines for the domain, adapted tools (.tool.yaml), configured contracts and agents, starter DB schema (Prisma), minimal but functional application code.

studio init --template document-analysis --name wiki-creator
cd wiki-creator
npm install
studio run document-analysis/analyzer --input "..."

Templates are designed to be reusable. Several products can start from the same template and diverge completely: Wiki Creator and Voice Training both use the document-analysis template, but one analyzes books and the other processes voice. It's the architectural pattern that is shared, not the domain.

Eventually, a community registry will allow publishing and installing custom templates. But this phase comes after validation of the official templates by real products.

studio init --template @user/legal-analysis --name my-tool

Revenue model

Inspired by the Linus Torvalds model: the tool is free, the ecosystem funds the development.

• The kernel is free, open source, forever
• The official templates are free, open source
• The hosted API (Studio Cloud, future) generates revenue via subscriptions
• Specialized products can be commercial or open source according to each team's choices
• The foundation is funded by the ecosystem of companies that depend on Studio

Linus never sold Linux or git. He is funded by the companies that depend on them, through the Linux Foundation. Studio follows the same model. No commercial decision can take precedence over the kernel invariants. Any evolution that improves performance or monetization at the cost of worsening inequalities is considered a regression.

Governance

The kernel is treated as a constitution, not as an implementation. Final authority over structural decisions belongs to the kernel and the foundation, not to agents, commercial products, or individual contributors.

Five operational principles:

Cadence

• A single public product at a time
• Refusal of artificial urgencies
• Any new idea passes through a latency period
• Human pace takes precedence over the roadmap
• Templates are created only after validation by a real product

Studio is not designed to scale fast. It is designed to last.

Definition of success

Studio is healthy when:

• The kernel remains coherent over time
• Projects finish or stop explicitly, they do not die by abandonment
• The cognitive load of the founder and contributors decreases over time
• Decisions are traceable
• Adoption is slow but voluntary
• The founder can step back without system collapse
• Templates are reused by the community
• Several products live on the same template

Money is a means of sustainability, never an end.

How to contribute

Studio is in active development. Three ways to participate now:

Status

Studio is in pre-launch. No public promotion yet. No hosted API yet. No version 1.0 yet.

Once Code Builder is validated in production, Studio will move into "first public release" mode. Until then, interested users can follow the repo and test locally. Bugs and incompatibilities are expected.