Harness-agnostic
Contracts state requirements; hosts supply tools, state, and execution capabilities. Learn the public skill interface and its implementation limits.
Harness-agnostic
A contract states requirements independently of a particular host. In the public skill format, an agent follows the OpenProse VM instructions and maps them to the host's tools. A compatible host must support the needed operations, inputs, and permissions to carry out the contract.
Reusing a contract preserves its requirements. It does not provide unavailable tools or make different models produce identical results. Check the host's capabilities against the work you are requesting.
The VM primitives a host must provide
A host is Prose-Complete when it can map the abstract VM operations onto its own tools. There are five, and they are the entire contract between the language and any host:
| Primitive | What the host must do |
|---|---|
spawn_session | Run a render (a responsibility or a called function) in an isolated agent/session with a prompt, an optional model, and access to the declared input/output paths |
ask_user | Pause for missing required caller input, and resume with the answer |
read_state / write_state | Read and write run state through whatever durable store the host provides |
copy_binding | Publish a declared output through that same durable store; never publish undeclared scratch |
check_env | Confirm an environment variable exists without exposing its value |
These operations define the VM interface. A particular contract can still need
data access, tools, permissions, and serving features beyond the interface
itself. The host maps spawn_session to its session mechanism and must honor
the declared paths and isolation requirements.
The mapping is the host's job, not yours. Codex-style and Claude Code-style environments are the primary documented targets. A Prose-Complete host with a real subagent primitive runs multi-agent contracts; a host without one may execute trivial single-render runs inline and must report the limitation rather than pretend.
Reuse Markdown across compatible hosts
A contract can be reused across compatible hosts without rewriting its requirements. The host changes; the conditions the work must satisfy remain. Portability requires a compatible skill version and the capabilities used by the contract.
Concretely, a shell line like:
prose run src/hello.prose.mdmeans "ask the selected agent harness to embody the OpenProse VM and execute this contract." Swapping the host changes who provides the five primitives, not what the contract asks for.
The session embodies the VM: there is no parser
The public skill has no separate parser or bytecode interpreter. An agent reads and interprets the Markdown instructions.
Instead, a SKILL-loaded agent session is the VM. When a Prose-Complete host
loads the open-prose skill and reads a contract, the session itself carries
the execution semantics: it resolves the contract, spawns renders, maintains the
world-model, and records receipts. The intelligence is the runtime. Even a compile
step is an agent session. The topology, the canonicalizer, and the validators
are all session output, not parser output.
A prose CLI is not a replacement VM. It forwards a run to the selected harness
and never parses .prose semantics itself. The CLI is plumbing; the
SKILL-loaded session is the machine.
This separates the authored requirements from a particular runtime binary. The agent and host still need the capabilities required for each run.
The language/harness seam
Keeping the two layers distinct keeps both honest. The boundary is sharp:
- The language has one source-derived compile.
prose compilelowers the*.prose.mdsource set into compile-phase IR. That IR is a pure function of the source set and nothing else: no clock, no run history, no host state. - Runtime mechanics are sibling state, owned by the host. A host's
receipts, forecasts, freshness tracking, and reconciler decisions are runtime
state owned by that host. They are not IR fields and not new
*.prose.mdsyntax. A host may keep none of this, some of it, or all of it; the language does not require any of it.
So when a host advertises receipts, fingerprints, memoization, or a reconciler, read those as one host's runtime, not as language features. A deterministic host can use them to re-render only what moved, so cost scales with surprise rather than the clock. The contract you author is the same whether or not a host chooses to memoize it. One such host today is Reactor, the deterministic harness built alongside the language; its reference lives with the packages in the openprose/prose repo.
Implementation status
Language requirements and implemented enforcement are different. The
public language specification at revision 770cebc9
records several gaps, including these facts about reference harness 0.3.3:
- Self-driven freshness uses a fixed poll interval rather than scheduling each
facet at its
valid_untiltime. - Deterministic postcondition validators exist, but the commit gate is not connected to the live path; commits rely on render self-attestation.
- Durable receipts do not retain all the specified failure detail.
That specification also identifies enforcement of ### Invariants and
cryptographic signing as gaps. A declared limit, a receipt, and verified
satisfaction are different things. Check the version and status of the host
you select before relying on those capabilities. These docs do not establish
that a newer host has closed the recorded gaps.
Where to go next
Setup
Install the skill, author a first contract, and run it where your agent lives.
Contracts
The authored surface: the five kinds and the recognized sections.
The canonical execution behavior lives in the open-source open-prose skill in
the openprose/prose repo. These docs are
orientation; if the docs and the skill disagree, trust the skill.