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

OpenProse is a markdown-based declarative language/framework for composing event-driven, multi-agent AI workflows where users declare 'what' outcome they wan...

Stop Telling Agents How: A Research Synthesis on OpenProse and Declarative Agent Programming

Abstract

This synthesis examines OpenProse, a markdown-based declarative language for composing event-driven, multi-agent artificial intelligence (AI) workflows. Its central thesis holds that practitioners should declare what outcome is required - a contract - rather than specifying how an agent should achieve it, permitting the harness and its sub-agents to self-shape toward contract satisfaction. The approach is situated within a four-stage progression of prompting practice: token completion, context engineering, harness engineering, and contract engineering. Analysis covers the framework's markdown kernel (approximately 70,000-80,000 tokens), its header-based type system, job composition via contract-plus-trigger pairing, and patterns including adversarial review and procedure pinning. Evidence is drawn from a pull-request review deployment and an enterprise quantitative-model documentation use case, with regulatory documentation costs estimated at $10-50 million annually for large banks. Implications concern reliability, auditability, and on-premises data sovereignty.

1. Introduction

The persistent difficulty in applied AI is not raw model capability but intent transfer: how a practitioner's internal objective becomes a specification a model can reliably execute. As articulated in the source material, "no matter how smart the thing gets, there is still this challenge of how do I get out of my brain the thing that I want and get it into the super intelligence that is just going to carry it away and do everything for me." This framing motivates OpenProse, a declarative substrate for expressing desired outcomes as machine-readable, human-legible contracts.

OpenProse is described variously as "a programming language for agents" and "one giant prompt." It is event-driven rather than chat-based, open source, and executable locally via NPX-distributed skills or through a hosted runtime at run.pros.md. A contract, in this context, is a declarative specification of required inputs, outputs, sub-agents, and available tools, against which an agent's work is evaluated - independent of the procedural steps used to produce it.

This synthesis analyzes four themes: (i) the abstraction trajectory from prompting to contracts; (ii) the structural design of OpenProse programs; (iii) empirical evidence from deployed workflows, including a PR-review system and a regulatory-documentation use case; and (iv) comparative positioning against adjacent frameworks such as DSPy, with attention to limitations and open research directions.

2. Background and Related Work

Prompting practice has progressed through successive layers of abstraction. Initial work concerned token completion - shaping immediate next-token behavior. This yielded to context engineering, concerned with curating information supplied to a model, and subsequently to harness engineering, addressing orchestration scaffolding around model calls. The claim advanced in this analysis is that each layer has progressively been absorbed by harnesses themselves; Anthropic's self-modifying harness topologies exemplify this absorption, with harnesses dynamically constructing their own control flow. The resulting inference is that contract engineering constitutes the current frontier: once an outcome is named precisely, a sufficiently capable harness can fan out, loop, or reconfigure itself to reach it.

The design borrows two established software engineering principles: composition over inheritance and declarative over imperative specification. DSPy serves as the primary comparator, since both frameworks abstract multi-step language-model workflows. They diverge in philosophy: DSPy treats each language-model call as a strictly typed black box with enforced input/output contracts at the call level, whereas OpenProse embraces a "fuzzy," AI-as-compiler approach in which the entire runtime is itself a natural-language artifact interpreted by the model.

3. Core Analysis

3.1 Structural Design of OpenProse Programs

OpenProse programs are written entirely in markdown, with overridden H3 headers functioning as a de facto type system. Programs declare sub-agents, the skills assigned to each sub-agent, the tools or command-line interfaces available to them, and the required inputs and outputs. If a declared dependency - a skill or tool - is unavailable in the executing environment, the program does not compile or run, enforcing a form of static validation analogous to compiled languages despite the substrate being natural language.

A job is formally defined as a contract paired with a trigger. Supported hosted triggers currently include webhooks (e.g., GitHub, Slack) and cron schedules, with the webhook surface described as open-ended and configurable beyond these examples. Contracts are composable: multiple contracts can be injected into a single execution for simultaneous satisfaction, mirroring the composition-over-inheritance principle inherited from software engineering.

Notably, the runtime itself - the "compiler" - is not a conventional program but a prompt of approximately 70,000-80,000 tokens. As stated directly in the source material, "You are the compiler. This is not an analogy. You are the compiler. And it seems to work." This literalism distinguishes OpenProse from frameworks that use natural language merely as an interface layer atop conventional orchestration code.

3.2 Reliability Mechanisms: Adversarial Review and Procedure Pinning

Two mechanisms address the reliability demands of production workflows. First, an event-driven adversarial review pattern mitigates self-review bias: rather than having the same model session check its own output, a fresh agent session evaluates the work against the declared contract. This separation is evidenced in the PR-review demonstration, where some reviews required up to fourteen rounds before passing, with each round benchmarked against a fresh session rather than accumulated chat context.

Second, a "pin the how" feature allows an expensive, high-capability model to solve a task once, after which that successful trace is codified into a more deterministic procedure for repeated, lower-cost execution. This pattern reflects a pragmatic middle ground between pure declarative specification and cost-sensitive production operation: the "how" is discovered once at higher cost and then fixed, while the contract remains the enduring unit of validation.

3.3 Harness Agnosticism and Deployment Flexibility

OpenProse is explicitly designed not to replace a harness's native sub-agent system - such as those in Claude Code or Codex - but to be compiled by it. The stated design goal is "bring your own harness": OpenProse constitutes one additional layer rather than a competing execution environment. This requires that the underlying harness support sub-agents; harnesses limited to single-agent execution, such as vanilla Python agent loops, are described as insufficient for the complex workflows OpenProse targets.

This agnosticism enables the enterprise use case of on-premises deployment. In the quantitative-model documentation scenario, OpenProse programs run against an organization's own models and harness, avoiding the transmission of proprietary data or institutional knowledge to external model providers. The source material frames internal documentation and standard operating procedures as "institutional operational knowledge" that organizations should not expose to large labs.

4. Technical Insights

Several implementation details carry direct engineering relevance. The markdown kernel's size (70,000-80,000 tokens) indicates that OpenProse programs impose non-trivial context overhead, a cost that must be weighed against the reliability gains from compile-time dependency checking. The requirement that all declared skills and tools (e.g., Exa for search) be available for compilation introduces a validation step uncommon in ad hoc prompting workflows, reducing silent failure modes at the expense of upfront configuration rigor.

The hosted trigger surface - GitHub webhooks and cron jobs, demonstrated in production across "dozens of PR review runs over 3-4 days" - suggests current maturity is concentrated in software-development-adjacent event sources, with broader webhook support positioned as configurable rather than fully generalized. The framework's ability to differentiate review behavior between staging and production environments within the same contract-based program indicates that environmental context can be encoded without altering the underlying contract structure, a useful separation of concerns for teams managing multiple deployment targets.

A notable trade-off is audience fit: adoption is reported as stronger among non-software-engineers (operations, product management, quantitative documentation specialists) than traditional software engineers, suggesting the declarative, English-readable format lowers barriers for domain experts while potentially offering less novelty to engineers already comfortable with imperative orchestration code.

5. Discussion

The broader implication of OpenProse's design is a reframing of the prompting discipline as compiler design conducted in natural language. This has consequences for auditability: because contracts are explicit, composable, and markdown-native, they can be exported, versioned, and reviewed independently of any particular execution trace, addressing a core requirement of regulated environments such as the quantitative-finance documentation case, where output was benchmarked against historical human-produced results and reviewed by domain experts.

A significant gap concerns verification cost and routing. The discussion of potential integration with "Jev"/decision models as fast, cheap verifiers or semantic memoizers - detecting when upstream state changes warrant downstream agent work - indicates that the current architecture may still invoke full-scale model reasoning for decisions that could be handled by cheaper classifiers. This remains speculative and unimplemented, as does the proposed use of models as event routers.

The explicit contrast with DSPy highlights an unresolved tension in the broader field between typed, black-box composability and fuzzy, compiler-as-model flexibility. OpenProse's acknowledgment that all-text workflows constitute an ideal substrate for future reinforcement learning applications - though not yet implemented - signals an anticipated but unrealized research direction connecting declarative contract specification to learned policy optimization.

6. Conclusion

OpenProse contributes a concrete instantiation of contract-based, declarative agent programming, demonstrating through a PR-review deployment and an enterprise quantitative-documentation use case that naming outcomes rather than procedures can yield auditable, repeatable, and cost-manageable AI workflows. Its harness-agnostic design and on-premises applicability address data-sovereignty concerns relevant to regulated industries.

The practical takeaway for engineers is that declarative contract specification, compile-time dependency validation, and adversarial fresh-session review constitute reusable patterns independent of any specific tool adoption. Future work should examine cheaper verification mechanisms, formalize the comparison with typed frameworks like DSPy, and explore reinforcement learning over the fully textual substrate OpenProse provides.

Sources

• Stop Telling Agents How - Dan Barrett, Raymond Weitekamp & Jose Montes de Oca, OpenProse - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub