# GraphAgent: A Durable DAG Workflow Engine Inside the OpenCode Terminal Agent > GraphAgent (published as OpenCode-GraphAgent) adds a directed acyclic graph execution engine to the OpenCode terminal AI agent. This review covers its node/wave/gate model, event-sourced durability, model tiering, and the maintenance constraints of v1. **LeXwDeX/OpenCode-GraphAgent** — Extends the Hooks API, Directed Acyclic Graph Agent Execution Engine. This project is self-maintained by AI. - Repository: https://github.com/LeXwDeX/OpenCode-GraphAgent - Website: https://github.com/LeXwDeX/OpenCode-GraphAgent/wiki - Stars: 114 · Forks: 1 - Language: TypeScript - License: MIT - Published: 2026-08-26 · Updated: 2026-08-26 · Language: en - Canonical page: https://hysenlabs.com/projects/lexwdex-opencode-graphagent ## What GraphAgent Solves and Who It Is For The repository states it is self-maintained by AI, which is unusual and worth noting. That means the maintenance cadence and responsiveness depend on an automated process, not a human team. For a tool that handles state and recovery, that is a factor to weigh before relying on it in production. ## The Graph Model: Nodes, Waves, and Gates The parent agent owns the graph. It designs the graph, starts it, and gets woken when a node reports or the workflow finishes. It never polls. When a wave fails, the parent rewrites the failed segment and the engine continues. This is a significant design choice: the system does not retry the whole graph, it replans the failed part. The view always shows the current graph, not the history of rewrites. That keeps the inspector clean but hides what was tried before. If you need a full audit trail of every failed attempt, this design does not give it to you. ## Durability and Crash Recovery via Event Sourcing The README does not specify the exact state machine transitions or the SQLite schema. You cannot verify the crash recovery behavior without running it or reading the source. The claim that it never fabricates provider work is reassuring, but it is a claim, not a demonstrated result. If you adopt this, you should test recovery yourself by killing a node mid-run and seeing what the inspector shows. ## Configuring Model Tiers in dag.jsonc This separation of criticality from model choice is practical. You can put review or arbitration nodes on the advanced tier and fan-out work on the standard tier. A project-level `dag.jsonc` overrides the global one. If you configure only one tier, it serves as the unified default. The README says a commented default is seeded in the config dir on first use, so you do not have to write the file from scratch. This is a low-friction setup, but it does mean you must understand which nodes are critical in your workflow, otherwise you might put a cheap model on a gate that needs judgment. ## Workflow Libraries and the /dag-auto Command The README also mentions composable blocks: `explore`, `plan`, `prototype`, `debug`, `coding`, `verify`, `review`, `synthesize`. These compile into the node graph, and low-level node fields remain available for anything blocks cannot express. The `workflow(action="draft")` renders a structured graph through the tool schema into a validated YAML spec, so field-name mistakes are rejected by the provider, not discovered at validation time. That is a nice touch: it moves validation earlier in the process. ## Observability and Control: TUI Inspector and HTTP API The inspector shows the current graph only, not the history of rewrites. That is a deliberate choice for clarity, but it means you cannot see what the parent agent replanned unless you were watching live. For debugging a workflow that repeatedly fails, that could be frustrating. The deadline countdown is useful for long-running nodes, and the ability to step a workflow node by node is a strong debugging feature. ## Limitations and Failure Modes The project also has a deep mode admission with a bounded Q&A pass (1/3/5 rounds) that produces a fingerprinted Requirement Brief with a READY, NOT_READY, or WAIVED verdict before an expensive graph starts. This is a guard against wasting tokens on poorly specified tasks. But it adds a delay and requires user interaction, which may be unwanted for automated pipelines. ## Alternatives and Maintenance Cost On maintenance cost: the project is self-maintained by AI, which is a risk. The release cadence is active, with v1.0.35 and v1.0.36 released within a day in the supplied data, but that does not guarantee long-term support. The license is MIT, so you can fork and maintain it yourself if needed, but the README says a successor will redesign the runtime independently, so your fork may diverge. The SQLite read model and event sourcing mean you can inspect the state, but you need to understand the schema to recover from corruption. There is no documentation in the README about database migration or backup procedures. You should verify that before you run it on critical work. ## Conclusion Adopt GraphAgent if you already use OpenCode and need multi-step tasks with parallel branches, review gates, or crash recovery that a single agent loop cannot provide. Do not adopt it if you need new platform features or large architectural changes, because v1 is in focused maintenance and will only receive narrowly scoped compatibility patches. Before adopting, verify that your model provider supports the node-level reasoning variant and that your tasks fit the wave-based execution model, since the parent agent rewrites failed segments rather than retrying the whole graph. Also check the successor project's timeline if you plan a long-term dependency, because v1 will not take foundational refactors. ## FAQ ### What does OpenCode actually do? The readme describes the upstream project as a MIT-licensed terminal AI agent, and this repository is a fork of it published under the product name GraphAgent. The fork adds a directed acyclic graph workflow engine on top of that terminal agent. ### What is OpenCode Agent? In this repository the upstream terminal agent is extended with a DAG workflow engine where a task becomes a graph of child sessions. The readme states the project is not affiliated with and not endorsed by the OpenCode team, and that its own documentation lives in the repository wiki. ### What are nodes, waves and gates in the GraphAgent engine? A node is one unit of work, a real child session with its own agent and context window, running a single prompt with optional timeout, retry budget and output contract. A wave is the set of nodes whose dependencies are satisfied, and it runs in parallel up to a concurrency limit. A gate is a judgement node emitting ACCEPT, REVISE, REJECT or BLOCKED, and downstream nodes can be conditioned on the verdict. ### How do I choose which model a GraphAgent node runs? Nodes never name their own model. The graph marks which nodes are critical and a configuration file maps the advanced and standard tiers onto concrete models, with a project file overriding a global one. Resolution per node runs tier, then worker agent model, then parent session model, and if none yields a model the workflow is not created. ### Where should I keep GraphAgent workflow specifications? In one of three scopes, resolved in order: a project scope file beside the repository, which is committed and shared with the team; a global scope file in the agent's config directory, available to every project on the machine; or the builtin scope compiled into the release binaries, described as the last-resort tier. The first match wins. ## Sources - [Official documentation](https://github.com/LeXwDeX/OpenCode-GraphAgent/wiki) - [Official README](https://github.com/LeXwDeX/OpenCode-GraphAgent#readme) - [Project repository](https://github.com/LeXwDeX/OpenCode-GraphAgent) - [Release notes](https://github.com/LeXwDeX/OpenCode-GraphAgent/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lexwdex-opencode-graphagent