One workflow.Any coding agent.
Aqorin is a runtime-agnostic orchestration layer for coding agents. Define how work is specified, implemented, validated and reviewed once. OpenCode, Pi, Codex, Claude Code or jcode execute it. Your setup stays yours.
npm i -g @aqorin/cliPronounced “A-cor-in”. An experiment built in public: this page shows the idea and where it is heading.
workflow● unchanged
feature@1
specify → implement
→ validate → review
no runtime insideassignmentper role
Your process lives in one agent's config folder.
Every coding agent ships its own agents, commands, skills, hooks and permission model. Write a real workflow — spec, implement, review, fix — and it exists in one runtime only, held together by a prompt asking the model to remember.
Aqorin is designed never to replace those files: it projects its own namespaced overlay beside them.
Aqorin owns the semantics. Runtimes own the execution.
The Orchestration Engine holds the Run — its state, its policies, its evidence — as an append-only event log. Adapters turn each step into whatever the runtime does natively. When a step tries to cut a corner, the reducer says no, not a prompt.
required_validations_passed in the core reducer.illustrativeRole ≠ Runtime ≠ Model
Three independent concepts: no canonical role implies a runtime or a model. Today a Run assigns one runtime and one model to every role; assigning them per role inside one Run is exactly what TV5 tests.
Rules for the engine, not rules a model should remember.
These are the design rules Aqorin is built against. Some are enforced in code today; the rest are what the validation track is building and testing.
Never touches your config
Aqorin projects an isolated, namespaced overlay beside your files. Agents, commands, skills, MCP and settings are never overwritten or deleted.
- Lives in
- Configuration Overlay · adapter
Your native UX stays
Keep running opencode, pi or codex exactly as today. Aqorin is opt-in, per task.
- Lives in
- By construction · a separate CLI
Invariants in code
Phase order, budgets, required review, approval gates and legal transitions belong to a reducer, not to a system prompt.
- Lives in
- Reducer · packages/core
State belongs to the Run
A runtime session is one attempt, not the Run. Events are durable, so a crashed runtime does not erase what happened.
- Lives in
- Event store
Honest guarantees
Every permission is labelled: runtime-native, Aqorin-enforced, OS-sandboxed, external — or not enforceable. Nothing is elevated silently.
- Lives in
- Each adapter's permission guide
No lowest common denominator
Use a runtime's best primitive natively, emulate safely, degrade visibly — or refuse to run. Features are not dropped for symmetry.
- Lives in
- Capability negotiation · engine
The thesis is being tested. This is the track.
Aqorin is only worth building if you can define a runtime-independent workflow once, and Aqorin runs it durably across runtimes and models — mixed in one Run — without special cases in the workflow. Before the product grows, a Thesis Validation Track tests exactly that.
Field notes · TV1 runtime parity2026-09-29
Work in progressThe current workflow was measured on OpenCode, Pi and Codex with the same task. It is not there yet: the gaps are in Aqorin's shared code, not in the runtimes.
Next: Aqorin runs validation itself, then one execution path for every runtime. That is what the rest of the track is for.
Exists today
- Durable Run and event core
- Five Runtime Adapters
- Built-in
featureworkflow, live once per runtime, separately, on macOS arm64 @aqorin/cli0.2.0 on npm, MIT — behind main
Next on the track
- User-defined workflows
- Mixed runtimes and models in one Run
- Validation run by Aqorin itself
- More platforms beyond macOS arm64
Run more than one coding agent? Talk to me.
This page exists to put the idea in front of developers while it can still change. The most useful answers are the uncomfortable ones.
Which workflow would you define once and never rewrite per agent?
Would you mix runtimes in one task — implement with one, review with another?
Where would you draw the line between what the engine enforces and what the model decides?
What would make you trust an orchestrator next to your repo and your credentials?
build log and open questions