OpenProse: Declaring Intent Instead of Prompting Procedures

From Prompt Engineering to Declarative Contracts

Dan, the creator of OpenProse, opens with a personal anchor: five years ago he was named the best prompter in the EleutherAI back rooms Discord, a skill that held its value for roughly two or three years before the field moved on. His core argument is that the surface of the work keeps changing (next-token completion, hand-filled context windows, RAG and tool-call stuffing, harnesses that manage context automatically, and now self-modifying harness topologies that fan out sub-agents), but the underlying problem persists. People still have to get what is in their heads into the machine.

His answer is to treat language as a creative force and to borrow from classical software engineering. The principles he lists are composition over inheritance, declarative over imperative, and telling the system what to achieve rather than how. The reasoning is economic as well as philosophical: prescribing the procedure locks in a cost and forfeits the chance for a more capable model to find a better path, or for a cheaper model to suffice. He calls the declared outcome a contract, and the goal is that contracts compose, so that complexity can be managed locally across a team or company.

What OpenProse Is

Raymond Weitekamp frames the project with two takeaways. First, it is just markdown, a programming language for agents in which the entire program is effectively one large prompt. Second, it is event-driven rather than chat-based. Agents are not conversed with to do work; they are triggered by cron schedules, webhooks, GitHub issues, or pull requests and then run multi-agent workflows to fulfill a contract.

A point that recurs throughout is that the “framework” is itself a prompt. The runtime and compiler are prompts too, and Raymond notes his favorite line from the system prompt: “You are the compiler. This is not an analogy.” The system is open source, installable through npx skills, and also available as a hosted app at run.prose.md. The authors position it as a layer that sits atop any harness (Claude Code, Codex, and others) rather than being a harness itself. Their stated goal is to be compiled by the harness instead of competing with it.

For regulated industries, the all-text property is pitched as a practical advantage. Banks can adopt it without new procurement, IT deployment, or infrastructure, using whatever coding agent, inference provider, and guardrails they already have. Raymond also argues that if you can read logical English, you can read OpenProse. The syntax is deliberately not the focus. The language is designed to be read and edited by people, with agents drafting the programs from natural-language descriptions, so users are not expected to learn a schema.

Agents, Skills, and Declared Wiring

A contract can declare sub-agents, assign specific skills to them, and specify available tools. Raymond’s example is a preference for the Exa search tool over generic web search, which is faster and cheaper for him. If a required skill or CLI is missing, the program simply does not run; there is no fallback. In this sense a program is wiring together a set of capabilities, and a missing dependency means a failed compile. Inputs and outputs are likewise declared, and the contract is the thing the run must deliver.

Dan’s remark about the harness is worth emphasizing: OpenProse deliberately avoids touching the harness’s own sub-agent system. Claude Code and Codex have different sub-agent mechanisms, and the authors do not want their prompt to be specific to either. They describe the core requirement for a harness as having sub-agents, along with bash or a VM-isolated code mode. Fan-out, fan-in, adversarial review, and loop-until-condition patterns, which Anthropic described in its dynamic workflows post, can all be expressed as OpenProse programs and run on any agent with sub-agents.

Event-Driven Jobs and Triggers

In the hosted app, a job is a contract paired with a trigger. Triggers currently include cron schedules and webhooks, which in practice cover Slack, GitHub, and most other services. The authors describe a “code factory” model in which standing jobs continuously triage and act on incoming events.

Raymond demonstrated this with GitHub. Any new issue can trigger a program that attempts to resolve it, with the output being a commit. Pull requests trigger an adversarial review loop. He points to the Anthropic workshop observation that a model reviewing its own work is biased toward approving it, and says the same is true of humans. In his setup, the implementing agents receive back-pressure from a separate reviewer agent operating through pull requests.

Raymond also describes using the system on itself. He developed the GitHub webhook feature by forcing the program to develop the program. He reports dozens of PRs over a few days, some passing after one review round and others requiring around fourteen rounds before the reviewer agents aligned and let the change through. He also mentions a discrepancy between dev and prod reviews that he caught and asked an agent to correct on staging.

The key architectural claim is that every fresh session is benchmarked against a declared contract, not against the previous session’s self-assessment. This breaks the self-confidence loop where the same model checks its own output.

Demo: A Grumpy Senior Reviewer

The demo shows the chat-based agent, the “pros write” function, which drafts a new program from a natural-language request. The request is for a PR reviewer that acts as a grumpy senior developer who dislikes AI-generated code. The agent drafts the program and asks for confirmation before any action that costs money, which the authors treat as a best practice. The job is then deployed with a GitHub pull request trigger, and the resulting reviewer appears in the jobs list.

The authors are candid that the generated programs can be long. The full runtime system prompt is around 70,000 to 80,000 tokens, which they are trying to slim as models improve. Beneath the markdown sits a type system that overrides it with a clear schema and a specific prompt for orchestrating complex multi-agent work.

Pinning a Winning Run and Reliability

A central question from the audience is why one would specify the “what” at all if the “how” can be fixed later. The answer is that OpenProse supports a progression. You begin with loose declarations and an intelligent, expensive model that figures out the path. Then you take the agent trace from a successful run and codify it into a more deterministic, procedural program. That shift drives down cost, moving the system along the spectrum from pure intent toward explicit procedure.

Raymond adds that LLMs are non-deterministic, that “pinned” model endpoints are changing under compute constraints, and that expectations drift. The first time a workflow dazzles, people want it every time, and reliability then becomes the gap. Codifying a golden session is the remedy.

OpenProse Versus DSPy

Raymond frames the intent as similar to DSPy, providing an abstraction layer over which complex workflows can be expressed, but the implementation is the opposite. In DSPy, each LLM call is a black box, isolated behind typed interfaces, with all control flow in deterministic code. In OpenProse, the AI itself is the compiler, and everything remains in fuzzy territory. The tradeoff is clear. Running the same program on a small model versus a frontier model produces very different results, and the agent decides when it is done.

Dan describes himself as an old-school DSPy user whose joke about the framework was that you must know what you want in advance, because you write the signature of the output first. OpenProse is looser, though it does ask you to know your use case. The authors say it is not for one-off exploration, where chat is better. It is built for workflows that are frequent, reliable, repeatable, and auditable.

Decision Models and the Verifier Role

The team discusses JEPA-like decision models, which they call “system one” models, as a natural fit for two places. The first is as a fast, cheap verifier at the end of a job, judging whether a messy real-world state meets an ideal contract. The second is as a semantic memoizer or cache. Running agents to determine whether upstream state has changed is expensive, whereas a cheap classifier can decide when something is stale and trigger everything downstream. This connects to the composition model, where contracts form a dependency graph and changes trickle down, similar to React-style memoization. They note this portion is still being built.

Raymond also mentions a planned router, so that a single GitHub event stream could be dispatched to the right job without manual wiring of issues versus pull requests.

Reinforcement Learning and Token Efficiency

An audience member asks why one would not reinforcement-learn against these contracts, given the volume of runs. The authors say they are in conversations with prospects about this. Because the language is all text, it is well suited to RL. They have not yet reached the volumes where it becomes essential. If one hosts a model with a roughly 100,000-token prefix, one can build more token-efficient representations of the prompt.

Demo: Bank Model Documentation

The finance use case is the most compelling. Regulators require banks to periodically update model documentation for quantitative models, typically every year, every three years, or upon certain changes. Dan says large banks may have around 4,000 models, and that this work is labor-intensive, costing between $10 and $50 million annually for some of the largest institutions. The documentation covers intended use, testing conditions, upstream dependencies, and other requirements that regulators, internal auditors, and compliance teams check.

Dan argues the regulatory requirements are themselves an OpenProse program. The workflow passes two things to the agent: a public “kernel” file and a program describing the contract. The kernel is markdown written for the agent rather than people, which is why it appears unformatted. He compares it to a bootloader or an index that tells the agent where to find other documents. The demo runs in Codex with a relatively cheap model. The generated example documents the public SOFR curve model, so no internal bank data is exposed. A question from the audience about how the documentation looks is handed off to quants for review.

The kernel also contains best practices and anti-patterns for declaring outcomes. Dan acknowledges that the hard part is extracting intent from people’s heads, and that this workflow addresses only part of that problem. The authors claim this approach is considerably cheaper than manual documentation, and that they benchmark it against historical results and the time teams spend, with quants rating output quality. Dan is candid that getting such output through compliance and auditing remains a separate hurdle.

Open Source, Deployment, and Data Control

Dan presents the on-prem deployment story as the most interesting enterprise path. The framework can run in-house on open models, with a bring-your-own-harness architecture serving as the application layer. The authors stress that the most valuable asset is not the data but the institutional operational knowledge encoded as standard operating procedures, which organizations would not want to send to frontier labs. The core is published as open source under a permissive license, and several large companies are already using it.

Composing Contracts

Composition is presented as a core feature rather than inheritance. Multiple contracts can be injected into a single run, and the agent must satisfy all of them. A contract can serve as a checkpoint in a directed acyclic graph of intermediate steps, and each intermediate contract is met before the next begins. This still lets the authors specify the path in part while leaving the agents flexible about how each intermediate step is achieved.

A simple example is an article workflow. The output is a specified article type with length and style constraints, the input is a topic, and a parent agent decides when the article is good enough to exit. Sub-agents include a researcher using a particular search CLI, a writer trained on the author’s ten best recent articles, and a copy editor. The entire multi-agent pipeline can be written in roughly 100 lines of markdown. Dan says these templates are a key difference from drag-and-drop workflow builders, because the shape is declared as contracts rather than as a fixed graph of nodes.

The authors also describe spec-driven development as a natural fit. Someone has wired a popular TDD-style workflow into a single program and had every sub-agent load the next skill in sequence. The team has not yet tested a formal spec-driven development contract in full, but considers it a promising direction.

Closing Observations

The discussion ends on a note about who uses the system. Engineers use it to build software, but more users are applying it to operations, product management, and quant model documentation. The authors suspect that the blend of markdown documentation and workflow automation appeals more to non-engineers. Chat, they argue, is an ideal interface for exploration and little else. For repeatable, auditable workflows, the contract is the better interface, and OpenProse is their attempt to make it the default way of expressing what you want from an agent.

• Tags:
• Prompt Engineering
• Multi-Agent Systems
• DSPy
• LLM Agents
• Event-Driven Architecture
• Agent Harness
• Declarative Programming
• Agent Workflows
• Model Documentation
• Contract Composition