Everything Founder OS does, and why it is built this way
Founder OS is not a chat box with plugins. It is a state engine with agents on top and a hard safety gate in front of anything irreversible. Here is each part in detail.
The canonical model of your company
Company State Engine
Goals, projects, tasks, decisions, metrics, people and meetings, all as first-class entities rather than text buried in documents. State arrives three ways — observed from your tools, handed over in the docs you give it, and written by the system as it learns — and each entity carries its provenance so you can always ask where a claim came from.
A write gate rejects low-confidence and contradictory updates instead of appending them
The reconciler merges the same project arriving from three tools into one entity
Dedup catches near-identical entities before they multiply
Decay marks entities nothing has touched, so stale work surfaces on its own
You never pick an agent
One Orchestrator, specialist agents
A single entry point analyses your request, decomposes it into subtasks, routes each to the right specialist — Planner, Content, Research, Support — and synthesises one coherent answer. Agents delegate to each other directly, so you are not left hand-wiring a pipeline every time the work spans two domains.
Durable orchestration: long runs survive restarts and can be resumed
Background execution with status polling, history and cancellation
Answers cite the state and memories they were built from
August still remembers March
Memory that compounds
Four layers of agent memory sit behind a temporal knowledge graph with typed relationships and entity linking. Composite scoring decides what is worth recalling, and spaced-repetition review keeps important context alive rather than letting recency win by default.
Temporal knowledge graph with typed relationships between entities
Composite relevance scoring instead of naive vector similarity alone
Pruning and decay, so the memory stays useful rather than merely large
Nothing has to migrate
Two-way tool sync
Each tool is treated as a synchronisation endpoint: an adapter reads it as a state source, and the renderer writes the reconciled picture back out as ordinary content in that tool. You keep writing where you already write.
Obsidian shipped — reads the vault, mirrors state back as plain Markdown
Notion in progress
Google Calendar feeds real capacity into planning
Adapters are pluggable, so a new tool is a new adapter, not a new product
Monday starts with a draft, not a blank page
Automatic weekly planning
A scheduled job builds next week's plan from live company state — open projects, active goals, unfinished tasks, last week's carry-over — and ranks candidates with ICE scoring against the goals you actually recorded. Calendar load is part of the input, so the plan is built against hours that exist.
Generated automatically every Monday morning
ICE (impact, confidence, effort) scoring against recorded goals
Updated in place as tasks close and new commitments are observed
Autonomy with a brake
Human-in-the-loop approval gate
Every proposed action is classified into one of three risk tiers. Low-risk work runs unattended; medium-risk follows your per-user preferences; anything irreversible or outward-facing is blocked until you explicitly approve it. The gate is enforced by the system, not by agent good behaviour.
Three-tier risk classification: low, medium, high
Mandatory gating for irreversible and outward-facing actions
Per-user preferences for what may run unattended
Your data, your model choice
Local-first, provider-pluggable AI
Ollama runs inference locally by default, so the whole system can operate without sending company data to a model vendor. Swap in Anthropic Claude, Google Gemini or any OpenAI-compatible endpoint when you want more capability, with a three-tier fallback chain if a provider is down.
Ollama by default — nothing leaves your infrastructure
Claude, Gemini and OpenAI-compatible providers supported
Three-tier fallback so one provider outage is not an outage for you
No drag-and-drop canvas to maintain
Workflows, generated not drawn
When a request needs a repeatable multi-step process, the Orchestrator generates the workflow rather than making you design it. A self-hosted n8n backend is available if you want a visible, editable flow — it is an execution option, not the differentiator.
Workflows generated on the fly from what the company actually needs
Optional n8n execution backend with link-out to the editor
Where to go next
Features read better with a week attached to them.
See the parts working together in an illustrative scenario — six tools reconciled into one state, a Monday plan that survives the week, or support triage with a human on the brake.
Check the practical questions on the FAQ — cost, setup time, self-hosting, and what happens to your data.
