From Company Brain to an AI Operating System

Most founders and company leaders wake up and open four or five tabs. The CRM to check the pipeline. The support inbox. Stripe. Analytics. A spreadsheet someone edited overnight.

A few minutes later, they have a sense of how things are going but are left wondering:

• Are we on track?
• What changed since yesterday?
• What needs my attention first?
• What’s about to go wrong?

If companies are already collecting data across different platforms and tools, why can’t we automate the process of organizing it and let AI answer these questions for us?

The Company Brain

Andrej Karpathy laid the intellectual foundation with his LLM Wiki pattern — markdown knowledge bases that agents maintain and navigate, where “the tedious part of maintaining a knowledge base is not the reading or the thinking — it’s the bookkeeping” [1]. Good answers get “filed back into the wiki as new pages” so knowledge compounds rather than evaporating.

Then YC gave the category a name, “The Company Brain,” as one of 15 categories in the Summer 2026 Requests for Startups:

“The biggest blocker to AI automation of companies is no longer the models, they just got so good so quickly. Now the blocker is the domain knowledge. Every company has critical know-how scattered everywhere. Some of it lives in people’s heads. Some of it is buried in old email accounts, Slack threads, support tickets, and databases… If we want every company to run on AI automation, we need a new primitive: a company brain… This isn’t a company-wide search or a chatbot over documents. It’s a living map of how a company works… I think every company in the world is going to need one.” [2]

Diana Hu, a YC partner, extended this:

“AI should not be a tool your company just uses. It should be the operating system your company runs on. Every important process in your company should be captured by an intelligent closed loop” [3].

Both hint at a similar architecture, and while we drew inspiration from it, we look to layer on top of it to answer the question:

What should a founder see at 8 a.m. when they need to know if the company is on track?

The AI Operating System uses the company brain as its memory layer. It pulls every signal into one place, turns raw events into a structured company knowledge base, runs rules and scripts to surface what matters, evaluates progress against company goals, and delivers role-specific briefings with next-best actions.

That is the system this post describes — it is what I’ve been working on at Digital Workers. We start by walking through the layers of the AI Operating System, then dive into the sandbox architecture that executes the agentic and non-agentic workflows running on top of the knowledge base.

The 5 Layers

The AI Operating System is built on a five-layer architecture.

Layer 1: Centralize

The foundation is connecting every source. Current connectors include Stripe, Email, HubSpot, Salesforce, Zendesk, Google Analytics, Meta Ads, Google Ads, Google Sheets, call transcripts, social media, databases, and desktop files, among others.

Connectors are pull-first. They run on a schedule, poll each source API multiple times per day, and own retry logic, rate limiting, and error handling.

Each connector looks back up to 30 days on every run to fill in gaps. Events are stored in raw form into a data lake and never overwritten, so the knowledge base can be rebuilt from scratch if the enrichment logic changes later (more on enrichment in the next section).

Layer 2: Organize

Entity resolution

Raw data is less useful if the same real-world entity — a customer, a deal, a company — is named differently across sources. This layer reconciles these scattered records into a single entity.

Schema normalization

Once records are reconciled, data is normalized: dates to ISO 8601, phone numbers to E.164, addresses to a consistent structure.

Enrichment

Where raw data is incomplete, we fill gaps — OCRing receipts and screenshots, extracting entities and summarizing transcriptions, resolving postal codes to geographic regions, and calling external APIs (Google Knowledge Graph, AlphaSense) to expand context.

Pre-computed metrics

Time-series snapshots and aggregations are derived from the processed data, making precomputed views — yesterday, last week, last month, sliced by geography, customer-journey stage, and any other metric that matters day-to-day — available to the downstream layers.

The resulting data is stored in the data lake as virtual or derived tables. Virtual tables provide a query-time view of raw records without duplicating storage, while derived tables store complex transformations, aggregations, and inferences that are computed once and read many times.

By giving workflows access to ready-made context, this layer prevents LLMs from having to rediscover the schema, spend tokens reconstructing basic facts, or repeatedly run the same calculations.

The output is a unified company knowledge base.

Layer 3: Surface Insights

With the knowledge base in place, Layer 3 turns it into a living monitoring system. One that users can configure without writing code.

The mechanism is a rule compiler, in which users write rules in plain English.

A rule might read:

“Flag customers who are at risk of churning — defined as any customer with two or more support tickets in the last 14 days where the sentiment is negative, and who has not logged in for more than seven days.”

That’s it. Plain language describing what to track, what conditions matter, and what threshold should trigger an alert.

The compiler reads the rules alongside the knowledge base schema — the table structures and field names from Layer 2 — and produces a workflow script using an LLM.

Take the churn risk rule above. The compiler produces something like this: a SQL step that fetches all customers with open support tickets in the last 14 days. Then comes an LLM evaluation step that classifies each ticket’s sentiment. Then comes another SQL step that filters the classified results down to customers with at least two negative tickets and no login activity in the last seven days. Finally, a count check against the threshold defined in the original rule triggers an alert if the count exceeds it.

When a script calls an LLM to score a transcript, classify sentiment, or judge tone, the output is written back to the knowledge base as a structured record: the entity, the score, a short rationale, the model and prompt version behind it, and a timestamp.

This is the bookkeeping Karpathy mentioned at the beginning of this post.

…good answers filed back so knowledge compounds instead of evaporating [1], except the filing is automatic.

Once the script is drafted, one of our engineers reviews and approves it — that’s our standard practice to make sure the script meets expectations.

The script runs on a schedule, is deterministic, versioned, and traceable.

The script and its outputs are then stored alongside the knowledge base, becoming part of the company brain.

Layer 4: Goal-Oriented

Layer 3 detects local conditions. Layer 4 evaluates them against company goals.

On their own, a spike in support tickets and a slowing deal look like two unrelated problems for two different teams. This layer sees all of them at once, connecting events across teams.

Goal Compiler

Goals are compiled the same way Layer 3 compiles rules: from plain English into executable evaluation workflows.

What a goal compiles into depends on the goal,

• A measurable one — “Increase customers 2x by end of Q3” — becomes a deterministic script.
• An interpretive one — “Improve awareness of the service during sales calls” — has no column in the data lake, so evaluating it requires reading call transcripts and using LLMs.

As in Layer 3, the LLM results are stored back in the knowledge base.

Council of Agents

With the information needed to assess the company’s goals, the obvious move is to hand it all to a single large model and ask what it thinks.

But a single model is a single point of failure. Whatever it gets wrong, nothing else is looking. Its first read becomes the system’s verdict, with no second perspective to challenge it. And early research suggests those errors don’t surface when re-running the same model: cross-model disagreement “is higher on incorrect answers,” meaning it takes a different model to notice the first one slipped [7].

This layer doesn’t use a single model. Instead, we use multiple frontier models, structured to disagree.

We run a council. Several models each examine the assembled context and independently assess progress against the goals. Then they critique and rank one another, and a single model reconciles the results. The structure borrows from Andrej Karpathy’s “LLM Council” pattern [4].

We use four different frontier models: GPT, Claude, Gemini, and Grok. Different model families reason differently and fail differently. That diversity does not guarantee correctness, but it gives the system a failure signal that a single-model setup lacks.

That said, even GPT, Claude, Gemini, and Grok share a fair amount of common web pretraining data, so their effective diversity is likely less than four.

The council runs in three stages

Stage 1: First opinions

Each model independently assesses the company context against the defined goals. Every model writes its assessment in isolation.

Stage 2: Cross-review

Each model then reads the others’ assessments and ranks them using a scoring rubric. The authors are anonymized, so a model judges the reasoning on its merits rather than by who wrote it [6].

Stage 3: Synthesis

A designated model reconciles the ranked outputs. It sorts them into what the council agrees on, where it actively disagrees, and what only one model caught, so a minority insight is considered rather than voted away [5].

The output of this layer is a structured goal report, with each at-risk goal explained with the evidence behind it.

As with Layer 3, the reports are stored alongside the knowledge base, becoming part of the company brain.

Layer 5: Coaching

This is the layer where we ask the models for an opinion.

Every morning, each leader receives a briefing tailored to them on the issues affecting their work.

A CMO’s Tuesday briefing might look like this:

Brand mentions up 34% week-over-week — driven by one viral customer tweet. Recommend: reach out for a case study before the moment cools.

Competitor Y launched a feature page targeting your top keyword. Recommend: assess your current SEO position and review the gap.

A Head of Sales sees the same underlying data through a different lens:

3 deals moved to the negotiation stage yesterday. Largest: Acme Corp ($48K ARR).

Acme Corp logged 2 support tickets this week — both billing-related. Recommend: address before the proposal call on Thursday. Finance friction kills deals at this stage.

How it works

Each role is defined in a document written in plain English: the data the role owns, what it’s responsible for, the KPIs it monitors, the goals it’s measured against, and how its briefing should read.

An LLM compiler reads that document alongside the knowledge base schema and compiles it into a set of briefs.

From then on, it runs every morning.

Unlike the previous layers, these briefings are not automatically saved back to the knowledge base. They are ephemeral recommendations based on the company's current state. The underlying evidence remains traceable, but the coaching layer is intentionally treated as guidance rather than durable company memory.

This is the newest layer, and how the council should weigh, rank, and frame a briefing is an active area of research for us.

Technical Appendix: Sandbox Architecture

What Is a Sandbox?

A sandbox is an isolated, throwaway environment where workflow scripts run without being able to touch anything outside it.

Each workflow gets its own fresh container with only the files it has access to, no visibility into other workflows’ data (unless explicitly shared), and no direct path to the public internet — any external capability is reached through the platform’s tools proxy, never by the script itself.

Scripts can read their inputs, write their outputs, and call the platform tools — and nothing else.

When the run finishes, the environment is torn down. This is what makes it safer to execute LLM-generated code. Even if a script misbehaves, the blast radius is a single disposable session.

The sandbox is built from five modules: entry points, context gathering, tools, execution, and results.

1. Entry Points

Workflows can be triggered in seven different ways.

Manual

Human-initiated from the UI. A user clicks “Run,” optionally provides inputs (text, images, files), and the workflow executes in real time, with streaming progress updates via server-sent events.

Webhook

Every workflow gets a unique secret URL (/api/webhook/{secret}). External services — Zapier, Make, a custom script, a CRM event — can POST to it and trigger execution.

Schedule

Cron expressions for recurring execution: hourly, daily (with time-of-day), weekly (with day-of-week).

Email

Each workflow can be assigned a unique inbound address ({workflow-name}@hiredigitalworkers.com). Inbound emails trigger workflow execution with sender, subject, and body injected as context.

Sync

Our desktop app watches connected local directories and uploads new or changed files through an authenticated API, triggering workflows each time.

MCP (Model Context Protocol)

Workflows can be automatically exposed as a tool on a Streamable HTTP MCP server. Any MCP client — Claude Cowork, Claude Code, Cursor, or a custom agent — can discover and execute workflows as tools.

Chain

Workflows wired as downstream targets in a DAG fire automatically when their upstream completes, with the upstream’s outputs passed through as inputs. Each edge carries a condition (on_success, on_error, or always), so one trigger can cascade through a whole pipeline.

2. Context Gathering

Before a script executes, the sandbox assembles the full context the workflow needs.

Inputs

User-provided inputs come through the UI, MCP, and other entry points, and are stored in inputs/user.json.

Files

Workspace files from chat sessions are copied into the session directory. If a user has a conversation with the workflow’s AI assistant (we have a chat AI assistant that helps build workflows, but it’s outside the scope of this post) and uploads files, those files are available to the workflow.

Assets

Shared project resources — knowledge base documents, skill frameworks, workflow-specific files.

Mounts

Mounts are connections to external data of the current workflow:

• Run mounts: symlinks to previous workflow session directories — one workflow’s output becomes another’s input
• FUSE mounts: external filesystems — Google Drive folders and the like — mounted as local paths.

Environment Variables

Session-scoped credentials that let generated code interact with the platform:

• SESSION_KEY: a key scoped to the running workflow execution, used to authenticate calls to the platform’s internal tool API
• PLATFORM_URL: base URL for all tool endpoints
• PROVISION_KEY: alternative API key auth for SDK-provisioned runs (SDK is outside the scope of this post)
• WORKSPACE: absolute path to the session’s output directory

Knowledge Base

The workflow is given scoped access to the company's knowledge base so it can read current metrics and entities.

3. Tools

Code never talks to API providers directly. Instead, it calls the platform’s prebaked tools over internal HTTP — each capability is an endpoint under /api/tools/…, invoked through a thin call_tool() client:

from executor import call_tool
result = call_tool("/api/tools/db/query", {
    "connection": "warehouse",
    # Under the hood the system turns natural language queries to SQL
    "question": "customers with 2+ negative tickets in the last 14 days",
})

4. Execution Module

This is where the workflow actually runs. The sandbox executes it in one of two ways — scripted or agentic.

Scripted (non-agentic)

A pinned workflow script runs top to bottom. With no LLM in the loop at runtime, the script is deterministic for a given input.

When it calls an LLM at fixed points — scoring a transcript, classifying sentiment — it’s only partially deterministic: the control flow is frozen, but those individual steps are not.

Either way, the structure is decided in advance, and the sandbox simply runs it.

Agentic workflows

The sandbox runs a ReAct loop: the model reasons, writes code, observes the result, and decides the next step. On an error, it retries with added context. On empty output, it’s nudged to continue — up to a cap of 20 turns.

This is the mode for the reasoning-heavy layers (4 and 5), where the steps can’t be determined up front.

LLM compilers

The LLM compiler that turns plain-English rules and goals into scripts is itself an agentic loop.

5. Result Module

Every file written to the workspace during execution is collected, along with a full record of the run and optionally added to the knowledge base.

Files

Everything the workflow generated.

Execution trace

Every event — tool calls, responses, errors, stdout lines — is recorded as a sequence-numbered entry. This drives two things: real-time SSE streaming to the UI (live progress) and post-hoc debugging (the entire run can be replayed—every decision, every code block, every error).

Metrics

Token usage (input and output), iteration count, execution duration, exit code, error messages, trigger type, and script version.

Downstream chains: composition as a DAG

A workflow’s output can trigger the next. A chain is a directed edge between two workflows with a condition — on_success, on_error, or always. The graph is validated on creation to prevent cycles, and chain depth is capped at 10, so a single trigger can cascade through a whole pipeline.