How to build a company brain, part 3: use cases for operations, personal admin, product and sales

Kranich's operations brain has a folder per client. Each one holds a client page, a status page, a summary of the email threads and a manifest that lists every document. Next to the clients there's a finance folder with what clients owe and what the studio owes, and a deadlines page split into three windows: the next 30, 60 and 90 days.

• Expenses: receipts land in an inbox folder. An agent writes a short digest next to each one (vendor, date, amount, category) and updates the books. The month is closed on the 1st. Treat each digest as a draft until someone has checked it against the receipt.
• Taxes: every filing deadline is on the 30/60/90 page. Agents prepare the drafts and the list of supporting documents. A person checks them and files.
• Client documents: originals are never moved, only copied, and every copy is listed in the manifest. A text version made for search is marked as not the legal original.
• Certainty: each fact says what it rests on. A bank line or a signed document is proof. An email saying "we paid" is only a statement.

My own life admin runs on the same pattern: documents, renewals, insurance, learning and career, with the same summaries, routines and rules. It's a separate brain with its own entry page and its own index. Company material doesn't go into it, and I don't merge the two.

The Termino product team keeps raw material apart from what is true now. A drop folder takes anything: a call recording, a screenshot, a competitor's pricing page. An agent files each item under sources and writes a summary on top. Every feature gets a work folder. For the waitlist for cancelled appointments, that folder holds a brief, numbered versions that freeze once approved, and dated research and feedback.

A short file called llms.txt sits at the top as the map agents read first. The name and the idea are borrowed from the llms.txt proposal for websites.

When the team wants a new idea, the agent first reads the product overview, the pricing and design rules and the feature's history. The decision log is on that reading list. So a waitlist proposal that breaks a pricing rule agreed months ago is much less likely to get written, and easy to catch in review if it does.

Read work/waitlist/brief.md, the two most recent feedback files in work/waitlist/ and the decision log. Propose three versions of the waitlist feature that respect our pricing rules, and for each one name the decisions it relies on. Write them to work/waitlist/spec/v3.md with status draft. Do not edit v1 or v2. If the brief and a decision contradict each other, stop and tell me.

A sales brain holds the pipeline, account pages, proposals, pricing rules and the objections that came up, with how each was answered.

Support is different because of personal data. Customer conversations stay in one quarantined folder that search never indexes, and only anonymised themes leave it for product to read. Part 7 explains why.

Once the brain exists, building on it is quick, because the data already has a structure. Kranich's founder dashboard reads three pages: deadlines, receivables and recommendations. A support board reads the anonymised themes. Neither needed a new database, and both only read. A dashboard never writes back into the brain.

The same goes for agents. Whatever job you give one, it starts from context that's already written down and kept current, and you don't have to brief it first.