Earlier this year, HubSpot’s Kieran Flanagan put out a video describing the 5 AI roles every marketing team needs. Prompt Strategist. Agent Ops Manager. AEO Specialist. AI Content Strategist. AI Creative Director.

He’s not wrong. These roles solve real problems — inconsistent output, unsupervised agents, invisible brands in AI search, generic content, and creative slop.

But here’s the part he didn’t say: most SMBs and the agencies that serve them can’t hire five new people.

So what if those roles weren’t people? What if they were workflows?

The Problem He Nailed

Kieran describes what he calls “the messy middle.” Teams are using AI to produce more, but the output is getting worse. Prompts are inconsistent across the team. Agents run unsupervised. Brand voice dissolves into generic AI tone. And buyers are asking AI what to buy — and your company isn’t in the answer.

He uses Unilever as the success story (Brand DNA systems, 30% faster assets, doubled engagement metrics) and Coca-Cola as the cautionary tale (technically correct content that’s emotionally wrong).

The gap between those two outcomes? Governance. Structure. Someone — or something — ensuring AI output is consistent, on-brand, and improving over time.

Five Roles, Mapped to Workflows

Here’s how each role translates from “person you need to hire” to “system you can own.”

• Prompt Strategist — a structured skill library

• Agent Ops Manager — a quality management system

• AEO Specialist — answer-engine audit workflows

• AI Content Strategist — context-aware content workflows

• AI Creative Director — directed creative workflows

The left column is a payroll line that scales linearly. The right column is infrastructure that compounds.

1. Prompt Strategist → Structured Skill Library

Kieran’s version: one person who maintains a shared prompt library, trains the team, and ensures consistency across all AI output.

The workflow version: every business operation is a structured skill with versioned instructions, model assignments, and quality tracking. Not a spreadsheet of prompts — a governed library where each skill has an owner, a quality score, and gets better with use.

The difference? A prompt strategist depends on one person’s availability. A skill library works at 2am on a Sunday.

2. Agent Ops Manager → Quality Management System

Kieran’s version: a “Chief Agent Officer” who monitors agent performance, catches failure states, and onboards new agents.

The workflow version: a quality management system that reviews every workflow against acceptance criteria, flags drift, and certifies outputs before they reach clients. Automated monitoring instead of manual oversight.

Unilever built this internally for their Beauty AI Studio. You can have the same governance pattern without Unilever’s budget.

3. AEO Specialist → Answer Engine Optimization Workflows

Kieran’s version: a dedicated specialist ensuring your brand appears in ChatGPT, Perplexity, and AI Overview results.

The workflow version: structured audits that score your AI citability, check crawler access, evaluate entity recognition, and generate action plans. Run it quarterly. Update your structured data. Stay visible.

By Kieran’s estimate, 80% of brands haven’t started. If that’s even directionally right, it’s a first-mover advantage you can capture with a system rather than a salary.

4. AI Content Strategist → Context-Aware Content Workflows

Kieran’s version: a craft person who builds writing style guides, winning platform profiles, and edit-feedback loops so AI content doesn’t all sound the same.

The workflow version: brand voice guidelines the system reads and follows. Per-platform profiles (what works on LinkedIn ≠ YouTube ≠ email). Content scoring that catches AI patterns before publishing. And a feedback loop where every edit makes the next draft better.

This is where context matters most. A system that knows your brand, your audience, and your past work produces fundamentally different output than a blank prompt.

5. AI Creative Director → Directed Creative Workflows

Kieran’s version: someone who directs AI creative with taste — choosing the right models, maintaining quality standards, and preventing “volume without soul.”

The workflow version: structured creative briefs, model-specific generation workflows, and quality gates that ensure fast doesn’t mean sloppy.

Unilever’s Sketch Pro brought concepts to life in 2 hours instead of 2 weeks. The key wasn’t the AI — it was the human direction encoded into the process.

The Real Insight

Kieran says one skilled person plus AI can match a team of 10-20. We agree. But the skill isn’t just “being good at prompting.” It’s having structured workflows that accumulate context over time.

A prompt library is a starting point. A system where client context, brand voice, competitive intelligence, and past work all flow into every output — that’s the multiplier.

The five roles Kieran describes are real needs. The question is whether you solve them with headcount or with infrastructure.

What This Means for You

If you’re an agency or consultancy serving SMBs, you’re probably feeling the pressure from both sides. Your clients want AI capabilities. Your team is already using AI but the output is inconsistent.

Hiring five specialists isn’t realistic. Building these capabilities as structured, governed workflows is.

That’s the model ThirdBrain BOB is built on: not five new hires, but five capabilities you own outright.

The video that sparked this: 5 AI Roles Every Marketing Team Needs Right Now by Marketing Against the Grain (HubSpot). Worth watching — Kieran gets the problem right. We just think the solution looks different for SMBs.

Alex Hormozi spent two and a half hours on Steven Bartlett’s Diary of a CEO recently, and about fifteen minutes of it were actually about AI. The rest was hiring, pricing, retention, his father’s story, how he picked a wife. Typical Hormozi — he’ll answer the AI question and then spend the next two hours proving the answer with his own life.

But the fifteen minutes are the ones worth sitting with, because they contain a claim most people building AI products are quietly ignoring: in a world where intelligence gets cheap, reality and reputation are the only moats left.

I want to take that claim seriously, because it’s not a soundbite. It’s a filter. And it tells you, with some precision, what to build and what to stop building.

The $350,000 mistake

Hormozi opens with an example that should sting anyone currently “AI-transforming” their business. A founder had eleven virtual assistants doing data-cleaning work, costing about $11,000 a month. Good enough work. Nothing broken. He spent $350,000 building an AI system to replace them — more than three years of what the VAs cost — and the process he automated wasn’t even the thing limiting his growth. He still didn’t have enough customers. He just had a more expensive version of the same non-problem.

This is the failure mode of AI adoption right now: doing the thing that’s available to automate instead of the thing that’s actually constraining the business. Hormozi’s diagnostic question is almost insultingly simple — “are you making more money?” — and it’s the right one precisely because it’s hard to dodge. Token-maxing isn’t a strategy. It’s a hobby that happens to run on a corporate card.

If you’re deciding where to point AI inside your own business, that’s the whole test. Not “can this be automated” — everything, eventually, can be automated. The question is whether automating it moves revenue, and whether the thing you’re automating was ever your bottleneck to begin with.

Why “reality is the moat” is not a slogan

Here’s the part that actually matters. Hormozi’s argument isn’t that AI is bad at content, or bad at advice, or bad at anything specific. It’s structural: as the cost of generating content and analysis collapses to zero, the supply explodes while demand — attention, trust, buying decisions — stays roughly fixed. Every unit of content becomes less valuable, because there’s simply more of it competing for the same eyeballs.

What survives that flood isn’t quality of output. A model can match or beat most human output on style and even on substance. What survives is proof that the output is connected to something real — a track record, a risk someone actually took, an outcome someone can verify happened.

He uses Warren Buffett to make the point almost cruelly well: a teacher in Des Moines could give better investing advice than Buffett, word for word, and it wouldn’t matter, because “they just forgot to build Berkshire Hathaway.” The advice was never the product. The eighty years of being right, in public, with real money, was the product. AI can generate the advice. It cannot generate the eighty years.

This is why he frames it as a spectrum, not a blanket threat: low-stakes education (a makeup tutorial) survives AI generation just fine, because the cost of being wrong is trivial. High-stakes education — business, money, health — gets hit hard, because credibility is the actual product being sold, and credibility can only be built in reality, over time, with something at risk.

Where this lands for anyone building with AI right now

I read this against the backdrop of building an AI-driven operating system for small businesses, and the framing snaps into focus fast. The temptation with AI tooling is to sell the AI — the model, the automation, the speed. Hormozi’s argument says: don’t. Sell the outcome, backed by something real, and treat the AI as invisible infrastructure.

Concretely, three things fall out of this:

First, judgment doesn’t get outsourced — it gets amplified. Hormozi tests every real decision by asking Claude, ChatGPT, and whichever other model is around, the same question, and reports that the answers scatter. His conclusion isn’t “AI is unreliable, avoid it.” It’s “the decision is still mine, and if I stop making decisions, I get weaker at making them.” That’s a useful discipline for anyone running a business with AI in the loop: use it to widen the option space, never to close the decision.

Second, retention is the actual AI-proof asset, and it’s older than AI. The clearest section of the interview has nothing to do with AI at all — it’s his walkthrough of why a business that keeps 100% of its customers year over year will out-earn an identical-revenue business that churns and re-sells from scratch, using dramatically less acquisition spend to get there. That’s not a new insight. But it’s the right insight to re-read right now, because retention is exactly the kind of moat AI can’t shortcut. You can’t automate a customer’s decision to stay. You can only earn it, repeatedly, in reality.

Third, proof of effort is the honest version of “fake it till you make it.” When you have no track record yet, Hormozi’s advice isn’t to project false credibility — it’s to document the work itself. MrBeast’s first viral video was him counting to a million. No outcome to show yet, just visible, verifiable effort. In an AI-saturated feed, that’s arguably more valuable than polish, because it’s the one thing a model can’t backfill for you.

The uncomfortable part

None of this is an argument against using AI. Hormozi says outright he’s a “big AI advocate.” The uncomfortable part is narrower and more specific: AI is extremely good at producing things that look like the valuable thing — advice, content, even decisions — without carrying what actually made the valuable thing valuable, which was always the reality behind it. If your business model depends on people being unable to tell the difference, AI is about to end that business model, quietly, by making the difference visible to everyone at once.

The businesses that come out ahead won’t be the ones with the best prompts. They’ll be the ones that spent the years building something an AI can’t fake: a track record, a retained customer base, a reputation with something real behind it. Hormozi didn’t say anything new here. He just said it at the exact moment enough people needed to hear it again.

Editirial Note:
This piece is an AI summary generated by BOB from the video, if you made it this far, find the link to the video below and take some time to watch it.

This piece draws on Alex Hormozi’s July 2026 interview with Steven Bartlett on The Diary of a CEO, “Alex Hormozi’s Warning: Stop Chasing AI, Build This Instead!”. Quotes and framing above are paraphrased from that conversation; watch the full 2h22m for the parts on hiring, pricing, and — unexpectedly — how he picked his wife.

A few weeks ago you ran a prompt that made the AI describe your folder structure and tell you, politely but honestly, where it would lose information. Since then, one prompt at a time, you’ve added every layer of a working AI operating system: a data model, a schema, governance rules, skills, playbooks, a context engine, authoring tools, automated validation, and queryable views.

All of it is still plain markdown. Every piece is readable, searchable, and editable without any special software. That was the point.

This final prompt adds the last layer: navigation. One config file turns the whole thing into something that feels like an app.

What the config does

The BOB Workspace plugin — free, open-source — reads a single file at .obsidian/plugins/bob-workspace/workspace.json. That file has six sections. The schemas block points at the YAML schemas folder you built in Prompt 7; that’s what renders the settings screens and entity forms for each record type. The bases block wires in the .base view files from Prompt 11. The navigation block defines a sidebar: named groups, icons, and click-through links to each entity screen. The dashboards block describes a home screen: stat tiles showing live counts (active clients, open deals, whatever matters to your business), quick-create buttons, and embedded Base views. settings controls which sidebar modules are visible.

Nothing is duplicated. The workspace file is a map of things that already exist. Remove it and the underlying data is untouched — it’s just markdown again.

The prompt below hands the AI the full format, the widget types, the rules that prevent the common failures, and a complete working example. It produces valid JSON. You place that file in the plugin directory, reload, and your vault is now a navigable workspace.

The prompt

Generate a complete, valid workspace.json for the BOB Workspace Obsidian plugin.

My entities (with key fields) are: [LIST EACH ENTITY + 3–5 FIELDS]. My YAML schemas folder is: [PATH]. My .base files live in: [PATH].

THE FORMAT — six top-level sections:
- "schemas": { "enabled": true, "folder": "<my YAML folder>" }  → renders entity screens/settings from my schemas.
- "navigation": { "groups": [ ... ], "secondaryTabs": {} }  → the left sidebar. Each group has "items"; an item is { "id", "label", "icon" (Lucide name), "desc", and "entityKey" to bind it to an entity }.
- "workbookGroups": []  → leave empty unless grouping entities.
- "bases": { "<entity>": { "file": "<path>/<Entity>.base" } }  → one entry per entity I want viewable.
- "dashboards": { "home": { "title", "subtitle", "stats": [ ... ], "layout": [ [ ...widgets... ] ] } }
- "settings": { "modules": { ... } }  → which sidebar modules are on.

STAT CARDS (dashboards.home.stats[]) — top-row number tiles:
{ "label": "OPEN DEALS", "entity": "deal", "count": "open", "sub": { "entity": "deal", "count": "all", "suffix": "total" }, "accent": "sky" }
("count" = "open" | "all" | a status value; "accent" = sky | mint | warn | pink.)

WIDGETS (each cell in dashboards.home.layout) — use these kinds:
- record list (no "kind"): { "title", "entity", "source": "recent-open", "titleFields": [...], "metaFields": [...], "limit": 8 }
- { "kind": "actions", "actions": [ { "label", "entityKey", "icon" } ] }  — quick-create buttons
- { "kind": "base-embed", "entity", "view": "Active", "limit": 6, "titleFields": [...], "metaFields": [...] }  — preview a Base view
- { "kind": "markdown", "title", "body": "..." }

RULES (these prevent the common failures):
- For a record-list widget, "source" MUST be "recent" (all) or "recent-open" (open only). Do NOT use "all" on a list widget — it renders empty. ("all" is only valid on a stat card's "count".)
- For "base-embed", the entity MUST also appear in the top-level "bases" map, and "view" is a plain string naming a view inside that .base file.
- Include at least one "actions" widget (or entityKey nav items) so records can be created — a dashboard of only lists is read-only.
- Output strictly valid JSON: no comments, no trailing commas.

Use this complete example as the pattern, then replace the entities/fields with mine:

```json
{
  "schemas": { "enabled": true, "folder": "Schemas/source" },
  "navigation": {
    "groups": [
      { "id": "home_group", "label": "", "items": [
        { "id": "home", "label": "Home", "icon": "home", "desc": "Command centre." }
      ] },
      { "id": "records", "label": "Records", "items": [
        { "id": "records.client", "label": "Clients", "icon": "users", "entityKey": "client", "desc": "Client records" },
        { "id": "records.deal", "label": "Deals", "icon": "trending-up", "entityKey": "deal", "desc": "Deal records" }
      ] },
      { "id": "misc", "label": "", "items": [
        { "id": "settings", "label": "Settings", "icon": "settings-2", "desc": "BOB Workspace settings." }
      ] }
    ],
    "secondaryTabs": {}
  },
  "workbookGroups": [],
  "bases": {
    "client": { "file": "Bases/Clients.base" },
    "deal": { "file": "Bases/Deals.base" }
  },
  "dashboards": {
    "home": {
      "title": "Command Centre",
      "subtitle": "Your business at a glance",
      "stats": [
        { "label": "ACTIVE CLIENTS", "entity": "client", "count": "active", "accent": "mint" },
        { "label": "OPEN DEALS", "entity": "deal", "count": "open",
          "sub": { "entity": "deal", "count": "all", "suffix": "total" }, "accent": "sky" }
      ],
      "layout": [
        [
          { "kind": "actions", "actions": [
            { "label": "New Client", "entityKey": "client", "icon": "user-plus" },
            { "label": "New Deal", "entityKey": "deal", "icon": "trending-up" }
          ] }
        ],
        [
          { "title": "RECENT DEALS", "entity": "deal", "source": "recent-open",
            "titleFields": ["title"], "metaFields": ["stage", "deal_value"], "limit": 8 },
          { "kind": "base-embed", "entity": "client", "view": "Active",
            "limit": 6, "titleFields": ["client_name"], "metaFields": ["status", "regions"] }
        ]
      ]
    }
  },
  "settings": { "modules": { "planner": true, "records": true } }
}
```

What you get — and what it means

The AI returns a complete workspace.json for your entities. Drop it at .obsidian/plugins/bob-workspace/workspace.json, reload the plugin, and your vault changes. The sidebar now lists your record types by name. The home screen shows live counts pulled from your actual notes. You click “New Client” and the form that appears is your YAML schema from Prompt 7, not a generic template. The embedded views are the filtered Base queries from Prompt 11.

Everything is rendered live, over the same plain markdown files. Nothing was moved. The config file is the only new thing, and it weighs a few kilobytes.

The full architecture, end to end

Step back for a moment, because this is worth naming clearly.

Over twelve prompts you have built: a map of what you had (Prompt 1), a structured data model with consistent entity types (Prompt 2), a folder hierarchy that makes sense to both you and an AI (Prompt 3), governance rules that keep it consistent (Prompt 4), a library of skills your AI knows how to run (Prompt 5), playbooks that chain those skills into repeatable workflows (Prompt 6), YAML schemas that define every field and constraint (Prompt 7), authoring templates that make creating new records fast (Prompt 8), automated validation that catches mistakes before they compound (Prompt 9), a context engine that loads the right information for each task without manual hunting (Prompt 10), queryable views over your data (Prompt 11), and now a navigation layer that surfaces all of it as an interface (Prompt 12).

That is the architecture ThirdBrain BOB is built on. Exactly this, applied to a full business — with dozens of entity types across sales, finance, operations, delivery, HR, and marketing, views and dashboards already wired together, a curated skill library, and a setup process that points the AI at your existing business context and has you operational in under thirty minutes.

The plugin is free and open-source. It was never the moat. The depth that fills it — the entities, the schemas, the skills, the governance, the context engine, the dashboards already built across a whole business — is the product.

You now understand BOB from the inside, because you built a version of it yourself. The architecture is yours to keep, extend, and reshape for whatever your business needs next.

---

That’s the series — twelve prompts, one AI operating system you built yourself. The architecture is yours to keep.

The complete guide — all twelve prompts as one polished PDFis free in the ThirdBrain Skool community.

Want the same architecture already filled out and wired across a whole business, operational in under 30 minutes? See what ThirdBrain BOB includes — and book a walkthrough — at brn.cx or find out more in the classroom section in the ThirdBrain Skool community.

There’s a gap between having structured data and being able to use it. You spent the last few weeks turning your notes into typed records such as clients with fields, deals with stages, contacts with roles. They’re all there. Correct, consistent, queryable in principle.

In practice, you’re still navigating a file tree.

A folder of markdown files is not a pipeline view. It’s not a client roster you can sort by region. It’s not a deal board you can scan to see what’s stuck. The data is good; the interface is still a list of filenames. This prompt closes that gap.

What Bases actually does

Obsidian ships a feature called Bases. Bases are built in, no plugin required. It does one thing: it reads the typed frontmatter on your notes and renders it as a table, a board, or a card view, filtered , grouped and sorted however you like. You write a small definition file, drop it in your vault, and open it. The view is live. Change a status field on a deal note and the board updates.

The definition file is not a query. You don’t write SQL or Dataview syntax. You declare which type of record to show (type == "deal"), which fields become columns, and which views you want. An active table sorted by close date, a card view grouped by stage. The AI writes these files from your schemas. You just open them.

One .base file per entity. A few dozen lines each. Your vault gets Clients.base, Deals.base, Projects.base , whatever entities you defined in Prompt 7. Open one and your data is a sortable, filterable table. Open another and your pipeline is a board.

The prompt

Paste your entity schemas from Prompt 7 where indicated. If you have them in YAML, paste the whole block.

Create an Obsidian Base (.base) file for each of my main entity types so I can see them as tables and cards.

My entities and their fields are in these schemas: [PASTE THE YAML FROM PROMPT 7].

For each entity, output a .base file in exactly this format:

```yaml
filters:
  and:
    - note.type == "<entity-name>"
formulas:
  open: link(file.path, "🔍")
properties:
  file.name:
    displayName: Name
  note.<field>:
    displayName: <Readable Label>
  note.status:
    displayName: Status
views:
  - type: table
    name: Active
    filters: note.status == "active"
    order:
      - formula.open
      - file.name
      - note.<field>
      - note.status
    sort:
      - property: file.name
        direction: ASC
  - type: cards
    name: By Status
    groupBy:
      property: status
    order:
      - formula.open
      - file.name
      - note.<field>
      - note.status
```

Rules:
- One .base file per entity type, named after it (e.g. Clients.base, Deals.base).
- Under `properties`, list the 4–7 most useful fields (use the schema's `key_fields`), each with a human-readable `displayName`.
- Give each entity 2–3 views: usually an "Active" table, an "All" table, and one grouped card view (by status, stage, region — whatever fits).
- Only reference fields that exist in the schema.

What you get back — and why it matters

One .base file per entity. Drop them in a Bases/ folder in your vault and open them. Each renders as a live, filterable view of that record type. No refresh button. No export step.

Deals.base shows your pipeline. Sort by expected close date, filter to open deals, group by stage. Clients.base shows every account , active, inactive, on hold , all sortable by region or status. Projects.base shows what’s running and what’s overdue. These are the screens you’d pay for in a CRM or project tool, built from the notes you already have.

The important thing is that nothing moves. Your notes are still markdown files in folders. The Base file is just a lens, a definition of what to show and how to arrange it. If you delete the Base file, your data is untouched. If you add a new client note with the right type: field, it appears in Clients.base the next time you open it.

Once you have these views, the folder tree stops being your interface. You open the board. You scan the table. You click through to a record when you need it. That’s the shift — from navigating a file system to working from structured views.

Next: the finale

Part 12 is the last one. It wires everything built across this series, the schemas, the templates, the views into a navigable workspace. Dashboards with quick actions. Navigation panels. A layout that opens to where your work actually is. A folder of markdown files becoming something that functions like an application. That’s where this ends.

---

This is part 11 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

There’s a gap between a system that starts right and one that stays right. Templates close the first gap. By part nine you have clean templates, typed records, and a folder structure the AI can reason about. But the moment an AI assistant writes a record — actually writes it, not fills a template interactively — you’re trusting it to remember every required field, every time, under any circumstance. That trust is usually misplaced.

The assistant doesn’t forget maliciously. It just deprioritises. It’s mid-task, the surrounding context is complex, and the record gets written with seven of nine required fields filled in. The note looks fine. It opens fine. It breaks silently, later, when a query tries to join on the missing field and returns nothing. You spend twenty minutes wondering why your dashboard is empty before you trace it back to a note that was never quite complete.

A hook solves this in one registration.

What a hook is

A hook is a small piece of automation that runs after your AI tool writes or edits a file. Most AI coding environments support them. They are called post-tool hooks, after-save hooks, or similar, depending on the tool. You register a script once, and from that point on, every time the AI writes a note, the hook fires.

The validation hook for this system does exactly one thing: it reads the type field from a note’s frontmatter, finds the matching YAML schema from the folder you built in prompt 7, and checks that every required field is present and non-empty. If everything is there, it exits cleanly. If anything is missing, it fails “loudly”, with a list of exactly which fields need filling and that failure is surfaced back to the assistant before the task is considered done.

The assistant can’t quietly move on. It has to fix the record.

The prompt

Write me a frontmatter validation hook so my AI tool can't save incomplete records.

My AI tool is: [NAME IT — e.g. Claude Code, Cursor, etc.]. My entity schemas live in: [SCHEMAS FOLDER PATH].

Produce two things:

1. A small validation script that, given a note file:
   - skips files with no frontmatter and any note whose `type` has no matching schema;
   - reads the note's `type`, loads <type>.yaml from my schemas folder;
   - checks every field marked `required: true` in the schema is present and non-empty;
   - on success, prints PASS and exits 0;
   - on failure, prints FAIL and lists the missing fields, and exits non-zero.

2. The hook configuration for my AI tool that runs this script automatically after any note write/edit, so a failed check is surfaced back to the assistant.

Keep the script dependency-light and explain in one line where to register the hook.

What you get back — and what changes

The AI produces a validation script and the configuration block to register it as a hook in your tool. You add the config, test it once on a deliberately incomplete note, watch it fail and list the missing fields, then leave it alone. From that point on it runs automatically.

What changes is the failure mode. Before the hook, an incomplete record was a silent problem. It existed, it looked normal, and it broke things downstream in ways that were hard to trace. After the hook, an incomplete record is an immediate, noisy problem that the AI cannot ignore. The system corrects itself at the point of creation, not hours later when you’re staring at an empty query result wondering what went wrong.

One honest caveat: hooks fire on AI edits, not on files written by external scripts. If you later add a script that creates records automatically, generating invoices from a template, for example. That script bypasses the hook entirely. The fix is straightforward: run the same validation script at the end of any such automation, explicitly. The principle is the same; it just isn’t automatic.

This is the mechanism that separates a system that works from one that merely looks like it works. Every other prompt in this series builds something. This one keeps everything else honest.

Next Part 11 : once your records are typed, validated, and enforced, you can finally see them as tables and boards rather than a folder of files. That’s where the payoff becomes obvious.

---

This is part 10 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get the next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

The previous prompt gave your records a schema: a declared set of fields that every note of a given type must carry. A meeting note must have a date, attendees, and a status. A client record must have an ID and a region. The schema is the spec.

But a spec doesn’t help you when you’re creating a note at speed on a Tuesday afternoon. You’re not going to pause and manually type out every required field from memory. And your AI definitely isn’t going to infer them from a blank page.

That’s the gap this prompt closes. A template makes a new record start with the schema already in place ie the frontmatter laid out, required fields present, body sections already named. You open a new meeting note and it already says “Attendees,” “Decisions,” “Actions.” You create a new client and it already has “Overview,” “Contacts,” “Notes.” The structure is there before you’ve typed a word.

Neither you nor the AI is starting from nothing.

What “starting complete” actually means

There’s a subtle distinction worth making. A schema lives in documentation, it is the rulebook. A template is what the rulebook looks like when you open a new file.

The difference matters because most AI OS failures happen at creation time, not query time. A record gets created in a hurry, the person skips a section, the AI later reads that record and doesn’t know what it doesn’t know. It can’t tell whether “Actions” was intentionally left blank or accidentally omitted. It just reasons from what’s there.

Templates solve this before it starts. If “Actions” is always in the note, even empty, the AI sees a field with no entries, not a field that might not exist. That’s a meaningful difference in how it reasons about your business.

The Templater plugin for Obsidian handles the mechanics: you build a template for each entity type, you tell Templater where your templates folder lives, and optionally you map each template to the folder where that entity type belongs, so when you create a new note in your clients folder, it’s offered the client template automatically. The right structure appears without you having to remember to ask for it.

The prompt

Install the Templater community plugin first. Have your YAML schemas from Prompt 7 to hand. Then paste this:

Create a note template for each entity type, matching my YAML schemas, so new records start complete.

Here are my schemas: [PASTE THE YAML FROM PROMPT 7]. For each entity, also tell me / decide the body sections a note of that type should always contain.

For each entity, output a markdown template in this shape:

```markdown
---
type: <entity-name>
<required_field>: <sensible default or "" placeholder>
<optional_field>:
created: <Templater date command — see rules below>
---

# {{title}}

## <Section every note of this type needs>

## <Next required section>
```

Rules:
- Frontmatter must list every field from the schema: required fields get a default or a clear placeholder; optional fields appear but empty, so I'm reminded they exist.
- For `created`, use a Templater date command — the `tp.date.now("YYYY-MM-DD")` function, wrapped in Templater's execution tags — so each new note stamps its own date instead of a fixed one.
- Give each entity the 2–4 body sections it genuinely needs — no generic filler.
- Output one template per entity, named after it.

What you get back and what to do with it

One template per entity. Drop them in a Templates/ folder, point Templater at it in settings, and optionally configure folder templates so the right one is offered automatically by location.

From that point on, a new meeting note already has “Attendees,” “Decisions,” “Actions.” A new client already has “Overview,” “Contacts,” “Notes.” A new project already has “Goals,” “Deliverables,” “Status.” The created date stamps itself that you don’t need to type and the AI doesn’t have to guess it.

This matters for you, obviously. But it matters more for the AI. When your AI is the one creating records, writing up a meeting it just attended, scaffolding a new client after a call, drafting a project note from a brief, it’s working from these same templates. The structure is given to it, not inferred by it. Every record it creates starts in the same shape as every record you create.

That consistency is the foundation everything else in the system depends on. You can’t query records reliably if half of them were created without the standard sections. You can’t run workflows across client records if some have “Overview” and others have “About” and others have nothing. Templates are how you prevent that drift from the very first note.

A working AI operating system ships these worked out across every entity type in a full business so new records of any kind, created by you or the AI, come structured from the start. You’re building the same thing, one entity at a time.

Next Part 10 — the write-hook that keeps records right even when the AI is the one writing them. Templates give you the starting shape; the hook enforces it stays correct after every edit.

---

This is part 9 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get the next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

The previous prompt gave you YAML schemas: machine-readable definitions that tell your system exactly what goes in each field, what values are allowed, and which fields are required. The AI reads those schemas. The BOB Workspace renders from them. They are the source of truth.

This week’s prompt generates something different — a point-and-click form for filling records by hand. It’s called a fileClass, it’s read by a plugin called Metadata Menu, and it is genuinely optional.

Here’s why I’m telling you it’s optional before I give you the prompt: a system that tells you what you don’t need is more trustworthy than one that treats every feature as mandatory. This is the one case in the series where the right answer might be “skip it.”

What the prompt actually generates

Metadata Menu is an Obsidian community plugin. Once installed and pointed at a folder of fileClass files, it reads those files and uses them to present a form inside every matching note. Open a client record — and instead of staring at raw YAML, you get a clean panel on the right: fields labelled, dropdowns populated with your allowed values, required fields flagged.

The fileClasses are generated directly from the YAML schemas you built in Part 7. One entity, one fileClass, one form. The plugin maps your field types for you: a string becomes a text input; a string with an enum becomes a dropdown; a date becomes a date picker; a link to another note becomes a file chooser.

It’s a genuinely useful thing, if filling records by hand is something you do.

One important clarification before you run the prompt. The fileClasses feed Metadata Menu. They do not feed the BOB Workspace plugin. The Workspace reads your YAML schemas from Part 7 directly — always has, always will. So Metadata Menu is not a dependency. It is a separate convenience layer for the human path. If your AI writes your records — which is what Prompts 9 and 10 are about — you can skip this entirely, and nothing downstream breaks.

The prompt

Install the Metadata Menu community plugin first. Have your YAML schemas from Part 7 ready to paste.

Generate a Metadata Menu "fileClass" for each entity, derived from my YAML schemas — so I can fill records through a form by hand.

Here are my YAML schemas: [PASTE THE YAML FILES FROM PROMPT 7].

For each entity, output a fileClass file in exactly this format:

```yaml
---
fileClass: <entity-name>
version: "1.0"
mapWithTag: false
filesPaths:
  - <the folder where these notes live>/
fields:
  - name: <field_name>
    type: <Input | Select | Multi | Date | Number | Boolean | File>
    required: <true if the YAML marked it required, omit otherwise>
    options:            # ONLY where the YAML had an `enum`
      - "0": <value>
      - "1": <value>
---
# <Entity> FileClass
```

Mapping rules from the YAML:
- YAML `string` → `Input`; YAML `string` with `enum` → `Select`; YAML `array` → `Multi`; `format: date` → `Date`; `number` → `Number`; `boolean` → `Boolean`; a link to another note → `File`.
- Carry `required: true` across wherever the YAML had it.
- Turn every YAML `enum` into the `options` list so I can't typo a value.
- Don't add fields the YAML doesn't have.

What comes back — and where it lives

One fileClass file per entity. Save them in a fileClasses/ folder inside your vault and point Metadata Menu at it in the plugin settings. From that point on, any note the plugin recognises gets the form.

The output is tidy and mechanical — which is the point. The AI is just translating your schemas into a format a different plugin can read. There is no interpretation here, no judgment. It’s a format conversion you could do by hand in an afternoon; the prompt just saves you the afternoon.

The one question that tells you whether to bother

Do you, or will you, ever fill records by hand?

If yes — run the prompt. The form prevents typos, keeps enums consistent, and makes the gap between “the AI created this record” and “I edited it” invisible to the system.

If no — skip it. The YAML from Part 7 is already doing everything that matters. The Workspace renders from it, the AI reads from it, validation runs against it. Adding a form nobody uses is just tidying a room that stays locked.

Next prompt: Part 9 — templates that make every new record start complete, with its sections already in place. That one applies whether or not you ran this one.

---

This is part 8 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

By now you have a working folder structure, a way to query it, templates for the records you keep, and a workspace to look at it all. What you don’t yet have is a single, authoritative definition of what each record type is. That’s what this prompt produces — and it’s the one that makes the whole thing self-consistent.

The problem without it is drift. You add a field to a template. You forget to update the workspace screen. Someone fills in a status value that doesn’t match the dropdown. Six months later you have records with slightly different shapes and a system that’s harder to query than a folder of documents. Nothing dramatic — just slow, silent entropy.

The fix is to define each entity once, in a format every tool in your system can read. That’s what a YAML schema is: a single file per record type, naming every field, its type, whether it’s required, and the exact values it’s allowed to carry. From that one file, your validation generates. Your field forms render. Your workspace screens pull their settings. Change the definition once; every layer picks it up.

Why machine-readable matters here

You could put this definition in a document. Plenty of people do. But a Word document can’t tell your system anything — it’s just text for humans to read and then manually translate into every other place the information needs to live. A YAML schema file is different: it’s structured data, and tools can parse it directly.

In practice, this means the workspace plugin that renders your entity screens reads from this file. The validation script that checks whether a record has all its required fields reads from this file. If you build a point-and-click form for filling records by hand, it reads from this file. You write the definition once, and every layer downstream stays in sync with it automatically. That discipline — one source of truth for each entity — is what lets a real system carry dozens of record types without collapsing under its own weight.

The prompt

Before you run it, have your data model from Prompt 2 to hand. Decide on a schemas folder — Schemas/source/ works well.

Turn my data model into machine-readable YAML schema definitions — one file per entity type. These are the canonical definitions my workspace, validation, and authoring tools will all read.

My data model: [PASTE THE ENTITY TYPES + FIELDS FROM PROMPT 2].

For each entity, output a YAML file in exactly this format:

```yaml
entity: <entity-name>
label: <Readable Label>
type_value: <entity-name>          # the value each note's `type:` field will carry
location_pattern: <folder where these notes live>/
description: <one line describing the entity>
key_fields:                        # the few fields shown in summaries/tables
  - <field>
fields:
  - name: type
    type: string
    required: true
  - name: <field_name>
    type: <string | array | number | boolean>
    required: <true | false>
    format: date                   # ONLY for date fields
    enum:                          # ONLY for fixed-value fields (status, stage, ...)
      - <value>
    description: <what this field is>
```

Rules:
- One YAML file per entity, named <entity-name>.yaml.
- Mark `required: true` only for fields a record cannot exist without.
- Use `enum` for any field with a fixed set of values — this is what stops typos and powers dropdowns later.
- Use `format: date` for dates and `type: array` for lists or links to other notes.
- Keep strictly to my model — don't invent fields.

What comes back — and why it matters

One YAML schema file per entity, ready to drop into your schemas folder. Each file is compact and readable — you can open it and see at a glance what a record is, what it must contain, and what values are legal. More importantly, your tools can read it too.

Note the four-backtick fence around the prompt above: that’s because the prompt itself contains a code block inside it. When you paste the prompt into your AI, you’re pasting the outer wrapper, not the inner YAML block — the AI reads the whole thing and knows what format you want.

This schemas folder is now the single source of truth for your data model. In Prompt 10, you’ll build a write-hook that validates every record against these files the moment it’s saved. In Prompt 12, you’ll point the workspace plugin’s schemas setting directly at this folder, and your entity screens render from it. The same files that define your entities are the ones your system acts on — no translation layer, no manual updating in multiple places.

Next week: Part 8 covers an optional point-and-click form for filling records by hand — handy if you want a structured UI for data entry, and one you can skip entirely if your AI is doing the writing.

---

This is part 7 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get the next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

A quick roundup. This series runs a prompt at a time on the site through the week; once a week I gather them here so you’re not chasing links. Here’s the first batch — six prompts, and by the end of them the pieces have started to connect into something that behaves like a system rather than a pile of clever chats.

The first five are the architecture: the thinking that has to be in place before any of it runs on its own. The sixth is where those files stop being documents and start being machinery. If you only run one this week, run the first — it’s the one people are most surprised by.

Part 1 — Make the AI describe what you already have
Before you add anything, make the AI map your current setup back to you, in writing, and tell it not to flatter you. Seeing your own mess reflected back accurately is the moment it stops being a chatbot and starts reasoning about your business.
→ Read it

Part 2 — Turn your notes into records you can query
Your notes aren’t free text; they’re typed records. A client always carries the same fields; an invoice always links to a client. That one shift turns a pile of files into something you can actually query.
→ Read it

Part 3 — One file the AI reads before it does anything
Consistency doesn’t come from a better prompt each time. It comes from one operating-instructions file the AI reads first — and every rule in it needs its reason, or the AI quietly drops it once a session runs long.
→ Read it

Part 4 — Stop re-explaining the same task to your AI
There’s a task you explain every single time you need it done. Write it down once as a skill file the AI loads when it’s needed, instead of leaving it in your chat history to slowly drift.
→ Read it

Part 5 — Turn a skill into a process that runs itself
A skill answers a question; a playbook runs a process — with human checkpoints exactly where money, client-facing output, or anything irreversible lives. You decide what the AI is allowed to do on its own.
→ Read it

Part 6 — Never re-paste your business again
This is where Part 1 ends and the machinery begins. A real system briefs itself: context lives in standard files, and one rule decides which to load before any task. The assistant shows up to every job already knowing your business — no re-pasting the profile every time.
→ Read it

That’s the foundation. The next six move fully into the machinery — YAML schemas, templates, the validation hook that won’t let the AI cut corners, and the views and workspace that turn all of it into something you can actually look at. Those land in the next roundup.

---

This is Build Your Own AI Operating System — a free series that turns the AI you already use into a system that runs your business. Six prompts down, six to go.

You’re already subscribed, so the next roundup arrives on its own. Know someone who’s still re-pasting their business into every new chat? Forward this — they can subscribe at carinebruyndoncx.substack.com.

Don’t want to wait ? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

Part 2 fixes that. It starts here, with a single mechanism that changes how the whole system operates: automatic context loading.

What a real AI operating system actually does

Most people think the hard part of an AI OS is the prompts. It isn’t. The hard part is the context plumbing — getting the right information in front of the AI before it starts work, every time, without you having to remember.

Think about what it costs when that doesn’t happen. You ask the assistant to draft a proposal. It gives you something technically fine and entirely off-brand, because it doesn’t know your tone, your pricing logic, your client’s history. So you paste the context in. It gets better. Next session, same problem. You paste again. The AI isn’t the bottleneck — the manual re-pasting is.

A real AI operating system doesn’t ask you to do that. The context is standard, the files are stable, and a single rule decides which of them to load before any task runs. The AI shows up already briefed. And critically: a finance task doesn’t drag in your marketing context, and a client proposal doesn’t load your supplier conventions. It’s conditional loading — enough to be relevant, not so much that it’s noise.

That conditional, automatic loading is the quiet engine under everything BOB does. This prompt builds yours.

The prompt

You’ll need to know the names and locations of the context files you created in Part 1 — your operating-instructions file, your data model, and any profile, ICP, or offer notes. Have them handy, then paste this:

I want automatic context loading for my system — a central rule that decides which files to read before any task.

My standard context files are: [LIST THEM — e.g. business profile, ICP, offerings, conventions, the data model, the operating-instructions file].

Produce three things:

1. CORE CONTEXT — the short list of files that should be read before EVERY task, no matter what. Keep it minimal: only files that genuinely change the quality of the output.

2. CONTEXT MAP — a table with three columns: "When the task is about X" | "also read these files" | "why". Cover my main kinds of work (e.g. sales, content, finance, client delivery). The point is conditional loading — a finance task shouldn't drag in marketing context, and vice versa.

3. LOADER RULE — a short instruction I can paste into my operating-instructions file telling any assistant: before starting a task, identify its kind, then read the core context plus the mapped files first. Include the reason, so a long session doesn't quietly drop the habit.

Keep it lean and specific to my business, not a generic checklist.

What you get back — and where it goes

Three things: a core context set, a conditional context map, and a loader rule.

The core context set is deliberately short — two or three files that genuinely improve every output, whatever the task. Your business profile probably goes here. Your conventions file. Maybe your operating-instructions file itself.

The context map is where the conditional logic lives. When the task is a client proposal, also read the client’s profile and your offer definitions. When the task is a finance question, also read the data model and the relevant accounts. Marketing copy? Pull in the ICP and the brand voice notes. The map is specific to your business — the AI builds it from the files you listed, not a generic template.

The loader rule is a short paragraph you drop into your operating-instructions file, which already exists from Part 3. It tells any assistant: before starting work, read the core context, identify the task type, then read the mapped files. It includes the reason — “so the output reflects the actual business, not a generic approximation” — because an instruction without a rationale gets dropped the moment a session runs long.

Once the loader rule is in place, the dynamic shifts. The assistant stops asking for background you’ve already written down. Its output gets more precise — consistently on-brand, correctly structured — because it’s always starting from the same canonical sources. You stop re-pasting and start noticing that the AI actually knows your business.

Next Prompt 7: turning your plain-language data model into machine-readable YAML schemas. The data model you built in Part 2 of this series reads well to humans. It reads better still when it’s structured so the AI can validate, query, and enforce it — that’s the spine everything else in the system reads from.

---

This is part 6 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get the prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

There’s a meaningful difference between an AI that can answer questions well and one that can run a process. The first is impressive. The second is useful in the way a reliable colleague is useful — you hand it the trigger, and something complete comes back at the end.

The gap between them is a playbook.

What a playbook actually is

A skill does one thing. “Draft the proposal from these notes.” “Score this lead.” “Summarise this call.” Useful, but it still requires you to be the conductor — deciding which skill to run, in what order, passing the output of one into the input of the next.

A playbook removes that orchestration burden. It sequences the skills into a complete outcome, describes what happens at each step, and — critically — marks the moments where the AI should stop and wait for you rather than continuing on its own.

That last part is where most people don’t think carefully enough. The temptation is either to checkpoint everything (which makes the playbook as slow as doing it manually) or to checkpoint nothing (which means the AI publishes the draft, sends the email, and marks the deal closed before you’ve looked at any of it). The right answer is somewhere specific and intentional: human checkpoints where money changes hands, where something goes to a client, or where an action can’t be undone. Everything else can flow.

Once you draw those lines deliberately, you’ve made an architectural decision about your business — not just a prompt.

The prompt

Think of one outcome that takes you several steps: onboarding a client, producing a piece of content end to end, closing out a project, sending a month-end summary. Then run this:

Help me turn a multi-step outcome into a repeatable "playbook".

The outcome is: [DESCRIBE THE END RESULT — e.g. "a new client is fully onboarded" or "a blog post is researched, written, reviewed and published"].

Build a playbook with:

- TRIGGER — the phrase or event that starts this playbook.
- STEPS — the ordered steps from start to finished outcome. For EACH step, mark it as either [AI] (you can do it) or [CHECK] (you do it, then stop and get my approval before continuing). Be realistic about which steps need my judgement.
- USES — note where a step would call one of my skills (like the one from Prompt 4).
- DONE WHEN — the clear definition of "this outcome is complete".

Keep the human checkpoints where money, client-facing output, or irreversible actions are involved. Everything else can flow automatically.

What comes back — and what to do with it

A sequenced, labelled process. Each step is either AI-driven or a human checkpoint, and the AI has been forced to reason about which is which rather than leaving it to you to decide later. The “DONE WHEN” line matters more than it looks: without a clear finish condition, processes sprawl.

Run it once, end to end. Watch where the checkpoints create friction and where skipping them would worry you. Adjust until the balance feels right. That calibration is not a one-time thing — it shifts as your confidence in the system grows.

One more thing worth noticing: the playbook will reference the skill you built in Prompt 4. That’s not incidental. Skills become the building blocks that playbooks call. Over time, you accumulate a library of reusable skills and a set of playbooks that orchestrate them — which is, structurally, exactly how a real AI operating system is built.

You’ve now built all five layers

This is the last prompt in Part 1 of the guide. Step back for a moment and look at what you have:

1. A system map — the honest picture of what you already had

2. A data model — the consistent structure that lets the AI work with your information reliably

3. Operating instructions — the business context the AI now carries automatically

4. A skill — one task the AI performs the same way every time

5. A playbook — a complete process the AI drives, with your judgement built in exactly where it belongs

That is the architecture of an AI operating system. Not a collection of clever prompts. A system with structure, memory, repeatable tasks, and defined processes — assembled from the tools you already use.

Next post starts Part 2: the machinery that makes the architecture run without you having to manually load it every session. Prompt 6 is about making the AI read your business context automatically, so you never re-paste it again.

---

This is part 5 of 12 in Build Your Own AI Operating System — one prompt at at time that turns the AI you already use into a system that runs your business.

Subscribe to get the next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

If you’ve run the first two prompts, you have a map of your system and a routing table that tells the AI where things belong. That’s real progress. But there’s a problem neither of those fixes on its own: every time you start a fresh session, the AI has forgotten all of it.

This is the most frustrating part of working with AI at any scale. You spend twenty minutes getting it calibrated — here’s my naming convention, here’s what we don’t rename, here’s why the client folder is structured that way — and the next day you start again from scratch. It’s not a failing of the AI. It’s a missing architectural piece. You haven’t given it a place to keep that knowledge.

That’s what this prompt builds.

The file that makes it consistent

Every real AI operating system — including ThirdBrain BOB — relies on one file sitting at the top of the system that the AI reads before it does anything else. Not a README. Not a welcome note. An actual operational document: your naming rules, your routing decisions, your do-and-don’t rules for how to behave in your setup.

In most AI coding tools, a file named AGENTS.md or CLAUDE.md gets picked up automatically when you open that folder. The AI reads it first, before your question, before the task. From that point on, it already knows your filing conventions, what it’s allowed to reorganise, and what it should leave alone.

That’s the “operating system” feeling people describe when they first experience it. A brand-new session already knows how your business works. The system carries the knowledge — not your memory, not a prompt you have to paste in every morning.

The prompt

Have your routing table from Part 2 ready to paste in where indicated. Then run this:

Write me a single "operating instructions" file that any AI assistant should read before working in my system. Keep it tight — one page. Include these sections:

1. WHAT THIS IS — one paragraph describing my business and what this system is for.
2. NAMING CONVENTIONS — how files and folders should be named (dates, casing, prefixes). State the rule once, clearly.
3. FOLDER MAP + ROUTING — the routing table we built (content → type → folder). This is the filing law.
4. RULES — 5 to 8 working rules, each written as "Do X — because Y" or "Never X — because Y". The reason is mandatory; it's what lets you judge situations I didn't anticipate.
5. THE BOUNDARY — clearly mark which areas are MINE (my own notes and source-of-truth, that you should not rewrite) versus which areas you may freely create and reorganise.

Write it so a brand-new assistant could read it cold and immediately work the way I want. No fluff.

Why the reason clause matters

Notice that Section 4 has a specific requirement: every rule must carry its reason. “Never rename client folders” is a rule. “Never rename client folders — because the folder name is the key that links every other file in the system” is an instruction. The first one gets followed literally and dropped the moment a session runs long. The second one gives the AI enough context to apply the rule correctly in situations you didn’t anticipate, and to hold it even when competing pressures push against it.

This is not a minor stylistic preference. It’s the difference between an AI that executes your rules mechanically — until something slightly unusual happens and it guesses — and one that understands what you’re actually trying to protect. Bare rules without reasons are the most common reason AI “operating systems” fail in practice. The system looks fine until it doesn’t, and there’s no graceful recovery.

Write the rules in plain language, state the reason clearly, and your file will survive edge cases. Write them as bare imperatives, and you’re one long session away from the AI doing something sensible-looking but wrong.

Save the file at the top level of your setup, named AGENTS.md or CLAUDE.md depending on which AI tool you use. Next time you open a session there, point the AI at it first. The calibration time drops to almost nothing. Your conventions carry forward. That’s the architectural layer clicking into place.

Next: Part 4 — packaging your first reusable skill, so the AI can do a specific job in your business the same way every time.

---

This is part 3 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get the next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

There is a task you explain to the AI every single time you need it done. Maybe it’s how you draft a certain kind of email. Maybe it’s how you prepare a client meeting, or how you structure a proposal section. You’ve said it so many times you’ve probably stopped noticing.

The AI has not been learning from those repetitions. Each conversation starts fresh. Which means every variation you explain, every constraint you add, every “actually do it like this” correction — it disappears when the chat closes. The next time you open a new window, you’re starting from the average of everything the AI has ever read, not the specific way you’ve refined this task over forty conversations.

That’s the problem a skill file solves.

What a skill actually is

A skill is not a prompt. It’s a file — a small, structured document that captures a task you do repeatedly: the trigger (when to use it), the steps (in the order you actually do them, including the judgement calls, not just the mechanics), the constraints (the mistakes you most want avoided, each one with a reason), and the output format.

You save it in a skills/ folder in your system. When the task comes up, you tell the AI to use the skill by name. It loads the file, runs the task the way you’ve defined it, and produces a consistent result. Next time you want to improve the process, you edit one file. Not a chat history buried somewhere. One file.

The shift is subtle but significant. Your capability stops living in your chat history — where it gets re-explained every session and quietly drifts — and starts living in a file you own, refine, and trust.

This follows the open agentskills.io standard, which means the file you write works across AI tools that support it. You’re not building something proprietary to one chatbot. You’re building something portable.

The prompt

Pick one task you find yourself re-explaining to the AI. Drafting a certain kind of email. A recurring meeting prep. Any process you’ve described out loud more than twice. Then paste this in:

I want to turn one repeated task into a reusable "skill" file, following the agentskills.io standard.

The task is: [DESCRIBE THE TASK IN ONE SENTENCE].

Write a skill file with these parts:

- NAME — a short, plain name for the skill.
- USE WHEN — the trigger phrases or situations where I'd want this skill (so the AI knows when to reach for it).
- STEPS — the numbered steps to do the task well, in the order I actually do them. Include the judgement calls, not just the mechanics.
- CONSTRAINTS — 3 to 5 rules, each as "Do/Never X — because Y", covering the mistakes I most want avoided.
- OUTPUT — what the finished result should look like (format, length, where it gets saved).

Keep it specific to how I do this task, not a generic how-to. Ask me up to 3 questions first if you need them to get the steps right.

What you get, and what to do with it

One skill file. Drop it in a skills/ folder in your system — the same folder structure you’ve been building over the past three prompts.

The first time you use it, you’ll notice something small: you didn’t have to explain yourself. You told the AI which skill to load and described the situation. It ran the process the way you defined it. That’s it.

That’s not magic. It’s just having written down how you work, once, in a place the AI can find it.

Over time, you refine the file as your process improves. You add a constraint you kept running into. You adjust a step that turned out to be wrong. The learning accumulates in the file, not in your head — and not scattered across thirty closed chat windows.

Next: Part 5 looks at chaining skills into a playbook — a sequence of steps that runs an entire process, not just a single task.

---

This is part 4 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get the next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx.

If you ran last week’s prompt, you have a system map: an honest, slightly uncomfortable picture of your current setup. Folders that mean different things on different days. Meeting notes in three different formats. A file called “final” that may or may not be final.

That map is the foundation. Here is the first thing you build on top of it.

The insight is simple, and once you see it you can’t unsee it: your notes are not free text. They are typed records. A “client” note always carries the same handful of fields — a name, a status, a region, a main contact. An “invoice” always links back to a client. A “meeting” involves people and produces decisions. These aren’t random documents. They’re instances of a small set of types, and those types connect to each other in predictable ways.

A pile of documents has no structure the AI can reason across. A set of typed, connected records is a system the AI can query, route into, and answer questions from. The difference between “find the invoice for the Acme project” returning blank stares versus the right file is almost entirely whether the AI knows that invoices link to clients and that this link is the one that matters.

The problem with generic notes

When everything lives as unstructured Markdown (or Word documents, or random Google Docs), the AI has to guess what each file is every single time it touches one. It reads the prose, infers a type, and hopes for the best. When you have a hundred files, that guessing accumulates into confusion. The AI “loses” things — not because it forgets them, but because it can’t reliably tell a deal from a deliverable from a project note.

The moment you define even a rough data model — a short list of record types, the fields each carries, and the one most important link each has to another type — the AI’s behaviour changes noticeably. It stops guessing. It can ask a sensible question: “Is this a client note or a deal note?” rather than treating them as the same category of blob.

You’re not building a database. You’re drawing a small diagram in plain English, and sharing it with the AI once.

The prompt

Paste your system map from Part 1 at the top if your assistant doesn’t still have it. Then run this:

Based on my setup, help me design a small data model — the typed records my business actually runs on.

Propose 6 to 10 "entity types" for MY business (not a generic list). For each one, give me:

- TYPE NAME — a short label (e.g. client, deal, meeting, invoice, idea).
- KEY FIELDS — the 3 to 6 pieces of structured information every record of this type should carry (e.g. a client has: name, status, region, main contact).
- LIVES IN — which folder records of this type belong in.
- LINKS TO — the one most important connection to another type (e.g. an invoice links to a client). This "foreign key" is what lets you query across the business.

Then give me a ROUTING TABLE as a simple 3-column table:
"When I create this kind of content" → "it becomes this type" → "and goes in this folder".

Rules: keep it small and real — only types I actually use. Prefer fewer, well-defined types over a sprawling list. Use plain field names a non-technical owner would understand.

What comes back — and why the routing table matters

The AI will propose something like eight types: client, deal, meeting, invoice, contact, project, deliverable, idea. Each one gets its fields and its folder. Then the routing table — two or three columns, a dozen rows — tells you exactly where any new piece of content belongs the moment you create it.

Save that routing table. From this point forward, any time you ask the AI to file something or create a note, you point it at the routing table first. You’ll notice immediately that it stops asking “where should this go?” and starts routing consistently. That consistency is what every later capability in this series is built on. A reminder that auto-files correctly. A pipeline that can pull every invoice for a specific client. A weekly summary that knows which meetings were with which company. None of that works without typed records with links.

If the model proposes twelve types and most of your work is actually four things, push back. Ask it to collapse the list. Smaller and well-defined beats comprehensive and muddled, every time.

Keep the system map and the data model together. Two documents. You’ll reference them repeatedly as the prompts build on each other.

Next: the single operating-instructions file the AI reads before it does anything in your setup — your rules, your preferences, your conventions, written once so you never have to re-explain them.

---

This is part 2 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get the next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx or in the ThirdBrain Skool community.

There’s a temptation, the moment you decide to get serious about AI, to start adding things. A better prompt. A new folder structure. Some tool a video told you about. Don’t. Before you add anything, do the opposite: make the AI describe what you already have, out loud, in writing — and tell it not to flatter you.

This sounds almost too simple to bother with. It isn’t. It’s the step where the AI stops guessing and starts reasoning about your setup, and you can feel the difference the instant it happens.

Why this is first, not later

An AI can only run your business if it can see the shape of it. Most people never let it. They open a fresh chat, paste in a question, and get a competent, generic answer — because the AI is working from the average of everything it has ever read, not from your actual files, your actual mess, your actual conventions.

The fix is not a cleverer question. It’s visibility. You point the assistant at the folder where you already keep your work — notes, documents, projects, whatever you’ve got — and you ask it to map it. Not improve it. Map it. The improving comes later, and it’s much easier once both of you are looking at the same honest picture.

The prompt

Open your AI assistant inside the folder (or vault, or drive) where your work already lives, so it can read your files. Then paste this in:

You are helping me understand the structure of my current setup before we improve it.

Read the folders and files I've pointed you at. Do not change anything. Produce a one-page "system map" with these sections:

1. TOP-LEVEL MAP — list each top-level folder and, in one line, what it appears to be for.
2. NOTE TYPES — identify any repeating kinds of document I keep (e.g. meeting notes, client records, invoices, ideas). For each, note whether they follow a consistent format or not.
3. CONVENTIONS — describe any naming or filing patterns you can detect (date formats, folder numbering, prefixes). Flag where they're inconsistent.
4. WEAK SPOTS — name the 3 places where you, as an AI, would most likely get confused, lose information, or have to guess. Explain why for each.
5. ONE SENTENCE — summarise, in plain language, what kind of "system" I currently have.

Be specific and quote real folder/file names. Don't flatter the setup — give me the unvarnished picture.

What comes back — and why it lands

A short, specific map of your own system, including the parts that are messy. It will quote your real folder names. It will tell you, plainly, that your meeting notes follow three different formats and that “Final_v2_actual_FINAL.docx” lives next to “final.docx” and it genuinely cannot tell which one you mean.

That last part is the point. Seeing your setup reflected back accurately — flaws and all — is the moment you stop thinking of the AI as a chatbot and start thinking of it as something that could actually run on top of your business. It’s reasoning about you, not a template.

Keep the map. You don’t need to act on it yet. The next prompt in this series fixes the first weak spot it surfaces — and each one after that builds on the last, until you’ve got a working AI operating system you assembled yourself. This is exactly how ThirdBrain BOB is built; you’re just building it on your own setup first.

Save the map where you’ll find it again. Next week: turning that pile of documents into a system you can actually query.

---

This is part 1 of 12 in Build Your Own AI Operating System — one prompt at a time that turns the AI you already use into a system that runs your business.

Subscribe to get the next prompt the moment it’s out.

Can’t wait? The complete guide — all twelve prompts as one polished PDF, plus the “under the hood” Part 2 — is free in the ThirdBrain Skool community.

Want the whole thing already wired up across a business? See what ThirdBrain BOB includes at brn.cx or in the ThirdBrain Skool community.

The offer goes like this. Pay a little to get in the room. Spend two weeks on live calls learning to assemble AI agents that handle real work — write the newsletter, edit the video, chase the invoice. Then stay in the community for a monthly fee, because the next thing is always coming.

The framing is good. “Stop renting AI by the hour and start hiring it.” “The AI does 80% of the work, you review and ship.” “Every agent you build stays yours.” I genuinely like that last line — it reaches for the right idea, that what you make should be an asset you keep, not access you rent.

The trouble is everything in front of that line contradicts it.

The category error

Here’s the thing nobody says out loud: you don’t take a two-week course to hire an employee.

When you hire a person, you don’t first enrol in a class on how to build a human. You bring in someone who can already do the job. The whole point of hiring is that the capability arrives ready — you onboard it to your context and put it to work.

“AI employees” are sold on exactly that promise — a worker that just does the thing — and then delivered as the opposite: a curriculum for building the worker yourself, over two weeks, with homework. The metaphor says hire. The product says enrol. You’re not hiring an employee. You’re attending a course on employment, then doing the job of HR, training, and IT for an agent you have to construct from a blank screen.

That’s the empty-box problem in a new wrapper. Claude Code out of the box is a brilliant, empty room. A cohort that teaches you to furnish it is teaching you to do the furnishing — which is real work, and real maintenance, that never ends.

Why the angle changes every month

If you watch these offers over time, you notice the offer keeps changing — new name, new hook, new two-week window — while the model stays identical: low-friction entry, then recurring membership.

There’s a reason for that. A membership funnel needs novelty to keep filling the room. When the thing you sell is a curriculum plus a community, you have to relaunch a fresh angle every cycle to bring people back to the top. The rotation isn’t a sign of momentum. It’s a sign that there’s no durable asset underneath — nothing that compounds on its own, so the engine has to be re-cranked monthly.

Contrast that with a system you own. It doesn’t need a relaunch. It just keeps working.

What the buyer is actually left holding

Strip away the framing and look at what you walk away with after the two weeks:

• You inherit the building. Day one you don’t have a team of AI employees. You have a backlog of agents to design, debug, and wire into your business. The “80% done by AI” only starts after you’ve built the thing that does the 80%.

• You inherit the maintenance, forever. Agents built from prompts go stale — model IDs change, APIs shift, what worked in June breaks in September. Nobody is keeping yours current but you.

• There’s no governance. No scoring, no validation, no versioning. Quality is whatever your agent produced on the call that afternoon. For a hobby, fine. For the thing that sends your client invoices, not fine.

• The recurring bill is the business model, not a feature. You keep paying to stay near the room, because the room is the product.

None of this makes the cohort a scam. It makes it a teaching artifact dressed as a workforce. If you enjoy building, it’s a fun fortnight. If you’re trying to run a business, it’s a non-starter — every step assumes you want to become the person who builds and patches the agents, rather than the person whose business is already running on them.

The fee is the smallest number on the page

Here’s the line the funnel never shows you. The membership is the part you can see, so it’s the part you weigh. Put the whole path on paper and the fee turns out to be the rounding error.

Add up the real first-year cost of building it yourself:

• The fee — visible, and the smallest of these. A little up front, a monthly bill after.

• The build — two weeks of calls plus the actual assembling and debugging. Call it ~40 hours of your time.

• The upkeep — agents drift as models and APIs move; keeping them alive runs a few hours a month, ~36 hours a year.

• The leverage you don’t have yet — the quiet one, and the biggest. Every week you spend building is a week the AI isn’t running your business. If a working system hands you back ~8 hours a week, then an 8-week build-and-debug ramp is ~64 hours of leverage you simply never collect. That time doesn’t come back.

Now put your own hourly rate on it. At €100/hour, the time alone — roughly 40 building + 36 maintaining + 64 of forgone leverage ≈ 140 hours, about €14,000 — dwarfs a year of membership. And that’s the optimistic version, where everything you build works.

That’s the sleight of hand in “it stays yours.” It’s priced as if the only cost is the subscription. The subscription is the cheapest thing about it. The expensive thing is the quarter of a year you spend becoming your own AI department instead of using one.

A system that’s operational before lunch doesn’t have a build cost, doesn’t have a ramp, and starts paying back the same afternoon. The two paths don’t differ by a subscription. They differ by a quarter of your year.

The honest comparison

To be fair, these are arguably different categories for different people. So here’s the straight version — the build-your-own-AI-employees cohort against a governed business operating system:

• What ships — Cohort: a curriculum plus the skill to build agents. Owned system: finished, certified skills on a ready structure.

• You leave with — Cohort: a backlog to build over two weeks. Owned system: something operational in under 30 minutes.

• Domain — Cohort: whatever you build yourself. Owned system: sales, finance, marketing, ops, HR — already covered.

• Quality — Cohort: whatever the agent did that day. Owned system: a certification gate, spec reviews, scorecards.

• The moat — Cohort: the room and the monthly bill. Owned system: structure, a data model, and a skills library you own.

• Cost shape — Cohort: recurring membership. Owned system: you own the asset.

The instinct underneath the cohort is right: small capabilities should compose into repeatable workflows, and what you build should stay yours. That’s exactly the architecture — skills compose into playbooks, playbooks route across the value chains of an actual business. The difference is whether that architecture arrives built, governed, and owned, or whether you spend a fortnight assembling a thin version of it and then pay monthly to keep being shown the next one.

Take the course, or have the result

So read the cohort material if you’re curious — the thinking about agents-as-workers is a useful frame, and the “it stays yours” instinct is the right one.

Just be clear about the trade. A course teaches you to build the thing. It is not the thing. And “I learned to build an AI employee over two weeks” is a different sentence from “my business runs on a system I had working before lunch.”

You don’t take a course to hire an employee. You hire one who can already do the job, and you get back to work.

Want to see what “already does the job” looks like for your business? brn.cx

ThirdBrain BOB is now public

Join the free ThirdBrain Skool community here: skool.com/thirdbrain-tech-3102/about

After four months of beta testing, ThirdBrain BOB is now available publicly, and so is the ThirdBrain Skool community, which becomes the public front door. You can join, read the full “What is BOB?” course, see the Starter Vault path, and decide whether the system fits before you buy.

There hasn’t been a proper public note explaining the whole thing yet. We’ve had internal release notes, product pages, and courseware, but never one plain explanation of what BOB is and why it exists. So this is that note.

What BOB is

BOB stands for Business Operating Brain, an owned AI operating system for people who use AI to run real work: business owners, consultants, coaches, agencies, and digitalization partners serving SMBs. Its natural habitat is Obsidian, but Obsidian isn’t the product. The product is the operating system around it: the folder structure, data model, skills, playbooks, plugin configuration, templates, hooks, quality rules, and business rules that let your AI CLI tool of choice work inside a structured business environment instead of a blank chat window.

The easiest way to understand it is by contrast. ChatGPT and Claude are blank boxes. Every session starts from zero, so you explain the business, paste the context, ask for help, copy the answer somewhere else, and repeat the same ceremony tomorrow. BOB is the opposite: it gives the AI a business structure to work inside. Your personal, company, and client-specific context lives in a local folder, and the AI reads the relevant files, chooses the right workflow, creates the output, saves it in the right place, and leaves a record of what changed. The goal isn’t better chat; it’s finished work.

What is in the system

BOB has six layers that work together.

1. The vault. Your business sits in plain Markdown files that you own: personal context, company profile, client folders, marketing assets, sales pipeline, finance notes, decisions, meetings, and deliverables. Obsidian is the natural interface because it makes the folder navigation human-friendly, but the underlying files are still yours.

2. The data model. BOB does not just write random notes. It knows the difference between a client, a project, a deal, a task, a report, a deliverable, and a piece of marketing content. Frontmatter templates and validation hooks help enforce those business rules, so dashboards, searches, and workflows keep working after the first week.

3. The skills. A skill is a repeatable AI workflow for a business job: write a proposal, qualify a lead, create a client folder, draft a LinkedIn post, reconcile a bank account, generate a report, build a diagram, prepare a launch plan. The system includes Obsidian tooling to enable and disable skills easily, so you can keep the active workspace focused on the job in front of you.

All skills are context-aware. They do not operate from the prompt alone; they know which central context files to read, what inputs they need, and where their outputs belong.

Many skills are adapted from the best-of-breed public skill libraries shared by the community, then standardized through our custom Skillsmith process so they behave consistently inside BOB instead of feeling like unrelated prompt fragments.

The Starter Vault ships with the bones and 150+ skills integrated; additional specialized packs (free and premium/pro) get the same treatment, so they slot into the system cleanly rather than bolting on. The complete system spans 300+ governed skills across business, sales, marketing, procurement, finance, ops, content, and project management.

4. The playbooks. Real work rarely happens in one step. A product launch, a monthly close, a client onboarding, or a lead-to-cash workflow needs multiple actions in order. Playbooks chain skills into guided business processes. And BOB does not only act when you ask: a built-in task scheduler runs recurring work on its own, and scheduled research keeps the vault current, including your regional context, so your business environment stays up to date without you babysitting it.

5. The workspace. BOB Workspace turns the vault into an operating cockpit: tasks, clients, content, dashboards, and live views over the underlying files. It is a no-code, fully customizable interface wired tightly into Obsidian. It is powered by your frontmatter and bases, so every type of note is findable through the UI consistently, not lost in a folder of text or a web of wikilinks. Your chosen AI CLI tool operates inside the same well-structured vault enforced by hooks and scripts (claude, codex, goose). That tight integration across providers and ai tools is the part I have not seen anywhere else.

6. The QMS. BOB includes a built-in Quality Management System. Different kinds of outputs can follow different review rules: a LinkedIn post does not need the same gate as a client deliverable, a finance report, a legal clause review, or a product release. The QMS gives each output type the right level of validation, review, and sign-off instead of pretending all AI output carries the same risk.

Around that sits a documentation layer: skill docs and a skills explorer that show what workflows exist, what inputs a skill expects, what context it depends on, what outputs it creates, and which business value chain each playbook serves so business growth suggestions are relevant to your state of the business.

Every skill also carries its provenance in metadata, so you can always see where it came from. You are not expected to inspect raw skill files just to understand what the system can do.

Integrated features make the product

That combination of integrated features makes the product

Much more than a prompt library, not a course, not another SaaS dashboard that owns your data. BOB is a working system you own, has a skills manager and a user interface, and is now at the point where everything is in place and integrated, ready to open the doors.

There are step-wise onboarding skills for when you are new to this AI skills based system. If you are familiar with claude code or codex, you can jump right in and point the AI at your existing business (your site, your documents, your notes), and it drafts your profile, your offer, and your ICP from that material. You answer a few gap questions. You are operational in under thirty minutes, not a weekend or a 6 week cohort just to get started.

The Starter Vault is now available through the free Skool community. The public “What is BOB?” course explains the full system before purchase. The Starter Vault course walks buyers through the actual download and setup path. BOB Workspace is configurable through plain-text files. Bases give more visible database-style views. Schema validation is more resilient. Every numbered folder now carries its own AI-readable AGENTS.md map, so Claude, Codex, Gemini, and other assistants can pick up local context as they move through the vault.

A small proof of that: I am not a video creator, but I used BOB itself to produce the explainer videos for this launch: avatar and faceless, rendered with Remotion. The system makes its own demo.

The practical architecture

BOB is designed around the whole business, not one department. Most “AI operating systems” you see are limited to one slice (GTM, content creation, or a personal life-OS setup) and do not meet the needs of a small or medium business owner. BOB covers the whole org: sales, marketing, operations, finance, HR, procurement, delivery, management, and content all have a place in the system.

The folder structure is deliberately boring. Folders use numbers and plain names so they stay in a predictable order and can be referenced consistently by humans and AI tools. Personal work, company work, and client work have separate homes. Temporary processing has its own dedicated 99-TMP area, so scratch files, scripts, imports, and intermediate outputs do not pollute the main operating structure.

BOB runs on desktop operating systems: Windows, Linux, and macOS. On Windows, WSL is the preferred setup because most AI CLI tooling behaves more reliably in a Linux-style environment.

The tooling philosophy is also deliberate: CLI-first, not MCP-heavy. Command-line workflows are easier to inspect, repeat, log, and automate than hidden UI actions, and they are deterministic and far cheaper on tokens because BOB runs on the AI subscription you already pay for rather than a metered API bill. MCP tools are still supported, and BOB includes a generic MCP client, but the default bias is toward simple command-line workflows that leave clear traces.

There is also a custom Python script creator built into the system. It enforces the uv single-file script pattern, so ad-hoc automation stays portable, isolated, and easy to rerun without turning the vault into a dependency mess.

BOB also connects to the tools people already use around knowledge work and delivery: Draw.io and Excalidraw for diagrams, NotebookLM for source-grounded exploration, Notion for external workspaces, Google Workspace for documents and collaboration, and Google Drive sync for shared files. The point is not to trap everything in one app. The point is to give the AI a stable home base, then let it reach the right surrounding tool when the work calls for it.

From inside Obsidian, you can also run multiple concurrent AI chat sessions with different providers. Claude, GPT, Gemini, or another compatible agent can work against the same vault context while staying separated by session. That matters when you want one assistant drafting, another reviewing, and a third researching without losing the shared business context.

Who this is for

BOB is for people who already believe AI is useful, but are tired of running it as scattered chats.

It is especially useful for:

• business owners who want one place where AI can understand the business

• consultants and coaches who want to deliver AI-powered work to clients

• agencies and digitalization partners who want infrastructure they can own and customize

• Obsidian power users who want their vault to become operational, not just archival

• operators who want repeatable workflows instead of one-off prompting

It is probably not for you if you want a passive course, a phone app, or an enterprise SaaS admin console.

Where to start

Join the free ThirdBrain Skool community:

skool.com/thirdbrain-tech-3102/about

Start with:

• What Is BOB? The Complete Picture: the free public course that explains the whole system

• Starter Vault: the buyer path for the vault structure, download, setup, and first week

You can also reach the product page from brn.cx.

Nate Jones’ “Open Skills” is a genuinely good piece of thinking about AI-agent design. It’s also a catalog of things you have to build yourself, sold under a word that promises things you can install. The gap between those two is worth a careful look — because it’s the whole argument for why we build the way we do.

I went through Nate Jones’ Open Skills page primitive by primitive — all 31 skills across 7 categories, plus the 7 runbooks that chain them together. I wanted an honest read: what’s real here, what’s marketing, and what it tells you about the actual problem of running agents well.

Here’s the short version. The thinking is sharp. The packaging oversells. And the gap between the two is the most useful thing on the page.

What it actually is

Open Skills calls itself “a library of reusable AI-agent primitives.” That phrasing does a lot of work. When most people hear “skills library,” they picture something they can install — a folder of finished, working capabilities.

That’s not what this is. The page says so plainly:

“These are not downloadable finished skills. Each entry gives you the prompt to build the primitive with your own agent.”

So the deliverable is 31 build-prompts and 7 composition diagrams. A well-written idea catalog with a setup prompt per idea. The artifact is the thinking — not the skill.

That’s the oversell in one line: “Open Skills” implies installable assets. It delivers build-and-maintain instructions. It’s a teaching artifact dressed as a tooling library.

Where it underdelivers, practically

Nothing wrong with a teaching artifact. The problem is what the buyer is left holding:

• You inherit all the maintenance. Several skills proudly “capture the current API request shape — which model IDs are live, what each model costs.” Useful — except now you keep that current, per skill, forever. The maintenance burden isn’t removed. It’s handed to you and renamed a feature.

• No governance. No scoring, no validation, no versioning, no certification. Quality is whatever your agent produced that afternoon.

• You build a backlog before you have a library. Day one, you don’t have 31 skills. You have a reading list and 31 things to implement, debug, and maintain.

For a developer who enjoys building tools, that’s a fun weekend. For anyone trying to run a business with AI, it’s a non-starter — every entry assumes you can write, debug, and maintain an API integration.

The honest comparison

This is where I have to be fair: Open Skills isn’t really competing with a business operating system. It’s a different category, for a different person.

Open Skills A governed skill library (ThirdBrain BOB) What ships Build-prompts (recipes) Finished, certified skill packages Audience Technical solo builders Business owners Domain Dev & media: PR merges, frontend, browser QA, video editing The business: sales, finance, marketing, ops, HR Composition 7 informal runbooks Playbooks + value-chain routing over a data model Quality None Certification gate, spec reviews, scorecards Setup Build each one yourself Operational in under 30 minutes

His “primitive → runbook” insight is exactly right — small skills compose into repeatable workflows. It’s the same architecture we shipped as skill → playbook → value chain. He has 31 primitives and 7 chains. The difference is what sits underneath: a governed system versus a list of good ideas.

Where he’s genuinely sharp

I don’t want to wave this away. A handful of his agent-operations ideas are crisp:

• The goal prompt as acceptance test — bake the definition of done and the verification gates into the delegation prompt itself.

• Testing discoveries must not die in chat — every QA pass leaves a runbook entry behind.

• The flywheel — a posture, running under every workflow, that watches your sessions for patterns worth turning into skills.

These are good instincts. Here’s the twist: they’re all things you encode as a reminder to the agent. A skill the agent loads — and may or may not honor.

The real lesson: a reminder is not a rule

This is the distinction worth keeping.

Open Skills encodes discipline as a skill the agent chooses to follow. “Don’t let testing discoveries die in chat” lives in a prompt the agent reads — and, on a long or distracted session, quietly drops.

The stronger move is to encode the same discipline as a hook the harness executes — automatically, every time, whether the agent remembers or not. The wrap-up runs on session end. The frontmatter validator runs on every write. The discovery becomes a task whether or not anyone asks.

A reminder depends on attention. A rule depends on nothing. The agent-ops layer Open Skills teaches as prompts is the weaker, hopeful version of enforcement you can move into the machinery itself.

That’s not a knock on Nate — it’s the natural ceiling of a “skills are prompts you build” model. You can’t enforce what you only suggest.

Recipes vs. the kitchen

So: read Open Skills. The thinking is worth your time, and the primitive-to-runbook framing is correct. Just be clear about what you’re getting — a sharp set of recipes you’ll cook yourself, and keep cooking, and keep maintaining.

The recipe is not the meal. And a stack of recipes is not a kitchen.

If what you want is to run something — not to spend your weekends building and patching the tools that run it — the question isn’t how good the recipes are. It’s who’s already built the kitchen.

Curious where the kitchen analogy goes for your business? brn.cx

You hire a human assistant — they reorganise a folder, add deals to your pipeline, send a few emails, draft an invoice. At the end of the day you can open a folder and see every record they touched.

You hire an AI — it does the same work, sometimes faster, sometimes overnight. At the end of the day you have a chat log and a feeling that something happened.

The agents got smart. The screen for the human who runs the business — the one that shows you what's true, right now, under rules you control — was left out of every AI OS shipping today.

So I built one.

Three layers, one screen

Obsidian is where the data lives. Plain markdown files on your disk, organised in folders. No database. No cloud lock-in. No vendor that can decide tomorrow that your pricing tier is being discontinued.

Claude or Codex, or a team of them, is the agent that operates on those files. It reads, writes, queries, and reconciles — through the same vault you use, under the same rules you set. Anthropic's Model Context Protocol gives it a structured way to act with the outside work, and Claude Code gives it a runtime that can work on your files and respects your validation hooks.

BOB Workspace is the human surface. One Obsidian plugin, eight modules, a left-nav and tabbed views. Your day, your revenue, your clients, your books, your partners, your suppliers, your numbers. The screen where you see what Claude did overnight and what's true right now.

The carousel I posted on LinkedIn earlier today shows it. This is the longform.

We turned Obsidian into a no-code application builder

Most people think Obsidian is for notes. I think it's the most underrated business operating system on the planet — and BOB is the proof.

Planner — your day, week, tasks, projects.

CRM — pipeline, leads, contacts, campaigns. Kanban or grid.

Client Work — one workspace per client. Meetings, deliverables, communications, feedback, surveys, testimonials.

Finance, HR , any kind of records you want to keep track off and need for context for the AI, for yourself, your company or your client(s)

Reports — pipeline, sales, partner, activity, productivity. Every number links back to the records that produced it. No black-box dashboard.

Plus PRM (partners, commissions, certifications) and Suppliers (requisitions, POs, three-way match).

Why it matters: same rules for humans and AI

In a normal application, the validation rules — what's required, what's allowed, what counts as a complete invoice — live inside the application. Humans use forms that enforce them. In AI OS agents bypass the forms and write straight to the file system, with their own rules drifting away from yours.

In BOB, the rulebook lives in one place. The human form uses it. The AI uses it. Both pass the same checks. Both leave the same trail.

When Claude tries to create an invoice without a due date, it can't — same as you. When Claude marks a deal as won, the pipeline report updates the same way it would if you'd done it manually. When Claude breaks a rule you set, you see it — the same warning that would stop you stops the agent.

Your team and your agents play by the same rulebook, on the same surface, with the same visibility.

No silent edits. No black-box mistakes. No surprises at month-end.

Under the hood

For the technically curious — here is how the layers actually fit together.

The data layer. Every business record is a single markdown file with YAML frontmatter.

The schema layer. Field definitions, enums, required flags, and relationships live in YAML at 00-CORE/Schemas/source/{entity}.yaml — a single source of truth that generates three things: a JSON Schema used by validation hooks, a Metadata Menu fileClass that powers the Obsidian authoring UI, and the entity table in the data-model docs. Edit the YAML, run regenerate.py, and every layer updates.

The view layer. .base files in 00-CORE/Bases/ define how each entity list renders — visible columns, filters, sort, groupBy, named views. The BOB plugin reads these natively, which means adding a new "Won this quarter" view to the pipeline takes two lines of YAML in deal.base and no plugin reload.

The plugin layer. BOB Workspace is a single Obsidian plugin that draws the left nav, the tabbed views, the capture modals, the dashboards. It stores nothing — it's a lens. If the plugin disappears tomorrow, every byte of business data is still sitting on your hard drive in a format you can read with cat.

The agent layer. Claude Code runs as the AI operator. It uses the Model Context Protocol for tool integration (Obsidian CLI, Playwright, custom MCP servers), and a Skills system — over 300 specialised skills covering sales, marketing, operations, finance, hr, content. Each skill is itself a markdown file with frontmatter declaring its inputs, outputs, and outbound network calls.

The enforcement layer — the part that makes the "same rules" promise real. Claude Code has a PostToolUse hook configured in .claude/settings.json that fires after every Write or Edit operation. The hook runs validate_frontmatter.py which loads the relevant JSON Schema and validates the file. Required field missing? Hook exits non-zero, change is blocked, agent has to fix and retry. The same JSON Schema powers the Metadata Menu UI that humans use to fill in forms. Same rulebook, two consumers.

The audit layer. Every AI session is logged. There is an ai-session-ledger skill that aggregates Claude Code's JSONL session files into per-day, per-client ai-session-log notes with token counts, files touched, deliverables produced, estimated cost. You can ask "what did the AI do this week for client X" and get an answer with receipts.

That's the build. Plain text underneath, plain language on top, AI in the middle that plays by your rules.

— Carine

Anthropic just shipped a small-business AI toolkit. It's well-made, honest about its scope, and built on a set of assumptions that will work beautifully for some businesses — and completely miss others.

Last week I sat down with Anthropic's new knowledge-work-plugins repository and mapped every one of its 15 commands against the ThirdBrain BOB skill library in a detailed side-by-side analysis. I wanted an honest picture: where are we ahead, where are we behind, and — more importantly — what does the shape of their product tell us about the problem they're actually solving?

The headline number is 40×. ThirdBrain BOB covers roughly 40 times as many business workflows as the Anthropic plugin across all 11 standard value chains. But that number flattens the more interesting story, which is about two fundamentally different bets on what AI for business should be.

What Anthropic Built — and Built Well

Credit where it's due: the Anthropic plugin is clean, focused, and genuinely useful for a specific kind of small business.

The 15 commands cover the basics well: write a job post, analyse your pipeline, draft invoice language, pull a Monday brief. There's a natural-language front door — an smb-router that maps plain English ("help me follow up on overdue invoices") to the right workflow. And the three live-connector integrations — QuickBooks, PayPal, HubSpot — do something that document-based AI genuinely cannot: they pull real numbers from your actual accounts and reason over them in real time.

That last point matters. If you're a US-based founder on QuickBooks, the Anthropic plugin can look at your actual cash position, your actual pipeline, your actual outstanding invoices — and give you a business brief that reflects reality rather than a model of it. That's a meaningful capability difference.

Fourteen of the fifteen commands are covered by existing ThirdBrain BOB skills. Three gaps are worth naming honestly:

1. Tax & compliance planning — quarterly estimated tax, 1099-NEC prep, accountant handoff. The vault has deep financial controls (GL, fixed assets, trial balance) but no tax-season workflow built for the owner-operator filing their own quarterlies.

2. Unified business pulse — Anthropic's Monday and Friday briefs pull across finance, sales, and ops into a single priority. ThirdBrain BOB has daily briefings and weekly reviews, but they're not yet integrated across functions.

3. Customer sentiment aggregation — a single weekly view across disputes, tickets, email sentiment, and reviews. The vault has each of these as separate skills; nobody has connected them into one signal.

These are real gaps. They'll be closed. But they're not the interesting part of this story.

The Hidden Assumptions in Anthropic's Design

When you look at the Anthropic plugin closely, you notice it was designed for a specific customer: a US-based, English-speaking small business owner running on standard American software infrastructure (QuickBooks, PayPal, HubSpot), using Claude, operating in a single jurisdiction, probably with fewer than 20 people.

That customer is real and well-served. But it leaves out most of the world.

Local vs. hosted. The Anthropic plugin is a cloud service. Your business data — your pipeline, your invoices, your customer records — travels to Anthropic's servers to be processed. For many US SMBs, that's fine. For businesses in the EU operating under GDPR, or in the UAE where data residency requirements are sharpening, or simply for any owner who doesn't want their competitive data in a third-party system, it's a non-starter. ThirdBrain BOB runs locally inside Obsidian. Your vault stays on your machine. Nothing leaves unless you explicitly send it somewhere.

Anthropic-only vs. any AI. The plugin is built for Claude. Full stop. ThirdBrain BOB is AI-agnostic by design: the same skill library runs on Claude Code, Gemini, Codex, and any agent that can read a markdown file. As models improve and pricing changes, you're not locked in. When a cheaper model handles 80% of your workflows well enough, you route to it. When you need Opus for a complex strategic analysis, you use that. The orchestration layer doesn't care.

US-only vs. EU/UAE/worldwide. This is the sharpest difference and the one that's hardest to close. The Anthropic plugin assumes US tax law, US software tools, and US business norms. ThirdBrain BOB was built with the UAE, Belgium, and multi-jurisdiction businesses as first-class citizens. The skill library includes UAE VAT returns, UAE corporate tax (with free zone qualifying income analysis), IFRS-compliant financial statements, FIDIC construction contract claims management, and gratuity provisions under UAE labour law. These aren't afterthoughts — they're production-grade workflows used in live businesses.

The Depth That Doesn't Show Up in a Feature Count

Here's what 338 skills actually means in practice.

The Anthropic plugin covers three value chains: lead-to-cash (partially), hire-to-productivity (partially), and record-to-insight (reasonably well). ThirdBrain BOB covers all eleven — including eight that Anthropic doesn't touch at all:

• Deliver-to-satisfaction: project management, FIDIC contract claims, escalation routing, issue resolution

• Procure-to-pay: requisition through supplier payment, three-way matching, supplier performance

• Plan-to-perform: market sizing, competitive positioning, JTBD analysis, quarterly planning, OKRs

• Order-to-fulfill: demand forecasting, production scheduling, logistics, quality control

• Concept-to-launch: product definition, go-to-market planning, launch readiness

• Service-to-renew: client health tracking, NPS aggregation, renewal management

• Create-to-publish: 42 skills covering the full content production pipeline — video, graphics, SEO, distribution

• Market-to-order: demand signal analysis, campaign-to-order tracking

A business using only the Anthropic plugin for AI assistance is getting help with roughly 3 of 11 functions. Everything else — production, procurement, delivery, content, client success, strategic planning — they're still doing manually or with point tools.

Two Different Bets

I don't think Anthropic made a mistake. I think they made a deliberate, smart bet on a specific wedge: get US SMBs hooked on AI-assisted business management through live integrations with the tools they already use, delivered through the most natural interface possible (just ask, in English). That's a strong product strategy for that market.

ThirdBrain BOB is a different bet.

The bet here is that the businesses with the most to gain from AI are the ones that are too complex, too international, or too sector-specific to be served by a US-centric plugin — and that the right architecture is a local, AI-agnostic, deeply customisable skill library that adapts to your business rather than asking your business to adapt to it.

The connector question is real: ThirdBrain BOB doesn't pull live data from QuickBooks. The workflows reason over documents, vault context, and data you bring in yourself. For businesses where the manual import is acceptable, the depth and flexibility are substantial. For businesses that need the live feed, the connector approach wins.

Both can be true. Different businesses, different bets, different tools.

What's Coming

Three things are in motion:

Closing the three gaps — tax-season-organizer, business-pulse, and customer-pulse are on the build list. They're straightforward to build; they just haven't been prioritised.

The connector question — live data integration is technically solvable with MCP (Model Context Protocol) servers. The QuickBooks MCP, the Xero MCP, the HubSpot MCP all exist. Wiring them into vault workflows is the next infrastructure move.

The router UX — Anthropic's smb-router pattern (type what you want, get routed to the right workflow) is the right UX for most users. A ThirdBrain BOB equivalent that maps plain English to the right skill chain — across all 11 value chains — is overdue.

The Anthropic plugin is good. It's focused, honest, and well-built for its target customer. If that target customer is you, use it.

If you're running a business in the UAE, Belgium, or anywhere outside the US-QuickBooks-HubSpot stack — or if you need AI assistance across the full business rather than just three functions — the picture is different.

That's the gap ThirdBrain BOB exists to close.

ThirdBrain BOB (Business Operating Brain) is an AI-native business operating system built on Obsidian. It runs locally, works with any AI model, and covers the full business value chain — from lead generation to financial close. Learn more at brn.cx.