The failure log is the most valuable thing in this 72-hour agent build repo

Three xAI engineers built and shipped a product from an empty repository in 72 hours, live on stream, using their own agent platform. This repo is the distillation of those three days: not a tutorial, not a framework, but a working artifact extracted from a real build under real pressure.

The core of it is AGENTS.md, a single file of house rules you drop into your repo root so your coding agent reads them automatically. That's the entry point. Everything else radiates outward from it: an orchestration reference, a verification guide, a prompts file, a PR template that enforces proof-of-reproduction before merge.

The antipatterns file is the most honest piece here. Forty things broke on air. Each entry names what broke, explains why, and states the rule that came out of it. That's a different kind of documentation than most agent repos produce - it's a failure log with derived principles, not a success story with caveats.

The roster covers a wide range of agent roles, one file per role, each specifying what the role owns, what it doesn't touch, where it gets its facts, and what requires human approval. The playbooks cover nine functional areas - engineering, PM, sales, support, marketing, and others - with the actual team of bots, the workflow as it ran, the prompts used, and the numbers. The economics reference tracks every cost and metric against the rule it supports, which is rare and useful: most agent documentation ignores token spend entirely.

The one-paragraph summary buried near the bottom of the README is the sharpest thing in it. Give each agent one narrow job. Build the verification loop before you build the second agent. Make the agent reproduce a bug before it fixes one. Audit routines weekly, because frequency is where the money goes. Keep a human gate on migrations, deploys, money, and permissions regardless of how well the loop has been running.

That last point matters. The repo doesn't argue for full automation - it argues for designed boundaries, and it shows what happens when you skip them. The Cursor ports, the PR template, the role files: all of it is structured around the assumption that agents fail in predictable ways and that the job is to make those failures visible and recoverable before they compound.

This is practitioner documentation, not research. Its value is proportional to how much you trust the source conditions - a 72-hour build is a specific kind of stress test, not a longitudinal study. But the failure log alone is worth the read.