7 things OpenProse changes about multi-agent workflow design

OpenProse is an open-source framework that lets you write multi-agent AI workflows as declarative markdown contracts, then compile them with whatever coding agent you already use. Its authors describe it as a language for stating outcomes rather than procedures, so the harness decides how to reach the declared end state.

What is OpenProse and how does a markdown contract work?

OpenProse is an open-source framework that describes multi-agent AI workflows as declarative markdown contracts, which a coding agent then compiles and executes. Its creator, Dan Barrett, presented it with Raymond Weitekamp and Jose Montes de Oca at the AI Engineer conference in October 2026. The contract states the goal, the required inputs and the expected outputs; the harness decides the steps.

The design borrows from software engineering rather than prompt libraries. Barrett frames it as composition over inheritance: prompts are written declaratively, not procedurally, so the agent can choose a cheaper path when one exists. A contract can spawn subagents, attach specific skills and tools, and refuse to compile when a declared dependency is missing.

Two ideas define the project's placement. It is all text, so a program can be exported as a plain markdown file and shared; and it is event driven, so work starts from a trigger such as a webhook, a pull request or a cron schedule rather than a conversation. Weitekamp said the runtime reads a kernel plus a program, and both are simply markdown.

The authors are explicit that the syntax is not the entry point. Users are expected to describe the work in ordinary language, let an agent draft the program, then edit the result. That drafting step is why the hosted product ships an agent that writes contracts on a user's behalf.

For a reader comparing this with prompt engineering, the shift is in what gets written down. A prompt optimises one model call. A contract records the conditions a finished job must meet, which makes the same file reusable across harnesses and reviewable by people who do not write code.

The project's public entry points are a hosted app at run.pro.md and a locally installable skill. The install command shown on stage was npx skills add openprose, which adds the skill to an existing coding agent rather than installing a separate runtime.

Why declarative contracts beat step-by-step prompting

Declaring an outcome instead of a procedure lets a stronger model find a cheaper execution path, and OpenProse treats that as its main efficiency argument. Barrett's reasoning is direct: if you dictate every step, the harness cannot substitute a simpler route, and you pay for instructions it did not need.

The framework's own history is a three-stage argument about where abstraction moves. Barrett described token-level prompting, then hand-built context engineering with retrieval and tool results, then harnesses that fill context automatically. In his account, the last stage is now being abstracted again by agent topologies that manage their own subagents.

That leaves a gap he thinks language can fill. If prompting, context management and harness topology are each handled by the platform, what remains is the act of naming the required result precisely. OpenProse calls that skill contract composition and publishes a best-practices guide inside the kernel for agents to follow.

The approach has a documented ceiling. One audience question asked why the team does not simply reinforce-learn the workflows, and Weitekamp agreed that plain text is well suited to that, while noting the team has not hit the volumes where it matters. The claim is a direction of travel, not a shipped training pipeline.

A second limit came up in discussion: the model that declared the work is also the one judging whether it finished. The authors describe this as a self-confidence loop and treat fresh sessions checked against a contract as a partial remedy, not a solved problem.

How jobs, triggers and the hosted app fit together

A job in OpenProse is a contract plus a trigger, which turns a reusable workflow into scheduled or event-driven work. Weitekamp demonstrated the hosted app at run.pro.md with two trigger types implemented at the time of the talk: webhooks, which cover services such as GitHub and Slack, and cron schedules.

The demonstration used a pull request review written as a contract. A user asked for a program that reviews pull requests in the tone of a grumpy senior developer who dislikes AI-generated code, and the app's drafting agent produced the wiring, including the model choice and the trigger. The user then had to confirm before the job could spend money on future runs.

Cost controls are part of the interface, not an afterthought. Weitekamp stated that any action that can charge or spend money requires an explicit confirmation click. That is a product decision that keeps an autonomous job from starting to bill a user's account on its own.

The back-pressure demonstration is the most concrete use of the pattern. Weitekamp said the review jobs had processed dozens of pull requests over roughly three to four days while he was building the GitHub webhook feature, and one pull request went through fourteen review rounds before the reviewing agents aligned and let it pass.

That volume figure comes from the speaker's own dashboard during the talk, so treat it as first-hand experience rather than a measured benchmark. It does show the shape of the workflow: a developer agent proposes, a separate review session checks the proposal against the contract, and the loop repeats until the contract is met.

The hosted version is one delivery path. Barrett stressed that the same framework can run on-premises with a company's own harness and approved models, which is the version he said financial services prospects care about most.

Claude Code, Codex and the bring-your-own-harness boundary

OpenProse is not a harness and does not try to be one; it is a layer compiled by whichever coding agent the user already runs. The team demonstrated it inside Claude Code, Anthropic terminal coding agent, and inside Codex, with an explicit statement that the interface is harness agnostic.

The boundary matters because harnesses differ. Claude Code has its own subagent system, and Weitekamp said the team deliberately avoids overriding it; Codex organises subagents differently again. The project's own prompt therefore stays generic and leans on whatever subagent support the host provides.

Weitekamp named one practical requirement: the host needs subagents for the more complex workflow shapes. A bare agent without subagent support limits which fan-out, adversarial review or loop-until patterns can be expressed, which is a constraint on the patterns rather than on the markdown itself.

The runtime is described as a prompt, and Weitekamp said the full system prompt or skill behind the compiler has run close to 70,000 to 80,000 tokens. He also said the agents are now capable enough that the prompt can be trimmed, which makes the token count a moving figure rather than a specification.

What the finance demonstration claims, and what it does not

The finance demonstration produced model documentation for the SABR volatility model, a widely used interest-rate model, using only public data rather than any bank's internal material. Barrett ran it in Codex with a deliberately cheap model so it would finish during the session.

The workflow targets a real compliance burden. Barrett described quantitative model documentation that banks must refresh annually or on defined events, covering each model's purpose, the conditions it was tested under and which other models reference it upstream, as required by regulators and read by internal audit and compliance.

The business claim is large and should be read as a vendor estimate. Barrett said a big bank may hold around 4,000 models requiring annual re-documentation, and that the work is worth between $10 million and $50 million a year at some of the largest institutions. He also said the team benchmarks against historical results and has quants rate the output.

No published benchmark, sample size or accuracy figure was shown for that comparison, and the demonstration output was reviewed informally by anyone in the room with quantitative experience. The cost saving is therefore a first-party claim made by the vendor's co-founder, not independently verified evidence.

Barrett was candid about the remaining obstacle. Getting this kind of documentation through compliance, auditors and regulators is separate work from producing a draft, and he said so directly. A generated document is an input to a review process, not a replacement for one.

For regulated teams, the architecture argument runs on what stays inside the perimeter. The contract can run on open models, on the organisation's own harness, with its standard operating procedures kept in-house rather than sent to a model lab, which is a deployment option rather than a compliance certification.

How OpenProse compares with DSPy and workflow builders

OpenProse and DSPy, the Stanford-originated framework for programming language-model pipelines, share an intent to put an abstraction layer over complex model work, but they implement that intent in opposite directions. Weitekamp drew the comparison himself during the session.

DSPy isolates each model call behind typed interfaces and deterministic code, so the opaque model touches as little as possible. OpenProse keeps everything in fuzzy language and asks a capable model to act as the compiler, which makes output quality depend far more on which model and harness run the program.

Workflow builders occupy a third position. Barrett described drag-and-drop tools as a different way of thinking about the same problem, and argued that composing intermediate contracts along a directed acyclic graph gives you a declared route through checkpoints while still leaving each step room to manoeuvre.

The table below compares the three approaches on dimensions the speakers actually discussed rather than on invented scores.

Frequently asked questions about OpenProse

• Is OpenProse a programming language or a prompt template? It is a markdown-based language with a type system that the authors say is meant to be read and edited by people and drafted by agents. Weitekamp called it, informally, a programming language for agents, and the compiler is itself a prompt run by the host harness.

• Does OpenProse replace Claude Code or Codex? No. It runs inside an existing harness and relies on that harness for subagents and execution. Dan Barrett described it as a layer above the harness, so a team keeps its current coding agent and approved models while writing contracts in markdown.

• What triggers can start an OpenProse job? In the hosted run.pro.md app demonstrated in October 2026, the implemented triggers were webhooks and cron schedules. Weitekamp said the team is open to adding more triggers based on feedback, so treat the list as current at the time of the talk.

• Has the bank model-documentation workflow been independently benchmarked? No public benchmark was shown. Barrett described internal comparisons against historical documentation and ratings from quantitative staff, and acknowledged that clearing compliance and auditors is a separate challenge from generating the draft.

• Who are Dan Barrett, Raymond Weitekamp and Jose Montes de Oca? They are the OpenProse team presenting at the AI Engineer conference in October 2026. Barrett created the project; Weitekamp built the hosted app and described it as his work; Montes de Oca contributed to the engineering and framing of the talks.

• Is OpenProse open source? The team describes it as an open-core project with a permissive license that can be brought in-house. The open portion is the framework and language; the hosted application is a separate service, so verify the license terms for the specific component before depending on them.

• Can OpenProse run on-premises with open models? Yes, according to the speakers. Barrett said the framework can run on-premises with a company's own harness and approved models, keeping standard operating procedures in-house rather than sending them to a model lab, though compliance obligations remain with the organisation.

• Why not just use chat for the same workflow? The team's answer is repeatability and auditability. OpenProse targets work that must happen often and be checked against a fixed contract, while chat suits one-off exploration where the desired outcome is still unclear.

• What happens when a contract cannot be satisfied? The program is designed to fail rather than proceed silently: a missing declared skill or tool means the program does not compile. Once running, review loops repeat against the contract, and the app requires confirmation before any action that would spend money.

Turning a repeating AI workflow into a versioned contract

The most transferable idea from the talk applies well beyond OpenProse: if a task must be repeated, checked and audited, write down the conditions for success once and let agents work against that document. Barrett frames the result as institutional operational knowledge stored as documentation, closer to a standard operating procedure than a prompt.

A practical sequence follows from the demonstrations. Write the outcome and the constraints in plain language, let an agent draft the contract with required inputs, outputs, skills and tools attached, wire it to a trigger, then run it and review what comes back against the original conditions.

1. Draft the contract in plain language, naming the inputs and the expected output.
2. Attach the skills and tools each subagent is allowed to use, and let the program refuse to compile if one is missing.
3. Bind the contract to a trigger such as a pull request webhook or a cron schedule.
4. Review completed runs against the contract, and keep the sessions that produced good work as candidates for reuse.
5. Pin a successful trace into a narrower procedure when cost matters more than flexibility.

Barrett described the last step as shrinking the ratio of what to how. A run that a strong expensive model solved can be codified into a more specific, cheaper procedure, which is the framework's mechanism for bringing cost down over time.

The authors also pointed to verification as unfinished work. A fast classifier deciding whether a messy real-world state satisfies an ideal contract is a natural fit for the non-generative decision models the audience asked about, and the team said that work is coming rather than shipped.

Where the pattern needs more evidence

OpenProse makes a coherent argument that contracts should live in text rather than in chat history, but several of its headline claims remain first-party. The bank cost figure, the review-round counts and the documentation quality all come from the vendor's own session rather than an independent evaluation.

The open-core and permissive-license description also needs checking against the actual repository before a team depends on it, because open-core arrangements differ in which components a license covers. The hosted app and the language skill are separate deliverables with separate terms.

What is verifiable is the architecture: a markdown kernel plus a markdown program, compiled by a harness the user already trusts, triggered by an event rather than a conversation. Teams that need repeatable, auditable AI work have a concrete pattern to test, and the price of testing it is a text file.

Brazilian developers who want to see this pattern applied in a structured learning path can look at the Crazystack TypeScript program and the Bootcamp do Dev Doido, both taught by Gustavo Dev Doido. Skala Blog covers agent tooling and engineering practice, and the writer of this piece occasionally follows material from those programs. This article was written in English, so a reader should expect the linked courses to be delivered in Portuguese.

Frequently asked questions

• What is OpenProse? OpenProse is an open-source language and framework for writing multi-agent AI workflows as declarative markdown contracts. A host coding agent such as Claude Code or Codex compiles and runs the contract, which states the desired outcome rather than the steps.

• How do OpenProse workflows start? A job is a contract plus a trigger. The hosted app demonstrated in October 2026 supported webhooks, such as GitHub events, and cron schedules, so a workflow runs when something happens rather than when someone types a message.

• How does OpenProse differ from DSPy? DSPy keeps model calls inside deterministic, typed code. OpenProse does the opposite: its compiler is itself a prompt, and it asks a capable model to interpret and execute a fuzzy markdown contract, which makes model and harness choice far more consequential.

• Is the finance model-documentation workflow a proven cost saver? The cost range was stated by a co-founder rather than measured in a published study. The claim covers quantitative model documentation at large banks, and the team says internal comparisons and practitioner reviews support it.

• What are the main limits of OpenProse today? Execution quality depends on the host harness and the chosen model, the host needs subagent support for complex patterns, and the framework still relies on the model to declare its own work complete, which the team calls a self-confidence loop.

Source video