BoS OS FAQ

Sections

Getting Started

Why would I use this? What has it actually helped people do?

The honest answer is that it depends on where you are. The people who have got the most out of it were not looking for an AI tool. They were looking for a way to get a grip on something specific.

One founder needed a forcing function. He knew he had to get his company using AI but kept putting it off. The bootstrap gave him a reason to sit down and do it, and something concrete to show the team.

Another needed clarity on a business problem that had been drifting for months. The process of answering the bootstrap’s questions forced him to articulate what was actually wrong. The answer was already there. The BoS OS just made him write it down.

A third had two people on his team running separate systems with different vocabulary, neither of them aware the other had done it. The BoS OS gave them a shared foundation.

None of these are what you might expect from “AI software.” The BoS OS is useful because it makes you think clearly about your own business, and then gives you a system that reflects that thinking back at you.

What do I need to get started?

You need a Claude Pro subscription (not free), the Cowork desktop app, and the skill zip file. That’s it. The BoS OS itself is a folder of text files on your machine. There’s no software to install beyond those three things.

What does "bootstrap" mean? I thought that meant self-funded.

In this context, bootstrap means “build from what’s already publicly known about your company.” The system researches you and creates a first draft of your BoS OS. It has nothing to do with funding status.

I set it up but I didn't connect my folder to the project first. Do I have to start again?

No. But you should always connect your folder to the project before running the bootstrap. If you’ve already run it without the folder connected, the files may not be in the right place. Fix: back up what you have, reconnect the folder, and re-run the bootstrap. It’s additive and won’t delete anything.

How do I install a skill? The zip file structure isn't working.

Skills are installed from the Claude sidebar under “Skills.” The zip file must have the skill folder at the top level, not nested inside another folder. If Claude says it cannot find the skill after installing, unzip the file, check the structure, and re-zip from inside the skill folder rather than from the parent level.

When a readme says “spec a new agent,” the command to type is: run agent spec builder (or the equivalent named command). If the instructions don’t tell you the exact phrase to type, that’s a gap. Ask in the workshop community and we’ll update the docs.

I'm on a Mac / Windows and the setup instructions don't match what I'm seeing.

Mac and Windows paths and tooling differ. If you get stuck on setup steps that don’t match your environment, use the Cowork-only flow. It avoids the command-line entirely. If you’re on Windows and need PowerShell installed, that’s a one-time setup step.

I'm not on Mac and can't use the Cowork desktop app. Can I still use the BoS OS?

Yes, with some friction. The BoS OS is a folder of text files, and Claude Code (the command-line tool) can read and update them on any platform. The Cowork desktop app makes this significantly easier and is strongly recommended where available. If you are on Linux or Windows without Cowork, Claude Code is the path. It works, it just requires a bit more setup. For step-by-step help, ask in the workshop community or reach out to BoS directly at mark@businessofsoftware.org. Someone who has done it will walk you through it.

We have also successfully migrated existing systems to Codecs, which worked well. No guarantees — setups vary — but it is worth trying if that is your environment.

My IT or security team is nervous about Claude. How do we set it up safely?

There are two separate questions here, and they have different answers.

The first is not about the BoS OS at all. It is about whether your company is ready to use AI-enabled tools in general. That is a company policy question your security team is right to ask, and it applies to Claude the same way it applies to any other AI tool. Involve them early, work through your existing policies, and make sure Claude sits within your governance framework before you start.

The second question is about the BoS OS specifically, and the answer is straightforward: the BoS OS is a series of folders and text files that sit on your machine. There is no database, no cloud sync, no background process. You decide which files Claude can see during a session, and when the session ends, it stops. Nothing goes anywhere you have not chosen to put it.

The BoS OS starts from zero trust by design. The bootstrap builds your first version from publicly available information about your company only. Nothing private, nothing internal. You can run a fully functional BoS OS from that point without putting a single confidential document into the system. From there, what you add and when is entirely your call.

One thing worth being deliberate about: how Claude handles data from your sessions is governed by Anthropic’s terms and conditions and your account settings, not the BoS OS. Check those settings before you start and make sure they reflect what your organisation needs. Do not assume the defaults are right for you, and do not rely on anyone else’s summary of the terms, including this one.

The BoS OS exists so that you control your AI, not the other way round. If a step ever feels like it requires you to give up control, that is a signal something has gone wrong.

What happens after the workshop? What comes next?

The workshop is a starting point, not a destination. Once you’ve been through it, there are a few directions depending on where you are.

More workshops — new cohorts run regularly. If you want the peer group and structured accountability again, the next cohort is the natural next step. Dates are at businessofsoftware.org/events.

Focused workshops — as you get further into the OS, there are more targeted sessions for specific challenges: team deployment, advanced mission work, and other topics that go deeper than the intro programme.

Inner Circle — for founders who are running the OS actively and want a closer ongoing relationship with BoS. If you think that’s you, reach out to mark@businessofsoftware.org.

The honest answer is: most people find the workshop opens up more questions than it closes. That’s intentional. The next step is usually whatever you’re most stuck on.

Should I use voice input instead of typing?

If you already use voice-to-text tools, yes. Whisper Flow or Super Whisper work well with the BoS OS because you’re usually explaining a situation rather than issuing precise commands. If you’ve never tried voice-to-text, the setup cost is worth it for AI work in general.

What's an API key, and why does the BoS OS ask for mine?

An API key is a password that lets applications (like BoS OS skills) use Claude on your behalf. The BoS OS asks you to provide your own key because it lets you control costs and protects our systems from unintended usage. If you’re running the BoS OS, it will be running using your Claude credentials automatically. You can generate a key from Anthropic’s console in under two minutes.

Learning the System

What is the BoS OS?

The BoS OS is a series of text files that sit on your machine. That is all it is. There is no software to install beyond the BoS OS tools, no database, no cloud sync, no background process running on your behalf.

The files describe your company: your values, your strategy, your decisions, your constraints, your agents, and your active missions. When you open a session with the BoS OS connected, it reads those files and uses them as context for everything it does. When the session ends, it stops. Nothing persists except the files you chose to update.

This means a few things worth understanding.

You own it entirely. The files are yours. You can read them, edit them, move them, back them up, or delete them. No vendor holds your data. No subscription locks you in.

It starts from zero trust. The bootstrap builds your first version from publicly available information about your company. Nothing private goes in unless you choose to add it. You can run a fully functional BoS OS without ever putting a single confidential document into the system.

It compounds over time. Each session that ends with updated files leaves the BoS OS slightly more informed than before. The decisions you log, the strategies you refine, the agent instructions you improve: these accumulate. The longer you run it, the better it knows your business.

It is not an AI product in the conventional sense. The BoS OS does not do anything on its own. It is the structure that makes AI useful for your specific company, rather than useful in general. The AI is the engine. The BoS OS is what points it at your business.

What's the difference between Bootstrap, Workshop, and Run?

Bootstrap creates, Workshop refines, Run operates.

Bootstrap builds your BoS OS from scratch using publicly available information about your company. It produces your folder structure, strategy document drafts, role stubs for each person on your team, and a CLAUDE.md. You finish with a working foundation in under an hour.

Workshop helps you deepen what Bootstrap produced. It uses your insider knowledge to challenge assumptions, sharpen strategy documents, and turn role stubs into full agent specs — with decision boundaries, escalation triggers, and evaluation criteria. This is where the system starts to reflect how you actually run the business, not just what’s publicly known about it.

Run is the coordination layer for operating the BoS OS day to day. Three agents — Mission Shaper, Agent Planner, Delivery Manager — take a rough idea and turn it into a staffed, running mission. Use Run once Bootstrap and Workshop have done their job.

Use them in sequence. You can’t run a mission well without strategy documents to govern it, and you can’t refine what doesn’t exist yet.

What's the difference between the bootstrap skill and the workshop skill?

Bootstrap creates the initial structure of your BoS OS from public information about your company. The workshop skill then walks you through refining it: adding your real goals, metrics, values, and decisions. Bootstrap first, workshop second. They’re sequential, not interchangeable.

What is the workshop skill actually trying to produce?

Fair criticism of v1: early versions of the workshop skill did not state their goal clearly upfront. Later versions have addressed this. The intended output is: (1) a refined set of BoS OS strategy documents that reflect your actual business rather than the bootstrapped draft, and (2) a first mission with a defined goal, owner, and timeline. If you are running the workshop and those two things are not yet taking shape, ask it directly: “What are we trying to have at the end of this? What does done look like?”

How long does the Workshop take, and how do I know when it's finished?

The Workshop has four phases and typically takes 40–90 minutes if you work through it in one sitting. You can stop between phases and pick it up later — the BoS OS will tell you which phase you were on.

You’ll know it’s finished when Phase 4 closes with an explicit summary of everything produced: what was saved, where it is, and what to do next. If you haven’t seen that closing summary, the Workshop isn’t done yet. If you’re unsure where you are, ask: “Where am I?”

I set up my BoS OS but I'm not sure when I've "finished" the workshop. How do I know when to move on?

The workshop is done when you have two things: strategy documents that reflect how you actually run the business (not just the bootstrapped draft), and at least one mission with a goal, an owner, and a timeline. If either of those is still vague, the workshop has more to do. You can ask it directly: “What are we trying to have at the end of this? What does done look like?” — and it will tell you what’s still open.

What's the difference between group cohorts and one-to-one sessions?

Group cohorts (typically 2–4 sessions over a few weeks) are designed for teams or founders who want peer feedback and community. One-to-one sessions (typically 2–3 sessions, often compressed into fewer days) are for founders who want personalized guidance and faster time-to-working-OS. Both are available; choose based on your learning style and team context. The group format creates peer calibration and accountability; the 1:1 format produces more transformational individual learning moments. Neither length is fixed — what matters is the format, not the duration.

I'm stuck on documentation and don't know how to move forward.

This is a curriculum signal, not a personal one. Many founders set their own perfectionism standard for documentation that prevents them from starting missions. The BoS OS works best when strategy and missions run in parallel — you don’t need perfect docs before starting. Here’s what to do: ask the BoS OS directly whether it has enough information to help you prioritize your activities right now. If the answer is yes, start a mission. You can refine strategy and mission in parallel. The programme has a “good enough to proceed” moment specifically designed for this — you don’t need to wait for perfection.

Is the workshop program going to change for Cohort 2?

Yes. We are constantly iterating and developing the program based on what we learn from each cohort. For details on what’s coming next, check back at businessofsoftware.org/events.

Do I need to bring my whole team into this from day one?

No. Our experience is that one person — ideally the founder — starts the process of building the BoS OS, and you wait until you can see the value it brings you before you bring team members in. Solo first. Once you have a working OS that’s producing value, that’s when showing the team “here’s what I did and here’s what came out of it” lands better than asking them to trust you on the concept. Start alone, prove it to yourself, then invite your team in.

Do I need to build agents straight away?

No. Bootstrap maps your people and your strategy. Agents come later, in the Workshop phase. The bootstrap step formerly called “Create Agent Specifications” confused multiple users into thinking they needed to build AI agents immediately. It doesn’t. At the bootstrap stage you’re mapping who does what in your business — real people, real responsibilities. Full agent specs come once you’ve worked through the Workshop and have strategy documents that reflect your actual business.

I'm already using Claude Code and Claude Cowork. Is the BoS OS worth it for someone who knows what they're doing with AI?

Yes — probably more so. The BoS OS is not a beginners’ tool that becomes redundant once you know what you’re doing. It’s a structure for pointing AI at your specific business instead of using it in general. If you’re already comfortable with AI, you’ll understand faster why the governance layer matters: you’ll have already made the mistakes it protects against — sessions that ended without saving, agents that ran without clear decision boundaries, conversations that produced good thinking you couldn’t find again. The BoS OS doesn’t replace your AI skills. It gives them somewhere to land.

Can I use the BoS OS if I'm a solo operator, not a company with a team?

Yes. The BoS OS works differently for a one-person business — you’re not using it to give a team clarity on what you want, you’re using it to give yourself clarity on what you actually believe about your business, your offer, and your decisions. Some parts of the system (agent delegation, team-facing mission updates) won’t apply yet. But the core — strategy documents, decisions log, missions, the session start routine — is useful regardless of headcount. Several of the early users who got the most value from it were solo founders.

Does the BoS OS have real agents, or are they just scheduled tasks?

When you are not in a session, nothing is running. Claude’s Cowork UI has no persistent background process. What the BoS OS calls “agents” are scheduled prompts: Claude wakes at a set time, reads its instructions and your BoS OS files, does the task, and stops. “Agent” in the BoS OS is a conceptual label for a role with defined decision boundaries, not a technical description of how Claude works underneath. If you are expecting persistent, autonomous agents that monitor things continuously between sessions, that is not the current architecture. What you get instead is structured, bounded, scheduled tasks that run with your context and your constraints. In practice that is more controllable and often more useful than fully autonomous agents, but it is worth understanding the distinction so your expectations match the reality.

Claude keeps forgetting everything. What's the point?

Yes — Claude doesn’t remember anything between conversations. Every new chat is a blank slate. If you’ve been frustrated by this, you’re not doing it wrong. That’s just how it works.

The BoS OS is the solution. Instead of relying on Claude to remember, you give Claude something to read. A set of structured files — built in the workshop — captures what matters about your business: your strategy, your constraints, your decisions, your context. Claude reads those files at the start of every session.

It’s not memory in the way a person remembers. It’s better: it’s written down, it doesn’t drift, and it’s available to every agent working on your behalf, not just the one you’re talking to right now.

What's the difference between using the BoS OS and just using AI as a chatbot?

Most people use AI the way they use a search engine. You type a question, you get an answer, you close the tab. Every conversation starts from scratch. The AI has no idea who you are, what your business does, or what you decided last Tuesday.

That’s fine for one-off questions. It’s not a system.

The BoS OS is what turns AI into a system. It gives Claude the context it needs to work on your behalf — your company’s values, strategy, decisions, processes, the things that make your business yours. That context is written into structured files that Claude reads every time. Instead of re-explaining yourself, Claude already knows.

The work compounds. An agent that helped you think through a pricing decision last month already understands the constraints you were working within.

The workshop teaches you how to build that system for your specific business.

I already use ChatGPT or Claude a lot. Why do I need the BoS OS?

Using ChatGPT or Claude is not the same as using AI. It’s a start — but it’s the equivalent of having a brilliant person available to answer questions, and only ever asking them one question at a time, never telling them anything about your business, and starting the conversation from scratch every day.

The BoS OS is the bigger thing. It’s the layer that turns a capable AI model into something that actually understands your business — your strategy, your decisions, your constraints, the things that took you years to figure out. That knowledge gets encoded once and is available every time an agent works on your behalf. The second task is better than the first. The tenth is better than the second.

Here’s what makes this a genuine opportunity: you’ve already done the hard part. You have a real business, with real knowledge, real processes, and real judgment built up over years. Most AI tools are aimed at people starting from zero. The BoS OS is built for people who already have something — and want to put it to work.

For founders with established businesses, this is one of the most significant arbitrage opportunities in the last twenty years. The tools exist. The window is open. Most of your competitors are still using AI as a chatbot.

Is this just a fancy way of using ChatGPT?

No. ChatGPT (or Claude without this system) is a general-purpose AI with no memory of your company and no constraints on what it does. The BoS OS gives Claude persistent context about your specific business: your values, strategy, decisions, constraints. It operates as a knowledgeable colleague rather than a blank-slate chatbot. The files are the thing, not the AI.

What does "the antidote to ad hoc AI adoption" mean?

Most companies use AI reactively. Someone finds a useful tool, others copy them, nobody coordinates. This produces duplication, inconsistency, and AI that does not actually know the business. The BoS OS is the structured alternative: AI that runs on the same values, strategy, and constraints that govern everything else in your company.

What does "top-down vs bottom-up" mean? I keep hearing this.

Bottom-up means starting with a specific tool, task, or problem: “I need a content calendar,” “I need to filter these search results,” “I need to sort out our transcript process.” Top-down means starting with the outcome and letting the system figure out how to get there: “I want newsletter subscribers to grow, what does our content system need to do?” or “I want to understand what’s actually driving trial conversions.”

The BoS OS gets dramatically more useful when you work top-down. When you start with the solution, you constrain what it can suggest. When you start with the goal, it can draw on everything it knows about your business and propose approaches you wouldn’t have thought of. A useful test: if you can describe what the output should look like before you’ve asked the question, you’re probably being too specific. Try opening it up.

In the bootstrap process, the BoS OS keeps asking me to confirm things that feel obvious. Why does it need me to verify basic information?

The BoS OS is calibrating against what it can verify from public sources. Anything it can’t confirm from public data, it asks you about — even if it feels obvious to you. This is intentional: the system would rather ask and be certain than assume and get it wrong. Once you’ve confirmed something, it remembers it and won’t ask again. Probably. Even the best AI can forget things.

The BoS OS is suggesting I do extra work to set up an agent. I thought this was supposed to save me time.

If the BoS OS is asking you to do work to set something up, that’s usually a one-time cost for a recurring benefit. Example: entering the email address for exception logging takes five minutes; not having to personally route every exception afterwards saves hours. The BoS OS shouldn’t increase your ongoing workload — if it feels like it is, push back and ask it to find an approach that requires less from you. It will try to find one.

There’s also a deeper principle at work: when the BoS OS identifies a problem or a symptom, it tries to solve it by making the overall system a little better, not just fixing the immediate issue. What’s remarkable about this type of system is that fixing the root cause often takes no more time than fixing the individual instance — and unlike fixing the individual instance, it compounds. The BoS OS is building a better process, not just answering your question.

Why does the BoS OS produce better answers than just asking Claude directly?

Because Claude’s accuracy is primarily a context problem, not a capability problem.

When you ask bare Claude a question, it searches across everything it knows, which might include dozens of plausible-but-conflicting answers to your question. The more ambiguous your business context, the more likely it picks the wrong one, confidently.

The BoS OS narrows that space down to a single governed answer. When you have one clear values document, one strategy for a given area, one definition of your ICP, the BoS OS doesn’t have to guess which one to use. It uses yours. The output is more reliable not because the AI got smarter, but because you removed the ambiguity it would otherwise have to resolve on its own.

This is also why letting the BoS OS go stale matters more than it looks. If your strategy documents haven’t been updated in three months, the BoS OS is still working from a three-month-old version of your business. The AI doesn’t flag that. It just uses what’s there. Keeping the files current is not housekeeping. It is the main thing that keeps outputs accurate.

Using the BoS OS Day to Day

Why doesn't the BoS OS automatically update my files when I accept a suggestion?

This is a deliberate design choice in the BoS OS, not a limitation of Claude. The BoS OS requires explicit instruction before writing to any file. If you ask a question, read the answer, and close the session without telling it to write anything, nothing is saved. This is intentional: the BoS OS should never change your files without your say-so.

To make a suggestion stick, tell it: “Good, update the relevant documents with this.” Claude will then propose the specific changes, which you approve before anything is written. This is the single most common reason new users do not see the BoS OS improving over time: the conversation was good, but the instruction to write was never given.

Should I keep my conversations going, or start new ones? And do I need to close old sessions?

Start fresh conversations for new topics. Long threads slow Claude down because it re-reads the entire thread on every message. That is Claude’s behaviour, not something the BoS OS controls. End each session, archive the thread, and start fresh next time. Starting fresh does not mean starting from scratch: Claude builds a summary of your work over time, so it retains context across conversations on paid plans.

The BoS OS-specific reason to close sessions properly: if a session discussed changes to your OS files that were never written, those changes do not exist. If you then start a new session, the BoS OS will not have them. The most common source of confusion about setup is sessions that ended without the write step. Go through open threads, complete any pending file updates, and archive them before your next session.

What happens when a session compacts? Will I lose my work?

Every conversation with the BoS OS runs inside a fixed amount of working memory. Think of it as a whiteboard. As the session goes on, the whiteboard fills up: files read, drafts written, decisions made, back-and-forth conversation.

When the whiteboard is almost full, Claude compacts — replacing the detailed transcript with a compressed summary. The summary captures the broad shape of what happened. The detail is gone. The user doesn’t see this happen. There’s no warning, no countdown, no pause. The conversation continues — and Claude is now working from a summary of a summary.

What am I in danger of losing?

It’s generally best to end your session once a compaction has happened, then open a new session — you’ll start from where you left off based on the session files.

The nuance behind decisions is what compaction strips most. It preserves what was decided, not the full reasoning, the options considered, the exact wording that was agreed, or the back-and-forth that led there. If you spent time getting a sentence exactly right and it was never written to a file, compaction may paraphrase it into something close but not quite what you agreed.

What am I NOT in danger of losing?

Anything saved to disk survives compaction completely — files in 00_LOCAL_CONTEXT/, 05_ARTIFACTS/, the session summary in 01_STATE/session_summary.md, mission state files, the decisions log.

How do I protect against it?

The most reliable protection: save often, not just at session end. Ask Claude to save drafts to 00_LOCAL_CONTEXT/ as they’re produced. A draft saved to disk and then improved is much safer than one that exists only in the thread.

Watch for the 20-tool-call checkpoint. The BoS OS is configured to pause and save all in-context drafts when a session reaches 20 tool calls. If Claude doesn’t do this, prompt it: “Is there anything unsaved?”

At any natural break, ask: “Is there anything in this session that isn’t saved to disk?” If the answer is yes, save before continuing.

What should I do if compaction has already happened?

Check 00_LOCAL_CONTEXT/ first — everything saved to disk is recoverable. Then read 01_STATE/session_summary.md for the broad picture and 01_STATE/sessions/YYYY-MM-DD.md for the full record of any properly closed session. If a draft is genuinely lost, re-produce it in a new session — session summary plus mission state files reconstruct the picture in under a minute.

The safest assumption: if Claude produced it and it’s not on disk, it can disappear. The BoS OS is designed around files, not threads.

How much does it matter how often I use the BoS OS?

More than most people expect. The BoS OS compounds through use — each session that ends with updated files leaves the system slightly more informed about your business than before. A founder who opens a session every day, even briefly, builds a system that reflects current reality. One who opens it once a week accumulates drift.

The “set it and forget it” expectation is common and wrong. The BoS OS is not a tool you deploy once. It is more like a management habit: the value comes from the consistent daily attention, not from the setup. Founders who treat it as part of their daily rhythm — checking the briefing, logging a decision, updating a mission file — get compounding returns. Founders who return to it monthly find they are re-explaining context every time.

If you are not yet in the daily habit, start small. Open a session. Read your briefing. Update one file. Close it properly. Do that every working day for a month, and the BoS OS will know your business meaningfully better than it did when you started.

What's the difference between Opus and Sonnet? Which one should I use?

These are Claude models, not BoS OS features. Opus is more capable and more expensive. Use it for strategic work, bootstrapping, and complex reasoning. Sonnet is faster and cheaper. Use it for everyday tasks like drafting content, reviewing documents, and routine agent work. Practical tip: do your heavy lifting in the morning before US usage drives token costs up after around 1pm UK time.

Can I switch models (Opus / Sonnet) mid-conversation?

No. This is a Claude limitation: once you start a thread, the model is fixed for that thread. If you realise halfway through that you want a more capable model, you need to start a new conversation. Decide your model before you start, not after. For strategic work and bootstrapping, start with Opus. For routine tasks, Sonnet is fine and uses fewer tokens. Think of it as choosing the right tool before you pick up the job, not after.

How much of my Claude Pro subscription does running the BoS OS use up?

Our aim is to help you build an efficient system, not a system that token-maxes. This is because we are not idiots. The value of AI is not how many tokens you use. The value of AI is what it does for you.

The bootstrap process will typically use less than 10% of your token allowance in any session. As you use the BoS OS more on a day-to-day basis, you may find you create more activity that uses more tokens — but that’s up to you.

A standard Claude Pro subscription handles the full BoS OS workflow. Resist the temptation to upgrade before you’ve genuinely needed to — the constraint is doing something useful. When you have unlimited capacity, you get lazy about what you ask. You throw broad problems at the system and hope something sticks. You don’t develop judgment about what Claude is actually good at, what it needs to do well, or where humans should stay in control. Programmers in Soviet Russia were, by legend, exceptional — not despite the terrible hardware they worked on, but because of it. Every instruction had to count. The same logic applies here: scarcity forces craft.

Before going to a higher tier, I’d recommend buying extra credits at your existing tier first — so that when you’ve genuinely hit a limit on a task that matters, you can continue. The principal reason is this: the constraint encourages good habits and behaviours and helps you understand how the system works. Saving money and energy are also useful benefits, of course.

Is my Claude session slower because someone else on the team is using it at the same time?

No. Claude sessions are independent — one person’s usage doesn’t affect another’s speed. If Claude feels slow, it’s usually the task complexity, your machine’s resources (especially if video is also processing), or network speed. Claude does run multiple operations in parallel within a session, which can make some tasks appear to queue — but that’s within your session, not across users.

Why can't I find that conversation I had earlier? Did it get deleted?

Archived conversations aren’t deleted. Go to “View All” on the left sidebar to find archived threads. To move one back into a project, use the three-dot menu on the thread.

What do the blue and grey conversations on the left sidebar mean?

Blue means there are unread updates in that thread. Claude wrote something you haven’t seen yet. Grey means you’ve read everything in it. It has nothing to do with whether the session is open, closed, or active.

Can I use the BoS OS without the community?

Yes, absolutely. The BoS OS is a powerful standalone tool that works whether or not you’re part of the community. Community membership is optional and adds peer learning value — but the operating system itself stands alone. You can build a fully functional BoS OS for your company with just the tool, the bootstrap process, and your own team. The community workshops and peer networks are optional add-ons, not prerequisites.

Why does Claude finish a task in 30 minutes when I told it to "work for three hours"?

Claude doesn’t experience time. “Work for three hours” means nothing to it. It works until the task is complete or it hits a context or tool limit, however long that takes. For large tasks, break them into explicit phases with defined outputs rather than giving a time budget. If you want Claude to do more, give it more things to do in sequence, not more time.

Can I branch a conversation and come back to the original thread?

Branching isn’t currently available in Cowork. The practical workaround: start a new conversation in the same project for the side topic, then return to the original thread when you’re ready. Both threads share the same project file context, so there’s no loss of background knowledge about your business. Only the specific conversation history differs.

The BoS OS warned me my thread is getting long. What should I do?

This is a feature, not a problem. The BoS OS monitors session length and warns you proactively — before compaction silently strips detail from your session. When you see this warning, your options are: (1) ask Claude to save all in-progress drafts to 00_LOCAL_CONTEXT/ now, then start a new thread; or (2) ask Claude to produce a summary of decisions and current state, which you paste into a fresh session as the opening prompt. Either way, nothing saved to disk is at risk. The warning exists so you can act before information is lost, not after.

Why does the AI seem to have forgotten something I told it earlier in the same session?

This is context compression happening silently. Every conversation runs inside a fixed memory limit. When that limit fills up, the AI compresses older content — quietly, without warning, without telling you. What you told it in message 5 may no longer be in full detail by message 50. The compression keeps the broad shape of the conversation but loses specifics: exact wording, nuances, constraints stated early on. The fix is not to repeat yourself — it’s to save important decisions and instructions to disk as they’re agreed, so they’re in the files Claude reads rather than in the thread Claude is compressing.

My AI keeps repeating mistakes I already corrected. Why?

This is a classic sign the thread has gotten too long. When a thread compresses, corrections made early in the session are among the first things to lose detail. The AI isn’t ignoring you — it genuinely no longer has the full correction in view. Two fixes: for the immediate session, restate the correction; for the longer term, log the correction to your agent spec or strategy documents so it’s in the files Claude reads at startup, not just in the thread.

When should I start a new thread instead of continuing one?

Four situations call for a fresh thread: (1) you’re switching to a genuinely different type of task — don’t carry marketing work context into a mission planning session; (2) Claude seems confused, slow, or is repeating mistakes you already corrected — that’s a thread-too-long signal; (3) the BoS OS warned you the thread is getting long; (4) you want to test an alternative approach without risking the working state in your current thread. Starting fresh does not mean starting from scratch — the session summary and project files carry your context across.

How do I know when a thread has gotten too long?

Four signals to watch for: responses are noticeably slower than usual; Claude raises constraints or errors you already resolved earlier in the session; formatting rules or instructions you set at the start have quietly stopped being followed; the BoS OS displays a long-thread warning. If you’re seeing any of these, save everything to disk and start a new thread. The sooner you act, the less you have to reconstruct.

How do I carry my work into a new thread without losing progress?

Three steps: first, before leaving the old thread, ask Claude to write a “current state” summary to 00_LOCAL_CONTEXT/ — what was decided, what’s in progress, what’s next. Second, copy only the latest working version of any draft you’re iterating on, not the entire back-and-forth. Third, open a new thread and paste the summary as your opening prompt. The new thread picks up where the old one left off. You’re leaving the conversation history behind; you’re not leaving the work behind.

Can I test a new idea without ruining what's already working?

Yes. Start a new thread in the same project, paste your current working context as the opening prompt, and try the alternative from there. If it fails, the original thread is untouched and you can return to it. This also lets you compare approaches directly — run the same prompt in two threads with slightly different framings and see which produces the better result. The project files are shared across both threads, so your BoS OS context is available in either.

Does starting a new thread mean I lose everything?

No. The conversation history stays in your project and can be found under “View All” in the sidebar. More importantly, the work itself — decisions, drafts, strategy updates — lives in your BoS OS files, not in the thread. The BoS OS is designed around files, not threads: anything saved to disk survives perfectly. What a new thread does is reset the live conversation context, which is usually what you want when a thread is getting long. Think of it as closing one whiteboard and opening a fresh one, while keeping all the notes you decided were worth keeping.

Is Claude making things up? I asked it about a company and it invented details.

Yes. This is Claude’s behaviour, not the BoS OS. Claude can state things confidently that are not true. This is why the BoS OS is built around grounding Claude in your own documents: when it works from files you have written and approved, the output is verifiable. When it works from general recall, it can be wrong. For research tasks about external companies or people, always ask for sources and verify key claims independently.

Why does my bootstrapped CLAUDE.md tell the agent to "surface issues to the CEO" — can it actually do that?

No. When the bootstrap creates your CLAUDE.md, it fills in escalation sections using judgment. The phrase “pause and surface to the CEO” sounds like sensible governance but describes something the agent cannot do. An agent can only communicate with the person it is currently talking to. It has no mechanism to contact anyone else unless you have explicitly wired up a connector (for example, a Slack or WhatsApp notification via Zapier).

The correct escalation behaviour for any agent is: stop work, tell the person in the current session, and wait for explicit human authorisation before continuing. If you want alerts to go to a specific person who isn’t in the session, that requires a connector.

If you see this language in your CLAUDE.md or agent specs, replace it with: “If you encounter a hard constraint violation, stop work, tell the person you are talking to, and do not proceed until a human explicitly authorises the next step.”

The bootstrap skill has been updated to generate accurate escalation language.

The BoS OS made a statement that was clearly wrong. Is it broken?

Maybe not. The BoS OS draws inferences from the data it can see, and those conclusions are only as good as the data and the instructions it has.

It is incredibly important to remember that you, a human, are in charge of any AI output. You are responsible for thinking critically when the BoS OS suggests something that seems wrong. Ask it again. And more importantly, try to understand why it came to that conclusion — because it is often because the information within the system is incorrect.

Here’s a real example. The BoS OS stated confidently that pricing was, by far, the single topic of most interest to our audience. I knew this wasn’t true from the numerous interactions I’ve had with attendees over the years. So I interrogated the conclusion. The explanation turned out to be simple: we had uploaded some historical data about downloads of guides from our website. Neil Davidson’s Guide to Software Pricing has been downloaded tens of thousands of times over 15 years. The other guides had been available for four weeks. The BoS OS wasn’t broken. It was working with the data it had been given, and no one had told it to account for age.

Human responsibility doesn’t stop at spotting that something is wrong. It means interrogating the output, understanding how it happened, and using those edge cases to build a better system. In this case: the fix was simple. Now the system knows to ask about the age and context of any data before drawing conclusions from volume alone.

Your Files and Folders

What is an MD file? I keep seeing files that end in .md.

MD stands for Markdown. It’s a plain text file with light formatting: asterisks for bold, hash symbols for headings, hyphens for bullet points. The BoS OS stores almost everything in MD files — your strategy documents, your agent specs, your decisions, your missions. They open in any text editor and are readable without any special software.

You don’t need to know Markdown to use the BoS OS. Claude reads and writes them on your behalf. But it helps to know that when you see a .md file, it’s just a text document. Nothing technical is happening inside it.

What is an artifact?

An artifact is a finished deliverable — something the BoS OS produced that is ready to use, share, or publish. This includes approved documents, reports, campaign briefs, talk harvests, insight briefs, and templates. Artifacts live in the 05_ARTIFACTS/ folder. They are distinct from working drafts, which live in 00_LOCAL_CONTEXT/ until they have been reviewed and approved.

The simple rule: if it is still being worked on, it is a draft. If it has been approved and is ready to use, it is an artifact.

What are RFCs? Why does it keep calling things "RFC-001"?

RFC stands for “Request for Comments,” an engineering term for a working document. In the BoS OS, RFCs are strategy documents describing one operational area of your business (e.g., marketing, sales, values). Newer versions of the BoS OS rename these to plain English (e.g., “Values and Culture,” “Brand and Messaging”) to remove the jargon.

What's a CLAUDE.md file and why does it matter?

CLAUDE.md is the rules file that every session reads at startup. It’s your company’s constitution. It tells the BoS OS who you are, what constraints it must follow, and what it should always do and never do. Everything in the BoS OS sits on top of this foundation. Getting it right is the most important single step.

Why doesn't the BoS OS work properly with Google Drive on Windows?

Google Drive on Windows creates a virtual drive using symlinks rather than real local files. Claude cannot reliably follow these links to reach the actual file contents, even when files appear to be synced locally. This is a Claude/Cowork limitation rather than a BoS OS design issue, and it is expected to improve over time.

For now, the reliable workaround is Dropbox with “make available offline” turned on for your BoS OS folder. Dropbox writes real files to your local drive and Claude can read them without issue. For team sharing with access control, GitHub with GitHub Desktop is the robust long-term solution. Google Drive may work in future versions of Cowork, but as of June 2026 it is not reliable on Windows.

Should I use a skill or just a markdown file for my agents?

For most purposes, a markdown file works just as well as a skill and is easier to maintain. Skills are useful when you want to package and distribute something to others. For things you are building and iterating on inside your own BoS OS — agents, retrospectives, custom workflows — keep them as markdown files. The overhead of skill packaging rarely adds value until something is stable and ready to share widely.

One practical note: skill installation procedures can change between Cowork versions, which adds maintenance friction. A markdown file stays consistent across versions.

How do I share my BoS OS with my team?

Everything sits in one folder and you can isolate it from the rest of your network. For now, the focus is getting the OS running — when you’re ready to involve your team, you’ll need to think about who gets access to what.

The BoS OS has a structure for this: the 00_LOCAL_CONTEXT/ folder is private to you and never shared. Everything else — strategy documents, agent specs, mission files, approved deliverables — can go in a shared folder your team accesses via Dropbox or GitHub. You decide what goes where.

A dedicated team setup guide is in development. Until then, the practical starting point: get your own OS working well first. Bring people in once it reflects reality.

Can I use Google Drive, Dropbox, or GitHub to share the OS with my team? What should I keep private?

The BoS OS has two folder tiers by design: a private folder for anything confidential (financials, personnel notes, sensitive client information) that stays on your machine, and a shared folder for the strategy documents, agent specs, and deliverables you choose to make accessible to your team. Not everything needs to go in the shared folder. Some strategy documents may stay private, depending on what you are comfortable sharing. You decide what goes where.

For sharing the team folder: Dropbox works well and is what BoS uses internally, and it is the simplest option for non-technical teams. GitHub with GitHub Desktop as a simpler interface is the robust long-term solution, giving you version control, access permissions, and the ability to review changes before they go in. Google Drive has known compatibility limitations with Claude on Windows. Even files set to “available offline” can be unreadable. Start with Dropbox and move to Git when the team is ready.

One thing to be aware of regardless of which tool you use: Claude cannot index files on a remote shared drive. The folder needs to be connected locally on each person’s machine.

Can I use Obsidian as a front-end for managing my BoS OS files?

Yes. Obsidian works well as a file browser and editor for your BoS OS. It renders markdown cleanly and has a GitHub plugin that simplifies staging and committing changes — useful for non-technical users who want version control without learning Git commands.

One clarification: this is not Obsidian Sync or an Obsidian Vault. You are using Obsidian purely as a local file manager, with your BoS OS files stored as regular markdown files that Claude also reads. Obsidian is a view onto your files; it does not replace or conflict with the BoS OS.

My cloud sync tool is conflicting with my OS files. What do I do?

Conflicts between cloud sync tools and the BoS OS are a known friction point across platforms. When a sync tool is actively managing the same files Claude is writing to, you can get conflicts, read errors, or files that appear to update but don’t. This is largely a platform limitation rather than something the BoS OS can solve, but it is improving as these tools mature. The minimum viable setup that avoids most of these issues: keep your private BoS OS folder on a plain local path outside any sync boundary, and share only the team folder via a sync tool. Dropbox tends to behave most reliably in practice. For team sharing at scale, Git (with GitHub Desktop as a simpler interface) is the robust long-term answer. If you are on a corporate device with enforced sync policies, talk to IT about creating an exclusion for the BoS OS folder path.

Should I keep company knowledge inside my OS strategy documents, or build a separate knowledge base?

Start by putting knowledge into the BoS OS. Every piece of information you add enriches the system. The more context the BoS OS has about your business, the better it gets at helping you think and act. This is how the BoS OS compounds over time: not by completing individual tasks, but by accumulating a richer picture of your business that makes every future task more useful. The practical limit comes later, when you are running at scale: if you try to embed your entire competitive intelligence library, your full CRM history, and every meeting note, you will eventually hit context limits and the system will become slower and less focused. When that happens, the right move is to externalise raw data to a knowledge base and let the BoS OS point to it, keeping the distilled judgment (decisions, strategy, agent instructions) inside the BoS OS and the supporting detail outside. For now, lean toward putting things in. The compounding value of a richer BoS OS outweighs the theoretical future cost of tidying it up.

If I update the bootstrap skill, will it overwrite everything I've already done?

No. The bootstrap is additive. It adds to what’s there; it does not replace it. Back up your BoS OS folder before running a new version, just in case.

We have good discussions on Discord/Slack. How do we get those into the BoS OS?

You can connect Slack or Discord directly through Claude, which gives the BoS OS read access to your channels and lets it scan for signals — decisions, action items, hypotheses — and feed them in automatically. WhatsApp integration is more limited but partial interaction is possible via Zapier. For a lighter-touch approach, export your channel history and run it through the transcript processing flow. Key principle regardless of method: any decision worth keeping should make it into the BoS OS within 24 hours, or it probably won’t happen.

Getting Value

The BoS OS gave me a number, a recommendation, or a plan. Should I just go with it?

Think of everything the BoS OS produces as a suggestion, not an option. When someone gives you four options to choose from, you feel obliged to pick one. A suggestion is different. You can take it, ignore it, or go in a completely different direction. That is the right relationship to have with BoS OS outputs.

This matters most when the BoS OS produces something that looks precise but is not grounded in data. Ask it for a target and it will give you one. Ask it if the target is “more realistic” and it will give you a lower one, because to an LLM, “more realistic” reads as “the number is too high, bring it down.” It is not exercising judgment. It is pattern-matching on your phrasing. Neither number means anything without a baseline. The BoS OS is responsive, not automatically cautious about its own uncertainty, so you have to be.

When the BoS OS gives you a number or a recommendation, the question to ask is: what data would actually inform this? Go and get some of that before you act. A target set against a known baseline is worth ten times a target set against nothing.

The BoS OS is a thinking tool. It is at its best when you push back on it, not when you accept the first thing it says.

How reliable is the output? When should I act on it and when should I check it?

This is one of the most important questions to answer before you rely on the BoS OS for anything consequential.

The AI at the core of the BoS OS is probabilistic, not deterministic. Traditional software gives the same output every time for the same input. AI gives an output within a range. It can vary, and it can be wrong, sometimes confidently. This is not a bug to work around. It is the nature of how these systems work.

In practice, think in three zones.

High confidence, act on it: formatting, summarising, restructuring content you have provided, drafting from a clear brief. The output is reliable here because you can verify it against the source material.

Calibration required, challenge it: analysis, strategy, interpretation, research about external companies or people. The output may be directionally right but factually wrong on specifics. Always ask for sources on factual claims. Treat strategic analysis as a starting point, not a conclusion.

Always verify before acting: anything with external consequences such as commitments, communications, financial figures, legal or regulatory claims. The system can state things with complete confidence that are not true. If you would be embarrassed if the output turned out to be wrong, verify it independently before acting.

The BoS OS governance model, specifically the decision cascade and the rule that nothing goes external without human approval, is the practical answer to this question built into the system. Governance is not bureaucracy. It is how you manage the gap between what the system produces and what you can safely rely on.

I never seem to find time to sit down with the BoS OS. What should I do?

The two-hour block framing is the problem, not your schedule. The BoS OS works best when it’s part of how you already work — open it when you encounter something worth logging, ask it a question when you’re stuck, update a file when a decision is made. The goal is workflow integration, not scheduled blocks.

Start with five minutes: one question, one file updated, one decision logged. The value compounds from daily contact, not from marathon sessions. If the BoS OS feels like something you have to find time for, it hasn’t yet become part of how you work. That’s the thing to fix — not your calendar.

I'm not sure where to start or what to focus on first.

Start with two things: your CLAUDE.md (the rules file) and one strategy document covering the area where you most want AI to help. Do not try to build the whole BoS OS at once. Get one area working well, then add more.

What makes a good mission? Mine scored badly when I ran the evaluation.

A mission is not a parking lot for ideas. If you have written something like “explore how AI could help with marketing” or “think about our hiring process,” that is a topic, not a mission. A well-formed mission has: a specific outcome you can describe, an owner, a timeline, and a clear definition of done. The evaluation scores poorly when those elements are missing because the agents have nothing concrete to act on. The fix is not to delete the idea. Ask instead: what specifically would we do, by when, and how would we know it worked? If you cannot answer those three questions, the mission is not ready yet.

What's the difference between an activity and an outcome? Why does it matter for missions?

An activity is something you do: “publish talks,” “write emails,” “run the keyword monitor.” An outcome is what changes as a result: “newsletter subscribers up 20%,” “trial-to-paid conversion improves,” “two qualified prospects engage per week.”

Missions need outcomes, not activities. Agents can only build feedback loops around things that can be measured. If your mission says “do X,” you’ll never know whether X worked. If it says “achieve Y,” you can check, iterate, and improve.

When you write a mission, ask yourself: “how would I know in four weeks whether this succeeded?” If you can’t answer that with a number or a clear observable state, the mission isn’t ready. The Mission Planner will catch some of this, but the activity/outcome distinction is one you need to apply yourself.

I've been through the workshop but still don't know what my mission should be.

Start with the press release. Describe, in two sentences, what success looks like six weeks from now, as if writing a headline for it. Then work backward: what would have to be true for that headline to be real? That’s your mission scope. If you can’t write the press release, the mission is still too vague to execute. That’s useful to know.

My Mission Planner didn't push back on measurability. Is that a bug?

Not a bug, but a known gap. The current Mission Planner focuses on scoping and phasing. It will catch many weak missions, but it doesn’t yet consistently challenge you on whether the mission is outcome-oriented and measurable. If your mission feels like a to-do list rather than a business objective, ask the Mission Planner directly: “Is this mission outcome-oriented and measurable? What would a more ambitious version of this goal look like?” That usually surfaces the gap. A more proactive challenge on measurability is planned for a future skill update.

The output doesn't sound like us. It sounds too generic.

This means the BoS OS does not yet have enough of your company’s voice in it. When the output sounds wrong, tell it specifically what is off and ask it to update the relevant strategy document or voice guidelines. Over time, as you give feedback and the documents improve, outputs get more specific to you.

What's the "one number I should be watching"? What's a north star metric?

The bootstrap asks this to anchor the BoS OS on what actually matters to your business. Do not overthink it. It is whatever number, if it went up, would tell you the business is heading in the right direction. Revenue, MRR, trial conversions, demo bookings: whatever you actually check first on a Monday morning.

How do I introduce the BoS OS to my team without making it an "AI project"?

Start with the problem, not the system. Your team does not need to understand the BoS OS to benefit from it. Pick one workflow that is currently manual, inconsistent, or friction-heavy, and show how the BoS OS makes it faster and better. Let the result speak before explaining the architecture.

When you do explain it, frame it as “a better way to run the business” rather than “an AI initiative.” People tend to lean into things that make their work easier and clearer. They tend to be suspicious of things that feel like a technology rollout.

A few things that help: make sure your own BoS OS is working well before you involve anyone else — you cannot teach what you have not done yourself. Bring people in to help solve a specific piece of the puzzle they already own. And give them a simple starting point (a module, a single workflow) rather than the whole system at once.

Note: A dedicated team adoption module (Module S) is in development based on Cohort 1 feedback.

Someone told me not to tell my team it's an "AI project." Why?

Because “AI project” lands differently in a team than “I’ve been figuring out how to write down the things that only exist in my head.” Both are true descriptions of the BoS OS. The second one is the one your team has been waiting to hear. Once they see that the BoS OS gives them more clarity on what you want, who’s blocking who, and what the actual priorities are — the fact that it runs on Claude becomes a minor detail. Start there. Let them experience it first.

How do I get my team to actually use this?

Start by building it yourself. Get the bootstrap done, run the workshop, complete at least one mission that produces something genuinely useful. Then bring people in to help solve specific pieces of the puzzle, not to join an AI project, but to help make the business better, clearer, and easier to work in.

That framing matters. If you present this as “we’re adopting AI,” you will get mixed reactions. If you present it as “here’s something that makes our strategy clearer and our decisions easier to find,” people lean in. The BoS OS is a tool for running the business better. Lead with that, and team adoption follows naturally.

I built a workflow but it still has a manual step. How do I remove it?

Ask the BoS OS, but frame the question at the level of the whole system, not just the one step. Rather than “how do I automate this paste,” try: “Here is my full workflow. I want it to run without any manual steps. What needs to change, and what are my options?” The BoS OS knows your connected platforms and your constraints. When you give it the whole picture, it can suggest a better approach. Sometimes the manual step is a symptom of a broader design issue rather than just a missing integration. The habit to build: whenever something feels like friction, describe the outcome you want and ask the BoS OS how the system could deliver it. That question is almost always more useful than trying to fix the specific step yourself.

I want multiple co-founders or team members to work on the same problem. How do we share context?

There’s no live shared-session feature yet, but there’s a practical workaround. When you’ve been working through an idea and want teammates to build on it, ask the BoS OS to write a “current working thinking” summary to a file in your shared BoS OS folder (e.g., 00_LOCAL_CONTEXT/thinking_on_[topic].md). Anyone on the team can open that file, continue in their own session, and write back. It’s asynchronous rather than live, but the shared folder keeps the thinking accessible and compounding.

This is an area being actively developed. Expect better support for team collaboration in future BoS OS versions.

I tried to filter noise from my agent's results at the tool level, but it's not working well. What should I do instead?

Don’t try to solve filtering inside the external tool (e.g., negative keywords in an API search config). Instead, give the BoS OS the raw results and tell it directly what’s irrelevant and why: “anything related to games or game development is noise for my use case.” The BoS OS learns your filtering criteria across sessions and gets better at qualification over time. The external tool does the broad search; the BoS OS does the judgment. Trying to pre-filter at the API level removes the BoS OS’s ability to learn your specific criteria, and most APIs can’t handle the nuance you actually need anyway.

Strategy, Content and Marketing

Where does the content in my marketing signals document come from?

Marketing signals are extracted from conversation transcripts — workshops, discovery calls, demos, and team catch-ups — that have been processed by the Insight Brief pipeline. Each signal traces back to a specific conversation. The document is a draft until Mark approves it; once approved, the signals update the relevant strategy documents. If you’re unsure where a specific signal came from, you can ask the BoS OS to show you the source file.

When you're faced with a large list or too many ideas, how do you prioritise?

The system is designed to surface signals, not decisions. When you’re faced with a large list, ask the BoS OS to rank them by relevance to a specific goal — “which of these are most useful for our next email campaign” will get a better answer than “show me everything.” You’re looking for the signal, not the volume. If a list feels overwhelming, that’s usually a sign the question was too broad.

What's the point of the funnel map, and when would I use it?

A funnel map is a visual representation of how activity flows through a system, from input to output, stage by stage. In the BoS OS, it helps you see where leads or content enter, what happens at each stage, and where things drop off.

It is most useful when planning missions around growth or marketing. Rather than assuming you need to improve the whole system, a funnel map lets you ask: which stage are we actually trying to fix? A mission aimed at the wrong stage will produce effort without results.

If you ask the BoS OS to show you your funnel map, it will generate one from the strategy and mission documents in your BoS OS. If the output looks wrong (stages missing or in the wrong sequence), that usually means the relevant strategy documents do not yet describe your actual funnel clearly. Use that as a prompt to improve those documents rather than correcting the map directly.

How does the BoS OS help with preparing a business for sale?

The BoS OS systematically documents how your company actually works: your values, strategy, decisions, and the operating processes your agents run. This creates a verifiable record that the business is manageable without the founder — which is one of the core criteria buyers use to assess value and reduce acquisition risk.

When everything the business does is documented in structured files, it demonstrates that operations are not locked inside the founder’s head. A buyer or investor can review the BoS OS and see exactly what the business does, how decisions get made, and what the operating model looks like. That transparency reduces the risk premium and supports valuation.

This is not a primary reason to build the BoS OS — it is a consequence of running it well. But for founders who expect to sell within the next few years, systematising via the BoS OS now also prepares the business for due diligence.

What's the difference between a general agent and a specific agent — and which should I use?

After the bootstrap, your BoS OS contains two quite different kinds of agents.

General agents (like ceo_agent) are scaffolding generated during the bootstrap. They describe a broad role with a range of capabilities. In practice, most participants find they use these rarely or not at all. A general agent trying to cover everything a CEO does tends to produce mediocre output across the board — the context is split across too many possible tasks, and there is no clear success criterion for any of them.

Specific agents are created through the Mission Planner when you are designing a particular mission. They have a narrow scope, well-defined inputs, clear outputs, and an explicit feedback loop. These are the agents participants actually get value from.

The practical recommendation: treat bootstrap-generated general agents as placeholders that tell you what roles might eventually exist in your OS. Do not invest time in them until you have run several specific missions and can see a genuine recurring pattern — for example, “I always need a research step” or “I always need an editor reviewing before anything goes out.” At that point, a reusable general agent for that role is worth building — one shaped by real missions, not designed in the abstract.

The progression that works: specific agents first, accumulate experience, then consider general agents when the pattern is clear.

Understanding the Concepts

What is a "context window" and why does it matter?

Every AI conversation runs inside a fixed amount of working memory called the context window. Think of it as a whiteboard. Everything in the session goes onto it: files Claude reads, drafts it produces, your back-and-forth conversation. When the whiteboard fills up, the AI compresses older content to make room — silently, without warning. The compressed version keeps the broad shape of what happened but loses specifics: exact wording, early constraints, nuances from the beginning of the session.

This is not a bug. It’s how all current AI models work. The BoS OS is designed around it: anything worth keeping should be saved to disk, not left in the thread. Files survive compaction perfectly. Conversation history does not.

The practical rule: treat the context window as working memory, not storage. If it matters, write it down.

What do you mean by "agents"? I thought this was about AI tools, not robots.

An agent is a written set of instructions that tells the AI what to do in a specific situation — what it can decide on its own, what it must stop and check with you, and how you’ll know whether it’s working. It is not software. It is not a robot. It is a job description for the AI.

When you specify that your agent should log a pricing exception to a file but never send an email on your behalf without your approval, you have written an agent. When you define what counts as out-of-bounds and what the AI should do when it hits that boundary, you have written an agent. The spec builder interview walks you through the five elements every good agent needs.

Why does the spec builder keep asking me to be more specific? Isn't what I said obvious enough?

The point of the spec builder is not to teach the AI things you already know. It is to create a written record of your judgment that works when you are not in the room — for a new hire, a successor, or an AI running your mission in the morning before you’ve read your email.

“Obvious to me” is the most common reason agent boundaries fail. What is obvious to you is a judgment call shaped by experience, context, and priorities you have never had to write down. The spec builder turns that into something explicit. When the interviewer says “that’s a preference, not a constraint,” it is not being difficult — it is asking you to decide whether you actually mean it.

How many elements are there in the spec builder? How long does this take?

There are five elements you need to specify:

1. Role 2. Agent Type 3. Decision Boundary 4. Escalation Triggers 5. Evaluation Criteria

The spec builder works by interviewing you to understand what you want to do. The first time this runs, it will typically take 20 to 40 minutes, depending on how complex your agent is. The first session will feel longer because you’re also thinking about the underlying questions for the first time and understanding how you interact with the BoS OS. The second agent you spec will take half as long.

Why does the agent type matter? Can't I just describe what I want it to do?

The type (Execution / Measurement / Guardian) changes how specific you need to be about the boundary.

An Execution agent takes actions — it can log a record, send a message, or flag an exception. Because it acts, you need to be very precise about what it can and cannot do alone. The boundary matters more.

A Measurement agent observes and reports. It does not act. The boundary is wider because the worst it can do is give you a wrong signal — the decision is still yours.

A Guardian agent enforces a standard. It stops things or flags them. It needs a precise definition of what it is guarding, because a vague standard makes a vague guardian.

Knowing the type before you write the boundary means you know how tight it needs to be, but don’t worry if you don’t know what type of agent. Ask the BoS OS.

I set my agent to run every hour. Is that the right schedule?

It depends on the volume of events your agent is watching for. More frequent is not automatically better — an agent checking an inbox hourly when you receive two relevant emails a week is burning cycles on empty runs.

A better question: how quickly would you need to know if something happened? If a pricing exception arrives at 9am and you check at noon, is that too late? If not, daily is almost always the right starting schedule for a Phase 1 agent. You can always increase frequency once you know the event rate.

For agents in early calibration phase — where the point is to learn patterns rather than respond in real time — daily is right by default. Match the schedule to expected event volume, not to thoroughness.

My agent is logging decisions. How do I know if it's actually learning?

The most common mistake with early-phase learning agents is treating “more data logged” as the same as “more calibrated.” Logging and learning are different.

A simple signal: ask your agent periodically whether it would have called any recent decisions differently, based on what it has learned since it started. An agent that is genuinely updating its model will sometimes say yes — it would have called something differently six weeks ago than it would today. An agent that only accumulates data without updating will never say this.

This is not the same as a streak of correct predictions, which could just mean you picked easy cases. The “would I have called this differently?” signal is more honest.

The BoS OS approach for early-phase agents: log the structured data in real time; leave the reasoning field blank; run a dedicated calibration session every few weeks where you review a sample of decisions together and capture the reasoning in batch. Some will reveal patterns. Some won’t. Both are useful.

What is a mission?

A mission is a piece of work your business has decided to do — with a defined outcome, a measure of success, and one person accountable for the result. It is not a project plan. It is not a prompt. It is a commitment: this outcome matters, here is how we will know we achieved it, and here is who owns it.

The BoS OS gives you a way to run missions with AI doing the legwork. But the mission itself is just good business thinking. If you cannot define the outcome and the measure without AI in the room, AI will not fix that.

A mission is time-bound (heading toward a finish line) or ongoing (a standing operation you maintain). Both are valid. What matters is that you know which one you have, because they have different definitions of done.

What's the difference between a mission, an agent, and a skill?

These are different things that work together.

A mission is a piece of work your business wants to do — a defined outcome, a measure, an owner. It exists independently of AI. The BoS OS helps you run it with AI doing the legwork.

An agent is a Claude session loaded with a specific spec that tells it what it’s authorised to do and what it must escalate. The Mission Shaper is an agent. The Brand Quality Guardian is an agent. Each agent has a defined role, a decision boundary, and escalation triggers. Agents do the work inside a mission.

A skill is a file you install in Cowork that tells Claude how to behave when triggered. Bootstrap, Workshop, and Run are skills. When you say “Bootstrap my company OS,” the Bootstrap skill loads and gives Claude its instructions. Skills are the delivery mechanism; agents are the specification of behaviour.

The short version: missions are the work, agents are the workers, skills are how the workers get their instructions.

What's the difference between a role stub and an agent spec?

A role stub describes a human. An agent spec authorises an AI.

Bootstrap produces role stubs — one per person on your team. A role stub captures their name, title, the functions they own, and the strategy documents they’re responsible for. It’s a map of who does what in your company.

Workshop turns role stubs into agent specs. An agent spec defines what an AI agent is authorised to do on that person’s behalf: the decision boundary (what it can do without asking), escalation triggers (when it must stop and ask a human), evaluation criteria (how you’ll know it’s working), and hard constraints (what it must never do).

Don’t skip Bootstrap and go straight to agent specs. The role stub is the foundation. An agent spec without a role stub is an AI with no context about the human it’s working for.

What's the difference between an agent and a mission?

An agent is a role. It has a defined purpose, a decision boundary, and things it’s allowed to do without asking. A mission is a time-bound project with a goal, a scope, and an end state. Agents run inside missions. The common mistake early on is building an agent that’s trying to do everything a mission should do: a mission dressed up as an agent. If your thing has a goal, a timeline, and a deliverable, it’s a mission. If it has a role and a decision boundary and runs repeatedly, it’s an agent. The right way to think about it: define the mission first. What outcome are you trying to achieve, by when? Then ask which parts of that work an agent can handle on your behalf. The mission sets the direction. The agent does a bounded piece of the work within it.

The BoS OS keeps suggesting I spec a CEO agent. Should I?

Not necessarily first. Before deciding what agent to build, answer a prior question: what roles or functions in your business currently have no reliable owner, human or AI? The CEO agent framing can push you straight into speccing an agent for your most complex, judgment-heavy work, which is the hardest place to start and the easiest place to stall. A better starting point: map the functions that are either undone or poorly owned, then ask which of those an agent could handle with a clear decision boundary. The CEO agent might be the right answer eventually, but it should be the conclusion of that thinking, not the opening assumption.

I've been fixing fires my whole career. How is this different from any other tool?

Most tools help you fix problems faster. The BoS OS helps you fix problems and fix the system that keeps producing them.

When you encounter a recurring issue in the BoS OS, the same effort that fixes today’s instance can also update the agent spec, the strategy document, or the process that generated it — so the problem is less likely to happen again. This is qualitatively different from reactive problem-solving, and it’s only possible because the OS holds your operating context persistently across sessions.

Founders who’ve been through the workshops describe this moment: “I’ve been firefighting for years. Now I can fix the fire and fix the building at the same time.” The insight is experiential — you don’t understand it from a description, you feel it the first time you fix a problem and then immediately fix the process that caused it, in the same session.

Why should I fix the system rather than just fixing the problem in front of me?

Because the same problem will be back next week.

Most of what AI gets used for is fixing instances — one email, one data error, one piece of content. That’s useful, but it’s not compounding. The BoS OS is designed to help you fix the system that keeps producing the instance. If your content isn’t reaching the right people, you can fix today’s newsletter. Or you can build a mission that makes content distribution a working system. The first clears the queue. The second changes the queue.

This is one of the Mission Shaper’s explicit jobs: when you describe a recurring problem, it will ask whether you’re fixing the symptom or the system. That question is worth sitting with before you commit to a mission.

The BoS OS keeps giving me outputs I don't know how to use. How do I build fluency?

Ask for curated results rather than full lists. Instead of “show me all the marketing signals,” try “show me the three most actionable signals for my next post.” Then tell the system whether those choices fit your thinking. Do this regularly and two things happen: your feedback gets more specific, and the system’s suggestions get better aligned with how you actually work. Fluency comes from the feedback loop, not from reading the documentation.

Who is responsible for making sure AI outputs don't go wrong?

You are. The BoS OS drafts ideas, surfaces patterns, and makes suggestions. You decide what is real, what is worth acting on, and what is noise. No AI output should ever go external without your explicit approval. The system presents options. You make decisions.

Can I use the BoS OS if I've already built my own AI system?

Yes, and people who have already built their own systems often find it most useful as a structural reference or governance complement rather than a replacement. The BoS OS’s value is in the team-accessible folder structure, the decision cascade governance, and the workshop path — not in raw architecture. If you have built something that works for you personally, the question worth asking is: can your team use it without you? If not, the BoS OS’s shared folder structure and non-technical onboarding path is worth looking at.

How do I know whether an agent is actually helping?

Start with hygiene: is the agent consistently doing the basic thing you asked — logging exceptions, flagging items, running on schedule? If yes, you have a baseline. Then look for learning signals: is it getting better at predicting your decisions? Is its reasoning getting more specific over time? Leading indicators are harder to define and require you to decide what “helpful” means in your specific context before you start. Define that upfront. An agent whose success criteria are vague will feel useful without being measurable.

How long does the Bootstrap process take?

Approximately 10 minutes from start to finish. The process uses less than 9% of your total Claude context window, making it efficient even for founders with limited session time. Most of the work is Claude researching your company from public information and synthesizing it into your initial OS structure.

Can I use the BoS OS without joining the BoS community?

Yes, absolutely. The BoS OS is a powerful standalone tool for entrepreneurs. Community membership is entirely optional and adds peer learning value, but it is not required to benefit from the system. Many users run the OS independently without ever attending a BoS event or workshop.

When should an agent interrupt (escalate) to me?

Only for true exceptions. An agent should escalate when: (1) it encounters a legal or contractual implication, (2) a decision falls outside its defined boundaries, or (3) to report learning milestones (e.g., “10 correct predictions in a row”). Routine work completion should not trigger notifications — you should pull status on demand instead of the agent pushing updates for every routine task.

How much time does calibrating an agent actually take?

Plan for monthly CEO review sessions where you review the agent’s decisions alongside your own decisions on the same items, then explain your reasoning to the system. This is an ongoing cost, not a one-time setup. Start with 1–2 hours monthly. The payoff: the agent learns your decision patterns and gets better at predicting what you’ll actually do.

Does the BoS OS work better for solo founders or teams?

Both, but the value is different. Solo founders use the OS as a “co-founder you never had” — external thinking and a forcing function for clarity. Teams use it as a shared source of truth and alignment tool. The OS reflects back what you put into it, so teams that invest in shared documentation get more compounding value over time.

My task list keeps growing. Is that a bug?

No, but it’s a signal you should pay attention to. The OS generates tasks based on decisions, dependencies, and open items it surfaces. If tasks feel endless, that usually means: (1) you’re not closing out completed items explicitly, or (2) the system is surfacing blocked work faster than you can unblock it. Both are useful signals. The fix: close completed items actively in each session, and use “blocked” status to separate “things I should do” from “things I’m waiting on.”

What makes the BoS OS different from just using Claude directly?

Structure and compounding. Using Claude directly gives you smart answers to individual questions. The BoS OS gives you a system that remembers your answers, learns from them, and surfaces patterns you would miss if you were asking questions one at a time. The compounding happens over sessions — each time you update your OS files, the next session starts from a slightly more informed version of your business.

Should I put all my confidential data into the BoS OS from day one?

No. Start with what’s public or what you’re comfortable sharing. The OS is most valuable when it contains your actual decisions, strategies, and tensions — but you decide what to add and when. You can run a fully functional BoS OS using only publicly available information about your company for months before you add anything confidential.

What happens if I use different team members in different sessions?

The OS learns each person and adapts. If your CFO joins one session and your COO joins the next, the system treats them as distinct perspectives and asks different questions. This is a feature, not a bug — it surfaces blind spots and variation in how different people see the business. Over time, the OS becomes a record of how your company’s leadership team thinks about problems.

Can I pause a mission mid-stream and restart it later?

Yes. Missions are stored in files, and files are just text. You can pause, restart, pivot, or run multiple versions of the same mission in parallel if you want. The OS does not enforce linearity. Some teams run a mission for a few weeks, decide to table it, and come back to it months later. The system picks up where you left off.

Does the bootstrap accuracy degrade if I don't update it?

No, it improves. The bootstrap is most accurate at the moment you run it (it uses current public information). But accuracy degrades only if your company changes faster than you update your OS files. If you’re actively refining your strategy documents based on what you learn, the OS becomes increasingly accurate and increasingly useful. Stale OS files are the real risk, not time passing.

Should I give my board or advisors access to my BoS OS?

That is an explicit design decision you need to make. The BoS OS is your thinking space — it contains half-baked ideas, tensions, and decisions not yet public. Some founders love sharing it with their board or advisors to get aligned on what they’re actually thinking. Others treat it as private. There is no right answer. Decide what feels safe and useful, and set access accordingly. The OS will tell you what’s in it.

Open Questions