Okay, OpenProse made it dead simple to make a multi-agent flow. I have a prose command to orchestrate 5 agents that all coordinate with beads and agent mail. Beautiful. cc @irl_danB
Stop scripting agents.Declare them.
Declarative by default. Reconciled on change, signed with a receipt.
$ npx skills add openprose/proseRuns inside Claude, Codex, or any Prose Complete harness.
Source
This is a Prose program.
A real *.prose.md file: the same source you commit, install, and run.
--- name: json-verifier kind: service --- # JSON Verifier ### Description Validates generated JSON before a downstream system consumes it. ### Requires - `candidate_json`: JSON text to validate ### Ensures - `validation_report`: whether the JSON is valid, with parse errors and line references when validation fails ### Tools - `cli:jq`: JSON CLI available on PATH for syntax validation ### Strategies - when JSON validation fails, report the parse error and location without rewriting the input
Representative output, not a live run.
The Requires go in; the Ensures come out. The model plus your harness is the runtime.
The stack
Language. Framework. Runtime.
OpenProse is three composable layers. You author at the language level; the framework wires it; the runtime executes it.
A programming language for AI sessions. Write a contract in Markdown; declare what should happen. Drop into ProseScript when you want explicit control flow.
*.prose.md files are the source: versioned with your project, in six kinds from service to system.
The intelligent dependency-injection framework. It matches each Requires to an Ensures, resolves dependencies, and produces a compiled manifest the runtime follows.
prose compile lowers your contracts into a dependency graph; on prose run, Forme wires it before the VM executes.
The evented runtime for standing responsibilities. An event wakes a bounded judge; when the evidence is unchanged the verdict is reused at zero token cost; spend scales with surprise, not the clock.
Statuses are up, drifting, down, or blocked, and every judgment is a content-addressed receipt. Early preview.
From the field.
Practitioners discovering that a programming language for AI sessions changes how they work.
As a non-engineer, I cannot not love this idea: Open Prose relies "on the model to do the full orchestration", as opposed to more traditional frameworks who will still "wire all the steps together using a classical runtime (eg:Python)". An absolutely fascinating level of abstraction proposed here... And, on top of offering the project to the community, Dan is incredibly gracious in the replies.
@irl_danB I use in folowing way Skill spawns prose Prose spawns parallel agent Each agent calls a skill Skill used to provide context to prose agents
@Shpigford This looks like a perfect use case for OpenProse prose.md. It will make your e2e workflow more repeatable and reliable. @irl_danB
OpenProse in production.
We run OpenProse on OpenProse. Live responsibilities (scheduled, evented, with durable traces) operating the company. Alpha, frontier R&D, and fully honest about what that means.
Scheduled runs
liveResponsibilities running on a cron, writing durable traces to .prose/runs/.
Eval loops
alphaProse programs that judge their own outputs: evals run inside the same session.
OpenProse on OpenProse
previewThirteen maintained responsibilities operating the company, including this site.
See the full field notes for live outcomes, run traces, and the dogfooding story.
Common questions
- How is this a VM?
- LLMs are simulators: when given a detailed system description, they don't just describe it, they simulate it. The prose.md spec describes a VM with enough fidelity that reading it induces simulation. But simulation with sufficient fidelity is implementation: each session spawns a real subagent, outputs are real artifacts. The simulation is the execution.
- Does this lock me into Claude?
- No. OpenProse programs are framework-agnostic: the language defines an abstract host interface (spawn_session, read_file, write_file, ask_user) that any Prose Complete harness implements. A program written for Claude Code runs on Codex, OpenCode, or Amp without modification. Declarative programs get cheaper and smarter as models improve; you don't refactor every time the landscape shifts.
- Why Markdown, not YAML or a custom .prose syntax?
- Human understanding is the bottleneck. YAML is precise but alien. A custom syntax needs a parser and fights the model's training. Markdown is what your team already writes, what the model already reads, and what already diffs, reviews, and documents itself in every tool you use. OpenProse structures Markdown with contracts; it doesn't replace the medium.
- How is this different from Anthropic's SKILLS.md or AGENTS.md?
- Same substrate: Markdown. Different purpose. SKILLS.md and AGENTS.md document a single capability a model has. An OpenProse program specifies a system: multiple services wired together by contract, with declared inputs, outputs, strategies, and invariants. OpenProse doesn't replace SKILLS.md; it structures it. The language itself installs as a skill.
- Why not LangChain, CrewAI, or AutoGen?
- Those are libraries that orchestrate agents from outside. OpenProse runs inside the agent session: the session itself is the runtime. This means zero external dependencies and portability across any AI assistant.
More questions? Read the OpenProse manual for the full FAQ, VM concepts, and worked examples.
Follow the build.
Field notes from building OpenProse in the open, and an open door if you want to take a real workflow further.