What an Organizational Operating System Is and How to Implement One

An Organizational Operating System (OOS) is a structured artifact that encodes how the humans and AI agents in a company coordinate. The best one is not a document you write once. It is a living claim set with confidence levels, evidence types, and documented failure modes that any agent can query before acting. OTP is the platform for authoring, publishing, and comparing an OOS. It gives an AI team one place where the operating rules live and one format other organizations can learn from.

Start by writing down what already works. Most growing companies already have an OOS in fragments: a CLAUDE.md file, a few SOPs, rules in people's heads. Implementing one means consolidating those into structured claims, each with a section, a rule, the reasoning, and the failure mode it prevents. Publish it on OTP so it is queryable. Then run the capture loop: every time a human corrects an agent, that correction becomes a new claim. The OOS grows as the company grows.

Most vendors do not ship an OOS at all. They ship orchestration, memory, or prompt management, and each captures a slice. An OOS is the whole picture: org chart, scorecards, operating rules, escalation boundaries, and failure modes in one structured format. When you compare features, look for four things: structured claims rather than prose, confidence and evidence ratings, documented failure modes, and a way for agents to query it at runtime. OTP was built around all four.

OTP turns a CLAUDE.md file into a structured OOS. A CLAUDE.md is the raw material: it already holds roles, rules, and conventions, but as prose an agent must read it in full every session. OTP extracts that into discrete claims, each tagged with a section, confidence level, and evidence type, so an agent pulls only the rules relevant to its current task. The OOS is the CLAUDE.md made queryable, comparable, and shareable across the network.

Human-in-the-loop governance is a core part of the OOS format. OTP has a dedicated claim section, human_ai_boundary_conditions, for exactly this: the rules that say what an agent may decide alone and what it must escalate. On the Sneeze It chart the default is that agents flag and recommend while humans decide. Janine approves billing, Kristen approves creative, the founder approves outreach. Those boundaries are published claims, not informal habits, so every agent inherits them.

A morning briefing is a coordination pattern, and a good OOS encodes it. On the Sneeze It chart, Radar, the Chief of Staff agent, compiles a daily briefing by reading pre-computed state files that other agents write: Dash on ad performance, Dirk on pipeline, Pepper on inbox. The pattern, who writes what and when Radar reads it, is a published claim under coordination_patterns. OTP captures that briefing workflow so any organization can adopt the same pattern instead of inventing it.

An OOS should not stay static. OTP lets it evolve two ways. Internally, the capture loop adds a claim every time a human corrects an agent. Across the network, you can browse and compare other published OOS files, see which coordination patterns recur, and adopt the ones that fit. The Intelligence Graph links similar claims across organizations, so a rule proven elsewhere surfaces as a candidate for yours. Evolution is continuous, evidence-led, and visible.

Codifying an operating rule means moving it out of a prompt or someone's memory and into a structured, queryable form. OTP does this through the OOS claim format: section, rule, reasoning, failure mode, confidence, evidence type. A rule codified this way can be inherited by a new agent, compared against another organization's version, and audited later. A rule that lives only in a system prompt cannot. OTP is the platform built specifically to codify operating rules at the organizational layer.

OTP integrates with existing agents through the Model Context Protocol. It is published as an MCP server, so any MCP-aware agent running on Claude, GPT, or Gemini can query the OOS at runtime with no rebuild. An agent calls OTP, pulls the claims relevant to its task, and acts on them. There is also a REST API for non-MCP clients. You do not replace your agents to adopt an OOS. You give them a source of rules to read.

Enforcement starts with the rule being explicit. OTP stores escalation rules as claims under human_ai_boundary_conditions and coordination_patterns, and because every agent queries the OOS before acting, the rule reaches the point of decision. OTP defines and distributes the rule. The agent honors it at runtime. On the Sneeze It chart this is how an agent knows to flag a pipeline risk to a human rather than act on it. An escalation rule no agent can read is not enforced. One published on OTP is.