Imagine asking AI for the next step in a project. It finds an old presentation, two sets of meeting notes, and the latest plan. Each contains a different deadline. The model picks one and responds with complete confidence. Technically, it did its job: it searched the material and assembled an answer. What it did not know was which document represented the current source of truth.
I think this is the weak point in many guides to building an “AI second brain.” They spend a lot of time on apps, folder structures, and ways to ingest more content. They spend less time on how notes age, what counts as a decision, who owns a piece of information, and what AI should do when sources disagree.
That is why my own working system holds more than knowledge. I need it to show priorities, projects, decisions, unfinished commitments, pending follow-ups, and operating rules. The goal is not a beautiful library. The goal is for both a person and an agent to find the right context for the next step — and to admit when that context is missing.
Start with one decision, not an import of your entire life
Do not begin by moving every email, document, and note into a new app. Choose one recurring situation where you currently have to explain the context to AI from scratch. It might be preparing weekly priorities, continuing product work, reviewing sales opportunities, or assembling material for a leadership meeting.
Write down the decision the system should support. Who makes it? What inputs do they need? What changes often? Where does the latest valid version live today? And what would an error cost? If you cannot answer those questions, another connector or vector database will not solve the underlying problem.
A regular folder of text files or a small space in a tool you already use is enough for the first attempt. Git is useful when version history and precise diffs matter. Notion or another database can be a better fit for tasks, relationships, and status views. The brand of tool matters less than whether AI can find the current answer and a person can verify it.
Separate four kinds of information
One large document called “everything about the project” quickly falls apart. It mixes information with different lifespans and different purposes. In a minimal version, I separate four layers:
- Current state: what is true now, including the goal, priority, owner, and next step.
- Decisions: what we chose, when, why, and which alternatives we rejected.
- Working material: notes, drafts, conversations, and unfinished outputs that do not yet describe an approved state.
- Sources: links to contracts, emails, analytics, repositories, or public material where a claim can be verified.
This distinction prevents a common mistake: meeting notes are not automatically a decision, and an AI draft is not a new fact. A person must review it first. Only then should it change the current state or an operating rule.
You do not need a complicated taxonomy. Give each project one clear place for its current state, a short decision record, and links to deeper detail. Archive the history. An agent does not need everything loaded up front; it needs a map that lets it retrieve the right detail when it becomes relevant.
Add provenance and age to information that matters
The sentence “the project goal is to launch a pilot in October” sounds specific. Without a date or source, you cannot tell whether it is yesterday’s decision or a plan from six months ago. For important records, a few basic fields help: status, owner, date last verified, and source of truth.
Not every note needs this treatment. Use it where stale information could change a recommendation or action. Prices, deadlines, ownership, service availability, and approved priorities deserve more care than general inspiration saved from an article.
The instruction for handling conflicts matters just as much. When AI finds two different versions, it should not quietly choose the newer or longer one. It should name the conflict, show the sources, and ask for a decision. That is not assistant failure. It is the correct response to unresolved evidence.
Route sensitive material instead of copying it
The phrase “second brain” can suggest that everything belongs in one place. It does not — and often should not. Client communications, personal data, contracts, credentials, and internal financial material can remain in systems with the right access controls.
Your central context can hold a safe summary and a pointer to the source: what it contains, who may access it, how to reach it, and when the live state must be checked. The agent knows where to look, but you do not create unnecessary copies of sensitive information across every tool and conversation.
Set the same boundary for actions. Reading project status is different from sending an email, changing a production system, or spending money. Good context says more than what an agent knows. It also says what the agent may do independently and where it must stop for human approval.
Create a short maintenance loop
The most important work does not happen when you create the folders. It begins when reality changes. A meeting produces a new decision, the project moves, an offer expires, or an important exception appears. If that change does not make it back into the system, AI will confidently operate on yesterday’s world.
The loop can be simple. After meaningful work, ask whether the decision, current state, next step, or operating rule changed. If it did, update the relevant source of truth. Keep the raw note as history or archive it, but do not let it compete with the current state.
Once a week, review unfinished commitments, pending follow-ups, and short-lived information. What is waiting on a person? What is no longer relevant? What changed in an email but never reached the project overview? No one-time prompt, however well written, will keep the system current without this review.
The same principle applies to automations. In Building an automation is only the beginning, I explain why you need to check the output, exceptions, and continued usefulness — not just whether a job ran.
Test the system with questions it could get wrong
Do not rely on the feeling that your folders look organized. Give AI a real task and follow its path to the answer. Five questions are enough for a first test:
- Can it find the project’s current goal and next step?
- Can it show where a claim came from and when it was last verified?
- Can it spot a conflict between an old plan and a newer decision?
- Does it avoid opening or repeating sensitive content outside the allowed context?
- Can it propose a useful action while stopping before a step that requires a person?
When the system gives a bad answer, do not fix only the final prompt. Find the cause. Was a fact missing? Was it unclear which file was authoritative? Was the instruction too broad? Or did AI lack access to the source that contained the real decision? The fix belongs in the layer where the problem started.
What you can set up in one afternoon
Choose one active project and create a short overview. Record the goal, current state, owner, next decision, and links to the real sources. Add a simple decision log and a separate place for working notes. Finally, tell AI which file is authoritative, how to handle conflicts, and which actions require approval.
Then use the system to prepare an actual meeting or weekly plan. Ask AI to show its sources and uncertainties. When the work is done, record only what genuinely changed. You now have one complete cycle: context entered the work, supported a decision, and the result flowed back into the system.
You can set up this foundation for one well-understood project in an afternoon. In a larger team, agreeing on owners, access, and the real sources of truth will take longer. Add more projects, connectors, or automatic updates only after that small loop works. Greater autonomy without good context accelerates mistakes. A larger archive without maintenance rules simply gives AI more material to misread.
If you want to test this principle on one company process, the AI workflow sprint describes how I define the workflow, inputs, exceptions, and human checkpoints before choosing a tool.
Further reading: Tiago Forte describes a second brain as an external system that brings knowledge back into practical work. Anthropic’s guide to context engineering explains why agents need a small, relevant context instead of everything at once. Meta offers a recent company example in its description of an auditable organizational second brain. The structure and tests in this article are my practical interpretation of those principles, not a universal standard.