Chester

What it is

Chester is a CLI that orchestrates specialized AI agents to write code. Instead of one agent doing everything, a task flows through a pipeline - researcher, planner, architect, executor, QA, reviewer, and sign-off stages - with quality gates between each step.

The problem it solves

A single-agent assistant conflates skills: the model that writes code well is not the one that should grade it. Chester splits the work so each stage uses the best-fit model, local or cloud, and each hand-off passes a gate instead of vibes.

My contribution

I designed and built Chester: the agent pipeline, the per-stage model routing, the approval interactions, and the single-binary Go distribution.

Workflow walkthrough

A task like chester chat "add user authentication with JWT" flows like this:

1. Researcher reads the relevant code and gathers context (read_file, list_directory).
2. Planner turns the research into an implementation plan and asks for approval.
3. Architect validates structural decisions.
4. Executor writes the code, using a heavy coding model where it helps.
5. QA runs checks; Reviewer scores the result and passes or rejects it.
6. Documenter records what changed.

Each stage’s model is configurable, so a cheap local model can handle routing while a stronger one writes code - and cost per task stays visible in the summary.

Engineering decisions

Pipeline with gates, not a mega-prompt. Intermediate approvals catch plan errors before code exists, and a rejected review loops back instead of shipping.

Model routing per stage. Stages declare the kind of model they want; Chester resolves that against local and cloud providers.

Single Go binary. Same deployment story as Network Monitor: copy one file and run.

Stack

Go, pluggable LLM providers (local and cloud), terminal UI.

Lifecycle is unspecified: Chester is an earlier project whose current maintenance status I have not re-verified for this portfolio.