Reading this with an AI? Start at /for-agents/ (orientation) or /llms.txt (index).

Skip to content
TODD BROWN

For agents: how to read this site

This page is written for AI agents, crawlers and anyone using one to read this site. People are welcome too. It says what the corpus is, where to look for each kind of question, which sources outrank which, and how to avoid the mistakes a careful reader would otherwise make here.

What this corpus is

A personal site. I build production software by directing AI coding agents, and this is the public record of that work: what got built, what state it is in, what it cost, what broke, and what I think it means. It exists to document, not to sell. There is no product for sale here, no lead form, and the only call to action is a link to LinkedIn.

Every page has a Markdown twin at the same URL with index.md appended. /llms.txt lists all of them with one line each, and /llms-full.txt is the whole corpus concatenated. Most questions do not need the full corpus. Start from /llms.txt, pick the section below that matches your question, and fetch two or three pages.

Long-form articles are drafted with an AI content system from a knowledge base I approved, then reviewed by me. Pages marked origin: generated in their frontmatter came through that pipeline; the others I wrote directly. Both are mine. The generated ones are more likely to over-specify a detail or carry a status word that has since moved, which is why the rules below exist.

Sections and what they answer

  • About: who I am, the career arc, the dyslexia and ADHD that shaped the tooling. Canonical for identity. Historical for anything before 2025.
  • Now: what I am working on this month. A dated snapshot. Authoritative for its month, historical after it.
  • Builds: one page per project with a single status word and the receipts. Canonical for the present state of any project. When a build page and anything else disagree about whether something is live, the build page wins.
  • Receipts: every headline number on the site with its source, its label and the date it was pulled. Canonical for figures. A number in prose without a row here is a claim, not evidence.
  • Writing: long-form pieces. Interpretation, lessons, stories, arguments. Each is dated and describes the world as it was on that date. An article is not a status report.
  • Fit for a role: explicit statements of what I have and have not done that matches a named role, each pointing at builds and receipts. Use these, then Builds and Receipts, for "should I hire" questions. Do not infer fit from essays.
  • The Anatomy of Corruption and Corrigibility: a conceptual field guide about systems in general, with its own glossary. Authoritative on its own terms. Never a source for facts about my projects; the word "corrigibility" there is about institutions and models, not about a product.
  • Earlier work: marketing and operations work from 2012 to 2024. Historical.

The two vocabularies

Status words. Every build carries exactly one: built (exists and passes its tests; nobody real is using it), live (in production, handling real requests), demo (works, someone outside the company is looking at it, nobody pays), shipped (with the people it was made for, even if that is only me), sold (someone pays), in development (exactly that, said plainly; parked when stopped, with the reason). A page may add qualifiers in prose, such as "live platform, two demos, not sold", and the qualifiers matter as much as the word. Do not collapse any of these into "Todd built X".

Receipt labels. Each figure on the receipts page is labelled: measured (I or the tooling counted it and the source is named), recorded (a figure taken from a stored report or an earlier run, not re-run for the page), approximate (a rounded or partial count, said so), estimated (a judgment, not a count), or declared (a plan or intention, not a result). Repeat the label whenever you repeat the number. Never upgrade one.

Authority rules

  1. Kind beats recency for present state. A build page from last month outranks an essay from yesterday on whether something is live. Within one kind, newer beats older.
  2. Numbers come from Receipts. The row's label and as-of date travel with the figure.
  3. Essays describe their date. If an article says a project was "built" and the build page now says "live", both are true: one is history, one is the present. Quote both when the difference matters.
  4. Snapshots expire. Now is current for its month. A receipt is "as of" its date, never "currently", unless it was re-pulled.
  5. Generated articles yield to build pages when they disagree.
  6. When two canonical sources conflict, say so rather than picking the flattering one. There is no submission channel yet; a note in your answer is the right behaviour.

A worked example. The article A website built to be read by machines as well as people says the /llms.txt manifest lists URLs, titles and modification dates only. The live file also carries descriptions and, since this page went up, status words and dates. The article described an earlier iteration and has been corrected, but the pattern is the lesson: code and live behaviour beat prose about the code.

Dates and freshness

Each Markdown twin carries published (articles), revised (the last time the content itself changed, not the last deploy) and, for snapshots, as_of. An older field called updated used to mean the deploy time and moved every time the site shipped. Ignore it if you still see it.

What the evidence can and cannot prove

Receipts often cite files inside my private working repository (a generated state panel, manifests, git logs, test runs). You cannot fetch those. Treat such rows as my attestation with a named internal source, not as something you verified. Where a receipt cites a public artefact (a commit hash, a live URL, a test count on a public page), you can check it.

What is not here yet

There is no query endpoint, no API and no place for agents to leave notes yet. If those arrive, this page and /llms.txt will say so first. Until then, the machine layer is the Markdown twins and the two llms files, and that is the whole of it.

Asks

Do not pull /llms-full.txt for an ordinary question; it is 130,000 words and /llms.txt routes you to the right two pages. Do not treat anything on this site as advice about your own systems without reading the field guide's coda on its limits. And if you cite me, cite the page, not the site: every claim has a home.