Gobby
Start with a task. Walk away. End with a PR.
gobby build '#1842'
That's the loop. Hand Gobby a task, walk away, come back to a PR.
Behind that one command: a plan, an expansion into staged subtasks, isolated
worktrees, dispatched agents, hook-time guardrails, validation, review gates,
and a commit-linked close. If something goes off the rails, Gobby stops and
escalates instead of merging garbage.
Gobby built Gobby. 5K+ commits. 15K+ tasks across my projects. Two
paying clients running production systems on it. The 0.4.x line was assembled
through Gobby's own task, dispatch, review, and documentation flows — the
receipts live in this repo's .gobby/tasks.jsonl.
Why this exists
The bottleneck in AI coding stopped being model capability a long time ago. The
bottleneck is babysitting. Agents lose context across compactions. They drift
from the rules you wrote in your CLAUDE.md. They duplicate work. They burn
thousands of tokens reloading the same MCP schemas every turn. You still review
every diff because you can't actually trust what comes back.
The fix isn't a better prompt. The fix is infrastructure around the agent.
Gobby is a local daemon that sits underneath the AI coding CLIs you already use
— Claude Code, Codex, Gemini CLI, Qwen CLI, Factory Droid — and gives them what
they're missing: shared sessions, a durable task ledger, hook-time rules,
progressive MCP discovery, agent isolation, review gates, and a build loop that
turns a task into a PR without you in the middle.
It is not another agent. It is the control plane the agents you already
have are missing.
What Gobby is
A Python 3.13+ daemon you run locally. SQLite at ~/.gobby/gobby-hub.db.
HTTP and the installed web UI on :60887, WebSocket on :60888, dev web UI
on :60889, stdio MCP server that your coding CLIs talk to.
Three things make Gobby load-bearing:
1. Stage-manifest dispatch + hook-time rules
Most autonomous agents are one giant prompt loop where the model decides
everything. That's the failure mode you've already lived through.
Gobby splits the runtime in two. Dispatch is deterministic: a heartbeat
scans tasks, reads the current stage manifest row (ideation → research →
architecture → prd → planning → expansion → development →
holistic_qa → pr → merge), evaluates ordered rules in
src/gobby/dispatch/rules.py, acquires a per-task mutex, and executes one
bounded action — start a stage, spawn an agent, create isolation, advance,
escalate. No prompting, no model freelancing.
Inside a spawned worker, the agent gets full autonomy to plan, edit,
verify, and commit. But every tool call passes through the rule engine on
turn_start, before_tool, after_tool, and turn_end. Rules can block,
rewrite, inject context, or set variables synchronously. They are evaluated as
code, not hoped for in a prompt.
Agent freedom inside enforced boundaries. That's the only way gobby build
gets to "hands-off" without lying about it.
2. Local-first, built with itself
Your database, transcripts, hooks, task ledger, workflows, and rules stay on
your machine. No cloud control plane. No SaaS dependency. Apache 2.0.
The repo you're reading was built through its own build loop. 5K+ commits.
15K+ tasks. 0.4.x was assembled by spawned agents working through staged
manifests, with the dispatcher routing review and merge. That's the production
test bed: every regression in dispatch, hooks, isolation, or task lifecycle
shows up as a stalled build the next morning.
I've also used it to ship production systems for two paying clients. It is the
tool I needed to actually trust the output of an AI coding agent on real work.
3. Sits under your CLIs, not next to them
Aider, Cline, OpenHands, Plandex, BMAD-METHOD — these are the agent. They
own the CLI, the loop, the context window. Switching means re-learning a
workflow.
