OpenProgram: an agent harness where the docstring is the system prompt
Self-Programming AI Assistant. Capture, automate, and refine all your workflows.
At a glance
- What is it?
- OpenProgram wraps LLM calls inside ordinary Python functions and keeps the control flow in code. It is aimed at engineers who want deterministic orchestration with model judgement at the leaves, and it is licensed AGPL-3.0.
- Who is it for?
- Adopt OpenProgram if your workflows are already Python and you want the model to make decisions inside functions you control, rather than handing it the whole loop. Do not adopt it if you need permissive licensing for a closed product, or if your runtime is Windows and you depend on sandboxed execution, since the README describes that as a separate level.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem OpenProgram targets: LLM flexibility without losing determinism
The README states the trade-off plainly. An LLM is flexible; code is deterministic. Let the model run everything and you get unpredictable execution, context explosion, and no output guarantees. Hard-code everything and you lose the intelligence. OpenProgram is a harness that interleaves the two, described in the project's own framing as Python for the flow you want fixed and the LLM for the judgement you can't script. That is the whole pitch, and it is narrower than the tagline about capturing and automating all your workflows suggests. The audience is Python engineers who already know what their pipeline should do and want a model to fill in the steps that resist a rule. It is not a no-code automation builder, and nothing in the material suggests a visual workflow editor for end users. The repository topics list agent orchestration, agent runtime, multi-agent and workflow automation, which matches the framing: this is infrastructure for people building agents, not a finished assistant for people who want one.
The agentic function primitive and what the docstring actually does
The core mechanism is the @agentic_function decorator, introduced in the first release on 2026-04-03. An agent is a Python function. The README's own example diagram annotates the parts: the docstring is the system prompt, each argument is input for this run, a str argument is the task, and llm() is the model message. Two names appear in that diagram with specific roles. expose is shown to later functions, and render_range is history context from callers. So the design puts the prompt in the same place as the documentation and the call signature in the same place as the input schema. That is a real design decision with a real consequence: refactoring the function changes the prompt, and there is no separate prompt file to keep in sync. The cost is that prompt engineering becomes code review. A reviewer reading a diff sees a docstring change and has to judge it as a behavioural change to a model call, not as a comment edit. The README does not describe how the framework versions or pins prompts, so treat prompt drift as something you manage yourself.
DAG context, spawn, and how multi-agent sessions are wired
The second mechanism is DAG context, described as being for native multi-agent systems. The third is the agentic workflow layer, described as being for trustworthy and self-evolving agents, which is the self-programming claim in the product name. The fourth is event infrastructure, for proactive agents. The release notes give the concrete shape of the multi-agent work: the 2026-07-21 entry lists spawn sub-agents, message across sessions, and file-touching branches in git worktrees. That last item is the interesting one. Running parallel agents in separate git worktrees is a containment strategy that keeps concurrent file edits from colliding, and it implies the framework expects agents to write to disk rather than only return values. The README does not describe the scheduling policy, how conflicts between worktrees are merged, or what happens when a spawned agent fails mid-task. Those are the questions to answer from the source before trusting the multi-agent path with anything that matters.
Getting it running: install, setup, and the commands in the README
Installation is a shell one-liner: curl -fsSL https://openprogram.io/install | sh. On Windows x86_64 or arm64 the README gives irm https://openprogram.io/install.ps1 | iex. The first openprogram run opens a provider setup wizard and then the terminal chat, and the wizard can be re-run with openprogram setup. The Web UI starts with openprogram web and listens on http://localhost:18100. For a non-interactive check the README offers openprogram --print "Introduce yourself in one sentence", which prints a single reply. Additional harnesses install with openprogram programs install <owner>/<repo>, documented in docs/capabilities/installing-harnesses.md. Platform support is macOS, Linux, and native Windows x86_64/arm64 for the CLI and server. The desktop distribution differs by platform: macOS uses an unsigned DMG, Windows uses a signed installer when that artifact is attached to the GitHub Release, and Linux plus Windows without that EXE use the CLI/server runtime and Web UI. A doctor command, openprogram doctor, is referenced in the installation docs. Python 3.11 or newer is required.
Where the harness model breaks down
The constraint the README states most directly is on Windows: sandbox execution remains a separate level. That means the Windows path, including the signed desktop installer, does not carry the same execution isolation as the other platforms, and the documentation does not say when that gap closes. If you are running agents that touch files or the network on Windows, that sentence should decide your platform. Two other limits follow from the design rather than from any statement in the material. First, because the docstring is the system prompt, every agent you write is a model call with a hand-written contract, and there is no described mechanism for validating that the model's output matches what the function promised. The README claims output guarantees as the thing hard-coding gives you, but it does not explain what the harness does when a model returns something the surrounding Python cannot use. Second, the self-programming framing implies agents that modify their own workflows, and the material gives no account of how generated code is reviewed, sandboxed, or reverted. Until you find that in the source, treat self-modification as an area to bound rather than a feature to switch on.
How this differs from LangGraph and similar graph orchestrators
The obvious comparison is a graph-based orchestrator such as LangGraph, where you declare nodes and edges and the framework owns the traversal. OpenProgram inverts that. The Python function is the unit, the decorator attaches model behaviour to it, and the DAG context is a record of what happened rather than the thing you author. If you want to inspect the execution graph as a first-class artifact, or hand the graph to a non-Python tool, the other model fits better. If you want to read your agent as a normal module with imports, tests, and type hints, OpenProgram's approach is closer to ordinary software. The trade is that you lose the framework's ability to reason about the whole graph before running it, since control flow lives in Python and can branch on anything. The README's Stravinsky epigraph about constraints and freedom is doing real work here: the constraint is the function signature, and the freedom is what the model does inside it.
Licence, upgrade cadence, and what to check before adopting
OpenProgram is AGPL-3.0. That is a copyleft licence with a network clause, and it matters for anyone who plans to run a modified version as a service. The repository does not state a separate commercial licence or an exception, so if your product depends on keeping modifications private, this is a blocker rather than a detail. I am not giving legal advice; read the LICENSE file and talk to counsel. On maintenance, the release history shows v0.7.1 on 2026-08-19, then v0.8.0 and v0.8.1 both on 2026-08-24, with the last push to the repository on 2026-09-10. That is a fast cadence for a project still below 1.0, and two releases in one day suggests active iteration rather than a settled API. The project is not archived. The paper listed as arXiv:2606.15874 was accepted at the KDD 2026 Workshop on Agentic Software Engineering, per the news entry dated 2026-06-22, so there is a written rationale to read alongside the code. Pin a version, read the philosophy document before you design around the primitive, and check the platform matrix for your target OS.
Editorial conclusion
Adopt OpenProgram if your workflows are already Python and you want the model to make decisions inside functions you control, rather than handing it the whole loop. Do not adopt it if you need permissive licensing for a closed product, or if your runtime is Windows and you depend on sandboxed execution, since the README describes that as a separate level. Before committing, run openprogram doctor, read docs/capabilities/agentic-programming/philosophy.md, and check the install page for your platform, because the desktop artifacts differ by operating system.
Community notes