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

Layers

The Company OS follows a layered architecture that separates concerns between user interaction, system control, and tenant workloads. This structure enables multi-tenancy, clear responsibility boundaries, and independent evolution of each layer.

Three Layers

1. Harness / Channel (Outermost Layer)

The outermost layer consists of external communication channels where users interact with the system. These include:

  • Messaging platforms: WhatsApp, Telegram, Slack, Teams
  • AI interfaces: ChatGPT, Claude Code
  • Custom channels: openclaw/grokbot (for internal use)

The OS provides these channels as a service to tenants, allowing users to engage with agents and applications through their preferred interface. For a given tenant, the OS manages channel-specific adapters that normalize inbound requests and outbound responses into a common internal format.

2. Company OS (Control Plane)

The middle layer is the administrative and operational core of the platform. It provides:

  • 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

This layer ensures that all agent actions, regardless of entry channel, pass through consistent security, metering, and governance checks.

3. Core Apps + Data (Innermost Layer)

The innermost layer contains tenant-specific applications and their associated data. This includes:

  • Business applications: ATS (Applicant Tracking System), CRM, Linear, GitHub
  • Domain-specific apps: Job Intelligence (the first tenant application)
  • Data layers: Hot/cold storage strategies for different data access patterns
  • Analytics: BI layer built atop the aggregated data for reporting and insights

All agent actions and tool calls from the OS layer are ultimately executed against and recorded in this layer. The OS treats these applications as controlled endpoints, enforcing data isolation and access policies at the platform level.

Layer Responsibilities and Interactions

  • Ingress: User requests enter via the Harness/channel layer (e.g., a WhatsApp message)
  • Routing: The OS layer identifies the tenant and principal, validates permissions, 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

This layered approach ensures that concerns like authentication, metering, and policy enforcement are centralized in the OS layer, while tenant-specific logic resides in the applications. The channels remain loosely coupled adapters, allowing new channels to be added without modifying the core OS or applications.

Was this page helpful?