Build an AI Second Brain with ChatGPT and Codex

When you return to a business project, the assistant needs the current decision and the record behind it. Repeating the entire history in each conversation wastes time and makes old drafts easy to mistake for current instructions.

Our AI second brain connects selected project records, saved sources, and useful notes. We adapted Nate Herk’s AIS-OS into our existing WorkOS rather than moving every project into a new system. The useful part is being able to find a decision, open its source, and use it in the next task.

You can start much smaller. Pick one business project, save its current decisions and sources, and test whether a fresh conversation can find the right answer. The graph can come later.

What our second brain actually reads

Our local dashboard reads selected project records and reviewed notes. It also shows existing reports and recurring-run receipts. That lets us see the output of work already happening without creating another automation to ask for the same report.

The source list is deliberate. Credentials, unrelated folders, and raw chat archives are excluded. Refreshing a dashboard does not prove that an automation ran or that every connected service is current. For your first version, choose a small source list and make every useful answer point back to a readable record.

Decide what the collection should help you answer

“Remember everything about my business” is a poor starting requirement. It gives you no way to judge success and encourages indiscriminate collection.

Choose a topic tied to work you expect to do again. For a small service company, that might be customer objections, delivery procedures, or lessons from completed projects.

Write three questions before collecting anything:

• What do customers ask before agreeing to this service?
• Which explanations have we approved for those questions?
• What evidence supports each explanation, and what remains uncertain?

These questions become your acceptance test. If the system cannot answer them with traceable evidence, adding another hundred documents will not necessarily help.

Keep sources, synthesis, and current status distinct

Our local WorkOS separates original captures from reviewed notes and keeps changing project status in the owning project's record. Its knowledge view reads selected files. That is an implementation pattern you can reproduce without adopting our entire folder structure.

Use three kinds of information:

A synthesis can point to current status without copying it. Otherwise a price change may leave several convincing but inconsistent notes behind.

Download a starter and see the structure we use

Download the sanitized second-brain starter template. It contains four project-record templates, a source-capture note, a topic note, and a retrieval checklist. Copy its sections into separate files; replace the bracketed prompts with your own facts. It contains no account connections or private project material.

Our working project structure uses PROJECT_MEMORY.md for current state, WORK.md for scope, SOURCES.md for evidence pointers, and TOOLS.md for the capabilities a task needs. For a growth question, the assistant reads the current project record, follows the relevant source, and saves reusable synthesis as a knowledge note. The next action stays in the project record.

Our selected-file dashboard reads these command records and chosen knowledge notes. Search results open the original files. Refreshing the dashboard rereads its configured sources; it does not prove that a connected service was checked or a business task completed. Those claims need a dated source read or output receipt.

The local visual knowledge app was adapted from Nate Herk's AIS-OS, an MIT-licensed project. The templates here are a small, original starting point for the record structure, not a copy of that application.

For the broader setup, see the Work System Guide, its Build yours walkthrough, and our ChatGPT and Codex command-center article.

Choose where your working material lives

A ChatGPT project can hold reference files and related conversations. It also supports project-specific instructions. Those features make it a practical starting place for a small collection. OpenAI's Projects documentation explains the available controls and plan-dependent limits.

For a local collection, keep ordinary readable files in a chosen folder. Ask the assistant to work only from those sources and to return the exact note it creates. Open the saved file afterward. If the assistant says it created a note, verify the file and its contents before relying on it.

You can combine the approaches, but define the authoritative copy. If you upload a snapshot of a local note, record that it is a snapshot. Do not assume editing one automatically changes the other.

Choose information you are authorized to use. A useful second brain rarely needs credentials, every raw conversation, or unrelated personal material.

Capture a source with enough context to reuse it

An article title alone is not a useful research note. Neither is a page of AI-generated conclusions with no link back to the original.

For each source, record:

• A descriptive title and original location.
• The author or organization, when available.
• The publication date and the date you reviewed it.
• The business question it helps answer.
• The relevant findings and their limitations.
• A next use, such as revising an FAQ or comparing an offer.

If a source is a video, preserve its URL and useful timestamps. If you have only a partial transcript, say so. Do not treat a summary of an inaccessible source as a complete review.

Try this capture prompt:

Read this source for our customer-onboarding project. Save the useful findings, the source location, the date reviewed, and any important limitations. Separate the author's claims from our interpretation. Link the note to the onboarding topic. Do not convert an untested suggestion into an approved procedure.

The distinction between a source's claim and your own conclusion is what makes later verification possible.

Write notes around questions people actually ask

A collection of summaries can still be hard to use. Add a short topic note that combines relevant evidence around one question.

For example, “Why customers postpone a maintenance plan” is more useful than “Marketing research miscellaneous.” The note might identify three objections, link each to interview evidence, and list the unanswered question you should ask next.

Use a compact structure:

Question: Why do customers postpone the maintenance plan?
Current understanding: Summarize only supported patterns.
Evidence: Link each important point to its source.
Limits: Describe missing coverage or conflicting examples.
Related work: Link to the current offer or FAQ draft.
Next question: Identify the most useful gap to investigate.

This example is a template, not a claim about any actual customer dataset. If you have interviewed only a few customers, preserve that limitation in the note.

Test retrieval in a fresh conversation

Once the first handful of notes exists, open a new conversation in the appropriate project or workspace. Ask your original three questions without pasting the answers into the prompt.

Require the assistant to identify the files it used and distinguish a missing answer from a supported conclusion. Then open the cited files yourself.

Check four things: did it find the right material, interpret it correctly, identify its age, and admit what the material cannot establish?

If it fails, diagnose the specific gap. A file outside the indexed collection is an access problem. An unclear title may be a discovery problem. Two contradictory notes create an authority problem. None of those is solved merely by asking the model to “think harder.”

If a later conversation loses context, check whether the intended files were included, whether the titles make them findable, and whether one source is marked as current. A separate context-troubleshooting guide is still queued for publication.

Add a visual map only when it helps navigation

A map can reveal useful connections, but a visible edge should have a clear meaning. A direct source link, a title mention, and membership in the same folder are different relationships.

In our local implementation, the graph distinguishes these connection types. It also has a defined source list. A document outside that list can exist on disk without appearing in the graph.

Apply the same discipline to your own viewer. Make it possible to open the original note. Explain what refresh actually updates. A refreshed page may reread saved files without contacting the original calendar, CRM, or reporting service.

File modification time also deserves care. Reformatting a note today does not mean its underlying business facts were checked today.

Maintain the collection when real work changes it

At the end of a useful task, ask whether it produced a decision or lesson worth saving. Update that one record and link the supporting evidence. Preserve superseded material where history matters, but clearly identify the current version.

Avoid creating a separate maintenance project before you have a useful collection. Start by testing retrieval after meaningful additions. Add a recurring review only when the material's rate of change warrants it.

Your first finished second brain can be modest: a focused index, several reliable sources, a few clear topic notes, and three questions it can answer accurately. The collection earns expansion when it helps you complete actual work.

If your team needs help choosing the source list and testing a first workflow, contact AIBB to discuss the project scope.