AI / POC Lab — Gabriel Philipson

NC

New Compass

In Progress

A governed multi-agent product platform that runs a product idea through the full discovery-to-launch lifecycle — with every irreversible decision held at a gate a human has to sign.

Last updated: August 22, 2026

The engine is built and heavily proven: eight of eleven build blocks complete, 21 proof suites and 393 checks green, re-run twice to show repeatability. Discovery, Strategy and the Go/No-Go pair are producing. The next build is the gate screen where a person makes the call.

DBOS durable executionSupabase / PostgreSQLRow-level securityClaudeOpenAIGeminiMulti-agent orchestrationTypeScript

What it does

New Compass takes a product idea through the stages a real product organization would run it through — discovery, review, opportunity screen, cost baseline, Go/No-Go — with a different specialist agent producing each stage. Seven lifecycle agents are specified; three are built and producing today: Discovery (which lands a brief plus grounded facts in the database), Strategy (which proved the same engine is reusable by a second producer), and the Go/No-Go pair. The founding rule is that the platform never decides on its own. Agents produce evidence and arguments; a human makes every gate decision. Every run is cost-accounted at four rates, so the price of a product idea is a number rather than a guess.

How it's built

The substrate is DBOS durable execution on Supabase, so a run survives a crash and resumes where it stopped — proven against deliberate crash injection. Every agent write goes through a single chokepoint: a broker that commits an agent's output and its outbox message in one transaction, so there is no state where an agent has acted but the record disagrees. Row-level security is on every table and agents run under a deliberately constrained login. Schema moves only through numbered migrations — 36 applied so far — and each build block ships with its own proof suite. The suites are run twice: once to show they pass, once to show that passing is repeatable.

The governance machinery

The most thoroughly proven code in the project is the part that argues with itself. At a Go/No-Go gate, two agents are dispatched — one to make the case for, one to make the case against — and the database enforces that they come from different model families, so the platform cannot mark its own homework. The evidence is frozen to the exact packet the human read, so a decision can be audited later against what was actually on the screen rather than what the system knows now. Underneath that sits a grounding floor: every fact a Discovery agent produces has to declare whether it is sourced, and unverified facts are labelled as unverified rather than quietly mixed in. Ahead of the gate, a review loop with a premise-gated stop fails closed — if the loop cannot establish that the premise still holds, it stops rather than proceeding.

Where it stands

Audited line by line against the repository on 2026-08-22: eight of eleven build blocks fully built with test evidence behind them, 36 migrations, 21 proof suites, 393 checks green. Four milestones reached — first real Discovery run, the iterate-to-bar review loop, the opportunity screen with a per-product cost baseline, and the cost envelope. Next in the build order: the gate-packet screen, the interface where a human reads the frozen packet and makes the call (the data contract for it is already built and waiting); then the four remaining lifecycle agents — Business Case, Build-verify, Launch and Monitoring — plus the sandbox that Build-verify needs; then throughput, which is the real test of the premise, since everything proven so far has been proven one product at a time.

The 6-step workflow

1
Discovery
A brief goes in; an agent produces a structured brief plus a set of facts, each one declaring whether it is sourced or unverified. Cost is accounted at four rates from the first call.
2
Review and dissent
A reviewer from a different model family iterates the output to a quality bar, with a premise-gated stop that fails closed rather than pushing a weak premise forward.
3
Opportunity screen
The idea is screened against a per-product cost baseline, so the spend floor for pursuing it is known before anything expensive runs.
4
Bull and bear
Two agents argue the Go/No-Go — one for, one against — with the database enforcing that they come from different model families.
5
Sealed packet
The arguments and their evidence are frozen into a tamper-evident packet, so the decision can later be audited against exactly what the human saw.
6
The human gate
A person reads the packet and decides. Nothing irreversible happens without that signature — which is why the gate screen is the next thing being built.

Screenshots

Verified build audit · commit ce04189

New Compass — build status

Every row checked against the repository and its proof suites, not against the prose that describes them.

Engine proven

8 / 11

Blocks built

36

Migrations

393

Checks green

3 / 7

Lifecycle agents

Milestones

M1

First real Discovery run lands a brief and facts in the database

Jul 13

M2

Iterate-to-bar loop: review, dissent, premise-gated stop

Jul 17

M3

Opportunity screen with a per-product cost baseline

Jul 21

M4

Cost envelope: a cheap reused phase plus the expensive Go/No-Go

Aug 20

M5

One product end to end, Discovery through Launch

Portfolio at volume on a real scheduler

Planned

Build blocks

Schema forks + identityRow-level security on every table; the constrained runtime loginidentity 10/10

Host + durable executionDBOS on Supabase — a run survives a crash and resumesspike 4/4

BrokerSingle-commit outbox; the one chokepoint every agent write passes throughbroker 21/21

Discovery agentFirst producer in the lifecycle; four-rate cost accountingdiscovery 30/30

Review + premise stopFail-closed stop and a cross-family reviewer; mechanism proven, live reviewer awaiting a credentialreview 47/47

Gate assembly + sealThe database spine of a gate decision; the screen that renders it is next in the build ordergate 19/19

Scheduler + cost baselineClaim and dispatch line, with a per-product spend floorscheduler 23/23

Strategy producerProved the engine is reusable by a second agent; one real billed runstrategy 33/33

Grounding floorFacts must declare whether they are sourced; unverified ones are labelled, not hiddengrounding 10/10

Go/No-Go bull & bearTwo agents argue for and against, on evidence frozen to the packet the human readscross-family 14/14

Counts read from the repository at commit ce04189. Proof totals come from a full suite run on local PostgreSQL 17, executed twice — once to show it passes, again to show it is repeatable. Nothing here has run in production yet.

The build board as of the 2026-08-22 audit — eight of eleven blocks built with proof suites behind them, four milestones reached, and 393 checks green across 21 suites run twice for repeatability.

GPS

gabephilipson.com - This Site

Fully Operational

A production consulting website built entirely with Claude - strategy, copy, prototypes, and full-stack deployment - in under 22 hours at zero build cost.

Last updated: March 29, 2026

Most senior executives either pay $15K-$30K and wait 6-10 weeks for a professional site, or settle for a generic template that undersells them. The goal was a founder-forward dual-audience site with real content and a live AI/POC Lab - without the agency timeline or cost.

ClaudeClaude CodeNext.js 15VercelSanity CMSResend

ADK

AdmitKit

Fully Operational▶ Live Project

An AI-powered college discovery platform built for families. Personalized probability scoring across ~2,000 schools, YouTube-derived student perspectives, and balanced list recommendations.

Last updated: May 7, 2026

Most families don't know how to build a balanced college list. They navigate with spreadsheets, gut feel, and conflicting advice from counselors. AdmitKit asks the right questions, calculates personalized admission probabilities, surfaces student perspectives from YouTube, and recommends a list balanced across Safety, Target, and Reach schools. The tool that started as a custom build for one family is now a public beta available to every family.

Next.jsSupabaseAnthropic Sonnet 4.6FirecrawlClaude CodeProduction Beta

JSA

Autonomous Job Search Agent

Fully Operational

A job-search engine rebuilt from scratch as a Python system. It screens roles against fixed rules and fit analysis, generates tailored resumes and cover letters behind a verified-facts gate, and pre-fills real ATS applications up to a hard stop where a human presses submit.

Last updated: August 22, 2026

A serious job search has more moving parts than a chat assistant can hold reliably: applications spread across many platforms, recruiter threads, shifting follow-up deadlines, and screening criteria that change from role to role. The first version of this system solved that inside a chat window and then accumulated enough regression that reliability became the real problem. A run could not be trusted to behave the same way twice, and the spreadsheet it wrote to was a synced file that corrupted under concurrent writes. The rebuild treats the search as a data pipeline rather than a conversation, so every stage is inspectable, testable, and repeatable.

PythonSQLiteClaudeFirecrawlATS AdapterspytestGmail MCPClaude in Chrome

What it does

It runs a seven-stage daily loop: find new roles, run on a schedule, screen them for fit, rank what is worth applying to, generate the documents, pre-fill the application, and hand back a ranked list. The honest constraint is that a fully unattended run is impossible, because career sites, full job descriptions, and live applications all require a logged-in browser. So the loop is split. A morning brief runs headless on a local scheduler and produces the deterministic slice: pipeline snapshot, a non-committing preview of the time rules, the ranked queue, follow-ups coming due, and an explicit list of what needs a human browser pass. The gated work is queued rather than faked.

How it is built

A Python package behind a single command line tool, covering intake, deduplication, rule enforcement, ranking, document generation, and assisted apply. A local database is the source of truth, and the spreadsheet people actually read is regenerated from it as a read-only view. Sourcing adapters cover the major applicant tracking systems, with a headless renderer as the first path for JavaScript-heavy postings and a browser as the fallback. Document generation runs a chain of linters: a verified-facts gate, a repetition check, an AI-tell pass, and a keyword scorer. The whole thing is covered by an automated test suite, which is the part that makes a daily run trustworthy.

What it refuses to do

The interesting constraints are the refusals, and they are enforced in code rather than left to judgment. The apply executor drives the form and then halts at the review screen: it will never click submit, log in, accept terms, or answer voluntary disclosure questions. Fit scores and tailoring require the complete job description, so a truncated alert snippet parks the role in a pending state instead of producing a number that looks real. Generated documents draw on a curated inventory of verified facts, and keyword coverage can only inject terms that inventory supports, which makes stuffing structurally impossible rather than discouraged. And the synced spreadsheet is never written directly, because that was the original corruption bug.

Where it stands

Document generation is complete, and the assisted-apply path has been run live from end to end, which surfaced two constraints that changed the design: the browser cannot attach a file from the local machine, so the human uploads the resume, and letting the tracking system parse that resume beats typing fields by hand even after corrections. Known gaps are tracked rather than papered over. Per-role bullet tailoring is still manual, some job boards are not wired in yet, and a self-healing check on source health is unbuilt. An interview-preparation track was added most recently, building recall aids from the same evidence base the documents draw on.

The 7-step workflow

1
Finds new roles
Triages Gmail alert digests, scans a tiered watchlist of career sites, and pulls directly from ATS platforms. Everything is deduplicated against the full history, matched on external job ID or on a normalized company and title pair.
2
Runs on a schedule
A morning brief fires from a local task scheduler and produces the slice that can honestly run without a human: pipeline counts, a preview of the time rules that never commits, the ranked queue, and follow-ups due. Work that needs a logged-in browser is queued, not skipped silently.
3
Screens for fit
Retrieves the complete posting, scores it, then applies deterministic banding and flags before writing to the database. A partial description is not scored at all: the role is parked as pending review, because a fit number derived from a truncated snippet is worse than no number.
4
Ranks the queue
Orders the apply queue by a stretch-penalized composite that discounts fit by how much of the role sits outside demonstrable experience, tie-broken by freshness and compensation, then split into a capped ready tier and a tier needing one explicit acknowledgement.
5
Generates documents
Produces a tailored resume and cover letter through a verified-facts gate, a repetition check, an AI-tell linter, and a keyword pass that folds in only terms the evidence inventory can back. Output is checked as rendered PDF, not just as source.
6
Pre-fills the application
Detects the ATS, loads the matching adapter, verifies the documents are current, builds a field-level fill plan, then drives the browser to the review page and stops. A static safety invariant makes submit, login, terms, and voluntary disclosure unreachable. Unknown platforms degrade to a packet handoff instead of guessing.
7
Hands back the day
Drafts a summary of new roles, the ranked queue, follow-ups coming due, and any degradation flags raised during the run. The submission itself stays a human act, recorded afterward through a guarded command that enforces event ordering.

Screenshots

Daily run

The loop, split by what needs a person

A fully unattended run is not possible, because career sites, complete postings, and live applications all require a logged-in browser. So the run does the part it can do honestly and queues the rest.

Scheduled

Runs unattended

Queued for a human browser pass

01

Find new roles

Mail alerts triage on their own. Career-site sweeps need a signed-in session, so they are listed rather than attempted.

Mixed

02

Run on a schedule

A morning brief fires from a local scheduler: pipeline snapshot, a preview of the time rules that never commits, the ranked queue, and follow-ups coming due.

Unattended

03

Screen for fit

Scoring requires the complete posting. A truncated alert snippet is not scored at all; the role parks as pending review.

Needs browser

04

Rank the queue

Ordered by fit discounted for how much of the role sits outside demonstrable experience, then split into a ready tier and one needing an explicit acknowledgement.

Unattended

05

Generate documents

Resume and cover letter produced through the gate chain, then checked as rendered output rather than as source.

Unattended

06

Pre-fill the application

Drives the real form to the review screen and stops there. Unknown platforms degrade to a packet handoff instead of guessing.

Needs browser

07

Hand back the day

Drafts a summary of the queue, follow-ups due, and anything that degraded during the run. Drafts it. Does not send it.

Unattended

The split is the design. A system that claims a clean unattended run, while quietly skipping everything it could not reach, is worse than one that hands back a short list of what still needs a person.

The loop is split by what can honestly run without a person. The deterministic stages run unattended on a schedule; the stages that need a logged-in browser are queued for a human pass rather than faked or skipped quietly. Being explicit about that boundary is what keeps an unattended run trustworthy.

TII

The Intangibles Index, A Wins Predictor

Fully Operational▶ Live Project

A satirical 2026 Mets wins predictor built on a riff on CAPM. Live record, tunable intangibles, hardcoded fWAR.

Traditional baseball projections like PECOTA are statistically rigorous and emotionally empty. Fans know a season is not just wins above replacement. It is tabloid drama, mascot charisma, and whether the bullpen can find the strike zone in August. This project puts those variables in the equation.

VercelServerless FunctionsMLB Stats APIClaude CodeVanilla JS

CMP

Compass — PM Agent Pipeline

In Progress▶ Live Sandbox

Your personal AI product manager. Describe a problem in plain English, get a prioritized strategy, and ship engineering-ready requirements with stakeholder-tailored documentation. 60 features live across 9 categories. Seven pipeline runs across software, creative, and business domains.

Last updated: April 8, 2026

Phase I complete. Phase II active. Stakeholder intelligence shapes agent decisions and tailors BRD/PRD exports to individual audiences. Seven documented runs across ERP forecasting, e-commerce, athletic training, furniture making, and professional networking, with 100% schema compliance since Round 2. The pipeline adapts naturally to non-software domains without special handling.

ReactClaudeAnthropic APIOpenAIGeminiMulti-AgentNode.jsGitHub JSON persistenceProvider abstraction layer

What it does

Takes a PM from raw problem statement to approved PRD through a structured multi-agent pipeline. Each stage (Discovery, Strategy, Requirements) produces structured outputs the PM can review, edit, and approve before advancing. An Orchestrator agent manages state, routes rejections back to the earliest affected upstream stage, and maintains a running session dossier stored as JSON in GitHub. Gate modes are configurable per stage: manual, supervised, or auto with a countdown timer. Discovery is permanently locked to manual — it is the foundation, and wrong problem means wrong everything. Each stage delivers formatted output with risk and priority badges. Stakeholder context shapes Strategy rationale and Requirements flags. /cmp:export doc generates a six-section BRD/PRD. /cmp:export doc [name] tailors the executive summary to the named stakeholder's communication style and priorities. 49 features live, 11 planned.

How it's built

React single-page app with a provider abstraction layer supporting Claude (default), OpenAI, and Gemini — swappable per agent without touching agent logic. Session state persists as a structured JSON dossier in a private GitHub repo. Each agent reads the full dossier and writes only to its own block. The Orchestrator carries a hybrid context model: structured JSON state plus a running narrative summary. A pre-flight intake form (with optional /cmp:brief free-text command) scores project size before firing the pipeline. Seven documented runs with consistent token efficiency (~17,800 avg). Phase II adds stakeholder intelligence, BRD/PRD export (delivered), open question answer flow, and Execution, Launch, and Analytics agents.

Screenshots

Compass — PM Agent Pipeline

Your personal AI product manager. Describe a problem. Get a strategy. Ship requirements.

Phase II, Active

Phase

II of III

Phase I complete, Phase II active

Features

60

49 live, 11 planned

Pipeline runs

7+

Software, creative, business

Avg tokens/run

17,775

Full pipeline end-to-end

How it works

Discovery

Frames the problem, identifies target user, surfaces assumptions with structured risk classification.

→

Strategy

OKRs, ranked features with rationale, explicit out-of-scope. Picks the right framework for the project.

→

Requirements

User stories with Given/When/Then acceptance criteria, NFRs, open questions with blocking dependencies.

Each stage is reviewed and approved by you before the next one runs. Automation is earned, not assumed.

The Compass hero — Phase II active with 60 features, 7+ pipeline runs, and an average of 17,775 tokens per full run from problem to requirements.

Not Just Aware of AI. Using It.