OpenProse: Declaring Outcomes for Event-Driven Agent Workflows

Dan Barrett introduces OpenProse and colleagues Raymond Weitekamp and Jose Montes de Oca. Barrett recalls that the skill of prompting has changed rapidly, while the challenge of communicating what a person wants remains.

Barrett says that regardless of the model or harness, people still have to express intent. A capable system cannot deliver the right result if its goal is not communicated.

He describes OpenProse as a language and framework built around the idea that language can specify things for agents to make. The question becomes what sentence or contract to write.

In his account, prompting evolved from completion patterns to manually assembling retrieval results and tool calls, then to harnesses that manage context. He views declarative contracts as a further abstraction, rather than evidence that those earlier problems are universally solved.

Barrett proposes naming the desired end state and allowing a harness to choose a route. He borrows composition from software engineering: small contracts can be combined so teams can manage complexity locally.

His preference is to specify what an agent should achieve rather than every step, because different models may find different routes. This is a design philosophy, not a guarantee that a model will meet the goal or spend less.

Weitekamp offers two points to remember: OpenProse programs are text in Markdown, and the workflows they describe can be event-driven rather than chat-based. The open-source approach can run locally; he also demonstrates a hosted service.

For organizations with established controls, he says text-based contracts can sit alongside their chosen agents, models and safeguards. Whether a particular deployment satisfies security and procurement requirements remains an organizational decision.

The language has syntax, but Weitekamp expects people to read and edit programs more often than handwrite them from scratch. An agent can draft a reusable workflow from a description, after which a person can inspect and change it.

He says the runtime and compiler are themselves instructions to an agent. The team describes a Markdown contract as a way to express a multi-agent workflow while using the underlying coding agent's own capabilities.

A contract can declare sub-agents, their skills and tools, along with inputs and expected outputs. A team can specify a required search tool or internal skill and ask the program to stop if a dependency is unavailable.

A schedule, GitHub issue, pull request or webhook can trigger a workflow. In the hosted example, Weitekamp frames a standing job as a contract plus a trigger, with each event starting a run.

He says the application supported schedules and webhooks at the time of the demonstration. An issue-handling program can take an issue as input and aim to produce a commit; a separate program can review pull requests.

The team contrasts independent review with asking the same session to check its own work. A fresh review against a written contract can provide another perspective, though the review still needs to be evaluated.

Asked about specifying the method, Barrett says it is a spectrum. Start with an outcome and leave the method open, then capture a successful trace as a more specific procedure when that helps repeatability or cost.

Weitekamp calls a particularly successful run a golden session that can be turned into a workflow. He notes that model behavior is nondeterministic, so preserving a good example does not guarantee identical results later.

The visible program is only part of the instructions, he says: a larger prompt describes types and execution. The goal is to use a host harness's sub-agent mechanism rather than replace it with a harness specific to OpenProse.

In the hosted demo, a program is displayed in edit mode as Markdown with configuration in its front matter. Weitekamp says it can be exported and shared, while users can rely on an agent to draft the program.

He asks the voice agent to create a pull-request reviewer with the perspective of a skeptical senior developer. The app asks for confirmation before the drafting action incurs a cost.

He also shows manual job setup: choose a trigger, repository, contract and model. For a GitHub pull request, the job can run a review when the configured event arrives.

Weitekamp describes using these reviews while building the product itself. Some changes passed after one round; others went through many rounds as developer agents responded to review feedback.

Barrett emphasizes that each fresh session is compared with a declarative contract. He presents this as a way to reduce self-review bias, while independent review is still not proof that every defect has been found.

The presenters discuss using a decision model to check a real result against an ideal contract. They say this verifier was an idea for future work at the time, not a feature demonstrated as already deployed.

Weitekamp compares the approach with DSPy: he characterizes DSPy as isolating model calls inside structured code, while OpenProse gives the agent more freedom to interpret and execute the workflow. These are his descriptions of the two approaches.

The tradeoff is that results depend heavily on the model, and the agent may itself declare the contract complete. The team suggests a separate verifier and event router as possible additions.

Asked about reinforcement learning, Barrett says text contracts can be versioned and shared and could potentially support training. The presenters say they were discussing that direction, not currently doing it.

The drafted skeptical reviewer is ready. Weitekamp confirms deployment because each subsequent pull request can cause a paid run, then shows the new standing job in the application.

Barrett turns to an on-premises use case. He says a company can combine the open application layer with its own harness and approved models; an entirely internal deployment depends on the actual infrastructure and model choices.

The team treats operating procedures as institutional knowledge as well as instructions. Keeping workflows and model processing in-house can be relevant where organizations do not want to send sensitive data or practices to external providers.

The finance example documents quantitative models. Barrett says documentation may need updating periodically or after triggering events, and covers purpose, testing conditions, dependencies and other compliance requirements.

He describes this as expert-intensive work. Because many requirements are written in prose, the team expresses them as a contract and runs it through a coding agent to produce a draft.

In the demo, he starts a program in Codex and shows the Markdown kernel that tells the agent how to discover and interpret instructions. The separate program specifies the desired documentation and conditions.

The sample concerns a public SOFR curve rather than private bank data. The generated document appears on screen, but the workshop does not establish that the draft is ready for production or regulatory submission.

Barrett reports that his team compares outputs with historical work, elapsed time and expert ratings. He also acknowledges that approval by compliance teams, auditors and regulators is a separate part of the process.

A participant asks how people create the contract. Barrett says an agent can help iterate using the project's guidance and anti-patterns, but extracting a person's actual intent remains difficult.

Weitekamp says chat can be useful when someone does not yet know what they want. A reusable contract becomes more appropriate when the task is better understood; an assistant can help formulate it.

Barrett says their intended use cases are recurring tasks where reliability, repeatability and auditability matter. He recommends ordinary chat for exploratory or one-off work.

Contracts can be composed so a run must satisfy several requirements. Barrett also describes upstream dependencies that may cause downstream work to become stale when inputs change.

The team is exploring a decision model as a semantic classifier for detecting changed state and deciding whether to rerun downstream work. Barrett makes clear that this integration was still being built.

Weitekamp gives an article workflow as an example: a researcher uses a specified search tool, a writer follows examples, and a copy editor reviews the draft. A parent agent decides whether the result meets the stated goal.

Barrett explains that intermediate contracts can serve as checkpoints. Each stage must satisfy its own conditions before the next proceeds, while agents retain flexibility in how they satisfy those conditions.

Weitekamp lists workflow shapes such as fan-out and fan-in, adversarial review, and loops with an exit condition. The team says these patterns rely on the capabilities of the underlying agent and, for many complex cases, isolated sub-agents.

Asked about the basis of the framework, Barrett cites engineering experience and internal empirical tests. He says they use tests to assess whether a shorter kernel still conforms to expected behavior.

Weitekamp describes composing existing skills into a staged workflow, such as asking questions and then applying a test-driven development process. The speakers say they would like to test specific specification-driven workflows rather than claiming every combination already works.

Barrett closes by saying that users apply OpenProse not only to software development but also to operations, product management and quantitative-model documentation. The common need is a repeatable way to express and carry out work.