The open-source startup, fresh out of Y Combinator, thinks the fix for flaky AI agents isn't a smarter model. It's a better way to tell the model what "done" looks like - written in plain Markdown.
For most of the last two years, building an AI agent has meant writing a long chain of prompts and hoping the model lands somewhere close to what you meant. When it drifts - and it drifts - you patch the prompt, add a guardrail, and cross your fingers again. OpenProse, an open-source startup out of Y Combinator's Spring 2026 batch, starts from a different premise: what if you never scripted the steps at all, and instead just wrote down the outcome you wanted?
That outcome lives in a Markdown file. Not a config wrapper around code, not a YAML pipeline - an actual .prose.md document that reads like a memo and runs like a program. You declare the state the world should be in, and OpenProse's runtime works out what an AI model needs to do to keep it that way. The company's tagline puts it bluntly: "Stop scripting agents. Declare them."
"Write the future as a Markdown contract agents can run, review, and maintain."
-OpenProse, on prose.mdThe move OpenProse is making isn't new to software - it's just new to agents. Databases learned it with SQL: you describe the rows you want, not the disk seeks to fetch them. Infrastructure learned it with Terraform: you declare the servers that should exist, and a reconciler makes reality match. Kubernetes runs the same loop for containers. In each case the trade was the same - give up step-by-step control, get back reliability, portability, and something you can actually reason about.
OpenProse applies that pattern to the messiest new runtime in computing: a large language model doing open-ended work. A program is a set of "responsibilities," each written as a contract with sections like Goal, Requires, Maintains, and Strategies. A responsibility declares what it needs and what truths it promises to keep true. A component called Forme reads those declarations and wires the pieces together by matching contracts, rather than making you hand-connect them.
There is a small piece of philosophy tucked underneath the tooling. OpenProse describes an AI session as a kind of virtual machine and leans on a deliberately provocative line - "simulation with sufficient fidelity is implementation." Translated out of the manifesto voice, it means this: if a model can hold enough of the world in its head to act as though the contract is satisfied, then satisfying the contract is the program running. The Markdown isn't documentation that sits next to the code. The Markdown is the code. That inversion is what lets the whole thing stay readable - there is no second, hidden layer where the real logic lives.
It also changes what a "bug" looks like. In a prompt chain, a failure is usually a step that fired in the wrong order or a hand-off that dropped context. In a declarative contract, a failure is a gap between the state you declared and the state the runtime produced - which is a far easier thing to see and to test. OpenProse leans into that with a fifth contract kind, a plain test, so a program can assert its own truths the way a codebase asserts them in CI.
# prompt chain step 1: fetch the issues step 2: summarize each one step 3: draft a reply step 4: ...hope it worked
# issue-triage.prose.md ### Maintains every open issue has a triage label and a draft reply ### Requires the repository issue list
The detail that makes engineers lean in is portability. An OpenProse program defines an abstract host interface, and any harness that implements it becomes, in the founder's words, an "OpenProse VM." That means a contract you wrote against Claude Code runs unchanged on Codex, OpenCode, or Amp. No rewrite, no per-vendor fork. In a market where every agent framework tends to marry a single runtime, being able to move the same file between them is a genuinely different bet.
Underneath sits Reactor, the recommended runtime, published to npm as @openprose/reactor alongside a companion CLI. Reactor watches the contracts and re-renders only the nodes whose fingerprints have moved - if an input hasn't changed, the work is memoized and skipped. That matters more than it sounds: model calls are the expensive part, and skipping the ones that would produce identical output is the difference between an agent you can afford to leave running and one you can't. Every decision leaves a content-addressed receipt, so a run produces a durable, auditable trace rather than a black box. Dependencies resolve through git with a prose.lock file, the way a package manager pins versions.
The default posture is declarative, but OpenProse doesn't pretend the world is always tidy. When a job genuinely needs choreography - do this, then that, in order - there is an optional imperative mode called ProseScript for the parts that need it. It is a small concession with a clear logic: declare by default, script only where the sequence is the point. That mix is a big part of why early users describe stitching together complex orchestration patterns without pulling in a stack of external libraries.
"People are using OpenProse to make complex agent orchestration patterns without external libraries, dependencies, or any other rigid baggage."
-Dan Barrett, founder, on XOpenProse is the work of Dan Barrett, a software engineer with twelve years behind him and five of those spent building agents - long enough to be unsentimental about what breaks. He is a two-time founder, and the company is small on purpose: a team of three, based in San Francisco after the YC move, with Jose Montes de Oca on AI engineering. The primary YC partner is Pete Koomen.
The culture shows up in an unusual place: the project's own honesty. The repository openly lists what isn't done - benchmarks are pending, cryptographic signing is a v2 item, the roadmap is public. It even treats bug reports filed by AI agents themselves as first-class feedback, which is a quietly telling detail. If your users are increasingly other agents, then the agents may as well file the tickets. For a category that runs on hype, publishing your rough edges is a stance rather than an oversight.
Barrett's own path reads like the setup for the product. Twelve years writing software, five spent watching agents do impressive things and then, without warning, confidently do the wrong one. The pattern he kept hitting - that the model was capable but the scaffolding around it was brittle - is the exact problem OpenProse is pointed at. In May 2026, the approach got an outside read when the engineer and author Kent Beck examined "prose as a programming language" in his newsletter, a signal that people who have spent careers thinking about how software is structured find the framing worth arguing with.
The MarketThe competitive neighborhood is crowded - LangChain, LangGraph, CrewAI, AutoGen, plus workflow engines like Temporal and prompt-optimizers like DSPy. Most of them are imperative: you assemble the steps. OpenProse's wedge is being declarative-first and harness-agnostic at the same time. You describe the destination once, and the same description travels across runtimes.
The business plan follows the familiar open-core shape. The language, spec, and framework are MIT-licensed and free - a quick npx skills add openprose/prose and you're running. The money is meant to arrive with a managed cloud, in early access now, that handles scheduled execution, event triggers, and durable traces for teams that want agents running in production without babysitting them. The seed round, part of the YC batch, is small and early. So is the company.
What You Can Do With ItThe clearest way to picture OpenProse is a "standing" job - work that should keep being true, not a single request you fire and forget. Keep every open issue triaged and drafted. Keep a changelog current. Keep a set of docs in sync with the code. You write the contract once; Reactor keeps reconciling as the inputs move, doing only the work that changed. The internal team dogfoods this with more than a dozen responsibility contracts running its own operations - the company is, in a real sense, partly run by the thing it sells.
That is also the tell for who this is for. OpenProse is not aimed at someone who wants a chatbot to answer one question. It is aimed at the developer or team that has an ongoing obligation - a report that has to stay accurate, a queue that has to stay clear, a corpus that has to stay in sync - and is tired of the maintenance tax of keeping a brittle agent alive to do it. For that person, "declare the outcome and let it reconcile" isn't a slogan. It is the difference between owning a script and owning a service.
"Standing AI jobs, declared in Markdown."
-The OpenProse repositoryWhether "declare it, don't script it" becomes the default for agents is an open question, and OpenProse is early enough that the honest answer is: too soon to tell. But the idea is legible in a way most of the category isn't. You can read an entire agent program the way you'd read a well-written memo - and for anyone who has spent an afternoon debugging a prompt chain, that alone is worth a look.