# What Company OS can help a company do Company OS is not one feature. It is a connected operating system for the work a company needs people and AI to do together. The detailed Company OS catalog contains **840 listed entries**. Many are the parts behind one experience—such as a task, its owner, the policy around it, a model call, the evidence it used, an approval, and the receipt after it finishes. When those supporting parts are grouped together, the catalog describes roughly **450 product-level capabilities**. This page is the plain-language map. It explains the whole system in the way an operator, buyer, or partner should encounter it: by the work it makes possible. ## The eight capabilities that matter ### 01. Set up a company workspace Create a company space, choose how it runs, connect the people and systems involved, and see what needs attention. This includes onboarding, settings, the workspace and desktop surfaces, company records, model choices, and health checks. ### 02. Turn requests into owned work Take a message, idea, or problem and make it visible work with an owner, a deadline, context, dependencies, and a trail of what changed. This includes goals, projects, tasks, handoffs, priorities, status history, service commitments, responsibility assignments, and evidence. ### 03. Let people and agents act safely Give the right person or AI agent a clear lane; pause when a decision needs a human; keep sensitive work inside explicit boundaries. This includes permissions, policies, approvals, delegation, spending rules, access to tools, audit records, and recovery controls. ### 04. Give AI the context to do useful work Let agents use approved company knowledge, files, data, past decisions, and instructions instead of guessing from one chat message. This includes company memory, search and retrieval, reusable skills, project context, agent chat, model selection, and governed work sessions. ### 05. Get work done across the company Research, draft, analyze, update records, run workflows, prepare a review, or coordinate a follow-up—using tools and connected systems where allowed. This includes workspace and artifact review, connected services, external actions, automations, recurring routines, recovery, and adaptive workflows. ### 06. See what happened and improve it Follow an agent run, inspect its cost and timing, see evidence and failures, compare approaches, and promote changes only when the proof is good enough. This includes traces, run receipts, spend, trust signals, evaluation, benchmarks, quality checks, promotion gates, and snapshots. ### 07. Connect it to the rest of the company Use Company OS from existing products, scripts, standards, and developer workflows without creating a second, ungoverned version of the work. This includes integrations, developer tools, imports and exports, standard formats, provider connections, and bringing results back into the company record. ### 08. Operate it as a real product Run the desktop and console surfaces, manage updates and packaging, use operator tools, and verify that the system is healthy enough for the work you ask it to do. This includes deployment, diagnostics, backup and recovery, proof suites, release gates, package tooling, and skills. ## One request, across the system Imagine an operations lead says: > Review yesterday’s customer complaints, identify the ones that need action, draft responses, and ask me before anything is sent. Company OS can turn that one request into a governed loop: ```text Request → company context → owned tasks → the right agents and tools → evidence and draft results → approval where needed → receipt, follow-up, and remembered improvement ``` That single loop touches task management, data and memory, agent execution, permissions, approval, observability, and learning. The catalog’s many entries exist so this does not have to depend on an untracked chat transcript or blind automation. ## What is available, growing, or still being proven The map is intentionally broader than a release checklist. Company OS has working product paths, advanced lab and optional lanes, in-progress desktop work, and named gaps. A capability being listed does **not** mean that it is universally configured, polished for every customer, or release-evidenced. Use the catalog’s language this way: - **Live** means the product path exists in the repository and is treated as supported by its developers. - **Partial** means the useful core exists but the experience is incomplete. - **Optional** and **Lab** mean it is an extension or advanced lane, not required for the core operating loop. - **Planned**, **Gap**, and **Withdrawn** mean the system names the work honestly rather than implying it exists. The practical question is never “does the catalog have a row for this?” It is: **which outcome do you need, what proof is required, and which parts of the system are ready for that level of responsibility?** ## Where to go next - Start with [Company OS: start here](./COMPANY_OS_START_HERE.md) for the product path. - Read [AgentChat branding and marketing](./AGENTCHAT_BRANDING_AND_MARKETING.md) for the customer-facing explanation. - Read [Agent quality cockpit](./agent-quality-observability-product.md) for traces, evaluations, cost, and improvement. - Read [Embeddable benchmarks](./EMBEDDABLE_BENCHMARKS.md) for performance and regression evidence. - Use the [full capability catalog](../../claudedocs/COMPANY_OS_CAPABILITY_CATALOG_2026-09-17.md) when you need the exact item, status, and evidence boundary.