Skip to main content

Case Study — AI Platform · Production Infrastructure

Agentic infrastructure — an AI platform I built and operate

An AI development platform I use across projects: multiple concurrent AI coding sessions working over a shared, git-versioned knowledge base, with a gated ingest pipeline and a semantic memory recorded at ~700k entries in August 2026, two-tier model routing, and health automation that recovers from selected process failures. Built and operated for delivery work, research, and business workflows.

  • TypeScript
  • Python
  • Claude Code
  • SQLite
  • ChromaDB
  • launchd
  • Git
~700kSemantic memory entries (August 2026 snapshot)
4.4xIngest throughput gain from batched single-writer writes
103Open browser tabs captured, classified, and synthesized in one gated batch

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 backed by recovery automation.

The system carries real production workloads: invoicing, quarter closes, delivery projects, and research all flow through it. That constraint shapes the design: the ingest pipeline has validation gates, and the memory system has measured recovery runbooks for index divergence, a wedged daemon, and quarantined vector segments.

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 and hooks intended to reduce interference between simultaneous sessions.

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: the same capture-and-gate machinery serves every source instead of one workflow per source.

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. The August 2026 record documents the platform in use. Everything described here is infrastructure I designed, built, and operate; the practices apply to building AI-native platforms for a team.

Building a team that owns production?

I am open to remote senior and staff-level product and platform roles where technical judgment matters after the deploy, not only before it.

A useful first message

Send the role, product context, team shape, location constraints, and interview process. I will reply with the most relevant evidence from the systems I have shipped and operated.