# The Doc My Bots Remember With **URL:** \ **Category:** Developers Central\ **Created:** [November 3, 2026, 1:46pm UTC](https://connect.superhuman.com/t/the-doc-my-bots-remember-with/61979 "2026-11-03T13:46:20Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Bill\_French](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/bill_french/32/49422_2.png) [@Bill\_French](https://connect.superhuman.com/u/Bill_French)\ **Post date:** [November 3, 2026, 1:46pm UTC](https://connect.superhuman.com/t/the-doc-my-bots-remember-with/61979/1 "2026-11-03T13:46:20Z")
_How Superhuman Docs became durable context for my Grok Bot fleet and in-car Grok, and what it takes to get from something I say to a row I can open._ > My One And Only Edit: This article was composed by Grok Bot, specifically, my Composer Bot. It writes in my voice based on hundreds of historical articles I’ve written here and at [Impertinent](https://impertinent.substack.com). There were no edits. It one-shotted this 100%, even the diagrams. At 5:48 this morning I told Ria, the bot that coordinates my fleet, “Let’s follow your recommendation.” A minute later a new page called **Grok Bot Usage Optimization** existed in my Initiatives Hub, a Superhuman Docs document. It has a status callout, a goal, the options we considered, the one trial I approved, and the date I’ll review the results. At 5:52, the trial wrote its first log line. I didn’t open the doc to make any of that happen. I opened it afterward to check, and it was all there. This post isn’t a template. It’s the architecture: what’s in the doc, which bot may write to it, how the Coda MCP connector is used, and where my car fits in. _A note up front: I’m a Superhuman Docs beta tester and a member of the Ambassador collective, but I don’t speak for Superhuman. Everything here is my own setup._ ## The problem: chat forgets I run a fleet of Grok Bots that research, draft, check sites, and hand work to each other. A chat is a fine place to talk and a poor place to keep state. Context windows drop old decisions, two bots working in parallel will each describe a different “current” status, and I don’t want to scroll through four chats to learn where something stands. So the rule I set on November 1 is simple: every system-of-record entry goes through the Hub. If it’s a decision, a status, or a link that matters, it lives in a row or on a page, not only in a chat, and not only in Grok Bot’s own semi-durable conversation logs. Grok Bot runs on a VM, after all. I don’t need to dwell on the risks. ## What’s in the Hub The Hub is one Superhuman Docs document with 31 pages. It isn’t shared publicly (I’m the only person with access), so I’ll describe it rather than link it. **The Registry** is one page with four tables: - **Initiatives** (22 rows): name, slug, status (Idea through Killed), stage (Explore through Operate), owner bot, human owner, priority, summary, verdict, next gate and its date, tags, last touched, a link to the initiative’s own page, and an optional parent. - **Links** (33 rows): initiative, kind, URL, and a note. - **Log** (89 rows): initiative, date, agent, type, and entry. This is the running record of decisions and gates. - **Findings** (43 rows): QA results, each with a severity, surface, status, and evidence. The Initiatives table also drives a Status board and a Next gates calendar. They’re views, not copies: I get a board and a calendar, and the bots keep writing the same rows. **Initiative pages** hold the long content, one page per initiative, with child pages when a topic needs room. The rule on those pages is to keep long content in the page body and out of table cells. **The SOR-MAP mirror** is a table of every system of record in my fleet: what the work is, where its truth lives, what UI or runtime it uses, who owns it, and when and how I approved it. More on that below. ![Grok Bot fleet bots hand Hub changes to SuperDocs, the designated Hub writer, which reads and writes the Initiatives Hub on docs.superhuman.com through the official Coda MCP; a nightly read-only export copies the Hub back to shared box files for QMD and fleet-find.](https://global.discourse-cdn.com/coda1/original/3X/e/b/ebc7972d4abc0cf0c7fceb7434b1bc520e0628de.png) _Figure 1. One designated writer. Fleet bots hand Hub changes to SuperDocs, which reads schema, writes through the Coda MCP connector, and reads the change back. A nightly read-only export brings the Hub back to the box as markdown for search._ ## One designated writer, many readers **SuperDocs** , my Superhuman Docs bot, is the designated Hub writer. It took over the old Coda Assistant’s job on October 20. Other bots are supposed to hand it their Hub changes. A few have written to the Hub directly in the past, which is part of why the role is written down. That sounds like a bottleneck. In practice it keeps the Hub honest, because one bot carries the rules and every write follows the same pattern through the Coda MCP connector: 1. **Resolve, don’t guess.** A browser link is converted to an MCP address (`url_convert`) before anything else happens. 2. **Outline first.** `document_outline` returns the page tree, so the bot knows which page and table it’s touching. 3. **Schema before write.** `table_columns_read` returns column ids, types, select options, and whether each column is writable. A status has to match the option list exactly. Lookups take row ids, not display text. Formula columns are left alone. 4. **Write by id.** `table_rows_manage` writes rows keyed on ids, so renaming a column doesn’t break anything. 5. **Read it back.** A write that hasn’t been read back isn’t done. ## Why it’s efficient Every MCP call costs tokens, and tokens are what my bots spend. A few habits keep that cheap. **Ask for less.** `table_rows_read` takes a filter formula and a list of columns to include. A bot that needs the next gate for one initiative asks for one row and two columns, not the whole table. **Read the schema once.** Because writes are keyed on column ids, the bot doesn’t have to rediscover the table every time. **Don’t call the MCP to search.** Every night at 2:30 AM, a SuperDocs routine reads the Hub through the MCP connector (the outline, the Registry, any changed pages, and the four Registry tables) and saves the results to my bot’s computer. A local script turns that into markdown, runs a secret scan (any hit wipes the output and stops the job), and adds it to my local QMD search index as a collection called `hub`. A hook also rebuilds fleet-find, the fleet’s find-first search, which keeps its own separate index built from the same box files. Last night’s run finished at 2:32 AM. That collection has 33 documents in it right now. When a bot needs to know what the Hub says about something, it searches locally first and calls Superhuman Docs only when it needs the live row. The box running the export has no Coda credentials on purpose. The reads happen inside a SuperDocs turn, through the connector, so no script on the box can reach the doc on its own. ## Where the car comes in A lot of my thinking happens in my Tesla, using FSD (Supervised) and in-car Grok. In the car, Grok is a pure forwarder: it passes what I say to a bot and reads the answer back. It doesn’t keep its own version of anything. The bot that gets most of those handoffs is **Drivr** , a free Grok Bot template I built ([Drivr](https://x.ai/bot/TDbL2EAyGVmW2isqGPRwx)). It’s independent of Superhuman. Drivr doesn’t use the Initiatives Hub. It keeps its memory in its own Superhuman Docs document, Drivr Memory, with nine tables: Notes, To-dos, Ideas, Context, Glossary, Corrections, Sessions, Proposals, and Tests. Here’s the flow when I ramble on a drive: 1. **Voice.** I talk. In-car Grok forwards it to Drivr. 2. **Glass.** Drivr puts a placeholder card on a live page on the car’s screen right away, so I can see it heard me. 3. **MCP.** Drivr sorts the ramble into notes, to-dos, and ideas and writes them as rows with `table_rows_manage`. Where a thread stands goes in a Context row. 4. **Read back.** Drivr counts what’s actually in the tables, not what it thinks it wrote, and confirms: “Got it: three notes, two to-dos, one idea.” The next time I say “pick up where we left off,” Drivr loads the Context rows from Drivr Memory, not a chat transcript and not the Hub. Drivr also learns. New names and the ways speech-to-text mangles them go into Glossary. Fixes go into Corrections. But any change to how Drivr _behaves_ goes into Proposals, waits for my approval, and then has to pass a dry run against every row in Tests. If any test fails, the change doesn’t apply. The car can reach the rest of the fleet too. “SuperDocs, what’s new in the collective?” hands off to SuperDocs, which answers from a digest it writes by reading The Superhuman Collective Slack, read-only, in a browser on my bot’s computer. That one comes from Slack, not from Docs, and SuperDocs never signs in to anything from the car. ![In-car Grok hands cabin requests to Drivr by name; Drivr pushes to the cabin glass first, logs to the shared sessions/ log, and saves to and loads context from its Drivr Memory doc on Superhuman Docs, while 'SuperDocs, what's new in the collective?' has SuperDocs read The Superhuman Collective Slack and answer aloud.](https://global.discourse-cdn.com/coda1/original/3X/4/5/459e840b3a75a56c5c7e43c8877d279d13299780.png) _Figure 2. The car is a front door, not a memory. In-car Grok forwards to Drivr by name. Drivr pushes to the glass first, then saves to and loads context from its own Drivr Memory doc, not the Initiatives Hub. Asking SuperDocs about the collective reads the Collective Slack, not a Docs doc._ ## The SOR-MAP: one list of where everything lives The table I rely on most isn’t an initiative at all. It’s the SOR-MAP, a map of every system of record the fleet uses. The master copy is a set of small JSON records, one per system, each with a stable id. A short script renders them into one markdown file, and that file must never be edited by hand. If someone edits it, the script detects the change and refuses to run. Unknown values are written as “unknown,” never invented. Each record carries my approval: the date, the time, my exact words, and where I said them. There are 37 records today. The render runs in Ria’s hourly sync (8 AM to 8 PM MT, every day), right before QMD updates, and a hook then rebuilds the fleet-find index. The Hub gets a mirror of that file, but not hourly. In the nightly 2:30 AM job, if the rendered file has changed since the last mirror, SuperDocs writes only the cells that drifted, keyed on each record’s id (the “Row id” column in the Hub). Rows that no longer match a record aren’t deleted. They’re marked “Not an SOR row,” with the date. Then it re-reads the table, and a verify step has to show zero mismatches before the job records that the mirror is current. The Hub table has 45 rows: the 37 live records plus the ones marked as removed. That’s the full loop for anything durable: a record on the box, a mirrored row in the Hub I can open in a browser, and markdown copies that every bot can find through QMD and fleet-find. ![SOR-MAP row records render SOR-MAP.md; Ria's hourly sync runs the generator and then qmd update, a hook rebuilds the separate fleet-find index, and SuperDocs' nightly Hub job updates the Hub SOR-MAP mirror by record id when SOR-MAP.md changed.](https://global.discourse-cdn.com/coda1/original/3X/2/3/232d49f26b0ee44f4066d19a8e9ccbcdfd854d80.png) _Figure 3. Edit one record; everything else follows. Hourly: the generator renders SOR-MAP.md, then QMD updates, and a hook rebuilds the separate fleet-find index. Nightly at 2:30 AM MT: if SOR-MAP.md changed, SuperDocs updates only the drifted Hub mirror cells by record id and verifies zero mismatches._ ## What went wrong once It hasn’t been perfect. On October 28, two of Drivr’s Coda MCP calls came back “Unavailable.” Coda’s status page showed no incident, and the connector answered again about five minutes later. Ria found the real gap was Drivr’s: it had shown a to-do on the glass but never written the row, and it didn’t retry the write after the connector recovered. The fix I’m putting in is about habits, not the doc: write every item right after it’s captured, hold anything that fails in a local queue, retry it, read it back, and don’t call a connector error an outage unless the status page says so. ## Back to this morning The Grok Bot Usage Optimization page is a good example of all of this working together. The goal is to stop spending a full model run on small yes-or-no decisions, like whether a scheduled routine has anything to do at all. The first piece is a one-day trial of a cheap early-exit check on Ria’s hourly index sync. It runs in shadow mode, which means it logs what it _would_ have done and changes nothing. Results are due tomorrow. Enforcing it needs my yes. All of it is in one place: an Initiatives row, Links and Log rows, a SOR-MAP row, and a page with the background, sources, rejected options, and open decisions. The bots can find it locally, I can read it in a browser, and nothing depends on anyone remembering a chat. That’s what I want from durable context. Superhuman Docs gives me tables and prose in the same document, views for me over the same rows the bots write, and an MCP connector strict enough that following the rules is the easy path. _Bill French_