Bulkhead Forge — product / Agent Delivery
Agents write the code. Your team keeps the decisions.
Agent Delivery is a control plane for agent-driven development. Humans file tasks and review the artifacts — specs, then pull requests. Code agents draft, build and test in isolated VMs, behind review gates, a drift guard and budgets your team sets. The job shifts from writing to approving.
Working prototype · Google Cloud · EU region
Every screenshot on this page is the working prototype with sample data. The names, task IDs, token counts and dollar figures are fixtures used to build the interface — they are not client work, and not measured results.
The problem
Code generation isn't the bottleneck anymore. Trust is.
Agents can already write most of the code. What teams lack is the machinery around them: gates that decide what merges, guards that catch an agent drifting off-spec, and a bill that's visible before month end. That machinery is the product.
| Concern | Agents today | With Agent Delivery |
|---|---|---|
| Control | Output merged on vibes and a skim of the diff | Spec gate, then code gate — every requirement traced from R1 to the line that implements it |
| Scope | An agent quietly rewrites half the service | Drift gate: past the threshold the agent pauses itself and posts options — re-scope, split, or roll back |
| Spend | Token bills discovered at month end | Per-task budgets, weekly team caps, and agents that sleep at $0/hr while waiting on CI or reviews |
How it works
The delivery loop: two gates, one human
-
Phase 01
Intake
A task arrives from Slack or the console. The agent reads the knowledge-graph slice around it and asks its questions up front.
-
Phase 02 · gate
Spec
The agent drafts a spec as Markdown in your repo — goals, requirements, test plan. A human approves it, and approval auto-starts the build.
-
Phase 03
Build
An isolated VM per task. Checkpoints after each step, sleep during CI, and a drift gate that stops work that grows past the approved scope.
-
Phase 04 · gate
Code review
A pull request with requirement traceability and the agent's notes on why the code took this shape. Your feedback wakes the agent; it revises and re-requests.
-
Phase 05
Verify
Canary and end-to-end tests after merge, a delivery report, and the knowledge graph updated — so the next task starts smarter than this one did.
Inside the console
Your home isn't a kanban. It's the review queue.
Eight screens, one idea: everything that needs a human is in front of you; everything that doesn't is an agent's job. Review is the work now — generation isn't.
Spec review
Agent-drafted, versioned in GitHub. Changed sections marked; one open question blocks approval. Approve — and the build starts itself.
Code review
Every requirement mapped to the diff that implements it. Agent notes explain why the code took this shape — challenge them, and it revises.
Agent fleet
Every agent's state, harness version, tokens and cost — live. Idle agents auto-sleep; the week's spend tracks against the team budget.
Knowledge graph
Services, entities and specs as a living graph. See a task's blast radius before the build starts — the same slice each agent loads as context.
Guardrails
Autonomy you can sign off on
-
Two human gates
Nothing builds without an approved spec; nothing merges without a human review. Trivial diffs can take a no-spec lane — by policy, not by exception.
-
Drift gate
When the implementation grows past your threshold, the agent pauses itself and posts options with estimates. A human decides; work resumes.
-
Spec traceability
R1–R5 aren't prose — they're anchors. The pull-request view shows which requirement each hunk covers and which are still pending.
-
Sleep/wake economics
Waiting on CI, a review or an answer? The agent sleeps at $0/hr and wakes on the event. Idle time costs nothing by design.
-
Versioned harnesses
The agent runtime is versioned like software — stable, LTS, canary. Override per task; the change applies on next wake with session context preserved.
-
Your tools, both ways
Specs live in your repo as Markdown; pull requests are real GitHub pull requests; reviews sync both ways. Slack carries intake, questions and escalations.
Google Cloud
Built on Google Cloud from day one
Running today
- Console, BFF and domain services on Cloud Run — europe-west1
- Isolated agent VMs provisioned per task
- Cloud SQL (PostgreSQL) + Cloud Workflows pipelines
- Google OAuth sign-in · GitHub & Slack integrations
- Secret Manager · Artifact Registry · keyless WIF deploys
- Cloud Monitoring — every model call metered (ai.model.*)
Where Gemini fits next
- Spec drafting and intake Q&A on long context — a whole service slice in one pass
- Coding-harness roles on Vertex AI, versioned and overridable per task
- Drift detection as fast, cheap classification against the approved spec
- Per-task token metering is already wired — model cost shows up on the task card, not the invoice
Roadmap
Where this goes
Now
- Working prototype — 8 screens, full loop
- Drift gate · harness override · sleep/wake
- Spec & code gates with traceability
Next
- Implementation on the Forge console stack
- Live GitHub & Slack two-way sync
- Real fleet telemetry & budgets
Later
- Multi-team rollout & policy packs
- Delivery analytics & reports
- Findings from Discovery, tasks from Actions
Early access
Review is the job now. Generation is the agent's.
We're looking for teams to shape the first release with. Bring one service and one backlog — we'll run the loop on it together. One email is the whole first step.
contact@bulkheadlogic.com