TruPath Stack

I'll write a full teardown of this once the architecture has another month of production data. What follows is the current picture.

The three-tier structure

The portfolio runs on three tiers. TruPath Ventures is the mothership — it holds the cross-venture kanban, the agent hierarchy, the legal/IP work, and the operational decisions that span all three companies. Quantum Caddy and Mile High Golf are the ventures — each with its own specialists, its own data stores, its own sprint cadence.

The kanban is the thread that connects them. One Supabase project, one table, every task tagged by venture (QC / MHG / TruPath), every status visible in one brief. The morning brief pulls from all three. The Telegram bot reads from all three.

The five agents

APEX is the chief of staff and the default. Briefs, scheduling, email drafts, cross-venture routing. SUMMIT runs Mile High Golf — site search, SBA loan coordination, grant tracking, build coordination with DDI. VELOCITY handles QC business — pitch, investors, ACL partnership, competitive intel. AXIOM handles QC engineering — CV pipeline, Supabase schema, ESP32 firmware, YOLO model evaluation. CIPHER handles legal and IP across all three ventures — patents, NDAs, entity formation, contracts.

Each agent has an explicit access table: what it reads, what it writes, what it never touches. The "never" list is the most important section. Every agent file says explicitly that it cannot edit its own constraints.

The hook system

Fifteen hooks in QC, growing. The principles are the same across all three ventures even where the implementations differ.

Every hook traces to a postmortem. The pre-cloud-gate hook exists because a training run spun up without a signed sprint contract and cost money with no output. The pre-implementation-gate hook exists because scope drift was eating sprints. The hooks-self-protection hook exists because an agent once helpfully "fixed" a hook that was blocking it.

The enforcement log after five months has 150+ blocked actions. Most of them would have caused incidents if they'd gone through. None of them required a rule to be remembered.

The Telegram bridge

The phone interface to the whole system. A Python bot runs on the Mac Studio as a launchd process. It bridges Telegram messages to claude -p headless and back. Thirty seconds from phone to answer.

/kanban pulls urgent and active tasks across all three ventures. /brief runs the morning brief. /ask routes a question to Claude in the vault working directory. Plain text routes to Claude as well, with a project-prefix override: "qc: why is the RTSP reconnect failing" routes to the QC codebase.

The bridge runs on the same subscription that runs the desktop sessions. No separate API billing. The headless mode uses the same models, the same permissions, the same hooks.

The compounding loop

This is why the stack works as a system rather than a collection of tools.

Incidents produce postmortems. Postmortems produce rules. Rules become hooks. Hooks produce enforcement log entries. Enforcement log entries show which rules agents most need reminding of — those are the candidates for sprint contract criteria. Sprint contracts produce handoff artifacts. Handoff artifacts close gaps between agents.

After five months, the system is materially better than it was on day one — not because I got smarter, but because every failure made the system harder to fail in the same way again. That's the goal of the stack. Not to prevent all failures. To prevent the same failure twice.

The full bundle — agent templates, hook scripts, sprint contract templates, postmortem template, CLAUDE.md skeleton, memory directory structure — ships when the architecture has another 30 days of production data.

— Michael, from the lab