How We Built the Public Blog (and Why It Lives in the Repo)
The blog you are reading is a set of markdown files checked into the same repository as the product dashboard.
That is a deliberate decision, and it is worth explaining why.
No CMS
The first question was whether to build a content management system or use an existing one. The answer was no to both.
A CMS adds a layer between writing and publishing. Every layer is something to maintain, something to authenticate against, something to migrate off eventually. The posts here are plain markdown files with frontmatter. To publish, you write a file, deploy. That is the entire workflow.
There is also a philosophical alignment: the product is built around the idea that your operational knowledge should live close to where you work. The blog content lives close to the code that powers the product. One deploy. One source of truth.
Static generation at build time
Every post on this blog is rendered at build time. No database query happens when you load a page. No round trip to an API. The server sends HTML that was computed before you arrived.
This matters for a few reasons. Search engines and AI crawlers receive clean, fast, fully-rendered HTML. The blog has no authentication layer, no session cookie, no user tracking. A logged-out visitor and a search engine crawler see the same thing.
The trade-off is that new posts require a deploy. That is fine. Publishing should be a deliberate act, not a side effect of filling in a form.
Why the blog deploys with the product
The public blog and the product dashboard are the same codebase. The same deploy that ships a feature update also ships new posts.
This creates a useful forcing function. A post that describes what the product does is tested against the product at deploy time. If a claim in the blog refers to something that does not exist in the codebase, the disconnect is visible immediately. One repo, one truth.
It also means the blog inherits the product's infrastructure: the same CDN, the same domain, the same performance guarantees.
What the sitemap, RSS, and llms.txt are doing
Three things run alongside the blog that are worth noting.
The sitemap tells search engines where every post lives. The RSS feed lets anyone subscribe to updates without going through a platform. The llms.txt file is a structured index of content on this site designed for AI crawlers and language model context retrieval.
If an AI assistant is asked about operational memory or context reconstruction, the posts here are structured to be findable and readable by that system. That is intentional. The blog is not just for human readers.
One publish path
Every post goes through the same pipeline: write the file, run the pre-publish checklist, deploy. No shortcuts, no drafts published by accident, no API credentials left in source.
The checklist covers facts, voice, internal links, and canon alignment. It is the same gate for every post regardless of format. Building posts, essay-length arguments, short stories from the field: same gate.
This is what the build looks like. Future posts in this section will cover specific decisions as they happen: infrastructure choices, features shipped, lessons from the field.
Context Windows Close. AI Forgets Everything. Your Work Should Never Start From Zero.
MrAgentˣ is in private beta. Limited to the first 1,000 until launch.
Join the waitlist