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: function --- # JSON Verifier ### Description Validates generated JSON before a downstream consumer uses it. ### Parameters - `candidate-json`: JSON text to validate ### Returns - `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 Parameters go in; the Returns come out. The model plus your harness is the runtime.
The stack
Author. Compile. Run.
OpenProse is one language and two phases. You author contracts; Forme compiles them into a wired topology once; Reactor runs it, re-rendering only what changed.
A declarative language for standing AI work. Write a contract in Markdown; declare what should stay true. Drop into ProseScript when you want explicit control flow.
*.prose.md files are the source: versioned with your project, in five kinds from function to responsibility.
The compile phase. It matches each Requires to the Maintains that satisfies it, draws the subscription edges, and emits the wired topology the runtime follows.
prose compile lowers your contracts into the topology once; intelligent at compile, dumb at run.
The deterministic reconciler for standing responsibilities. It fingerprints each node's inputs; when nothing moved it skips the render at zero token cost. Cost scales with surprise, not the clock.
Every decision is a content-addressed receipt, rendered or skipped. Early preview.
From the field.
Practitioners discovering that a declarative language for standing AI work 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 .agents/prose/runs/.
Eval loops
alphaProse programs that evaluate 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 composition: responsibilities wired together by contract, each with declared inputs, the truth it maintains, 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.