Stop Telling Agents How — Dan Barrett, Raymond Weitekamp & Jose Montes de Oca, OpenProse

Dan Barrett’s early skill as a prompter had a short shelf life. Models improved, people began assembling retrieval and tool results into context, and harnesses took over more of that assembly. The persistent problem was communicating what a person actually wanted.

OpenProse starts with a contract: a description of the desired outcome and the conditions it must satisfy. Barrett’s bet is that a capable harness can decide how to fan out work or loop toward that outcome. Prescribing every step can lock the workflow to an older approach and leave newer model capabilities unused. Contracts can also be composed, so a team can manage requirements locally and combine them for larger jobs.

Raymond Weitekamp describes OpenProse as text interpreted by an agent: the program is Markdown, and the compiler and runtime instructions are themselves prompts. An agent can write a program from a user’s description; the person can then read and edit the reusable workflow without hand-authoring its full syntax. The intended host is an existing harness such as Claude Code or Codex, rather than a replacement for its subagent machinery.

A contract can specify inputs, outputs, subagents, skills and tools. Weitekamp’s search example requires Exa and its CLI: if the dependency cannot be found, the program should not run with an arbitrary substitute. That is a deliberate constraint on how a task is performed, even when the larger outcome remains declarative.

In the hosted app, a job is a contract plus a trigger. The triggers described in the talk include schedules and webhooks. A GitHub issue can supply the input to a program whose intended output is a commit; a pull request can trigger a separate review workflow. These are standing jobs, so the user need not start a new chat for each event.

A contract need not remain maximally open-ended. Barrett describes starting with a loose goal and a capable, expensive agent, then taking a successful trace and codifying its procedure. The resulting workflow can give later runs more specific instructions and potentially reduce their cost. Weitekamp calls the source a “golden session”: a particularly good run worth turning into a reusable program.

The tradeoff is flexibility against repeatability and cost. Capturing a procedure does not make model execution deterministic. Nor is the small Markdown program the whole prompt: Weitekamp estimated that the underlying skill was then around 70,000–80,000 tokens, and the team said it was working to shorten it.

In run.prose.md, Weitekamp asks the app’s agent to create a reviewer for new pull requests in the run-prose repository: a grumpy senior developer skeptical of AI-generated code, but constructive and evidence-based. The agent drafts the program and its wiring. He confirms the drafting action because it costs money, and later confirms deployment because future pull requests will trigger paid runs.

The manual route exposes the same pieces: create a job, choose the GitHub pull request trigger and repository, attach a review contract, select a model, and deploy. The program’s Markdown front matter also carries the hosted configuration; Weitekamp describes exporting the file and importing it elsewhere to recreate that setup.

The review history answers a practical question: how much backpressure did this add while building the webhook feature? Weitekamp describes dozens of pull requests over a few days. Some passed after one round; some took 14 rounds before the reviewer agents aligned and let the change pass. He also asked an agent to change triggering behavior on staging while using the review system itself, so developer agents had to incorporate its feedback.

The point of the separate review is to counter the confidence of an agent checking its own work. Barrett describes fresh sessions evaluating work against the declared contract. This supplies a repeatable criterion and a new context for review; it does not establish that every accepted change is correct.

Weitekamp identifies a weakness in the approach: the agent can say it has met the contract, and outcomes vary with the model running it. He contrasts this with DSPy as he uses it: typed interfaces and deterministic code isolate individual model calls, whereas OpenProse gives the agent more responsibility for interpreting and executing the workflow. Both aim to express complex work at a higher level; they put different amounts of the execution in the model’s hands.

The team proposes two uses for fast decision models: checking a completed job against its contract, and routing incoming events to the appropriate job. The verifier was not in the demonstrated system. Reinforcement learning over text contracts and runs was another idea under discussion, not something the team was doing at the time.

For a bank, the contract can capture institutional procedures as well as output requirements. Barrett describes running OpenProse in-house with an organization’s own harness and approved models, keeping both data and operating knowledge inside that environment. The hosted app is one way to try the workflow, not a prerequisite for the approach.

The demonstrated workflow documents quantitative models, which may require updates annually, every three years, or after specified changes. Documentation can describe a model’s use, testing conditions and relationships with other models. Barrett starts the program in Codex by booting a Markdown kernel and running the contract. The kernel gives the agent operating instructions and paths to other documents; the program states the desired documentation and requirements.

What did that produce? The demonstration finishes with documentation for a public SOFR curve model, avoiding internal bank data. The output is an example of the requested artifact, rather than proof that it meets every regulatory requirement.

Barrett reports that the team compares outputs with historical work and completion times, and asks quants to rate them. He claims the workflow has been much cheaper than manual documentation, while acknowledging that compliance, auditor and regulator acceptance remains separate work. The talk supplies no comparative measurements for those claims.

Writing the contract is still a demanding part of the work. The kernel contains authoring practices and anti-patterns that an assistant can use while helping a person refine a contract. Weitekamp suggests chat may be better when the user does not yet know the shape of the problem; Barrett positions OpenProse for work that must be repeated, audited and made reliable.

Composition works in more than one way. A run can receive several contracts and have to satisfy all of them. Contracts can also act as intermediate checkpoints: satisfying one allows a dependent stage to proceed, while agents retain flexibility within each stage. Separately, the team describes an event-driven dependency system in which an upstream change can trigger downstream work. A proposed decision-model component would judge whether a cached dependency is out of date; that component was still being built.

An article workflow illustrates what can be packaged. The input is a topic and the output is an article with specified constraints. A researcher uses the required search skill and CLI; a writer receives ten examples of the desired style; a copy editor has its own role. The parent decides when the result is good enough to stop, making the quality of that judgment dependent on the model. Other possible shapes include fan-out and synthesis, adversarial review, or a loop until a condition is met.

Those more complex shapes rely on the host’s ability to manage subagents with isolated context. The Markdown specifies the work and its dependencies; the existing harness supplies the execution machinery.

The team says its kernel reflects engineering practice and internal benchmarks, including an evolutionary process for testing whether shorter versions still conform. Weitekamp’s “Auto Pocock” example packages a sequence of skills into one program: an initial questioning workflow, test-driven development and subsequent stages, with each subagent loading the skill required at its stage.

Barrett suggests composing OpenProse with an existing spec-driven development specification, while acknowledging that he had not yet tried that combination and did not know how the instructions would interact. He closes with a wider set of uses already observed by the team: operations, product management and quantitative-model documentation alongside software engineering. Readable Markdown makes the workflow accessible to the people who know those jobs.