Case Study — AI Platform · Own Infrastructure
Agentic infrastructure — running companies on an AI fleet I built
The platform behind everything else on this site: multiple concurrent AI coding sessions working over a shared, git-versioned knowledge base, with an automated ingest pipeline, a ~700k-entry semantic memory, two-tier model routing, and health automation that recovers from failures on its own. Built, measured, and operated solo — in production daily for real businesses.
- TypeScript
- Python
- Claude Code
- SQLite
- ChromaDB
- launchd
- Git
Overview
Most AI-assisted development is one chat window and a prompt. This is the other end of the spectrum: a private, cross-linked knowledge wiki acts as the context layer for every project, several AI coding sessions run against it concurrently, and the infrastructure around them — ingest, memory, routing, health checks — is versioned, measured, and self-recovering.
The system runs real companies: invoicing, quarter closes, client projects, and research all flow through it. That constraint shapes every design decision — nothing here is a demo, so every pipeline has a validation gate, every failure mode that has actually happened has a written runbook, and every claim about throughput comes from a measurement, not a feeling.
Engineering highlights
- Gated ingest pipeline: captured web content is triaged by a bulk-tier model, synthesized into wiki pages by a fine-tier model, and refused unless it passes validation — orphan pages are rejected, writable paths are allowlisted, and a human reviews every diff before publish.
- Author/verifier separation enforced in code: the model that grades a page can never resolve to the model that wrote it, so a fallback cannot quietly collapse generator and judge into one.
- Two-tier model routing chosen by volume, not importance: corpus-scale passes go to the quota that survives them, judgment passes to the stronger tier. Selectors throw on unrecognized names — a typo cannot silently move work between tiers.
- Semantic memory on a local fork of an open-source engine, carrying fixes aimed upstream: single-writer lock discipline, a prefetch scan that removed an O(n)-per-file mining cost, and a regex-DoS guard. Diagnosed a 36x write penalty on large stores and recovered 4.4x throughput by batching writes through one writer.
- Health automation: a watchdog probes the vector index and the daemon every 15 minutes, restarts wedged processes, abstains while a human holds the lock, and alerts instead of self-repairing when the fix would be destructive. Weekly retention pruning and backup rotation included.
- Multi-session concurrency discipline over a shared git repo: stage only your own paths, push promptly, format before commit — conventions plus hooks that keep five simultaneous sessions from corrupting each other.
A concrete end-to-end run
One evening batch: 103 open research tabs scraped from the browser with a CLI pipeline, classified by the bulk tier (50 ingest, 44 reject, the rest already covered), synthesized hub-first into 27 wiki pages, validated, human-reviewed, and committed — with the raw captures archived next to the synthesis so every claim stays traceable to its source.
The same pattern — capture, classify cheaply, synthesize carefully, gate, publish — repeats across newsletters, bookmarks, meeting notes, and code surveys. The pipeline is the product: each batch leaves the system better documented and cheaper to run than the last.
Why this matters for hiring
Operating AI at this depth is a different skill from using a coding assistant: it means designing for model failure, quota economics, concurrent writers, prompt-injection surface, and verification pipelines — then running the result in production for months. Everything described here is infrastructure I designed, built, and still operate daily; the practices transfer directly to building AI-native platforms for a team.