A4C (Agent for Coding)

Overview

A4C (Agent for Coding) is a governance and evidence layer for autonomous software engineering. You use it as a coding agent inside the host you already work in — GitHub Copilot CLI, OpenCode, or Antigravity. Give it work in chat; it does the engineering in an isolated git worktree, verifies the result, and hands you the evidence to accept or send it back.

A4C is deliberately not an agent framework. The coding host owns execution — tool selection, planning, implementation, testing, and any native subagents stay exactly where they are. A4C owns what surrounding autonomous work usually lacks: task identity and lifecycle, workspace isolation, durable records, human acceptance gates, and safe integration.

There is no execution mode to choose: one task is one governed engineering outcome, executed directly.

Task Lifecycle

Every task follows the same deterministic pipeline — failures and interruptions are recorded honestly, never papered over:

Task created -> Worktree allocated -> Host executes
    -> Result recorded (failed / interrupted is recorded honestly and stops here)
        -> Verification evidence -> Human acceptance
            -> Snapshot validation -> Safe integration

Task state is durable and portable: if a session dies or you switch hosts, open the same repository in another tool, select its A4C agent or skill, and ask to resume the unfinished task — no task ID needed, the one that most needs attention is resolved and named back to you.

Key Features

• Host-Native Execution — A4C runs as a selectable agent in Copilot CLI and OpenCode (copilot --agent a4c, opencode run --agent a4c) and as a skill in Antigravity (/a4c). The host keeps its own tools, planning, and subagents.
• Worktree Isolation — Every task gets its own git worktree and branch under .a4c/worktrees/. The base checkout is never dirtied, so parallel tasks and exploratory work can’t collide.
• Evidence, Not Vibes — Commands, outputs, and verification results are attached to the task record. a4c task diff shows exactly what you are approving, and a4c task inspect --json exposes the full audit trail.
• Human-Only Acceptance — a4c task accept refuses agent callers outright; unattended runs must present an explicit human authorization token. Self-approval is not a configuration option.
• Re-Validated Integration — Integration never trusts the approval that precedes it: an incomplete activity graph, a dirty base checkout, or a snapshot that moved since acceptance each aborts the merge with the reason.
• Tamper-Evident Audit Stream — Approvals, denials, and integrations append to a hash-chained log where every entry carries the hash of the entry before it, making edited history detectable rather than merely discouraged.
• Explicit Refusals — Nothing is silently ignored or guessed at: unknown commands name their replacement (a4c doctor → use a4c status doctor), close typos get a suggestion, and unsupported options fail with the reason.
• Strict Governance Mode — Optional a4c-strict agent variants deny the host’s native mutation tools and route every write through the governed, journaled team_apply_patch tool — built for unattended or regulated runs.

Works Where You Work

One a4c init . (or a4c install all) creates the .a4c state directory and wires every host at once. To continue a task in a different tool, just ask the new host to resume it.

CLI Automation & Administration

The CLI is optional automation around the chat experience, not a prerequisite for it:

Approving a change carries a release rule: acceptance records a patch-level version bump and integration lands it as its own chore(release) commit alongside the approved change. A rejected or abandoned task never bumps the version.

Engineering Knowledge

A4C keeps an optional, durable engineering memory outside the source repository (~/.a4c/<repo>/knowledge/) with findings/, experiments/, decisions/, and reviews/ subtrees. The agent consults it when prior learning helps and records only meaningful discoveries — failed approaches, surprising limitations, non-obvious observations. Knowledge work is optional and never ceremonial, and a4c init --no-knowledge opts a workspace out entirely.

Written in Go

The a4c executable is built with Go (go build -o a4c ./cmd/a4c, with the core in pkg/a4c) and released under the MIT license. All testing is deterministic and offline:

go build ./...
go test -short ./...
go test -race -short ./pkg/a4c/...

Dogfooding

A4C is built the way it governs: its own milestone reports — including governance closures, host-conformance reviews, and benchmark comparisons against large-repo and multi-agent squads — are produced as documented, reviewable evidence. This very showcase page was itself added through A4C: authored in an isolated worktree, verified with the site’s build and test suite, and presented to a human for acceptance.