The 40 failure reports beat the 69-role catalog
ANTIPATTERNS.md records 40 things that broke during the three-day Grok Bot build, then connects each incident to a reusable rule. That is the repository's best material. A coding agent opened a pull request after being told to investigate, client-side state let a player edit a score, and a launch path failed because testing used one account on a development machine. Each story gives the rule enough friction to remember.
The larger catalog contains 69 roles covering engineering, sales, support, marketing, operations, and personal work. It is useful as a menu, but copying the menu would miss its own advice. The roster says most livestream setups used 5 to 10 roles and tells readers to cut each ownership list down to what they need now. Start with one recurring failure, assign one owner, and add the approval boundary that failure demands.
What happened when we ran it
Our lab did not run commit 02780c0. The harness reported no supported ecosystem for this Python-labeled repository and found no Dockerfile. There are no measured install times, build results, test counts, dependency totals, or vulnerability findings to report. That absence is informative because the repository is a set of documents and PDF guides, despite GitHub classifying its primary language as Python.
The README's setup command only downloads AGENTS.md into another repository. No service starts and no model is included. Reading the material requires no secrets. Applying it is platform work: map the rules to your coding agent, replace placeholders, choose which tools it may call, and define who can approve deployments, migrations, money, permissions, or access to user data.
One AGENTS.md file makes proof the completion rule
The root AGENTS.md gives verification one clear job: reproduce a problem before changing code and attach proof before calling the work finished. It asks for screenshots or recordings on UI changes, before-and-after figures for backend work, and the failed then passing reproduction for a bug fix. It also tells an investigating agent to stop at diagnosis when the request does not authorize a fix.
Those rules are stronger than generic instructions to be careful. The file names actions and evidence. It also sets human stops around authentication, payments, permissions, user data, database migrations, destructive commands, production deployment, and unresolved product choices. You still need to reconcile those defaults with your own repository, because a copied AGENTS.md can conflict with existing contribution rules or grant the wrong platform assumptions.
Nine playbooks preserve detail and admit their limits
The 9 playbooks cover engineering, product management, founders, sales engineering, sales, SDR work, customer support, post-sales, and marketing. Each lists the agents involved, the workflow shown on stream, prompts, routines, and a setup checklist. Two PDF guides package the same material into 24 pages for the broader build story and 14 pages for marketing. The Markdown is easier to audit and adapt than the PDFs.
The caveats matter. Demo companies and accounts were fictional. Dictated prompts may have been lightly repunctuated, reconstructed prompts are labeled, and the figures in the notes were moving numbers spoken during September 2026 streams. The roster goes further: its descriptions were written from presenter explanations and were not published verbatim or tested as-is. Treat the files as careful reporting with editorial reconstruction, not official xAI configuration.
The 69 roles need sources, limits, and approval gates
Each roster file has a sensible template: ownership, exclusions, source of truth, approval needs, triggers, outputs, routines, and a paste-ready description. The does not own section is especially useful because agent sprawl often starts with overlapping authority. A role that drafts sales mail and a role that sends it should not quietly collapse into one agent with inbox access.
Some role descriptions still assume tools and data that your organization may not have. A competitive-intelligence agent is expected to use competitor products, while a support agent relies on a knowledge base and traces. The documents describe operating patterns, not the connectors, permission model, evaluation set, or audit trail needed to make them safe. The repository's own verification guide says autonomy depends on a machine-readable success signal. Build that signal before raising the autonomy rung.
v1.0 is a recent snapshot with a quiet issue tracker
GitHub showed 578 stars and 80 forks on October 6, 2026. Release v1.0 shipped on September 20 with the two guides, 69 roles, 9 playbooks, and the failure log. The last push was also September 20. One open issue titled Grok had no body or comments, so it offers no useful evidence of maintainer response or user support.
That short history does not establish neglect. The repository was only created on September 18, and a finished field-note release may change less often than software. It does mean adopters should judge the content on its dated source material instead of expecting patches, compatibility fixes, or an active support channel. Product behavior belongs in current xAI documentation, while this repository is strongest when a failure story helps you write a better local rule.
Grokbot Field Notes earns a place beside an agent policy draft, especially when a team keeps accepting code without proof. The sharpest adoption path is small: read the 40 failures, copy only the rules tied to problems you recognize, and make each rule answerable by evidence. The 69-role roster can wait until one agent already has a job that your team can verify.