Skip to content
Company OS
Esc
↑↓navigate↵open⌘Jpreview
On this page

Company OS System

The Company OS control plane provides unified connectivity, access control, metering, and governance for tenant workloads and external channels.

The Company OS is the middle layer in a three-layer architecture that separates concerns between external communication channels (Harness/Channel), the platform control plane, and tenant-specific applications and data (Core Apps+Data). This layer ensures that all agent actions, regardless of entry channel, pass through consistent security, metering, and governance checks.

Responsibilities

The Company OS provides the following core capabilities:

  • Unified connectivity: All MCP (Model Context Protocol) and REST integrations are bundled and managed here.
  • Access control: Role-Based Access Control (RBAC) enforced per principal role (e.g., recruiter vs CFO vs CTO).
  • Platform authorization: Mediates access to external platforms (e.g., LinkedIn, GitHub) on behalf of users.
  • Observability and metering: Every action generates a Receipt capturing cost, outcome, and correlation ID for billing and audit.
  • Action validation: User confirmation steps for sensitive operations.
  • Skills library: Registry of reusable agent capabilities that can be composed into workflows.
  • Model routing: LiteLLM for intelligent LLM selection and fallback.
  • Tracing: Langfuse integration for end-to-end observability of agent executions.

Components

The Company OS control plane consists of several interconnected components:

API Layer

Exposes endpoints via RPC and REST APIs. The API layer is defined by routers that include public procedures (e.g., health checks) and protected procedures that require authentication and receive user session context.

Services

Provides foundational services such as database access (db) and authentication (auth). These services are initialized from environment configuration and shared across the system.

Context

Request-scoped context that carries the authenticated session and database connection. The context is created per request by extracting session information from headers via the auth service and making it available to API procedures.

Interactions with Other Layers

  • Ingress: User requests enter via the Harness/channel layer (e.g., a WhatsApp message) and are normalized into a common internal format.
  • Routing: The OS layer identifies the tenant and principal, validates permissions via RBAC, and selects the appropriate skill or application.
  • Execution: The OS invokes the target application in the Core apps+data layer, passing through metering and validation checkpoints.
  • Egress: Results flow back through the OS layer (for receipt generation and observability) then to the Harness/channel layer for delivery to the user.

Diagram

The following diagram illustrates the three-layer architecture and the flow of requests through the Company OS control plane:

graph TD
    subgraph Harness["Harness/Channel (Outermost)"]
        WhatsApp[WhatsApp]
        Telegram[Telegram]
        Slack[Slack]
        Teams[Teams]
        Custom[Custom Channels]
    end
    subgraph OS["Company OS (Control Plane)"]
        API[API Layer]
        Services[Services (DB, Auth)]
        Context[Context]
        Routing[Model Routing (LiteLLM)]
        Metering[Observability & Metering]
        Validation[Action Validation]
        Skills[Skills Library]
        AuthZ[Platform Authorization]
    end
    subgraph Core["Core Apps + Data (Innermost)"]
        Apps[Tenant Applications]
        Data[Data Storage]
    end
    Harness -->|Normalized Requests| OS
    OS -->|Invokes| Core
    Core -->|Results| OS
    OS -->|Receipts, Responses| Harness

Was this page helpful?