ACA: Autonomous Coding Agent
ACA is a portable control plane for running autonomous coding work against real git repositories.
It is not another chat-based coding agent that opens a folder and starts editing. ACA sits beside your repos, takes work from a task source, binds that work to the correct repository, chooses an execution backend and model, then coordinates the run through a structured delivery loop. The result is not just “the agent changed some files” — it is a coding run with a durable task record, explicit repo binding, scoped execution, logs, diffs, artifacts, summaries, and handoff notes.
What ACA does
Finds the work
ACA accepts work from several task sources. Every task is normalized into one clear shape with title, description, acceptance criteria, source metadata, priority, labels, and repo information.
- GitHub ProjectsPick the next ready item, normalize it into a task, and route it to the right repo.
- Local Kanban boardsUse board cards as the canonical task source for solo or self-hosted teams.
- Backlog filesRead structured backlog files for repeatable, reviewable task intake.
- Custom task adaptersPlug in your own tracker via a small adapter and ACA treats it like any other source.
- Direct manual promptsHand ACA a single task on demand without registering a source.
Binds the work to the right repo
ACA does not guess which repository to edit. Before any coding work starts, the task must resolve to an explicit repo binding: a local path, GitHub repo slug, or clone URL plus checkout path. If the target repo is ambiguous, ACA stops instead of improvising.
Runs through Tandem
ACA uses Tandem as the execution backend. It checks whether a compatible Tandem engine is already running, reuses it when possible, or starts one only when configuration allows. The selected provider and model are recorded so the run is auditable later.
Coordinates the coding run
ACA creates a run record and writes the evidence needed to understand what happened, so coding automation is inspectable instead of opaque.
From task source to inspectable run.
Every run follows the same shape: intake, binding, execution, evidence. Small tasks run conservatively with one agent. Larger tasks coordinate a bounded swarm with a manager, workers, reviewer, and tester.
Resolve the task
Pick the next eligible task from GitHub Projects, a Kanban board, a backlog file, or a custom adapter, and normalize it into one shape.
Bind the repo
Refuse to edit until the target repository is explicit — local path, repo slug, or clone URL plus checkout path. Ambiguous binding stops the run.
Reuse the engine
Check whether a compatible Tandem engine is already running, reuse it when possible, and record the provider and model in the run.
Coordinate the run
Run small tasks with one agent. Run larger tasks with a manager plus workers, reviewer, and tester operating in isolated scopes.
Write evidence
Status snapshots, event logs, diffs, summaries, artifacts, and handoff notes — every run leaves the trail a human review needs.
Update the source
Where the source supports it, flip the board column or task status when the run lands. Your tracker keeps reflecting reality.
Use ACA when you need delivery, not edits
ACA is a fit for teams who want autonomous coding to produce a reviewable run, not a chat session that left files different.
Use ACA when ambiguity is the risk
Repo binding, backend, and model selection are explicit before any code is touched. Unclear inputs stop the run instead of triggering a guess.
Why this matters
Most coding agents are still prompt-first. That is fine for experiments, but it breaks down when you need repeatable software delivery. ACA is built around the questions a real delivery process has to answer:
- Which task was the agent working on?
- Which repo was it allowed to edit?
- Which model ran the work?
- What changed?
- What tests ran?
- What failed?
- What should a human review?
- Can the run be inspected later?
ACA turns autonomous coding from a one-off chat session into a structured, inspectable run.
Operating principles
Fails closed when inputs are unclear
If task source, repo binding, backend, or model selection are unclear, ACA refuses to edit.
Never assumes the current directory is the target repo
Repo binding is explicit. ACA does not improvise an edit target.
Stays scoped to the active task
Workers operate in isolated scopes. Side excursions are out of scope.
Avoids committing secrets
Run boundaries and review steps are designed to keep secrets out of commits.
Leaves a concise record
Every run produces logs, diffs, summaries, and handoff notes that survive the session.
On a hosted Tandem server
Every provisioned hosted server bundles ACA next to the Tandem engine, the control panel, and the knowledgebase MCP. Operators get the ACA intake form, the run dashboard, and per-run inspection without installing or wiring anything themselves.
Engine reuse, not respawn
ACA reuses the running Tandem engine on the same server. Runs do not pay a cold-start tax for every task.
Knowledgebase grounding
Hosted ACA can ground its work against the on-server knowledgebase MCP, so policies, runbooks, and team docs feed back into coding decisions.
Auditable by default
Run records, logs, diffs, and artifacts live on your provisioned server. You own the evidence trail without exporting it from a third-party agent service.
ACA turns a task source plus a repo binding plus a Tandem execution backend into a structured, inspectable autonomous coding run.