Product manager · builds with AI agents

I ship products by running AI agents as an engineering team — and I run the production they land on.

Product leadership applied to a one-person estate: fifteen live services, a memory system that keeps agents in context across sessions, and a pipeline that takes an idea to production with me only deciding what is worth building.

See the work ↓  Talk to me
15services in production, one Mac mini
654pull requests merged since Feb 2026
2client sites live with staging → promote
0engineers on payroll
Selected work

Six systems that run today

Each one is a real system in production, not a demo. Problem, what I did, what changed.

Topology diagram: Cloudflare to nginx to coreys-mac-mini, with the web services grouped into public, admin and client lanes

A production estate run by one person and a team of agents

Fifteen Flask and static services behind Cloudflare on a single Mac mini, with a staging box, per-service system users, a three-tier public / admin / client split and server-side branch protection.

macOS launchdnginxCloudflare Tunnel + AccessTailscaleGitHub rulesets
Case study →
Problem
Every service ran as the admin account, deploys were hand-run, and one careless command could take the site down.
What I did
Wrote the topology as a registry that a validator enforces, migrated every routed service off admin, cut over production to a new box with rehearsed runbooks, and put deploys behind scripts with snapshots and automatic rollback.
Outcome
15/15 healthy on the daily check; a rehearsed cutover to a new box; a deploy log with 37 successes and 2 clean automatic rollbacks in the last month.
Screenshot of the Memory Archive context graph: a central node of 3,778 items linked to clusters for memories, conversations, instructions, plans, services, agents and MCP tools

Memory Archive: context that survives the session

A PostgreSQL-backed memory and knowledge-graph service exposed over MCP, so every agent session starts with the decisions, instructions and learnings of the ones before it.

PostgreSQL + pgvectorMCPhybrid searchsession hooks
Explore the context graph →
Problem
Agents forgot rulings between sessions and re-asked settled questions, or quietly rebuilt things that already existed.
What I did
Built the archive, the hooks that load it at session start, a rulings ledger agents must read before asking, and embeddings with a labelled fallback so a degraded answer never looks like a real one.
Outcome
26 standing instructions loaded into every session; settled questions stay settled; the same design now backs a second company workspace.
Screenshot of the Dig Deep Grants hub: a search bar, status, funder-type and state filters, and a grid of grant cards with agency, match, deadline and source

Dig Deep Grants: a spreadsheet turned into a product

A grants-retrieval product for water-infrastructure funding, with its own development pipeline and a nightly retrieval that brings in new opportunities across state, federal, private-foundation and tribal sources.

Supabasenightly retrievalhuman-gated intakeclient build
Problem
Finding grants was a highly manual, Excel-backed process: someone searched each funder by hand, pasted rows into a spreadsheet, and the sheet was stale the moment it was saved.
What I did
Turned it into a product with its own development pipeline, and built autonomous nightly retrieval of new grant opportunities across all states, federal, private-foundation and tribal sources, with a human accepting or rejecting each one before it enters the hub.
Outcome
A searchable hub replaces the spreadsheet; new opportunities arrive overnight and a person accepts each one, so the list stays current without anyone searching by hand.
Screenshot of the conductor page: the current task, counts of tracks and items waiting on Corey, and columns for waiting-on-you, parked and Dig Deep cards

The conductor: an idea-to-production pipeline with real gates

One orchestrating session hands work to agents in isolated worktrees, gets a cross-model second opinion and merges by PR; I approve the problem, the prototype and the go. The next build is the deploy door that takes it the rest of the way to production without me.

Claude CodeCodex reviewgit worktreesproduct discovery skills
Problem
I was the router of my own system: every merge, deploy and check needed my tap, and tools got built before anyone checked they were needed.
What I did
Turned product-discovery methods into gates that write to a git ledger, retired a heavier pipeline I had built earlier, and designed the guardrails so I can step back: a single deploy entry point, required checks, a kill switch, an audit log, autonomy earned in levels.
Outcome
This page is the first idea through it. Verdicts — including "do not build" — are on the record.
Screenshot of the Slack #personal-assistant channel showing the morning brief header with the date and weather

Personal assistant in Slack: the estate reports to me

A Slack-first assistant that watches the critical services, turns what I read into a learning wiki, summarises the sources I follow and keeps my job search moving, so the day starts with a brief instead of a checklist.

SlackPushoverlearning wikimorning brief
Problem
Knowing whether every critical service was up, keeping up with the sources I follow and remembering what I had read all took separate tools and my own attention, every day.
What I did
Built a Slack daemon that posts a site report across all critical services, captures articles I send it into a learning wiki so the agents can learn from them, summarises key information sources into a morning brief, and handles career management from the same conversation.
Outcome
One Slack channel is where the estate reports in and where I hand things off; captures become wiki pages only on an explicit reply, so nothing publishes by accident.
Screenshot of the career hub dashboard: 438 new jobs to review, counts of applied and high-match openings, a job-URL capture box, and job cards with match scores and Generate, Skip and Archive actions

Career hub: search → apply → track, end to end

A three-tier system for the job search: it captures relevant openings for review, generates a resume from the job plus a career-history database, and tracks every application in Notion.

Notionresume generationjob capture
Case study →
Problem
A job search is three loops that never line up: finding the openings worth applying to, tailoring a resume for each one, and remembering where every application stands.
What I did
Built the three tiers as one flow: capture relevant openings for my review, generate a resume from the job and a career-history database, and track the application in Notion, with a headless-browser fetch that was hardened against SSRF along the way.
Outcome
The whole loop runs in one place: an opening comes in, I decide, a resume goes out and the application is tracked, without a spreadsheet or a folder of resume copies.
More

Other things that run

Client sites with a real release path

A photography site and a small-business site on their own system users, staging → promote, deploy keys fenced by rulesets so a compromised editor can never reach a live site.

Career bot

A public AI chat over my own history that answers the questions a recruiter actually asks.

Try it →

Community calendar

Aggregates neighbourhood feeds into one calendar with map layers; runs unattended on a schedule.

Open →

React enterprise transformation

Earlier chapter: three brands moved onto one component system. The lessons still shape how I sequence modernisation today.

Read →
How I work

Decide, then delegate, then verify

I start from a customer- or product-focused strategy: it defines the problems worth solving, not the tools to build. Everything below follows from that. The agents get the how; I keep the what and the why.

Problems before toolsA written problem statement and evidence before any spec. "Do not build" is a valid result and it is recorded.
Walls, not rulesGuardrails are enforced by the system — server-side branch protection, one deploy entry point, kill switch — not by asking an agent to behave.
Proof, not claimsAn agent's report is a claim. Tests run again, diffs are read, health is checked before anything is called done.
Everything on the recordRulings, verdicts and deploys live in git and an audit log, so the same question is never re-asked.