OpenAgentsControl: plan-first agents for OpenCode

The problem OpenAgentsControl actually targets

Generic coding agents produce generic code. The README makes this concrete with a side-by-side example: an AI-written route handler does `const data = await request.json()` and returns `Response.json({ success: true })`, while the same team's real handler parses the body through a Zod schema, writes through Drizzle, and returns a 201. The gap between those two functions is the entire product thesis. You do not fix it with a better model. You fix it by giving the model your conventions before it writes anything.

So the target user is not a solo developer experimenting with prompts. It is a team that already has a house style for validation, database access and response shaping, and is tired of re-teaching it in every session. The README frames the payoff as code that ships without heavy rework, and the cost as a one-time effort to write your patterns down. That trade is honest: if your conventions are not written down anywhere, this tool has nothing to load.

How the context system and approval gates fit together

OpenAgentsControl is built on OpenCode, an open-source AI coding framework, and extends it rather than replacing it. The extension points are visible in the repository layout: a `.opencode/` directory holding `agent/`, `command/`, `context/`, `plugin/`, `profiles/`, `prompts/`, `scripts/`, `skills/`, `tool/`, plus `config.json` and `opencode.json`. Agents are markdown files in `.opencode/agent/`, which is why the README calls them editable rather than baked-in plugins. You change behaviour by editing text, not by rebuilding anything.

The context directory is the part that carries your patterns. The README describes a Minimal Viable Information principle: context files stay under 200 lines and load lazily, so only what a task needs enters the window. Whether the 80 percent token reduction claimed in the comparison table holds for your repository is something the README asserts rather than demonstrates, and the repository does ship an `evals/` directory with a framework and per-agent test scripts, which is where you would look to check that claim yourself.

Execution flow is propose, approve, execute. The README states that agents always request approval before execution and that this is on by default, in contrast to tools where approval is optional and off. The same table lists execution speed as a weakness: OAC runs sequentially with approval, while the projects it compares against run fast or in parallel. That is a deliberate trade, and it is the single clearest dividing line between this project and its neighbours.

Installing it and running a first agent

Prerequisites are the OpenCode CLI, Bash 3.2 or newer, and Git. The installer will set up OpenCode CLI if it is missing, according to the README. The one-command path passes `developer` as an argument:

curl -fsSL https://raw.githubusercontent.com/darrenhinde/OpenAgentsControl/main/install.sh | bash -s developer

If you would rather read the script before running it, the README gives an interactive alternative that downloads it first:

curl -fsSL https://raw.githubusercontent.com/darrenhinde/OpenAgentsControl/main/install.sh -o install.sh
bash install.sh

Updates use a separate script. The README notes that `--install-dir PATH` is needed when you installed somewhere other than the default, giving `~/.config/opencode` as an example:

curl -fsSL https://raw.githubusercontent.com/darrenhinde/OpenAgentsControl/main/update.sh | bash

With the install done, you start an agent by name and give it a task. The README's example is a user authentication system:

opencode --agent OpenAgent
> "Create a user authentication system"

What you should see is a plan, not a diff. The agent analyses the request, proposes a plan, waits for your approval, then executes step by step with validation, delegating to specialist agents when the work calls for it. The README says this works immediately with your default model and needs no configuration. A Claude Code plugin path is also mentioned as an alternative, but the README excerpt does not document its setup steps.

Where the approval gate becomes friction

The approval gate is the feature and the limitation at the same time. Every step that needs a human decision is a step that stops. For a large refactor with dozens of file touches, the README's own comparison table concedes the weakness: execution is sequential with approval, and the projects it lines up against are marked fast or parallel. If your goal is to point an agent at a backlog and come back later, this is the wrong tool, and the README says so directly by recommending a fully autonomous alternative for that case.

There is a second constraint that matters more in practice. The whole value proposition depends on your patterns being written down in a form the context system can load. The README does not describe what happens when a repository has no context files, no established conventions, or conventions that live only in reviewers' heads. On a greenfield project with nothing to encode, you are paying the setup cost of a context system and getting the generic output the README opens by complaining about. The `CONTEXT_SYSTEM_GUIDE.md` file at the repository root is the place to check before assuming the system infers patterns on its own.

Multi-language support is listed as TypeScript, Python, Go, Rust, C# and, with an asterisk, any language. The asterisk is doing real work there. The shipped agents and the eval scripts in `package.json` target specific agents by name rather than by language, so the practical question is whether the agent definitions you install cover the stack you write in.

How it differs from autonomous agent runners

The closest comparison in the README's own table is Oh My OpenCode, which occupies the opposite corner: parallel agents, self-correcting error recovery, fully autonomous execution, and high token usage. The difference is not quality, it is where the human sits. Oh My OpenCode optimises for throughput on complex projects and accepts that the agent decides when it is done. OpenAgentsControl inserts a person between the plan and the execution, which caps how fast work moves and how much can run at once.

Against Cursor and Copilot the split is different again. Those tools are described as having no pattern learning and per-user settings, with approval gates present but off by default. OAC's claim is that patterns live in shared context files committed to the repository, so a new developer inherits the team's standards without configuring anything. Aider is characterised as auto-executing and aimed at solo file edits with no team coordination layer. The honest summary: pick OAC when the bottleneck is consistency across people, not raw generation speed. Pick one of the others when the bottleneck is volume.

Maintenance, packaging and licence

The package is published as `@nextsystems/oac` with a `bin` entry named `oac` pointing at `./bin/oac.js`, and it requires Node 18 or newer. It is a workspace monorepo with three workspaces: `evals/framework`, `packages/cli` and `packages/compatibility-layer`. The published file list is deliberately narrow, shipping `.opencode/` subdirectories, `scripts/`, `bin/`, `registry.json`, the installer and updater scripts, and the CLI dist output. That narrowness is worth noting: if you fork and add your own agent files outside those paths, they will not travel with the package.

Upgrade cost is mostly the cost of re-reading your own edits. Agents are markdown files you modify, so an update that rewrites `.opencode/agent/` can collide with local changes, and the README does not document a rollback path for the update script. The safest habit is to keep your edits in version control and diff before running the updater. Version history is uneven: v0.5.5, v0.7.0 and v0.7.1 landed within three days of each other in late January 2026, and the last push to the repository was on 2026-09-02. The CHANGELOG is the file to read for what moved in between.

Licensing is MIT, stated in the README badge and present as a LICENSE file at the repository root. MIT is permissive, so redistribution and modification are broadly allowed with the licence text retained, but this is not legal advice and you should have your own counsel review anything you ship commercially. Note also that OAC is built on OpenCode, a separate project with its own licence, and installing OAC pulls that dependency in.

Editorial conclusion

Adopt OpenAgentsControl if your team already has written coding conventions and you want an agent that reads them before writing code, and if you can accept sequential execution with a human approving each step. Skip it if you want autonomous parallel agents, or if you have no patterns to encode yet, because the context system has nothing to work from. Before committing, verify three things: that the OpenCode CLI installs cleanly on your platform, that the installer's default target directory matches where your OpenCode config already lives, and that the agents under .opencode/agent/ match the languages you actually ship. The last push was on 2026-09-02 and the most recent release is v0.7.1 from 2026-01-30, so check the CHANGELOG for what changed between those two points.

Frequently asked questions

Official sources

1. darrenhinde/OpenAgentsControl on GitHub
2. Issues
3. License: MIT
4. README
5. Releases