# OpenPraxis > OpenPraxis — Spec-driven development platform for autonomous coding agents at scale. Factory that assembles software products from components autonomously. If for example Ai model is a CNC machine, OpenPraxis is a factory. - **Type:** MCP server - **Install:** `agentstack add mcp-k8nstantin-openpraxis` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [k8nstantin](https://agentstack.voostack.com/s/k8nstantin) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [k8nstantin](https://github.com/k8nstantin) - **Source:** https://github.com/k8nstantin/OpenPraxis - **Website:** https://github.com/k8nstantin/OpenPraxis/releases/latest ## Install ```sh agentstack add mcp-k8nstantin-openpraxis ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # OpenPraxis [](https://github.com/k8nstantin/OpenPraxis/actions/workflows/ci.yml) [](https://github.com/k8nstantin/OpenPraxis/blob/main/go.mod) [](https://goreportcard.com/report/github.com/k8nstantin/OpenPraxis) [](https://opensource.org/licenses/Apache-2.0) [](https://github.com/k8nstantin/OpenPraxis/releases) ### Build products with AI agents — end to end. **OpenPraxis is a full DAG execution engine for AI-assisted software development.** One captured Idea becomes a Product. A Product holds chained Manifests (versioned specs with deliverables). Each Manifest holds chained Tasks that dispatch agents (Claude Code, Cursor, Codex) in isolated git worktrees. Every action is captured, every completed Task is audited independently of the agent, every cost unit attributes back to the spec that drove it — on a single graph, visualised, searchable, self-hosted. ```mermaid flowchart TB Idea[/"Ideacaptured concept"/]:::idea -->|becomes| P P(["Producttop-level spec"]):::product -->|holds| MH([Manifests]) MH --- M1["Manifest Aversioned spec"]:::manifest MH --- M2["Manifest B"]:::manifest M1 -->|holds| T1a["Taskatomic"]:::task M1 --- T1b["Taskatomic"]:::task T1a -. depends_on .-> R1a[ReviewTask]:::review T1b -. depends_on .-> R1b[ReviewTask]:::review M2 --- T2a["Taskatomic"]:::task T2a -. depends_on .-> R2a[ReviewTask]:::review classDef idea fill:#1a1a2e,stroke:#3b82f6,stroke-width:2px,color:#e4e4e7 classDef product fill:#4c1d95,stroke:#8b5cf6,stroke-width:3px,color:#fff classDef manifest fill:#1e3a5f,stroke:#3b82f6,stroke-width:2px,color:#e4e4e7 classDef task fill:#0a0a0f,stroke:#71717a,color:#a1a1aa classDef review fill:#0a0a0f,stroke:#f59e0b,color:#f59e0b ``` **Progression:** *Idea* → *Product* → *Manifest* → *Task (atomic)* → *Review Task*. Idea at the top — the captured concept. Product beneath it as the spec root. Manifests hang off the Product as independent specs — they do **not** depend on each other by default; each Manifest is its own fireable unit. Tasks hang off each Manifest as grapes — the Task is the **atomic unit of work** that dispatches one agent in one worktree. Each Task pairs with its own Review Task, chained via `depends_on`: when the parent Task completes, the Review Task auto-activates, inspects the real-world side effects, and posts `review_approval` or `review_rejection` on the parent. The watcher's gate findings surface as comments; the Review Task owns the verdict. *(Manifest-to-manifest and product-to-product `depends_on` dependencies are supported in the model — see [Workflow Engine reference](docs/workflow-engine.md) — but the primary pattern keeps Manifests independent. Complex cross-manifest coordination becomes useful as agents mature.)* **Cost control, independent quality audit, cross-agent comparison, and forecasting are outcomes of the engine** — not separate tools bolted on. ### Features - **Trace-grounded feedback loop.** *(v0.9)* Every retry sees what the previous run attempted — prior execution digests and agent review comments injected into the prompt automatically. Agents stop repeating the same mistakes. Pass rates per task queryable via API. An autonomous proposer loop evolves the prompt scaffold when tasks plateau. [Full guide →](docs/trace-grounded-feedback.md) - **End-to-end product build graph.** One Product, many independent Manifests (fire each on its own), many Tasks per Manifest with paired Review Tasks chained via `depends_on`. The graph plans, dispatches, audits, and costs every step from initiative spec to merged commit. IDE agents, orchestration SDKs, and observability proxies each cover a slice; OpenPraxis owns the whole chain. [Detailed comparison →](docs/compared-to-ai-agent-tools.md) - **Line-item cost attribution.** Every cost unit spent attributed to a task, a spec, a product, a day, and the authorizing policy. - **Pre-fire cost forecasting.** Predict what the next run, manifest, or sprint will cost from your actual history, per model, per agent, per spec shape. - **Independent quality audit.** Every completed task audited against spec, build, and diff by a separate watcher; paired review tasks post the final verdict. - **Cross-agent efficiency comparison.** Claude Code vs Cursor vs Codex measured on your real code — cost per approved task, review-approval rate, diff cleanliness. - **End-to-end audit trail.** Every action, decision, and verdict persists with full provenance for compliance, postmortems, and root-cause analysis. - **Team-wide shared memory.** Specs, memories, decisions, and rules sync across every engineer's machine over the local network — no SaaS lock-in. - **Central governance.** Daily budgets, per-task caps, approval rules, and scope boundaries enforced by the platform; engineers keep shipping. - **Atomic-granularity observability.** Drill from a product's total spend to the exact tool call that caused it in two clicks. - **Interactive build DAG.** The whole plan as a clickable, status-colored graph — brief a stakeholder without a deck. - **Self-hosted, offline-capable.** Control plane runs on your hardware; we're not in your data path. - **→ [How is OpenPraxis different from other AI-agent tools?](docs/compared-to-ai-agent-tools.md)** Full landscape map vs IDE agent runtimes (Cline, Cursor, OpenHands, Goose), orchestration SDKs (CrewAI, LangChain), observability proxies (Helicone, Langfuse, AgentOps), enterprise platforms (watsonx, UiPath), and closest concept match (Paperclip). Plus [OpenClaw comparison ↓](#where-openpraxis-fits) for the consumer-assistant axis. ### How it fits ```mermaid flowchart LR subgraph Inputs [" "] direction TB Spec[Spec / Manifest] Budget[Budget, Rules, Caps] end OP(["OpenPraxiscontrol plane"]) subgraph Agents [Multi-agent execution] direction TB A1[Claude Code] A2[Cursor] A3[Codex] end subgraph Outputs [" "] direction TB Git[(Gitbranch per task)] Cost[Cost attributionper action · task · day] Quality[Independent auditwatcher + reviews] Memory[Shared memoryLAN peer sync] DAG[Interactive DAGstatus-colored plan] end Spec --> OP Budget --> OP OP A1 OP A2 OP A3 OP --> Git OP --> Cost OP --> Quality OP --> Memory OP --> DAG ``` Developers write the spec. Leadership sets the budget, caps, and rules. OpenPraxis dispatches the work to whichever agent is best for the job, captures every action the agent takes, audits the result independently of the agent, attributes the spend to the originating spec, and syncs the memory across the team — all on your hardware, on your terms. ## The Hierarchy — Product → Manifest → Task **One organizational model, used everywhere.** OpenPraxis orchestrates work as a three-level hierarchy borrowed from how actual engineering teams already think. Everything — cost, turns, status, settings, review verdicts — cascades up or down this spine. ``` Peer (your machine, identified by UUID v7 + MAC fingerprint) │ ├── Idea [CAPTURED CONCEPT — upstream of any build work] │ │ priority (low/medium/high/critical) · tags │ │ link_idea_manifest ties ideas to the specs they spawned │ │ ├── Product [SPEC — top level, groups manifests under one umbrella] │ │ title · tags · status · cost rollup · DAG root │ │ │ ├── Manifest [SPEC — versioned markdown with deliverables] │ │ │ depends_on other manifests (build order) │ │ │ jira_refs · status · linked ideas · comments │ │ │ │ │ ├── Task [ATOMIC UNIT OF WORK — executes one agent] │ │ │ │ depends_on other tasks · schedule (once / 5m / at:) │ │ │ │ status, cost, turns, run_count, branch · comments │ │ │ │ │ │ │ ├── Run [ATOMIC UNIT OF EXECUTION — one attempt] │ │ │ │ │ started_at / completed_at · cost · exit code │ │ │ │ │ │ │ │ │ └── Action [ATOMIC UNIT OF MEASUREMENT — one tool call] │ │ │ │ tool_name · tool_input · tool_response · cwd │ │ │ │ │ └── Review Task [ATOMIC UNIT OF VERDICT — paired via depends_on] │ │ auto-activates on parent completion │ │ posts review_approval / review_rejection on parent │ │ │ └── More manifests … chained by manifest depends_on │ └── More products … ``` **The taxonomy at a glance:** | Level | What it is | Atomic? | |---|---|---| | **Idea** | Captured concept — priority + tags. Upstream of any build work; links to the Manifests it spawned. | No (seed) | | **Product** | Top-level spec — groups related manifests under one umbrella | No (container) | | **Manifest** | Versioned detailed spec with deliverables, depends_on, status | No (container) | | **Task** | Scheduled unit of work that dispatches one agent session | **Atomic unit of work** | | **Run** | One execution attempt of a task | **Atomic unit of execution** | | **Action** | One tool call made by the agent during a run | **Atomic unit of measurement** | | **Review Task** | A `depends_on`-paired Task that audits its parent's output | **Atomic unit of verdict** | ### Why a hierarchy - **Organization matches reality.** Initiatives have specs. Specs have work items. Work items have runs. Runs have tool calls. The model holds all the way down. - **Aggregation is free.** Cost and turns roll up at every level with no manual bookkeeping — drill from _"the product cost X"_ → _"this manifest accounted for most of it"_ → _"this one task spent the bulk"_ → _"this one agent turn burned the peak"_ → _"here's the exact prompt and tool call that caused it"._ - **Settings cascade.** 12 execution knobs resolve via `task → manifest → product → system`. Set `max_turns=100` once at the product, every task under it inherits. Override for one hard manifest. Override again for one risky task. The resolver walks the chain on every read. - **Dependencies at every layer.** Products depend on products. Manifests depend on manifests (build order). Tasks depend on tasks (run order + paired reviews). The same `depends_on` primitive powers all three — and the scheduler blocks dependents until prerequisites are terminal. - **Reviews ride the same chain.** The review-task pattern pairs every main task with a verify task via `depends_on`; when main completes, review auto-activates, polls real-world state, and posts the canonical verdict. No watcher can override it; no review agent can impersonate the watcher. ## The DAG — your shop floor, at a glance **The hierarchy isn't just a data model — it's a picture.** Every product renders as an interactive Directed Acyclic Graph. You see the whole build plan at once: what's done, what's running, what's blocked, what's next, where the money went, and exactly which task implements which line of which spec. - **Purple product node** at the top — the initiative. - **Manifest nodes** linked by blue manifest-dep edges — the build order. - **Task nodes** under each manifest linked by yellow task-dep edges — the execution chain. - **Ownership edges** (dashed) from manifest to each root task — the "I belong to this spec" relationship. - **Status colours** — green done, grey pending, red failed, amber in flight. One glance tells you where the build is. - **Any shape, no custom code.** Linear 12-task chain (like the ELS product: `T1 → T1R → T2 → T2R → … → T6R`)? Renders top-to-bottom. Eight independent pairs (like INT MySQL backup/verify)? Renders as eight parallel short columns. Multi-parent fan-in? Dagre figures it out. Empty manifest? Graceful. The renderer takes the edge set and delegates layout to [dagre](https://github.com/dagrejs/dagre) ([PR #158](https://github.com/k8nstantin/OpenPraxis/pull/158)); we don't do arithmetic on positions anymore. - **Click any node to drill in.** Purple → product detail. Blue → manifest detail. Chain node → task detail with live output. `#view-products//dag` is shareable. - **Contract-tested at the API level.** `TestProductHierarchy_EmptyProduct / _LinearChain / _ParallelPairs` locks the `/api/products/:id/hierarchy` payload the renderer rides on so a new DAG shape can't silently break the layout ([PR #160](https://github.com/k8nstantin/OpenPraxis/pull/160)). **Why it matters.** A spec without a picture is a PDF nobody reads. A DAG without real numbers is a toy. OpenPraxis combines both — you see the plan _and_ the current cost, status, run count, and cost-per-turn of every node in it, live, in one view. ## Table of contents - [Features](#features) · [How it fits](#how-it-fits) · [The Hierarchy](#the-hierarchy--product--manifest--task) · [The DAG](#the-dag--your-shop-floor-at-a-glance) · [Where OpenPraxis fits (vs OpenClaw)](#where-openpraxis-fits) - [See it in action](#see-it-in-action) - [Dashboard — cost today vs. budget, tasks ranked by spend](#dashboard--cost-today-vs-budget-tasks-ranked-by-spend) - [Live tool output — watch the agent work, turn by turn](#live-tool-output--watch-the-agent-work-turn-by-turn) - [Products → Manifests → Tasks — every cost and every turn rolls up](#products--manifests--tasks--every-cost-and-every-turn-rolls-up) - [Visualize the plan — interactive DAG, status-colored](#visualize-the-plan--interactive-dag-status-colored) - [Every conversation, every tool call, every visceral-rule ack — searchable forever](#every-conversation-every-tool-call-every-visceral-rule-ack--searchable-forever) - [Independent evaluation — three gates an agent can't override](#independent-evaluation--three-gates-an-agent-cant-override) - [Hierarchical execution controls — budgets, turns, and agent knobs that inherit](#hierarchical-execution-controls--budgets-turns-and-agent-knobs-that-inherit) - [How It Works](#how-it-works) - [The Workflow](#the-workflow) - [Architecture](#architecture) - [Key Concepts](#key-concepts) - [Products](#products) · [Manifests (Specs)](#manifests-specs) · [Tasks (Autonomous Execution)](#tasks-autonomous-execution) · [Watcher (Independent Auditor)](#watcher-independent-auditor) - [Ideas](#ideas) · [Memories](#memories) · [Visceral Rules](#visceral-rules) · [Conversations](#conversations) · [Chat](#chat) - [Dashboard (17 Tabs)](#dashboard-17-tabs) - [MCP Tools (55 as of 2026-04-22)](#mcp-tools-55-as-of-2026-04-22) - [Quick Start](#quick-start) - [Prerequisites](#prerequisites) · [Build and Run](#build-and-run) · [Connect to Claude Code](#connect-to-claude-code) · [Dashboard](#dashboard) - [Stats](#stats) - [Database](#database) - [Project Structure](#project-structure) - [Hooks](#hooks) - [Peer Sync](#peer-sync) - [Configuration](#configuration) - [Mobile App](#mobile-app) - [License](#license) **Deeper references:** - [Compared to other AI-agent tools — full landscape map](docs/compared-to-ai-agent-tools.md) — IDE runtimes, orchestration SDKs, observability proxies, enterprise platforms, and Paperclip - [Execution Controls — all 12 knobs in detail](docs/execution-controls.md) - [Workflow Engine — DAG, states, activation model, review loop, SCD principle](docs/workflow-engine.md) - [Changelog — April 2026 release notes](docs/changelog.md) ## Where OpenPraxis fits **If an AI model is a CNC machine, OpenPraxis is the factory.** The model cuts metal; OpenPraxis is everything around it: the specs (manifests), the work orders (tasks), the shop floor (execution engine), the time clock (cost + turn tracking), the QA station (watcher), the archive (memory), and the shift log (activity feed). One developer with OpenPraxis runs an engineering shop, not a chat thread. **Professional AI development tool — not a consumer agent-message manager.** Ope … ## Source & license This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [k8nstantin](https://github.com/k8nstantin) - **Source:** [k8nstantin/OpenPraxis](https://github.com/k8nstantin/OpenPraxis) - **License:** Apache-2.0 - **Homepage:** https://github.com/k8nstantin/OpenPraxis/releases/latest Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** yes - **Filesystem access:** no - **Shell / process execution:** yes - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/mcp-k8nstantin-openpraxis - Seller: https://agentstack.voostack.com/s/k8nstantin - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.