How to build an AI second brain for business decisions on Zo

An AI second brain for business needs three layers to be worth the effort: persistent memory that carries context between sessions, files on your own server as the durable record, and an AGENTS.md index that tells a cold session where everything lives. Add a decision log and it starts changing what you decide.

Key takeaways

• Most second brains fail as retrieval systems, not storage systems. Adding more notes does not fix a system you cannot query.
• Zo's persistent memory carries preferences, project names, and people across sessions, so a new chat starts with context instead of a blank slate.
• Files in your workspace are the layer you can inspect, edit, grep, and correct. Memory drifts. Markdown on disk does not.
• Treat AGENTS.md at your workspace root as a routing index, never a journal. Forty lines of pure signal beat a 400-line scroll.
• One short file per real decision is the whole decision log: the date, the call, the options you killed, the reasoning, the owner, and the review date.
• Rules hold behavior, AGENTS.md holds facts, skills hold procedures, personas hold jobs and permissions. Filing something in the wrong one is why it never fires.

Why does most second-brain advice fail?

Because it treats a retrieval problem as a storage problem. Capture more, tag better, pick the system with the right acronym. Eighteen months later you have 900 notes and still cannot answer why you priced the mid tier at $49 instead of $39.

Storage was never the bottleneck. Ask what you actually want from the thing. Not "where is that note." You want your own reasoning handed back when you need it, in a form you can act on. That is a query, and a pile of files nobody indexed cannot answer one.

The other half of the failure: an AI that remembers context is useless if it has no idea your notes exist. It boots cold and hands you a plausible average of the internet instead of what your company decided in March.

What are the three layers that actually work?

Name them plainly, because people collapse all three into "my notes" and then wonder why nothing compounds.

Memory is the relationship. Files are the record. AGENTS.md is the map that connects them. Miss the third one and you own a well-organized archive that nothing reads.

How do you set up each layer in Zo?

1. Write the durable decisions to files, not just memory. Memory carries context between sessions, but a file is the record you can trust, search, and correct when it drifts. Plans and limits are at zo.computer/pricing.
2. Tell Zo the background once. What to call you, what you are building, who approves what, how you want answers written. Then work normally and correct it when it slips.
3. Decide where the durable record lives. Pick real folder paths and use them. Decisions/, Clients/acme/, Playbooks/. Markdown, because you can read it in any editor on any machine, which is the whole point of files on your own server.
4. Have Zo draft the routing index, then cut it hard. The first draft always over-includes.

Read through my workspace and write a root AGENTS.md that maps my

active projects: name, actual folder path, and one sentence on what

each is for. Add a canonical-paths section and a don't-break list for

anything live. Keep it an index. No chat logs, no decision histories,

no secrets. Under 50 lines.

Project folders can carry an AGENTS.md of their own, and when both exist the narrower one takes priority. Your root file stays a map. The deep notes sit next to the work they describe. The AGENTS.md guide goes further on structure.

What is a decision log, and why does it change decisions?

A decision log is one short markdown file per real decision: the date, the call, the options you rejected, the reasoning, the owner, and the date you will revisit it. Almost nobody does this. It is what separates a second brain you consult from one you merely maintain.

Here is what it buys you. Next quarter, when someone reopens the pricing argument, you ask your own workspace what you decided and why. Your reasoning comes back, including the option you killed and the constraint that killed it, instead of relitigating it with everyone's memory of the meeting quietly rewritten in their favor.

Use this decision log template. Six required fields plus one optional, all in one file under 200 words.

Give Zo this prompt and it becomes a thirty-second habit instead of a documentation project:

Write a decision record to Decisions/YYYY-MM-DD-<short-slug>.md.

Decision: <the call, one sentence>
Options rejected: <what else was on the table, and why each lost>
Reasoning: <the constraint or evidence that decided it>
Owner: <name>
Review date: <actual date>
Confidence: <low / medium / high>

Use those exact headings. Keep the whole file under 200 words. Then
add one line to Decisions/AGENTS.md with the date, the slug, and a
six-word summary so a future session can find it.

That last instruction is the part people skip. A decision file nobody indexed is a file nobody reads. Then the retrieval side is one sentence: Read Decisions/ and tell me what we decided about pricing and why, including what we rejected.

Where does each thing belong: rule, skill, persona, or AGENTS.md?

Four containers, four questions. Pick wrong and the thing you wrote never fires when you expect.

"Never send an email without showing me the draft" is a rule. "Our pricing decisions live in Decisions/" is an AGENTS.md line. "Here is exactly how to write the Friday client update" is a skill, dormant at one line of context until a request matches it. And a reporting persona that can read your files but cannot send anything is how you run unattended work safely. The four-way breakdown settles the edge cases.

Keep these out of AGENTS.md:

• Chat transcripts and what-we-did-today logs
• One-off facts that expire next week
• Secrets, API keys, and tokens, which belong in Settings > Advanced and never in a file
• Your decision journal, which lives in Decisions/ with an index line pointing at it

The distinction on that last one is worth holding. AGENTS.md says the decisions folder exists. The folder holds the decisions. Collapse the two and your root file balloons past 400 lines, with the one fact you needed sitting somewhere around line 230.

How do you stop the library from rotting?

Notes land in the wrong place. That is normal and it is not worth fighting by hand. Set one automation to sweep loose captures into the library on a schedule, in plain English:

Every Sunday at 6pm, read anything new in Inbox/ and file it into the right folder under Knowledge/ or Decisions/, matching the existing naming conventions. Update the relevant AGENTS.md index lines. Email me a summary only if something was ambiguous or you had to guess.

Weekly suits most solo operators. That conditional delivery line keeps it from becoming another inbox, and every run saves as a real conversation you can open when the filing looks wrong.

How do you get Zo to push back instead of agreeing?

A second brain full of your own reasoning is dangerous if the thing reading it only ever tells you that you were right. Models slide toward yes. So install friction on purpose, as a rule:

Before executing any request involving a plan, an architecture choice, or public output, tell me the strongest objection to it first. If the request solves the wrong problem, say so plainly and give one concrete alternative. Do not soften it. When you finish a task, name one thing
you left out and one case that would break it.

The "do not soften it" line does real work. Without it you get the objection wrapped in three paragraphs of reassurance, which is the same as not getting it. For the persona version, where you build a reviewer whose whole job is to argue, the pushback guide walks through the setup and scoping.

What goes wrong

The log becomes a journal. Record every choice and you have recorded nothing. The filter: would you be annoyed to relitigate this in six months? Log that. Skip the rest.

AGENTS.md bloat. It loads early on every turn, so a bloated index crowds out the context you wanted Zo spending attention on. Prune stale lines when a project dies. Pruning is maintenance, not a separate chore.

Memory drift. Zo remembers something that changed three weeks ago and works from the old version. Correct it, and put anything you need exact into a file instead of trusting recall.

Credit burn on a fast schedule. Every scheduled run spends credits whether or not it notifies you. A 5-minute automation fires 288 times a day and bills for all 288. A weekly consolidation job costs almost nothing. Match the interval to how fast the data actually changes.

Silent failures from a lapsed token. A connected app's authorization expires, the schedule keeps firing, the call fails, and the run looks fine from outside. Open the saved conversation behind any suspiciously empty section.

Assuming the draft went out. Zo drafts and does not send. Keep the human gate on anything outbound, and give any unattended persona a scope that cannot message anyone.

Frequently asked questions

What is an AI second brain for business?

An AI second brain for business is a persistent knowledge system your AI reads before it works: your files, your project context, and your recorded decisions. Unlike a notes app, the AI queries it directly, so answers come from your own reasoning rather than a generic model guess.

Does Zo remember context between conversations?

Yes. Persistent memory carries preferences, project names, people you mention, and corrections you have made into new sessions, so a new chat starts warm instead of cold.

What should go in a decision log entry?

Six fields: the date, the decision in one sentence, the options you rejected and why, the reasoning that settled it, one named owner, and a review date. Keep each entry under 200 words and index it so a future session can find it.

Where does a business knowledge base in markdown beat a notes app?

A business knowledge base in markdown on your own server opens in any editor, searches with grep, syncs to your laptop, pushes to GitHub, and gets read directly by an AI with filesystem access. You keep custody. Moving the project means moving a folder.

What is the difference between a rule and AGENTS.md?

A rule changes how Zo behaves. AGENTS.md changes what Zo knows about your files and projects. "Always write in sentence case" is a rule. "The pricing model lives in Finance/pricing-v3.md" is an AGENTS.md line.

How often should you review a decision log?

Set the review date per decision when you record it, since a pricing call and a vendor choice age differently. Then run one monthly pass over anything whose review date has passed and either confirm the call or log a new decision superseding it.