Case Study BetaCraft Internal · 2025–2026
I designed and built BetaCraft's end-to-end AI-native delivery system: a 28-skill pipeline where a client email enters one end and a tested, reviewed, client-ready delivery exits the other — without the PM ever seeing code, or the developer ever seeing a client message.
01 / The problem
Most software agencies run two communication layers that don't talk to each other well: the client layer — requirements, emails, calls, approvals — and the engineering layer — specs, tickets, code, reviews. The gap between them is where projects go wrong. Scope gets lost in translation. Decisions don't get logged. Estimates don't match client expectations. PM overhead compounds with every new engagement.
At BetaCraft, running 3–5 concurrent client engagements, I was that translation layer. Manual, expensive, and a single point of failure. I built a system to replace the manual parts without losing the judgment.
Pain point
Client decisions made on a Monday call wouldn't reliably reach the engineer writing code on Wednesday. No formal decision log. No structured handoff.
Pain point
Every new engagement added email triage, call digestion, SOW drafting, sprint planning — all done manually, in parallel.
Pain point
Developers occasionally dragged into client conversations that should have stayed in the PM layer — losing build focus and creating communication risk.
Pain point
Features shipping without a structured review and sign-off process. Quality was person-dependent, not system-dependent.
02 / Architecture
The system separates concerns into three layers that communicate through a single defined interface — the bridge. No layer reaches past the bridge into the other's domain.
Layer 1 — PM
Business Administrative Manager. Ingests client comms, logs decisions, generates requirements, drafts client-facing updates. Never sees code.
Layer 2 — Bridge
A versioned shared folder. BAM writes REQUIREMENT-NNN.md. TPM reads it, builds, writes DELIVERY-UPDATE-NNN.md. BAM reads that back. No direct coupling.
Layer 3 — Dev
Technical PM agent translates requirements into specs the vibe-* dev skill system can execute. Dev never reads client emails.
Design principle
The bridge folder is the contract between two teams — or two agents. Today one person runs both layers. When BetaCraft grows, a dedicated PM runs BAM and a TPM runs vibe-*. The bridge protocol doesn't change.
03 / PM layer — 21 skills
The PM layer is the betacraft-pm-standard — a client-agnostic operating system for the full client relationship. It runs on Claude Code with Gmail and Fathom MCP integrations for live email and call transcript ingestion.
Reads a raw client email, archives it with a numbered convention, extracts decisions as proposals, flags status discrepancies against current project state.
Takes a Fathom transcript, produces verbatim record and synthesised summary, extracts decisions and action items, routes conflicts to review log.
Every requirement entering the bridge must have a logged decision behind it. This gate blocks generate-brief until DEC-NNN is locked and dated.
Translates a locked decision into a structured requirement document written for the TPM agent — the handoff point into the bridge.
Reads DELIVERY-UPDATE-NNN.md from the bridge and produces a client-facing email in the right house style, grounded in what actually shipped.
Generates a RAG-coded status report: overall health, decisions since last report, open risks, next milestones. Read-only — no files modified.
04 / The bridge
The bridge is a versioned folder — [client]-bridge/ — sitting between the PM and dev repositories. Two file types. One rule.
A REQUIREMENT-NNN.md contains: the decision number it implements, the feature or change in plain language, acceptance criteria the vibe-* system can consume directly, compliance or dependency constraints, and a priority call. The TPM agent picks it up and never needs to ask what the client actually wants — it's already been translated.
A DELIVERY-UPDATE-NNN.md contains: what shipped, explicit out-of-scope items, known issues, and a one-paragraph client-facing summary the BAM agent can paste directly into an email. No re-interpretation in either direction.
05 / Dev layer — vibe-* system
The development layer is the vibe-* framework — structured AI development skills covering the complete build lifecycle. The TPM agent translates bridge documents into vibe-* inputs so developers skip brainstorming and go straight to building.
TPM agent reads the bridge requirement and produces the exact spec format vibe-add-feature expects — pre-filled with context, criteria, and constraints.
Full workflow: spec → tasks → build → gate. Creates FEATURE_SPEC.md, FEATURE_PLAN.md, and FEATURE_TASKS.md before any code runs. Every feature has a defined blast radius.
Runs after every phase. Acts as senior engineer + architect + code quality auditor. P0 issues block the next phase. No feature ships without a passing review.
Traces every file a change touches, maps the full dependency graph, writes component + integration + E2E tests. Runs automatically after every feature.
Severity triage first. Significant bugs get BUG_SPEC.md, BUG_PLAN.md, regression test before fix code. Trivial bugs get a 3-task fast path.
After vibe-review passes, TPM agent writes the bridge delivery update. BAM picks it up and generates the client email. Loop closes.
06 / The full loop
From the moment a client sends an email to the moment they receive a delivery confirmation, every step is handled by the system — with human judgment applied at the right checkpoints.
The key insight
One person can run the entire loop. PM never sees code. Dev never sees client emails. The bridge is the only shared surface. When the team scales, the same protocol works with dedicated people on each side.
07 / Outcomes
Sapey, Brieflex, WePop, and Link Broadband all run through the same PM layer — no client-specific manual processes.
Email triage, MoM production, status reports, and SOW generation are now skills — they run in seconds, not hours.
The DEC-NNN gate means no requirement moves to engineering without a logged, dated, accountable decision. Scope disputes get resolved by the log, not by memory.
vibe-review runs on every phase. P0 issues block progression regardless of who's on the team that sprint.
A skill-evolution layer lets patterns observed in delivery feed back into skill refinements. The loop improves with every project it runs.
08 / Reflection
The core insight was that AI agents fail at boundaries, not at tasks. A well-prompted agent can write a feature spec, draft a client email, or produce a delivery summary. What it can't do reliably is decide which of those things to do next, or how information from one domain should translate into the language of another.
The bridge solves that by making the boundary explicit and structured. BAM doesn't need to think like a developer. TPM doesn't need to think like a PM. The bridge document is the translation — it exists precisely so neither agent has to reach across a domain it wasn't built for.
The human judgment layer matters too. I didn't automate decisions — I automated the preparation and execution around decisions. propose-decision and vibe-review are checkpoints where a human reads what the system produced and says yes or no. The system doesn't replace judgment; it makes judgment cheaper to apply more consistently.