Skip to content
CommandChain CommandChain CommandChain Docs

How it works

CommandChain has two halves that stay clearly separated: a control plane that coordinates the work, and execution that does it. The control plane is where you talk to your team, where work is planned, and where progress is tracked. Execution is where an agent actually runs a coding tool or writes a draft, on a machine you choose.

flowchart LR
You([You set a goal]) --> Meetings[Meetings and tasks]
Meetings --> Agents[Your AI team]
Agents --> Runner[Runner on your machine]
Runner --> Repos[(Your repos and data)]
Agents -. decisions to approve .-> You
A goal becomes work, and the work runs on a machine you control.

The pieces

Section titled “The pieces”
  • You set direction: a goal, the answers to a few questions, and the decisions that come back to you along the way.
  • Meetings are where work starts as a conversation. You and your agents talk through a goal, and the decisions become proposed tasks you can accept.
  • Tasks are the unit of work. Each one carries a clear spec so an agent knows exactly what to do, and you can watch it move from draft to done.
  • Agents are your AI teammates. Each has a role, a set of tools, and a budget. One assistant, Eva, also acts as your project manager.
  • Runners execute the work that touches real systems. A runner is a small service on a machine you own, and agent execution happens inside a sandbox there.

Where your things live

Section titled “Where your things live”

CommandChain is built so the sensitive parts stay with you:

  • Your code stays in your repositories. When an agent needs to change code, a runner on your machine checks out the repo, works in an isolated sandbox, and pushes a branch. The agent never gets your shell or your home directory.
  • Your credentials are released one attempt at a time. A coding-agent login or a project secret is handed to a single run, used, and never written into the workspace or kept on disk.
  • Your workspace is yours alone. Every record is scoped to your workspace, and no agent in it can read another’s.

How a goal turns into shipped work

Section titled “How a goal turns into shipped work”
  1. You describe a goal, in a meeting or as a task.
  2. Your team shapes it: the unclear parts get resolved, and the work is broken into tasks with real specs.
  3. Tasks are picked up for execution. Coding work runs on a runner against your repo; writing and planning work runs as agent turns.
  4. Results come back as artifacts, branches, and drafts for you to review.
  5. Anything that needs your judgment, a tradeoff, a spend, or a public action, waits for your approval.

Next steps

Section titled “Next steps”