Skip to content
agent-board
This text was generated by an LLM (how cgwalters uses LLMs). cgwalters has not reviewed it yet.

agent-board

The work board is the forge; the agent only proposes.

agent-board coordinates coding agents through a project board: tooling for agent planning that keeps its whole record on the forge. People and agents put work on an ordinary board and its issues; agent-board reads them, decides what job each issue should get, starts that job once with a record on the issue, and follows the pull requests that come back. It does not run agents itself, and nothing it derives from board text is write authority. Its own writes follow fixed rules from forge facts and preview by default, within a fixed request budget; what an agent produces needs an independent check.

It is meant for any forge. Today GitHub works fully; Forgejo boards can be read but not written or dispatched from; GitLab is not supported yet. See forges.

How it fits

  forge: board + issues ----read----> agent-board ----start job----> dispatcher
        ^                           (decides what       (agentic-job on CI,
        |                            to start)            or another backend)
        |                                                       |
        +---- pull requests, comments <---- agent job <---------+
                     |
                     v
              review, then merge or a fix round (agent-board pass)

The forge's board and issues hold the work: priority, status, plans and operator answers live there, where people already look. agent-board reads them and decides what to start; pass is that scheduled heartbeat, and the architecture is how it and the supervisor divide the work. A dispatcher runs the agent job: agentic-job on a CI runner is one backend, and dispatch describes the interface others would plug into. The job's pull requests and comments come back to the forge, a review step follows, and agent-board's pull request follow-up merges approved green heads or starts bounded fix rounds. A deployment is a trusted configuration file in a caller repository plus a scheduled trigger that runs agent-board; the records stay on the forge.

Start here

  • Setup: install, try it offline in a minute, then connect a board one lane at a time.
  • CLI reference: every command and flag, generated from the binary.
  • Forges: GitHub, Forgejo and GitLab support.

Topics

  • Architecture: the operator's decisions on writes, Status, bookkeeping and the two loops.
  • Job plans: how a plan on an issue becomes one dispatch, and when it is held back.
  • Epic plans: breaking an epic into sub-issues from a reviewed plan.
  • Dispatch: what agent-board sends to start a job and how it finds the run.
  • Pull request follow-up: what the poll does and every option of its configuration.
  • One pass: the single scheduled pass, partly built.
  • Supervisor: the auditing agent's commands as built today.
  • Operator interaction: the needs-human label, operator actions and status updates.
  • Review drafts: sending an agent-drafted review of another project's pull request once the operator approves it.
  • Release train: cutting a release and moving its callers' pins, a step a pass.
  • Broker probe: one outage issue, open while the inference broker is unreachable.
  • Per-role GitHub Apps: one app per automation role; so far only apps create exists.
  • Design: the original design and research, with its current implementation limits.
  • GitHub work queue comparison: how this differs from gh-aw's native work queue.

agent-board is licensed Apache-2.0 or MIT, at your option. The source is at cgwalters-forge/agent-board.