Getting the most out of FoundersOS

FoundersOS is model-agnostic and works with any MCP client - the AI agent you use is entirely your choice. Claude, and Cowork in particular, is the setup we reach for, and a handful of its features line up so well with FoundersOS that the whole thing starts to feel less like a tool and more like a teammate who already knows your business. Everything below has a plainer-client equivalent (see Running on a local model), so read this as patterns illustrated with our preferred stack, not a requirement to use it. Here is how we lay it out.

Two layers of memory, working together

FoundersOS gives you a semantic memory - durable, queryable business context with personal and org scopes, stored in your own database. Claude and Cowork also keep their own working memory for a project. They are not redundant; they do different jobs:

• FoundersOS memory is the long-term company brain: pricing decisions, customer preferences, strategy, lessons learned. It persists across every client and every session, and any teammate on the same project can recall it.
• Cowork’s project memory is the near-term working context for what you’re doing right now.

The pattern: let FoundersOS hold anything that should outlive the conversation, and let Cowork hold the session’s working state. Ask Claude to “remember that for the org” and it lands in FoundersOS where it’ll still be there in three months, from any device.

Projects as the unit of work

Pair the folder you open in your client with a FoundersOS project record and you get one place where files, tasks, and customers line up. When you first mention working on a project, Claude offers to create the record; creating it auto-provisions the project’s #tag in the registry. From there the scoping is essentially free: tag a task or customer with that #tag and it rolls up into the project card automatically, and because tags auto-register on first use you can’t really get it wrong. Ask for the project and you get status, recent tasks grouped by state, and attached customers, without hunting across tools.

A layout that holds up as work grows: one folder per area of work, a dedicated repo for written documents (markdown, so they version and hand off cleanly) sitting beside your code, and a single project tag tying it together. The folder and the tag answer “where does this go” so you never have to.

Project instructions as guardrails

A short instructions file teaches Claude your house style once, and every session honors it: write docs in markdown, deliver mockups as HTML, use a specific connector for company memory, never use em-dashes. A few lines of instructions turn “do it the way I like” from a per-session request into a default. It’s the cheapest consistency you’ll ever buy.

Skills and connectors: which does which

This is the distinction that trips people up most, so here is a clean rule. A connector (an MCP server like FoundersOS, Slack, or GitHub) gives your agent hands: live access to a system it can read from and act on. Some connectors are also a durable store, so they double as a memory - FoundersOS especially, where memory is a built-in feature, while something like a web-search connector is purely hands. A skill gives it a procedure: packaged know-how for producing a particular kind of output or following a workflow.

The quick test: if the work is “go touch this system,” reach for a connector; if it is “produce this artifact the right way,” reach for a skill. Most real tasks use both. Building a quarterly review deck, for example, leans on a deck-building skill for the how, FoundersOS for the actual numbers and project status, and maybe a Slack connector to post the result. When you are missing a capability, the same split tells you what to add: need to act in a new system, look for a connector; need to produce a new kind of deliverable reliably, look for (or write) a skill. For more on pairing connectors, see Connecting your stack.

Visualizations instead of walls of text

Because FoundersOS tools carry the rendering contract, a rich client like Cowork turns “catch me up” or “show me the pipeline” into a live widget rather than a paragraph. You can also pin a visualization as a persistent artifact - a status page that refetches from your connectors each time you open it, so your morning dashboard is always current without you re-asking.

Guided questions before work starts

When scope is fuzzy, Claude asks structured multiple-choice questions to pin it down before doing anything - the same elicitation you get when a playbook preflights or a project kicks off. You answer by picking, not by writing a paragraph, and the work that follows is aimed correctly the first time. On a plainer client the same questions arrive as a numbered list (see Running on a local model).

Scheduled tasks for work that should just happen

Some work shouldn’t wait for you to start a session. Scheduled tasks run on a cadence - a morning briefing, a weekly retro, a recurring health check - and can use your connectors to deliver the result somewhere you’ll see it.

Putting it together

None of these features is doing the heavy lifting alone. The leverage comes from the stack: a project gives the work a home and tags it for free, instructions keep it consistent, memory keeps it from starting over, the right reach (connector to act, skill to produce) keeps it capable, visualizations make the state legible at a glance, guided questions keep it aimed right, and scheduled tasks keep it moving while you’re away. A blueprint to copy: one folder per area of work tied to a project tag, a markdown docs repo beside your code, house style in instructions, and FoundersOS holding anything that should outlive the session - see it all in one picture in the blueprint, visualized. Start with one piece, add the next when you feel the friction, and run it on whichever agent you prefer. For concrete combinations, see the use-case recipes.