--- title: "What Is a Company OS? A GTM Team’s Guide" description: "A Company OS puts a GTM team's SOPs, ICP, playbooks, and client context in one git repo AI agents read every session. Repo anatomy plus a 5 step setup." canonical: "https://www.explorium.ai/blog/data-for-gtm/company-os-2026/" last-updated: "2026-08-18" --- # What Is a Company OS? A GTM Team’s Guide > A Company OS puts a GTM team's SOPs, ICP, playbooks, and client context in one git repo AI agents read every session. Repo anatomy plus a 5 step setup. - Canonical URL: https://www.explorium.ai/blog/data-for-gtm/company-os-2026/ - Last updated: 2026-08-18 A Company OS is a git repository of markdown context, skills, and guardrails that AI agents read at the start of every working session. The Company OS pattern spread through GTM faster than any other function: between April and August 2026, more than 10 practitioners publicly documented moving their entire operating context, SOPs, ICP definitions, voice guides, playbooks, and client data, into repos that Claude Code consumes on every run. The pattern matters because context is the difference between generic agent output and work that sounds like your team. A session that starts cold produces boilerplate. A session that starts by reading your Company OS knows your ICP, your voice, your active campaigns, and your open client threads before the first prompt. It is the operating layer underneath what we call a [GTM Brain: the always-on context system for revenue teams](https://www.explorium.ai/blog/data-for-gtm/gtm-brain-2026/). This guide covers what a Company OS is (and is not), the canonical repo anatomy, the per-client context pattern, the guardrails that make the system trustworthy, and the live data layer that keeps it from going stale. ## Q1: What Is a Company OS? **A Company OS is a version-controlled repository, usually plain markdown in git, that holds a company's full operating context: who the team is, how it sounds, what it sells, how work gets done, and which tools agents are allowed to touch.** Agents load it at session start, so every run begins with the company's accumulated knowledge instead of a blank context window. ### ❌ What a Company OS Is Not - **Not the legacy business operating system:** frameworks like EOS organize meeting cadences, scorecards, and accountability charts for humans. A Company OS organizes context for agents. - **Not PwC's agent OS:** [PwC's agent OS](https://www.pwc.com/us/en/services/ai/agent-os.html) is enterprise orchestration middleware that connects agents across vendor platforms. A Company OS is content, not infrastructure: files your team writes and owns. - **Not a prompt library:** prompts are per-task. A Company OS is persistent, versioned, and reviewed through pull requests like any other codebase. ### ✅ What Sits Inside the Definition - **Context files:** team, voice guide, design system, industry intel, ICP. - **Skills:** reusable instruction sets that tell the agent how to run a specific workflow, from cold email sequencing to discovery-call prep. - **Guardrails:** hooks that block dangerous tool calls and log every action. - **Connections:** MCP servers that give agents live access to the revenue stack. > "Our entire company dataset lives in one GitHub repo called Company OS... Our goal is to become the most advanced AI-native services company for our niche (GTM)." [Dan Rosenthal on X, April 2026](https://x.com/dan__rosenthal/status/2049202048508317888) ## Q2: Why Are GTM Teams Building Company OS Repos in 2026? **The pattern went mainstream in a single quarter because agencies proved the economics in public and Nvidia gave it enterprise legitimacy.** Between April and August 2026, at least 10 distinct practitioners published their Company OS builds, with individual threads reaching 1,037 likes. ### 🔄 The Practitioner Wave The public builds share a shape: GTM agencies and solo operators moved SOPs, ICP matrices, voice guides, and client files into git, then pointed Claude Code at the repo. One documented stack runs TAM mapping, signal tracking, and enrichment [entirely from the terminal](https://x.com/jack_9947/status/2085074267339657438). Another formalized the delegation chain agents follow inside the repo: > "Workspace Brain → Department Lead → Worker → Artifact → Proof" [Derek Nee on X, describing the agent company OS pattern](https://x.com/DerekNee/status/2070065136442933407) ### 🔑 Enterprise Legitimacy Jensen Huang says ["Claude Code and OpenClaw have sparked the agent inflection point"](https://www.cnbc.com/2026/03/20/nvidia-ai-agents-tokens-human-workers-engineer-jobs-unemployment-jensen-huang.html) and projects 7.5 million AI agents working alongside 75,000 Nvidia employees by 2036, up from roughly 42,000 humans today. The signal for smaller teams is direct: if agent-readable operating context scales to a 42,000-person company, it runs a 12-person agency. ## Q3: What Goes Inside a Company OS Repo? **The canonical anatomy from practitioner builds is five to six top-level directories plus a CLAUDE.md entry point that routes agents to everything else.** ### 🏗️ The Canonical Anatomy DirectoryWhat lives thereExample contents **company/**Identity and positioningTeam, voice guide, design system, industry intel **wiki/**How work gets doneSOPs, playbooks, campaign guides **clients/**Per-account contextICP fit notes, campaign history, open threads **skills/**Reusable agent instructionsOutbound copywriter, ICP modeller, discovery prep **plugin/**Workflow commandsStructured commands agents invoke by name **raw/**Source materialTranscripts, briefs, imported research ### 💡 CLAUDE.md as the Entry Point The public [company-os-starter-kit](https://github.com/Workflowsio/company-os-starter-kit) frames CLAUDE.md as "your AI's operating system": a persistent hub that points to company context, skills, tool connections, and safety rules. The same kit ships the guardrail layer as lifecycle hooks: a safety guard that blocks dangerous tool calls before they execute and a session logger that writes every event to per-session JSONL files. ## Q4: How Do Client Repos Work in a Company OS? **Each client gets a dedicated context file or sub-repo holding everything an agent needs to work that account: ICP fit, voice constraints, campaign history, and MCP connections to the client's own revenue stack.** This is the pattern that turns a Company OS from an internal wiki into a services delivery engine. ### 📊 What a Client Context File Contains - **Account profile:** what the client sells, who they sell to, current positioning. - **Voice constraints:** words the client uses, words they ban, approval rules. - **Campaign history:** what ran, what converted, what the client rejected. - **Live connections:** MCP and API links into the client's CRM and data tools, so agents act on current state rather than a snapshot. ### 🔄 Why Per-Client Context Compounds Every session on that account starts warm. A new hire, human or agent, reads the client file and inherits months of accumulated judgment in minutes. That compounding is the margin story behind [AI-native services firms](https://www.explorium.ai/blog/data-for-gtm/ai-native-services-2026/): the context does the onboarding, and senior operators review output instead of producing it. ## Q5: Why Does Build vs Trust Matter? **Practitioners consistently report that a Company OS takes days to build and weeks to trust, and the gap closes only through gates, guardrails, and proof loops.** The repo is the easy part. Letting agents act on it unsupervised is the hard part. ### ⚠️ The Trust Gap - An agent with write access to a client repo can corrupt months of accumulated context in one bad session. - An agent with send access can push outbound that violates a client's voice rules. - An agent reading stale data confidently personalizes on facts that stopped being true last quarter. ### ✅ Gates, Guardrails, and Proof Loops - **PreToolUse hooks:** block destructive or out-of-policy tool calls before execution. - **Session logs:** every action written to JSONL, so any output traces back to its inputs. - **Approval gates:** humans approve sends, publishes, and CRM writes until the failure rate earns autonomy. - **Artifact and proof:** the Worker → Artifact → Proof chain means every delegated task ends in a reviewable artifact, not a claim of completion. ## Q6: Why Did GTM Teams Adopt the Company OS First? **GTM adopted the pattern first because its core workflows, enrichment, outbound, account research, and CRM hygiene, are the most context-hungry work in the company.** Engineering had version control for 40 years. GTM got it when agents made context a production input. ### 🔑 Context-Hungry Workflows - **Outbound:** personalization needs ICP, voice, and account history in the same context window, which is exactly what [marketing to agents](https://www.explorium.ai/blog/data-for-gtm/marketing-to-agents-2026/) demands of vendors too. - **Account research:** a repo-resident research skill runs the same 15-step playbook every time instead of whatever the rep remembers. - **CRM hygiene:** dedupe and field-fill rules live as documented policy the agent applies, not tribal knowledge. ### ❌ What Breaks When Context Goes Stale A Company OS decays from the data inward. Strategy and voice change quarterly; firmographic facts change daily. Committed CSV exports drift within weeks: headcounts move, champions leave, funding stages advance. Agents then work signals that no longer exist while [uncaptured intent](https://www.explorium.ai/blog/data-for-gtm/uncaptured-intent-2026/) passes by, and the polish of the output hides the rot of the inputs. ## Q7: What Is the Data Layer of a Company OS? **Your Company OS is only as smart as the B2B data layer it can call: strategy, voice, and process belong in committed markdown, while company, contact, and signal data belong behind a live MCP connection.** Nearly every published Company OS stack list includes a B2B data feed, and most start with exports from legacy per-seat data platforms. ### ❌ The Stale Export Problem - CSV exports committed to raw/ are snapshots that decay from day one. - Per-seat licensing on the incumbent enrichment vendor means agents share a human's login, throttled by human-scale limits. - Every export-import cycle adds a manual step to a system built to remove manual steps. ### ✅ Vibe Prospecting as the Live Data Arm Vibe Prospecting is the drop-in data layer for a Company OS: one MCP connection gives every agent session live access to 150M+ company profiles and 800M+ people profiles, firmographics, technographics, and 18 buying-signal categories spanning 80+ signal types. It processes up to 1,000 entities per call server-side at 100 QPS with 97.8%+ company match accuracy, so a TAM-mapping skill in your repo runs at list scale instead of context-window scale. Credits draw from a unified pool with no seat tax, and installation is one click from the Claude or ChatGPT Connectors Directory, so the connection lives in the OS, not in one person's browser. > Building a Company OS for your team or your clients? Wire in the live data arm first. [Try Vibe Prospecting free](https://vibeprospecting.ai/signup) and give every agent session current firmographic, contact, and signal data. ## Q8: How Do You Start a Company OS This Week? **Start with one repo, one CLAUDE.md, and the three context files your agents ask for most, then earn autonomy with guardrails before scaling scope.** ### 🚀 The Five-Step Setup - **Step 1:** Create the repo with a CLAUDE.md that states what the company does, how it sounds, and where everything lives. - **Step 2:** Move your ICP definition, voice guide, and top three SOPs into company/ and wiki/. - **Step 3:** Write one client context file end to end and run a real deliverable against it. - **Step 4:** Add guardrails: a PreToolUse safety hook, session logging, and human approval on anything that leaves the building. - **Step 5:** Connect the live data layer by adding Vibe Prospecting from the Claude or ChatGPT Connectors Directory, and delete the CSV exports it replaces. ### 🔑 The Decision Framework Keep slow-changing truth in git, keep fast-changing data behind MCP, and keep every agent action gated until it has a proof loop. Teams that follow those three rules ship a working Company OS in days. And once agents inside other companies start reading about yours, track what they find: [LLM brand tracking](https://www.explorium.ai/blog/data-for-gtm/llm-brand-tracking-2026/) is how you audit the context the rest of the world's agents hold about you. ## Related Posts - [What Is a GTM Brain? The Context Layer for Revenue Teams](https://www.explorium.ai/blog/data-for-gtm/gtm-brain-2026/) - [AI-Native Services: How Agencies Rebuild Around Agents](https://www.explorium.ai/blog/data-for-gtm/ai-native-services-2026/) - [LLM Brand Tracking: Measure AI Share of Voice in 2026](https://www.explorium.ai/blog/data-for-gtm/llm-brand-tracking-2026/) ## Frequently Asked Questions ### What is a Company OS? A Company OS is a version-controlled repository, usually plain markdown in git, that holds a company's full operating context: identity, voice, SOPs, playbooks, client files, reusable agent skills, and safety guardrails. AI agents such as Claude Code read the repo at the start of every session, so each run begins with the company's accumulated knowledge instead of an empty context window. The pattern spread across GTM teams through 2026. ### How is a Company OS different from PwC's agent OS? PwC's agent OS is enterprise orchestration middleware: a vendor platform that connects and coordinates AI agents across systems like SAP, Salesforce, and cloud providers. A Company OS is content, not infrastructure: markdown files your team writes, versions in git, and owns outright. Any agent tool can read it, and switching agent vendors does not strand the context. The two solve different problems and the names collide only by accident. ### Is a Company OS the same as a business operating system like EOS? No. Legacy business operating systems such as EOS structure human coordination: meeting cadences, scorecards, rocks, and accountability charts. A Company OS structures machine-readable context: files that AI agents load to understand the company before doing work. A team can run both at once. The overlap is the name; the audience is different, humans in one case and agents in the other. ### What folders go in a Company OS repo? The canonical anatomy from practitioner builds and public starter kits: - **company/** for team, voice guide, design system, and industry intel - **wiki/** for SOPs, playbooks, and campaign guides - **clients/** for per-account context files - **skills/** for reusable agent instructions - **plugin/** for workflow commands, plus hooks for safety - **raw/** for transcripts, briefs, and imported source material A root CLAUDE.md acts as the entry point and routes agents to all of it. ### How do client repos work inside a Company OS? Each client gets a dedicated context file or sub-repo containing the account profile, voice constraints, campaign history, and live MCP connections to that client's revenue stack. Agents load it before working the account, so every session starts with months of accumulated judgment. Agencies use the pattern to onboard new operators in minutes and to keep agent output inside each client's approved voice and rules. ### What guardrails does a Company OS need? Four layers, drawn from public practitioner builds: - PreToolUse hooks that block dangerous or out-of-policy tool calls before execution - Session logging that writes every event to per-session JSONL files - Human approval gates on sends, publishes, and CRM writes - Proof loops where every delegated task ends in a reviewable artifact Practitioners report the system takes days to build and weeks to trust; guardrails close that gap. ### How does a Company OS get live B2B data? Through an MCP connection rather than committed CSV exports, which decay within weeks. Vibe Prospecting connects in one click from the Claude or ChatGPT Connectors Directory and gives every agent session live access to 150M+ company profiles, 800M+ people profiles, and 18 buying-signal categories, processing up to 1,000 entities per call. Credits draw from a unified pool, so every skill in the repo shares one data budget.