AgentBoard | asozyurt

Why It Exists

AgentBoard is built around a problem that shows up quickly once AI agents move beyond experiments: the work becomes hard to supervise. A single chat transcript is not enough when multiple agents are drafting scope, editing files, reviewing output, retrying failed runs and waiting for a human decision.

The project turns that process into a local delivery board. Work moves through explicit roles, every run leaves a trace, and the human approval step remains visible instead of being hidden inside a terminal session.

Product Shape

The board is organized around the actual delivery state of an agent task: to do, agent working, agent review, human approval and done. That makes it closer to an operating surface for AI-assisted engineering than a generic kanban clone.

AgentBoard board with to do, agent working, agent review, human approval and done columns. — The core board exposes where each task is in the agent workflow, including the human approval gate and project-level run cost summary.

Creating work stays intentionally small: a title and a rough description are enough to start. The PM role can enrich the prompt, split scope and turn the request into acceptance criteria before implementation begins.

New task modal in AgentBoard with title and description fields. — Task capture starts from a short brief, then the agent workflow adds structure before code changes begin.

Verification Loop

The most important part of the product is the handoff loop. Worker runs can produce implementation output, Reviewer runs can check acceptance criteria, and the final state still waits for explicit human approval or rejection.

AgentBoard task detail panel with acceptance criteria, agent runs, costs and approve or reject controls. — The task drawer ties acceptance criteria, individual agent runs, costs and approve/reject controls into one review surface. Subscription runs show an approximate API-equivalent cost, and a usage-limit failure is retried after the provider's reset time.

Comments and run history give the product an audit trail. That matters when an agent retries, partially completes work, or needs human direction before another pass.

AgentBoard task detail showing checked acceptance criteria, run history and comments. — Completed work remains inspectable: acceptance criteria, succeeded and failed runs, comments and copied context are visible in the same place.

Agent Model

AgentBoard treats agents as configurable personas rather than a single assistant. PM, Worker, Reviewer and Human each have different responsibilities, and the system can route those responsibilities to Claude Code, Codex CLI, Copilot CLI or future executors. Any role can also be a council: two to five agents from different providers debate in turn, and the last one writes the final result.

AgentBoard personas page showing PM, Worker, Reviewer, Human and Council cards. — Personas make the workflow explicit: scope, implementation, review and approval are separate responsibilities.

AgentBoard skills page showing a project skill next to the built-in code review, unit tests, tech spec, refactor, API client and release notes skills. — Skills attach reusable capabilities to roles or runs, so agent behavior can be shaped per project instead of hard-coded.

Your Subscription, Not a Surprise Bill

Most people who try agent tools already pay for Claude Pro/Max, ChatGPT or Copilot. AgentBoard lets each provider sign in with that subscription instead of an API key. In that mode the run’s environment drops the provider’s API-key variables, so a key left in a shell profile cannot silently switch the work to pay-as-you-go billing. Each run records how it actually signed in, and the doctor check warns when an API key would override a login.

AgentBoard project settings with per-role agent configuration, a Claude and Codex reviewer council, and per-provider sign-in choices. — Per project, each provider can use My subscription, an API key, or Auto. The reviewer here is a Claude and Codex council.

Architecture Notes

The implementation is deliberately local-first. The server runs on Node.js, stores project state in SQLite and exposes a local HTTP API for board, task, run, skill and session operations. Spawned agents never receive the server’s own token: each run gets a token that only works for its own task, and every part of a compound shell command is checked against the tool policy. The UI is built with React and Vite, with live agent activity streamed back into the board.

Session history is a first-class part of the product. Every recorded coding session is searchable by prompt, project or task. A session can be inspected after the fact, copied back into context, or opened from the CLI when deeper debugging is needed.

AgentBoard sessions list with intent tags, prompts, start time, duration and event counts. — The sessions index shows what each session was for, how long it ran and how much it did.

AgentBoard session detail page with summary, duration, event breakdown and event timeline. — Session detail turns agent activity into a debuggable timeline instead of leaving it buried in terminal output.

What I Like About It

The interesting design choice is that AgentBoard does not try to make agents feel magical. It gives them operational boundaries: role ownership, acceptance criteria, visible cost, retry limits, review states, scoped credentials and human approval. That is the difference between “an AI wrote some code” and “an AI-assisted delivery process can be inspected and improved.”