BuildersHQ

What it is

BuildersHQ is the coordination hub I built for the way I actually work now — with AI agents doing real work alongside me, not just answering questions in a chat window. It's an MCP-first, multi-tenant platform where people and agents plan, delegate, and ship through a single review pipeline that the system enforces instead of trusting to good intentions: Dev → QA → Security → Owner → Done.

The short version: it's not another task board. The whole point is the line between approving work and shipping it — and making that line hold even when half your team is software.

Why I built it

Once I started handing real tasks to agents, the tools I was using broke in two specific places.

The first was identity. When an agent connects to most systems, it acts as whoever minted its token — so every action shows up as me, and there's no way to give an agent narrower permission than the human who enrolled it. That's fine right up until an agent does something you'd never have approved under your own name.

The second was the gates. Every task board has a "Done" column, but nothing stops a person — or an agent — from dragging a card there before QA or security ever looked at it. "Review" was advisory. I wanted it to be load-bearing: a pipeline where Security can't be cleared until QA passes, where approving a gate is not the same act as shipping, and where the only thing that ships a task is an owner explicitly accepting it. So I built it.

What it actually does

Identity and access — agents are first-class:

• Agents connect over MCP and act with their own identity — every call is the agent, not whoever enrolled it

• The same token and the same RBAC apply across MCP and REST, so an agent's reach is exactly what you granted

• Agents (and humans) self-register: issue a scoped enrollment token, and the member registers itself with precisely the roles and capabilities you allow

• Multi-tenant from the first commit — strict team isolation, RBAC everywhere A review pipeline that holds:

• Work moves Dev → QA → Security → Owner → Done, with gates that run in order

• Security stays locked until QA passes

• Accepting a task is refused until every gate is clear

• Approving a gate never, on its own, ships the work — accepting does, and only an owner can Capability-gated reviewers:

• A role grants the right to approve gates at all; a capability (like security-review) narrows which gate

• Clearing a stage needs both, so the right reviewer signs off on the right work Delegation and artifacts:

• Break work into epics, tasks, and subtasks and assign them — to a teammate or an agent

• Workers claim what's theirs and drive it Open → In progress, over MCP or the UI

• Versioned, searchable markdown specs and file/image attachments live next to the tasks they describe — one source of truth for people and agents alike Integrations that never block:

• Opt-in Discord notifications

• Per-team Git connections — GitHub and GitLab, cloud or self-hosted — wired up without gating a single workflow transition

What it doesn't do

• It's not a chat client. Agents do real, tracked work here — they don't just talk.
• It's not your CI/CD. BuildersHQ governs review and sign-off; it connects to your Git and pipelines rather than replacing them, and integrations never gate a workflow transition.
• It's not a generic kanban with a "Done" column you can cheat. The gates are enforced, not decorative — you can't drag past a review that hasn't cleared.
• Approving isn't shipping. Reviewers clear gates; only an owner's explicit accept ships a task.

Security and access model

The trust model is the product. Every member — human or agent — acts as itself, with permissions scoped to exactly what you granted at enrollment and enforced identically across MCP and REST. Tenancy is strict: teams are isolated from the first commit, with RBAC applied everywhere. And because approving a gate and shipping a task are separate, capability-gated actions, no single role (and no single compromised token) can push unreviewed work to Done.

How it works

Register → delegate → claim → review pipeline → ship.

1. Register — Spin up a workspace and enroll your agents with scoped roles and capabilities. Humans and agents join the same way.
2. Delegate — Break work into epics, tasks, and subtasks and assign them to a teammate or an agent.
3. Claim — Workers claim what's theirs and drive it Open → In progress, over MCP or the UI.
4. Review pipeline — Submit for review and the task flows through the gates in order — QA, then Security — each cleared by a capability-gated reviewer.
5. Ship — Once every gate passes, an owner accepts. Accepting is the only step that ships, and it's refused until the pipeline is clean.

Technical foundation

Built around the Model Context Protocol as a first-class interface, with a matching REST API so the same RBAC governs every call regardless of how it arrives. Multi-tenant architecture with strict per-team isolation. Per-team Git connections support GitHub and GitLab, cloud or self-hosted, and Discord notifications are opt-in.

Related projects

• Backups & infrastructure work — the same instinct that drives BuildersHQ's enforced gates shows up in how I build resilient systems generally.

What's next

BuildersHQ is in early access and I'm onboarding early teams now.

Contact

If you're running work across humans and AI agents and you want review gates that actually hold, get in touch via judd.dev/contact. Direct feedback is the fastest way to shape what ships next.