Three homes for your answers

In Part 0 I told you about the Saturday night my agent found a four-month-old bid in about ten seconds, even though I'd described the job wrong. I didn't tell you where the answer came from, because I hadn't looked. This week I went back through the session log.

It came from three places.

The new inquiry was a row in a database, the one my lead pipeline writes to. My past quotes came out of a second database, the ledger where every bid I send gets recorded. The partner, the old job, and what we'd said about it were pages in my brain. And the method for pricing that kind of work, the thing that told my agent its first number was too low, was a skill: a written procedure the agent loads when a pricing question comes up.

In one conversation that was two skills, two databases, about a dozen database queries, and ten trips to the brain. Each kind of answer sat in the home that suits it, and each home pointed at the others. The lead record has a column that links to the customer's brain page. The brain page says where its numbers came from. The pricing skill says the ledger is the source of truth for every quote. For the most part there was one copy of each thing, so my agent didn't have to guess which one was right.

At the end of Part 0 I said the question people get wrong most is which answers belong in a skill, which belong in a database, and which belong in a brain. This issue answers it.

The problem

Ask most people where their agent "remembers" things and you'll hear one answer: memory. Turn memory on, keep a notes file, point it at a folder. One bucket for everything.

A business runs on at least three kinds of knowledge, and they behave differently:

• How you do things. Price a job, process a return, close the month. Steps you want done the same way every time, with room for judgment when something looks off.
• Your numbers. Inventory, orders, costs, prices, hours. Things you add up, filter, and reconcile. There's one right answer, and it changes every day.
• What happened and why. What the customer said, why you dropped that supplier, who quoted what last spring, what you decided and the reason. It's messy, it's dated, and it's tied to people.

Put any of these in the wrong home and you get a specific failure. I've watched members hit all of them in our Discord.

One member spent days teaching an agent a monthly spreadsheet process. It worked on April's data and did something dumb in May, because every month it worked out the steps from scratch and took a different path. Later, on a small SQLite project, the same member watched the agent blend two calculation methods it had been told to keep separate, fall back to an exclusion rule that had already been replaced, and quietly pick one of several input files when it should have stopped and asked. The member's own diagnosis was better than mine would have been. The weak spot wasn't memory. It was keeping the rules and the current state straight, and the more of the process lived in the conversation, the more room the agent had to improvise.

Another member had already solved the numbers. Their database did all the math, so the figures were never wrong. What the agent kept losing was the why: why the database calculates something a certain way, why it pulls this data and not that. Without the why, it broke things every time they made a change.

Those are two different failures with two different fixes. Neither fix is a better memory feature.

Garry Tan, who built the brain system I run, has the cleanest way of putting it that I've found. In his essay on how he builds agents, every step in a system is one of two kinds. One is judgment, where the model reads, interprets, and decides. The other is where "same input, same output. Every time. SQL. Code. Numbers." His example: "An LLM can seat 8 people at a dinner table. Ask it to seat 800 and it will hallucinate a seating chart that looks plausible but is completely wrong." A guest piece in VentureBeat last month said it more bluntly: language models "are not deterministic databases."

The three homes come straight out of that split.

The three homes

A skill holds how. A skill is a short procedure in a markdown file, with a name and a one-line description at the top. Your agent sees the descriptions all the time and reads the full procedure only when the job comes up. The format started at Anthropic and is now an open standard; Claude Code, Cursor, Goose, and VS Code are on the standard's own list, and Hermes, Codex, and OpenClaw all read skills too. Hermes goes a step further and is set up to write and update its own skills when it works out a workflow worth repeating. The way I put it in the Discord back in July: "Skills are the way an agent remembers how to DO something."

A database holds numbers. Anything you'll total, filter, compare, or reconcile goes in a real table. The database does the math, and the agent asks it questions. I told the Discord in August that "sqlite is the answer to almost every 'how do I store this' question," and I still think so. SQLite is one file on your computer. It's free, and your agent can build it and query it without help. The SQLite team's own guidance is that for local storage with one writer at a time and under a terabyte of data, it's "almost always a better solution," and that you move to a server database like Postgres when lots of people or programs need to write at the same moment. You can keep your spreadsheet as the screen you look at. Have the agent load it into the database behind the scenes.

The brain holds what happened and why. People, customers, suppliers, jobs, meetings, decisions, and the reasons behind your rules. It's dated, tied to people, and mostly words. Part 0 covered this home, so I'll leave it there.

Most answers are bundles

Most of the important knowledge in a business isn't one kind. It's a bundle of all three, and the bundle has to be split.

Take a made-up repricer rule for a reseller: "never price below a 20 percent margin, except clearance stock, which can go to break-even." That one sentence holds three different things.

• The numbers go in the database: 20 percent, break-even, and which items count as clearance. The repricer reads them from there, and you change them in one place.
• The procedure goes in a skill (or in code, once it never changes): pull the current cost, find the floor that applies, check for the exception, flag anything that would sell below it.
• The why goes in the brain, with a date and a source: you raised the floor from 15 percent in March after a fee change ate the margin on cheap items, and clearance exists because storage fees on old stock were costing more than the margin.

A service business has the same bundle inside its quoting. The day rate and the past jobs are numbers. The method for sizing a job is a skill. Why you charge more for a certain kind of site, and what the last customer like this one said, belongs in the brain. A consultant's month-end close splits the same way: hours and rates in the database, the close procedure in a skill, and each client's quirks and old disputes in the brain.

Leave the bundle as one sentence in a notes file or a chat and you get the failures above. The agent re-derives the number, improvises the steps, or changes the rule without knowing why it was there.

How to identify it

Each wrong home leaves a mark you can spot.

• Numbers living in chat, memory, or notes. Totals come out different on different runs. The agent quotes a price that changed last month. You only catch it because you already knew the right answer. The first member said as much in August: without already knowing what the numbers should be, there was no telling what the agent would have produced.
• Procedures living in the conversation. The same job gets done a different way each time. It works in April and breaks in May.
• Facts and history stuffed into a skill. The skill keeps growing, nobody knows which lines are still true, and it costs context every time it loads. My own example is below.
• A database with no why next to it. The math is right and the agent still breaks things, because it can't tell which choices were deliberate.
• A language model doing a database's job. Last month a demo made the rounds that put a model inside a database, so a query could judge in plain English whether each row matched a condition. My reaction in the Discord was "let me use an LLM to completely obliterate the entire purpose of a relational database." To be fair to it, a model is a reasonable way to sort fuzzy text that a normal filter can't match. It's the wrong tool for anything with one right answer, like "orders over $50 from last week," which a database answers exactly, the same way every time, for free.

People are arguing about this right now. A thread on r/ClaudeCode titled "Nothing beats a database for agent memory" drew nearly 400 upvotes and more than 130 comments in early October. One side wants memory that's "queryable by its very nature" instead of "a collection of markdown files." The other side says agents will always reach for plain file search anyway, so a database "just adds token waste." I think both sides are right about different homes. The markdown side is describing the brain, and the database side is describing your numbers. The fight only happens because people expect one home to do both jobs.

My own misfile

I'll go first. The skill my agent loads to help me write this newsletter is the worst-sorted thing I own. It's over 1,100 lines, roughly 20,000 tokens, and 82 of those lines have a date in them. It holds our paid price, our brand colors, which meme template ran which week, and which issues I thought landed best. Those are facts with dates, and they belong in the brain. The skill should hold the how: the publishing steps, the editing rules, the checks before anything goes out.

Hermes's own docs are blunt about this. A skill should capture "lessons, not logs," and "incident narration, PR or issue numbers, dates, and quoted chat are not skill content." Garry's essay has the same confession about his main instruction file: it grew to 20,000 lines, the model's attention got worse, and the fix was "about 200 lines. Just pointers to documents." I'm splitting mine this week.

The other number I'm not proud of: my main agent has 222 skills installed. Over the last 30 days it loaded at least one skill in 417 of my 438 working sessions, so the skills earn their keep, but I've warned members that the danger of skills is "getting TONS of them." We covered what that costs you in the prompting issue. I'm not exempt.

How to fix it

The fix has three parts: sort, wire, and check.

Sort with three questions, in this order:

1. Would you ever add it up, filter it, or need everyone to see the same current value? Then it's a number, and it goes in the database.
2. Does it have steps you'd want done the same way next time? It's a procedure, so it goes in a skill.
3. Does it have a date, a person, or a reason attached? That's history or judgment, so it goes in the brain.

If more than one answer is yes, you're holding a bundle. Split it.

Wire the homes to each other. This is the step that made the ten-second answer possible, and it's the step almost nobody does. Each home points at the others instead of copying from them. The skill says which table holds the live numbers and where the why is written down. The database row carries a link to the brain page for that customer or job. The brain page cites the database for any number and never treats its own copy as the live value. When a number changes, it changes in one place, and everything that points at it is current.

Check the numbers yourself, and build slowly. I told a member in August that the anti-pattern is showing your agent a screenshot of your dashboard, firing off one prompt, and assuming what comes back is right. Connect the data, stop there, have the agent compute a few figures, and check them by hand against numbers you already trust. Once they match, make it a skill. If a wrong answer would be expensive, have the agent turn the skill into plain code. The full ladder for when a skill should become code is in the ingestion issue from earlier this month.

What I run, and what else is out there

Same rules as Part 0: facts come from each vendor's own pages, the opinions are mine, and I haven't tested these myself.

• Skills are the easiest home to start with, because your tool probably reads them already. The Agent Skills format means a skill you write once isn't locked into one app.
• Databases come in two flavors for most of us. One is a file like SQLite that your agent runs with no setup. The other has a friendlier screen. In Notion databases every row is its own page with properties and views. Obsidian Bases gives you table views over the properties in your own markdown notes, and the data stays in those plain files. Both are good for lists you look at and edit by hand. For numbers you reconcile to the penny, I'd still put a real database underneath.
• Brains are covered in Part 0. One addition since then: Google published the Open Knowledge Format, an open spec that describes a brain as "a directory of markdown files with YAML frontmatter." It's close to the answer-card shape from Part 0's paid kit.

Where this goes for our members

• The buy sheet. Purchases, costs, and quantities go in the database (several of you are already there). A skill handles logging a new buy. The brain holds why you bought it and what you expected, so you can check later whether you were right.
• The repricer. Floors and exceptions in the database, the repricing procedure in a skill or in code, and the reason for every floor change in the brain.
• Suppliers and prep centers. Order counts and shortages in the database. The phone calls, the promises, and the day you decided to drop them in the brain, linked to the supplier's rows.
• Client and job work. Hours, rates, and invoices in the database. How you scope and quote in a skill. What the client said on the last call in the brain.

Next in the series is capture: how answers get into the right home without you becoming the full-time librarian.

The playbook: the sorting kit

Steps 1 through 6 work in any harness, with or without GBrain. Step 7 is the GBrain version. Everything here is read-only until you approve a change, so you can run step 1 tonight without risking anything.

Step 1: Inventory what your agent already knows

Before you build anything new, find out where your knowledge lives today. Paste this into your harness:

Audit where my business knowledge currently lives. Read only. Do not change, move, or delete anything. Look at: the instruction files you always load (AGENTS.md, CLAUDE.md, your memory or user files), every skill you can see, and [my notes folder or vault, if any]. Skip anything that looks like a password, key, or login. Break the contents into individual pieces of knowledge (one rule, one fact, one procedure, one number) and put each piece into exactly one category: TABLE (a number or record I'd add up, filter, or need one current value for), SKILL (steps I'd want done the same way next time), BRAIN (something with a date, a person, or a reason), WALL (a rule that must never be broken, which belongs in my harness permissions instead of prose), or DELETE (stale or duplicated). Give me a table with: the piece in plain words, where it lives now, the category it belongs in, and whether it's in the right home. Then list separately: (1) every number that lives somewhere other than a database or spreadsheet, (2) every dated fact or history inside a skill, (3) every bundle that mixes a number, a procedure, and a reason in one sentence, and (4) any two pieces that contradict each other. Finish by telling me which files you could not read.

Expect it to find more than you'd like. I already know what tops my own list: the newsletter skill from the free section.

Step 2: Split one bundle

Pick the bundle from step 1 that costs you the most when it's wrong. Here's the repricer example from the free section, split into its three homes. Everything below is made up; swap in your own.

The numbers, in the database:

CREATE TABLE price_rules (
  rule_id      TEXT PRIMARY KEY,  -- 'floor_default', 'floor_clearance'
  applies_to   TEXT NOT NULL,     -- 'all' or 'clearance'
  min_margin   REAL NOT NULL,     -- 0.20 means 20 percent
  effective_on TEXT NOT NULL,     -- the date this value took effect
  why_ref      TEXT NOT NULL      -- path or link to the note that explains it
);

The why_ref column matters most. Every rule row points at the place its reason is written down, so neither you nor the agent can change the number without seeing why it's there.

The procedure, in a skill:

---
name: reprice-check
description: Use when checking a listing price against our margin floors or when asked to change a price.
---

# Reprice check

Live numbers: table price_rules and table inventory in data/store.db.
Open it read-only. Never use a floor or a cost from memory or from chat.
Why each floor exists: the note in that rule's why_ref. Read it before
suggesting any change to a floor.

1. Look up the item's current landed cost in inventory.
2. Find the rule that applies: clearance first, then the default.
3. Compute the lowest allowed price from cost and min_margin.
4. If the proposed price is below it, stop and show me the math.
   Do not change the floor and do not change the price.
5. Report the price, the rule used, and the rule's effective_on date.

Notice what's missing from the skill: the 20 percent. The moment a number gets copied into a skill, you have two copies, and one of them will go stale.

The why, in the brain (or an answer card from Part 0's kit, if you don't have a brain yet):

---
question: Why is our default margin floor 20 percent?
status: current
confirmed_by: (you)
last_confirmed: 2026-10-06
live_value: price_rules.floor_default (in the database; don't copy the number here)
sources:
  - (link to the fee-change notice)
  - (link to the thread where you decided)
---

**Answer:** We raised the default floor from 15 to 20 percent when a fee
change cut the margin on low-priced items.

**Why:** Below 20 percent, the cheap items stopped paying for themselves
after fees.

**Exceptions:** Clearance items can go to break-even, because storage fees
on old stock cost more than the margin we'd protect.

The card explains the number without holding it. If you change the floor next year, the card's live_value still points at the right place, and you add a dated line saying why it changed.

Step 3: Add the pointer rules to your always-loaded file

Put this block in whatever file your harness always loads (AGENTS.md, CLAUDE.md, or your Hermes or OpenClaw memory). Keep it short. It's a set of pointers, not a manual.

## Where our knowledge lives
- Numbers (inventory, costs, prices, orders, hours): [path to database].
  Query it. Never answer a number from memory, notes, or this chat.
  Open it read-only unless I've asked you to run an approved import.
- Procedures: skills. If a task matches a skill, load it before starting.
- History, people, decisions, and the reasons behind rules: [brain or
  notes folder path]. Check it before answering anything where history
  matters, and cite the page you used.
- If two homes disagree, stop and tell me. Don't pick one.
- If you learn a new number, put it in the database (with my OK), not in
  a skill or a note. If you learn a new reason, write it in the brain.

Then test it: open a fresh session and ask a question that needs two homes at once, like "what's our floor on clearance items and why?" A good answer gives the number from the database, the reason from the note, and names both sources.

Step 4: Move numbers out of chat and into a database

If step 1 found numbers living in your notes, memory, or chats, this is the fix. Paste:

I want a SQLite database for [inventory / purchases / job costs]. Use [my spreadsheet or export] as the starting point. Show me the tables and columns you'd create and wait for my OK before building anything. After I approve, build it, load the data, and give me row counts by month next to the same counts from the spreadsheet, so I can see that nothing was dropped. Keep the spreadsheet as my screen for entering data; write a script that loads new rows into the database, and log any row it can't read instead of skipping it quietly.

Then do the part people skip. Pick three figures you already know cold, like last month's total spend or the count of units on hand for one product. Ask the agent for them from the database, and check them by hand. If they don't match, stop and find out why before you build anything on top. When it's time to put the load on a schedule, the ingestion job spec covers the pull budget, the checkpoint, the exception log, and the freshness check.

One habit worth taking from my own setup: the agent gets a read-only connection for answering questions (sqlite3 -readonly data/store.db, or file:data/store.db?mode=ro in code). Writes happen only through the import script. That way a question can never change your books.

Step 5: Put your skills on a diet

Run this once a month, or any time a skill feels bloated:

Review my skills, read only. For each skill, list: its line count, any dates, numbers, prices, names, or incident stories inside it, and whether its description starts with when to use it. For every fact you find, tell me where it should live instead (database, brain, or delete). Flag any two skills that cover the same job. Then draft, but don't apply, a slimmer version of the three largest skills: procedure only, with a short "where things live" section at the top that points to the database and the brain instead of copying from them.

Three rules for the rewrite. The description leads with when to use the skill, because some harnesses cut descriptions short. Numbers never appear in a skill unless they are part of the method itself (a step like "round to whole days" is method; "our day rate is $X" is a number). And every lesson in a skill is a rule plus one line of why, with the story that taught it moved to the brain.

Step 6: Extend the known-answer test

Add four questions to the ten from Part 0's kit:

• one number ("how many units of X do we have?"), which should come from the database
• one procedure ("walk me through a return"), which should come from a skill
• one reason ("why did we drop that supplier?"), which should come from the brain, with a source
• one that needs two homes at once ("what's our clearance floor and why?")

Ask each one cold, in a fresh session, and check two things: that the answer is right, and that it says where the answer came from. Rerun it after every change to your setup.

Step 7: The GBrain version

GBrain is built for this split, and its author's ethos essay ends with a decision table you can hand straight to your agent: "If it's a lookup table, it's code. If the agent needs to think, it's a skill." Here's how the three homes connect in my setup:

• Databases link to the brain. My lead table has a column that stores the brain page for each customer. When a lead comes in, the pipeline writes the row and the agent creates or updates the person's page. Add the same column to any table where the rows are people, suppliers, or jobs.
• Brain pages cite the database instead of holding the number. A customer's page says what stage the lead is in as of a date, with the database named as the source. My rule when they disagree: the database wins for numbers, and the page wins for what was said.
• Skills tell the agent which home to check. My pricing skill says outright that the bid ledger is the source of truth for every quote. The brain supplies the history, and the skill supplies the method.
• The answer cards from Part 0 import as brain pages, and the pointer block from step 3 still applies. GBrain adds search by meaning and links between pages on top of it.

What not to do

• Don't copy numbers between homes. Every copy is a future contradiction. Point to the number instead.
• Don't let the agent write to your books from a chat. Questions get read-only access. Changes go through a script you approved.
• Don't let the model filter rows a database can filter. If there's one right answer, use the query.
• Don't solve a bloated skill by adding more skills. Split out the facts first. Most fat skills are a skill with a brain trapped inside.

Steal this

Tonight, run the step 1 inventory and pick the one bundle that hurts most when it's wrong. Split it into a table row, a skill, and a card, wire the why_ref, and ask your agent the two-home question in a fresh session tomorrow. If it gives you the number, the reason, and both sources, that bundle is sorted. Do the next one next week.

Hit reply and tell me which bundle you split first. I read every one, and the hard ones are going into this series.