A new kind of language for a new kind of computer.

A programming language for the Intelligent VM.

A long-running AI session is a Turing-complete computer. OpenProse is a programming language for it.

MIT licensed · 1,000+ GitHub stars · 7,000+ installs · Backed by Y Combinator

The session is the computer.

Last generation, you were a conversant with the model. This generation, you are a tool call to it.

What changed when the model moved outside the chat.

Chatbot generationIntelligent VM
Runs to send the next messageRuns in an outer loop, outside of a chat
Tools serve the replyThe reply is a tool
You are the conversantYou are a tool call
ChatGPT · Claude.ai · GeminiClaude Code · Codex · Press · Pi · Amp

The anatomy. An Intelligent VM is a sufficiently intelligent model plus a harness. The harness needs three things: a loop (the clock), a REPL-like execution environment (the CPU), and a filesystem (memory and disk). Give a capable model those three and it simulates a computer you can program — in English.

You’re probably already programming this computer. Every SKILLS.md, every CLAUDE.md, every well-crafted system prompt is a program in English. Markdown is already the source. Coding agents are already the runtime. The discipline just doesn’t have a name yet.

And those programs are loosely typed. No dependency resolution. No inversion of control. No composition primitives. One file grows to a thousand lines and it starts to fray — the model loses the plot, agents collapse into each other, the same work gets done twice. OpenProse is a subset of Markdown that supplies what’s missing: contracts, shapes, semantic auto-wiring, and a catalog of composition patterns. The same Markdown you already write — with structure where it helps.

Everything is either a Component or the Container.

The system has two concepts. Everything else is an implication.

Component

A service with a contract. It may delegate to other components (via shape) or not. There is no architectural distinction between a “leaf” and a “coordinator” — a component that delegates is just a component whose shape mentions other components. Same file format, same contract surface, same rules.

Container

The intelligent orchestrator ( Forme + harness) that reads all components, auto-wires them by contract matching, and executes the dependency graph. Analogous to Spring’s DI container, but wires by understanding rather than type matching.

The rough map. If you’ve written Spring, this is mostly a rename.

SpringProse
@ComponentA .md file with kind: service
@AutowiredContract matching (requires matched to ensures)
@SpringBootApplication + @ComponentScanEntry point file with kind: program + services: [...]
@Test + JUnit assertionskind: test with fixtures:, expects:, expects-not:
applicationContext.xmlmanifest.md (the materialized wiring graph)
new Service() inlineExecution block with explicit let + call statements

Learn OpenProse in under five minutes.

Valid Markdown. No custom syntax.

YAML frontmatter for metadata. Markdown sections for the contract. Multiple services per file via ## headings. The entry point is whichever file has kind: program.

researcher.md
---
name: researcher
kind: service
shape:
  self: [evaluate sources, score confidence]
  delegates:
    summarizer: [compression]
  prohibited: [direct web scraping]
---

requires:
- topic: a research question to investigate

ensures:
- findings: sourced claims from 3+ distinct sources, each with confidence 0-1
- sources: all URLs consulted with relevance ratings
- if sources are unavailable: partial findings from cached data, flagged as stale

environment:
- SEARCH_API_KEY: provided by the runtime for web search access

errors:
- no-results: no relevant sources found for this topic

invariants:
- audit log is appended with this invocation's outcome

strategies:
- when few sources found: broaden search terms
- when many low-quality sources: prioritize academic and primary sources

That file is the whole component. Multi-service programs use ## headings to delimit services within a file, or split one service per file in the same directory. Programs can import others from the registry at p.prose.md.

Six sections. Most are optional.

The container wires on requires matched to ensures. The other four — errors, invariants, strategies, environment — declare failures, truths, behaviors, and runtime dependencies when a service needs them.

SectionMeaning
requires:What the caller must provide (inputs + constraints on them).
ensures:What this service produces on success. Conditional clauses express degraded or fallback outputs.
errors:Declared failure conditions this service can signal, with accompanying data.
invariants:What is true regardless of success or failure. Checked after the run completes.
strategies:Prioritized behavioral options the model selects from based on state.
environment:Runtime dependencies provided by the container, not by the caller. The model references them by variable name — never reads, logs, or includes the value in any output.

Declarative by default. Imperative when needed.

Three levels of specification. Each level's explicit code is what the level above would generate automatically if omitted. You trade adaptability for determinism, and you decide where on the spectrum to sit.

LevelWhat you writeSpring analogWhen to use
1 · Contracts onlyrequires + ensures on each component@AutowiredDefault. Trust the model. Programs improve as models improve.
2 · Wiring declarationExplicit dependency graph mapping outputs to inputsapplicationContext.xmlWhen you want to inspect, debug, or pin the graph.
3 · Execution blockExplicit let + call sequencenew Service() inlineFull procedural control. Deterministic — model follows exactly.
Level 3 — explicit execution block
### Execution

let { findings, sources } = call researcher
  topic: question

let evaluation = call critic
  findings: findings
  sources: sources

let report = call synthesizer
  findings: findings
  evaluation: evaluation

return report

Within execution blocks the full imperative grammar is available: parallel:, loop until, for each, try/catch, if/elif/else, choice.

The framework wires by understanding.

Forme is Phase 1 of a program run. It reads the contracts, resolves requires to ensures, and emits a manifest. Analogous to Spring's DI container — but it disambiguates by reading natural language, not by matching types.

Traditional containerForme container
Resolves by type signatureResolves by semantic understanding of contracts
Fails on ambiguous typesDisambiguates by reading natural language
Requires explicit annotationsInfers relationships from requires to ensures
Static wiring at compile timeIntelligent wiring at run time

The wiring algorithm

  1. Read the entry point — find the file with kind: program.
  2. Resolve component files for each name in services.
  3. Read each component's contract — frontmatter, requires, ensures, errors, invariants, strategies, environment.
  4. Auto-wire — match requires to another component's ensures; exact name first, then semantic equivalence, then shape-informed signals.
  5. Build the dependency graph — topological sort for execution order; identify parallelization opportunities.
  6. Collect environment declarations with service attribution.
  7. Validate — circular dependencies, missing components, unresolvable requirements.
  8. Copy source files into the run directory at services/{name}.md.
  9. Write manifest.md — the complete wiring graph.

Read the Forme specification →

Composites, controls, and roles.

Forme ships reusable structural components in three categories. Composites combine services into multi-agent patterns; controls manage delegation flow; roles fill leaf slots.

Composites

multi-agent structural patterns

worker-critic
Work, evaluate, retry until accepted
proposer-adversary
Propose then attack; parent decides
dialectic
Argue positions; disagreement is output
ensemble-synthesizer
K agents work, synthesizer merges
witness
Independent observation; discrepancies flag ambiguity
ratchet
Advance and certify; never roll back

Controls

delegation flow patterns

pipeline
Sequential transformation chain
map-reduce
Split, delegate in parallel, merge
gate
Check precondition, fail-fast if unmet
retry-with-learning
Retry with failure analysis between attempts
progressive-refinement
Iteratively improve to threshold

Roles

single-agent leaf behaviors

critic
Evaluate quality; accept or reject with reasoning
verifier
Check formal correctness against specification
summarizer
Compress preserving key information
classifier
Categorize input into a given set of labels
extractor
Map unstructured input to a typed schema

Prose Complete — the minimum capability threshold.

A harness is Prose Complete if it can run a .prose program of arbitrary complexity. Maintain state in context or files, spawn real subagents, evaluate discretion conditions intelligently. The LLM is the CPU. The harness is the computer.

A System is Prose Complete if it can run a .prose program of arbitrary complexity.

Known Prose Complete harnesses. Same program, different computer.

HarnessTypeStatus
Claude CodeCoding agent (Anthropic)Primary dev + prod harness
OpenCodeOpen-source coding agentProse Complete
PiOpen-source coding agentProse Complete
Codex CLICoding agent (OpenAI)Prose Complete
AmpCoding agent (Sourcegraph)Prose Complete
PressPurpose-built RLM runtime@openprose/press on npm

Two-phase execution. Forme writes the manifest; the harness reads it.

PhaseWhoInputOutput
1 · WiringForme.md component filesmanifest.md
2 · ExecutionProse VM (harness)manifest.mdProgram output

The manifest is a Markdown file. You can read it, diff it, and check it in. Inspect it to debug; pin it for determinism; regenerate it if the underlying programs change. Single-component programs skip Phase 1 entirely — the .md file is the program.

Results on standard benchmarks.

Press running Prose programs on current-generation RLM benchmarks.

BenchmarkBest resultNotes
ARC-AGI-285.28%Python reference via arcgentica
LongMemEval89.8%Near-SOTA (Raymond Weitekamp, dspy.RLM)
OOLONG58.4%Long-context aggregation, Gemini 3 Flash

The trace is the record.

The runtime emits structured events propagated through the full delegation tree. Every event carries runId, invocationId, parentId, depth, and timestamp.

Lifecycle

  • run:start
  • run:end
  • invocation:start
  • invocation:end
  • iteration:start
  • iteration:end

LLM

  • llm:request
  • llm:response
  • llm:error

Delegation

  • delegation:spawn
  • delegation:return
  • delegation:error

State

  • sandbox:snapshot

Token tracking and cost attribution are built in — events capture input/output token counts per LLM call, enabling cost breakdown by phase, service, and depth.

prose status --graph reconstructs the DAG of runs from upstream: headers in state.md, showing which runs consumed which prior runs. Lineage is visible across program boundaries.

Specs, code, and runtimes.

The public record of how Prose works. All MIT.