Stop Teaching AI What to Do: OpenProse's Declarative Agent Programming

While everyone is discussing context engineering, agent frameworks, and multi-agent orchestration, a counterintuitive idea has surfaced: the more you tell AI "how" to do something, the more you waste its intelligence. In a tech talk on Bilibili, OpenProse founder Dan and core team members Raymond and Jose presented their answer—an agent programming language written entirely in Markdown, event-driven, declarative rather than procedural.

From Prompt Engineering to Contract Orchestration: Three Abstraction Leaps in Five Years

Dan recounted his starting point: five years ago, he was voted "best prompt engineer" in the EleutherAI Discord. At the time, he thought the skill would hold its value for many years; its actual lifespan was only two or three. Since then, the industry has gone through three rounds of rising abstraction levels: first context engineering (manually stuffing RAG results, tool calls, and search results into the window), then frameworks automatically filling in context, and over the past eight to ten months, the frameworks themselves have begun to "self-modify"—Anthropic's talk on workflows demonstrated the ability to dynamically manage sub-agents with topology.

If prompts are solved, context is solved, and frameworks are solved, what's next? OpenProse's answer: name the end state you want and let the system find the path itself. This borrows from the declarative paradigm in classic software engineering—tell the system what you want, not how to do it.

Context Engineering is a practice that emerged after prompt engineering, referring to the systematic design, organization, and dynamic filling of information sent into a large model's context window, including retrieval-augmented generation (RAG) results, tool call return values, conversation history, system instructions, and more. The core problem it solves is that a model's reasoning quality depends heavily on what is in the context and in what order it appears. Early approaches manually assembled prompt templates; later frameworks like LangChain and LlamaIndex automated retrieval, tool orchestration, and memory management, turning context construction from hand-written strings into configurable pipelines. What OpenProse criticizes is precisely that this layer still implicitly contains a large number of "how-to" procedural instructions, and it advocates handing this layer over to the model to decide for itself.

What OpenProse Is: All Text, All Events

Raymond summed up the project in two sentences: first, it's just Markdown, everything is text, essentially one giant prompt; second, it's event-driven, not chat. You build multi-agent workflows triggered by triggers rather than conversing with a model. It is open source, can run locally via an NPX skill, and also offers a hosted version at run.prose.md.

This "pure text" nature brings several practical benefits. For regulated industries (such as banking and financial services), there's no need to involve procurement or IT departments—you can create multi-agent workflows with any code agent and any security measures; for people who don't write code, as long as they can read logical English, they can read and edit OpenProse programs; for AI engineers, it is even "a framework that isn't a framework"—because its compiler and virtual machine are themselves just giant prompts.

The minimal example given in the talk shows the core idea: a piece of Markdown declaring the goal, what the contract needs to maintain, and the available skills and tools. The team even writes "you are the compiler" directly in skill prompts—according to Raymond, this non-metaphorical phrasing works quite well.

The Core Value of Declarative: Don't Make Expensive Models Do Cheap Models' Work

Why insist on declarative? Dan's reasoning is very engineering-minded: if you tell an agent how to do something, you actually waste cost and intelligence—these steps could be done by cheaper models, and smarter models should find the implementation themselves.

This philosophy forms a spectrum from "what" to "how" in practice. Users can initially declare outcomes very loosely and let strong models explore on their own; once it's done, they can solidify the agent's execution trace into a deterministic "how," reducing the cost of subsequent runs. As the team responded when an audience member pressed: this is equivalent to encoding an excellent "painting" as a reusable process, letting nondeterminism gradually give way to determinism.

During the demo, Raymond used a single sentence to have the in-app agent generate a Pros program: whenever a new pull request arrives, review it in the tone of "a senior developer who dislikes AI-generated code." The entire generation process is presented as draft cards, and any operation that incurs cost must be manually confirmed—the team considers this best practice.

Declarative programming vs. procedural programming is the key to understanding OpenProse. Procedural programming (such as C or Python scripts) specifies "how" step by step: first loop, then branch, then assign, with control flow explicitly written by the programmer. Declarative programming (such as SQL, HTML, React's JSX, Terraform) only describes "what you want"—SQL says which rows I want, not how to scan the index; Terraform says how many machines of what specs I want, not which APIs to call. The execution path is derived by the compiler, query optimizer, or runtime itself. The benefits of declarative are optimizability, composability, and readability; the cost is that behavior depends on the underlying implementation, and results may vary by engine. OpenProse brings this paradigm to agent orchestration, letting the model act as the "optimizer" to plan steps itself, and thus also inherits the characteristic that "results vary by model."

GitHub Event-Driven in Practice: The Reverse Pressure of 14 Review Rounds

The most intuitive case is the GitHub Webhook-driven PR review workflow. Whenever a new PR arrives, a group of review agents is triggered: some features pass in a single review round, while others go through as many as 14 feedback loops until the review agents reach consensus. Raymond revealed that the system autonomously completed dozens or more pull requests within a few days; he himself was only responsible for expressing dissatisfaction in the staging environment, requesting changes to the trigger method, and then letting the system modify itself.

The key difference here is that the task is not considered complete until the development agent incorporates the feedback. Unlike chat-based processes, each review is a brand-new "painting" and is benchmarked against the contract written declaratively. In Raymond's words, this pulls the model out of the "self-confirmation" loop—don't let the same model check its own work. An audience member promptly suggested: isn't this a perfect scenario for a one-shot classification model like Jev? The team agreed, saying that the contract is the ideal state and reality is the messy state, and that using a fast, cheap classification model as the final verifier is very appropriate; the capability is already in the pipeline.

A Real Use Case: Compliance Simulation Documents for Quantitative Models

The most concrete implementation case of the whole session came from finance: a large bank's quantitative models need updated regulatory documentation every three years (or upon changes). A bank has about 4,000 models, rewritten year after year, costing larger institutions $10 million to $50 million annually.

OpenProse's approach is to write compliance requirements as Pros programs—regulatory documentation is naturally a set of compliance contracts. In the demo, Codex was used to launch the kernel and run the program, generating documentation for the SOFR curve, a public model, using a relatively cheap model. The team says several large companies have adopted the permissively licensed open-source core to build their own stacks on top of their own harness and approved models. For institutions, more sensitive than data is operational knowledge—standard operating procedures cannot be thrown over the wall to large labs.

A Mirror Relationship with DSPy: Boundaries with Jet-like Models

Dan admitted that OpenProse is the exact opposite of DSPy: DSPy treats each LLM call as a black box, with code and interfaces fully deterministic and typed; OpenProse believes models are smart enough to be the compiler and puts everything in the fuzzy domain. The cost is that results vary by model, and agents can claim "I have satisfied the contract." Therefore the team is clear: OpenProse itself has no place in the Jet-like model domain, because it understands language rather than generates it; but it is especially suited to combining with the hosted version as a fast, cheap verifier at the end of the workflow. The team is also building a router so that events are automatically routed to the corresponding task without manually clicking buttons.

Another possibility that was pointed out is reinforcement learning: all contracts are text, naturally suited to version control and naturally suited to RL. The team says it hasn't been implemented yet but has discussed it with potential customers—once everything is written as text, the door to RL opens.

DSPy is a programming framework proposed by Stanford that treats LLM calls as optimizable modules, declares input and output types with signatures, and then automatically searches for prompt and example combinations through a compiler. Its philosophy is "treat prompts as hyperparameters," keeping code and interfaces deterministic and strongly typed, with the model as a black box. OpenProse is the opposite: it hands the entire program to the model for interpretation and execution, trusting the model to act as the compiler, accepting fuzziness and nondeterminism in exchange for expressiveness and low cost. The two are not competitors but cover different reliability needs: choose DSPy when you need strict types and reproducible pipelines, and choose OpenProse when you need to quickly build event-driven, readable, auditable multi-agent workflows. Understanding this mirror relationship helps determine when to use which type of tool.

Not Every Scenario Should Use Contracts

Dan poured cold water on the scene, and incidentally explained why chat apps are so popular: if you are in exploration mode and don't even know what you're looking for, chat is the best entry point—you don't need to know what you want, and the magic of generative AI is returning results automatically. OpenProse targets a different kind of scenario: tasks that need to be executed frequently, reliably, repeatably, and audibly. The built-in agent in the app can help draft contracts, but the team has hard-coded confirmation prompts for any operation that incurs cost.

Composability is another core of the framework. Multiple contracts can be injected into the same run, and the agent must satisfy all of them simultaneously; event-driven dependency propagation is similar to React's caching mechanism, where upstream state changes trigger downstream, and cheap semantic classification models make "judging whether something is outdated" feasible. The team even joked on stage: you could put Matt Pocock's specification-driven development process entirely into a Pros program and execute it.

An Honest Caveat

It should be noted that the above content is mainly based on a single-source tech talk, and the data in the article (such as 4,000 models and tens of millions of dollars in annual costs) are oral statements by the speakers and have not been cross-validated by independent sources. OpenProse is still in an early stage, and how reliable its "all Markdown" promise is in actual use requires more public cases to test. But the direction itself is worth watching: as models become stronger, perhaps the way to constrain them is not longer prompts but clearer contracts.

One-line Summary

OpenProse advocates writing declarative contracts in pure Markdown and letting strong models plan on their own rather than handwriting steps.

Paragraph Summary

OpenProse is an event-driven declarative agent programming language written entirely in Markdown. Founder Dan and team members Raymond and Jose explained its philosophy in a Bilibili tech talk: tell AI what result you want, not how to do it. The article traces three abstraction leaps from prompt engineering to context engineering to framework self-modification, pointing out that procedural instructions waste strong models' intelligence and cost. OpenProse declares goals and constraints in the form of contracts, with the model acting as a compiler that plans its own path; in the GitHub PR review case, review agents went through as many as 14 feedback loops, using fresh reviews against the contract rather than letting the model self-check. The quantitative model compliance documentation case shows that a bank with about 4,000 models rewritten year after year, with annual costs reaching tens of millions of dollars, can significantly reduce costs through contract-based processes. The article also draws boundaries: exploratory scenarios are still suited to chat, while OpenProse targets frequent, reliable, auditable tasks and, being the opposite of DSPy's philosophy, is suited as a Jet-like verifier and event router.