Company Brain

The Problem

The biggest blocker to AI automation of companies is no longer the models. 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. The company works because humans vaguely remember where that knowledge is and how to apply it.

But AI agents can't operate like that. If we want every company to run on AI automation, we need a new primitive: a company brain.

A system that pulls knowledge out of all these fragmented sources, structures it, keeps it current, and turns it into executable skills for AI. This isn't a company-wide search or a chatbot over documents. It's a living map of how a company works: how refunds get handled, how pricing exceptions are decided, how engineers respond to incidents.

Then AI systems can use that knowledge to actually do the work — safely and consistently.

The company brain becomes the missing layer between raw company data and reliable AI automation.

The AI Operating System

The best AI-native companies have figured out something most haven't: they've made their entire company queryable. Every meeting recorded, every ticket tracked, every customer interaction captured — all legible to an intelligence layer that learns from it.

This turns a company from an open loop into a closed loop. In an open loop, you make a decision and maybe check the results weeks later. In a closed loop, the system monitors what's happening, compares it to what should be happening, and adjusts.

The problem is building this today requires brutal integration work — stitching together Slack, Linear, GitHub, Notion, call recordings, and a dozen other tools with custom glue code. There's no product that connects all this context into a single intelligence layer that can reason across it, flag when engineering is building the wrong thing, or generate specs agents can execute on.

The opportunity is the connective layer that makes a company legible to AI by default. Not another dashboard. The system that turns a company's own artifacts into a self-improving loop.

How Bento Fits

See also: Karpathy on company-level AI

Bento is the first implementation of this idea, starting small and growing out.

Layer 1: Agent Infrastructure

A daemon that manages persistent AI agents. Process supervision, scheduling, Telegram/Slack interface. The runtime.

Layer 2: Context Synthesis

Every session, meeting, ticket, and conversation gets tagged and indexed. Cross-channel recall — "what do we know about auth?" pulls from Slack, Linear, GitHub, Telegram, and shared sessions. The memory.

Layer 3: Company Brain

Ingest from all sources — Granola meetings, CRM (Attio), email, support tickets, code reviews. Organize by project, topic, team. Surface as executable skills and queryable knowledge via MCP. The intelligence layer.

Sources                    Bento                        Consumers
─────────                  ───────                     ─────────
Shared sessions    ──┐                           ┌──  Claude Code
Granola meetings   ──┤     ┌───────────────┐     ├──  Codex
CRM (Attio)        ──┼────>│  Tag + Index  │────>├──  pi
Email              ──┤     └───────────────┘     ├──  Slack bot
Linear issues      ──┤        by project /       ├──  Telegram
GitHub activity    ──┘        topic / team        └──  Dashboard

The MCP Interface

The brain is exposed as an MCP server. Any developer with any MCP-compatible agent connects and gets access to the company's accumulated knowledge and skills. They don't need to install anything, learn a new tool, or change their workflow. The knowledge just shows up in their agent's toolset.

A new engineer joins, connects to the MCP server, and their agent already knows how the codebase works, what decisions were made, and what the conventions are. Not because someone wrote docs — because the system learned from everyone's work.

Access Control

Raw knowledge ingestion is one thing. What gets served out depends on who's asking.

Redaction

Strip sensitive data before it enters the KB or at query time. PII, API keys, credentials, customer data. Some things should never leave bento.

Scoping

Not everyone sees everything. An external contractor's agent shouldn't get context from internal strategy discussions. Scope by team, project, or role.

Projection

Shape output for the consumer. An agent doing code review gets technical decisions and architecture context. It doesn't need CRM history or HR discussions.

access:
  layers:
    - name: internal
      tags: [strategy, hr, finance]
      visibility: team-only
 
    - name: redacted
      rules:
        - strip: [api_keys, credentials, pii]
        - mask: [customer_names, revenue_figures]
 
    - name: public
      tags: [engineering, architecture, conventions]
      visibility: anyone
 
projections:
  code-review:
    include_tags: [architecture, conventions, tech-decisions]
    exclude_tags: [finance, hr]
 
  onboarding:
    include_tags: [architecture, conventions, team-structure, processes]

The MCP server is the policy enforcement point. Raw data stays on bento, consumers get a filtered view.

Architecture Reading Order

If you're exploring how Bento is built, start here and follow this sequence:

Workload Architecture — core execution model: workloads, invocations, security boundary, API surface
Event Matcher — planned multi-repo routing architecture for webhook-driven pipelines
MCP Protocol Surface — current MCP tools + the roadmap for richer agent-to-agent interaction
Prompt Composition — how agent prompts are assembled from SOUL + skill + context
Runtime Wrapper — normalised metric collection across pi, claude, and codex
Skill Evolution — automated skill improvement via session history

References

Karpathy on company-level AI