01 · Ventures

This site

The site itself: an agent-orchestrated build on SvelteKit and Cloudflare Workers, including its own AI chat and fit-evaluation tools, governed by eval gates and rate limits rather than ad hoc trust.

Live 2026 Architected / Owned / Co-built

A site arguing that one architect can run a venture with agent fleets had to prove that claim by being built that way, not just asserting it. Decisions, architecture, and governance here are his — what to build, what never to claim, when to serve a degraded answer instead of a wrong one. Execution, on SvelteKit and Cloudflare Workers, was largely agent-driven under his direction, the same operating model described elsewhere on the site.

The chat and fit tools run on no vector database and no retrieval-augmented generation at all. The entire corpus — every venture, every fact this site is allowed to state — fits inside one model context, so it is stuffed into the prompt and cached at the AI Gateway instead. Building retrieval infrastructure for content this size would have been the wrong call. Knowing when not to reach for RAG is itself the judgment on display, not an afterthought.

evaluateFit, the tool a visiting recruiter can point at a job description, never returns a hire or no-hire verdict about its own principal — only strengths tied to a corpus source, ramp areas, and interview questions. Judging its own builder’s fit for a role was never something to automate; restraint here is a deliberate design constraint, not a missing feature.

Every change touching what the AI can say is checked against a committed eval suite before it ships — a real gate, not a formality, that can block a deploy outright. That gate is the evidence behind the site’s bigger claim about agent-driven execution: the fleet writes the code, but nothing reaches a visitor until it clears a test it does not get to grade itself.

When the AI Gateway spend cap runs out, the site does not go dark or serve an unchecked answer. It falls back to a committed snapshot of eval-verified answers, plus the FAQ — a degraded mode, honestly labeled as such, rather than a dead box. A visitor arriving after the budget is spent still gets something grounded and true.

The one thing to change: the drift checker — the mechanism that keeps rendered pages honest against the corpus — was wired in only after several pages already existed, rather than from the first page. Retrofitting that discipline cost more than building it in from the start would have. The colophon lays out the rest of the stack and the current eval snapshot in full.

This site — corpus to public surfaceCorpustyped facts, one contextAI Gatewayno vector DB — context + cache, not RAG1MCP surfaceevaluateFit: never a verdict, only evidence2Chat UIhuman visitorsEval gatedegraded-mode fallback beats an ungraded answer3Rate limit + Turnstileseparate per-surface budgets, not an open tap4

This site

A personal site that itself had to demonstrate the agent-orchestration thesis it argues for — AI-native building with governance, not just AI-assisted output.

  1. 1No vector database or RAG for the site's AI chat — context-stuffing plus AI Gateway prompt caching, deliberately choosing not to add retrieval infrastructure this corpus's size does not need.
  2. 2evaluateFit never returns a hire/no-hire verdict — only strengths, ramp areas and interview questions, each traced back to a corpus source.
  3. 3A committed eval-artifact snapshot serves as the degraded-mode fallback, so the site never serves an uncurated model answer when a rate cap is hit.
  4. 4Rate limiting and Turnstile bot verification gate both the human chat UI and the MCP tool surface, with separate per-surface budgets.

How this was done

Architected · Owned · Co-built

What I'd do differently

Would have wired the drift checker — the source-of-truth enforcement between corpus and rendered pages — in from the first page, rather than after several pages already existed.