How I Use Obsidian and Codex as a Second Brain for Business Work

01

An AI assistant can know too little or far too much

Every new AI conversation can feel like the first day of a new job. The assistant may be capable, but it does not automatically know how the business is positioned, which service names are current, what has already been decided or which writing style belongs to the company.

The obvious fix is to give it more context. That works until more becomes everything. A large folder of notes can contain current decisions, abandoned ideas, old prices, meeting fragments, personal reminders and several versions of the same answer. Loading all of that does not create reliable memory. It creates a very well supplied argument.

I use Obsidian as a durable business knowledge base and Codex as the assistant that helps apply that knowledge to real work. The useful part is not the number of notes. It is the route between the request and the smallest set of notes that should answer it.

That distinction is what turns a collection of Markdown files into a working Second Brain. Codex does not need to read everything I know. It needs to find the right source, understand its boundaries and stop before access becomes authority.

02

The idea started with a developer knowledge workflow

James Donnelly wrote about combining Obsidian with Claude Code for note capture, daily summaries, linked knowledge and repeatable skills. His setup keeps capture easy, then uses AI to process the tedious parts. The article also makes an honest point: templates, skills and instructions need maintenance, and AI summaries still need reviewing.

That prompted a useful question for my own work. What changes when the vault is not only a developer journal, but a handbook for two related businesses, their services, website plans, commercial decisions and operating rules?

The answer is governance. A personal note system can tolerate a little ambiguity because the person who wrote it can usually remember what they meant. An AI assistant cannot safely rely on that missing context. It needs a clear entry point, one owner for each subject and rules that explain what it may read or change.

Obsidian already provides the simple foundation. Notes are stored as files, they can link to one another and they remain readable outside the application. The extra work is deciding which notes are current truth and how an assistant should reach them.

03

A router is more useful than a giant prompt

My vault begins with a short START HERE note. It does not try to explain the whole business. It tells the assistant where different kinds of truth live and which small route to follow for common jobs.

A request about DanJMills website content routes towards the DanJMills identity and voice note plus the marketing and website plan. A pricing question follows a different route. A request about OrbitWeb services opens the service catalogue and any relevant commercial boundaries. A task request should leave the vault and go to the task system instead.

This is similar to the progressive disclosure used by Codex skills. OpenAI describes skills as focused packages of instructions, references and optional scripts. Codex first sees enough metadata to decide whether a skill applies, then loads the full instructions only when it needs them. Supporting material can remain closed until the workflow calls for it.

The same principle works for business knowledge. Start with the map, not the whole territory. A router keeps the initial context small, makes the route inspectable and reduces the chance that an unrelated old note influences the result.

04

One note needs to own each important answer

Routing only works when the destination is trustworthy. If pricing appears in four notes and each value is slightly different, Codex has not found context. It has found a committee meeting with nobody chairing it.

I mark important notes with the subjects they own. The pricing note owns current prices and commercial boundaries. The service catalogue owns the approved service names and what each service includes. The identity note owns how DanJMills should sound and how it differs from OrbitWeb.

Other notes may link to those facts, but they should not quietly become competing authorities. If a proposal contains an old price, the router knows the pricing note wins. If an archive preserves a previous decision, it remains useful history rather than current instruction.

This small ownership rule removes a surprising amount of ambiguity. It also makes maintenance possible. When something changes, I can update the note that owns the subject instead of searching the whole vault for every sentence that resembles the old answer.

05

The Second Brain is not the whole business system

A durable knowledge base becomes messy when it tries to own live work as well. Tasks, sales follow-ups and business knowledge change at different speeds and need different controls.

I keep those jobs separate. Obsidian holds decisions, positioning, services, policies, processes and plans that should remain understandable over time. A task manager owns deadlines, status and next actions. The CRM owns leads, opportunities, proposals and follow-up. Codex can work across those systems when authorised, but one system does not pretend to be all three.

06

Skills carry the method while notes carry the facts

A useful Codex skill explains how to perform a particular kind of work. It can define when the workflow should start, which references must be read, what checks are required and what finished output should look like.

The skill should not copy every business fact into its instructions. Facts change. If the same service description lives in the vault, the website and three skills, one of them will eventually become the confident old version.

I keep the business facts in the notes that own them and use skills to describe the route. A blog skill can say to load the DanJMills voice and marketing context, research the supplied source, write in UK English and check the result. It does not need to contain the complete company story, current pricing and every service description.

That separation also improves reuse. The same authoritative note can support a website page, article, proposal or review without each workflow maintaining its own copy. The method can change without rewriting the business, and the business can change without rebuilding every method.

07

Read access is not permission to act

This is the boundary I care about most. Giving an assistant enough context to understand a request does not give it permission to update the source, create a task, change a CRM record, publish a page or contact somebody.

My Second Brain skill treats the vault as read-only unless I explicitly ask for a knowledge change. It can route to the relevant notes and use them to answer the current request. It cannot silently tidy the handbook because a sentence looked awkward.

The same rule applies outside Obsidian. A content request does not imply a CRM update. A planning conversation does not create tasks unless I ask. A draft does not become a published article because the files happen to be accessible.

Clear permissions make the assistant more useful, not less. I can allow it to work confidently inside a known boundary because the next state-changing action still has a visible instruction and an accountable owner.

08

This article is a small example of the workflow

For this article, Codex began with the Second Brain router. The router identified two authoritative notes: one covering the DanJMills identity and voice, and one covering marketing and the website publishing plan.

It did not open pricing, proof records, live tasks, sales opportunities or the complete commercial plan. None of those sources were needed to explain how I use Obsidian and Codex. Reading them would have increased exposure and context without improving the article.

The writing workflow then opened its own instructions for research, article flow, headlines, featured images and social copy. The vault supplied the current business context. The skills supplied the method. The source article and official documentation supplied the external facts. I supplied the request and remained the person responsible for the result.

That is the whole model in one piece of work: route narrowly, separate facts from process, keep permissions explicit and review what comes back.

09

Start smaller than the system you imagine

You do not need a huge vault, a vector database or a beautifully coloured graph to begin. Start with one repeated request that currently requires a long explanation.

Create a short entry note that names the authoritative source for that request. Give the source note a clear job. Move old versions into an archive or label them as history. Then write a small skill or instruction that tells the assistant when to load that source, what outcome to produce and what it must not change.

Test the normal case, then test the awkward ones. Ask a question that should follow another route. Remove a required source. Add a conflicting archived note. Request a write action that has not been authorised. The useful test is not whether the assistant produces attractive prose. It is whether the system stops or asks when the route becomes unsafe or unclear.

Only add another route when the first one removes real re-explanation or improves consistency. A Second Brain should reduce work. If maintaining the structure becomes a hobby that creates more administration than it saves, the system has missed its job.

10

The vault still needs an owner

No router can repair knowledge that nobody maintains. Services change, plans move, naming improves and decisions are replaced. Authoritative notes need review dates, clear owners and archives that stay outside the current route.

AI can help identify repeated facts, broken links and possible conflicts. It can propose a cleaner structure or draft an update. It should not decide that a commercial rule is obsolete or overwrite a policy simply because another document sounds newer.

There is also a point where a local note system is not enough. Larger teams may need role-based access, document approval, audit logs, search across several repositories or stricter data controls. The routing principle still applies, but the technology and governance will be more formal.

My setup works because it matches the size of the problem. It keeps durable knowledge in readable files, gives Codex a narrow route into the right context and leaves live systems and state-changing actions under separate control.

11

A useful Second Brain gives AI less to read

The value of this workflow is not that Codex can read an Obsidian vault. Many tools can search or open files. The value comes from knowing where to begin, which source owns the answer and where the assistant must stop.

That changes the quality of the work. I spend less time repeating stable background, the result is less likely to mix brands or revive old decisions, and every task can use the context it genuinely needs without wandering through the rest of the business.

If you want to try the idea, build one router, one authoritative note and one read-only workflow. Make that small route reliable before adding more knowledge or more automation.

A Second Brain becomes useful when it is not treated as one enormous memory. It should behave like a good colleague: find the right record, understand its limits and ask before changing anything important.