Canonical: https://molo17.com/blog/company-brain/ Markdown mirror: https://molo17.com/blog/company-brain/index.md Title: Company brain: the governed semantic layer for AI agents Description: A company brain is a governed semantic layer over the systems you already run, where people and AI agents read and write one shared organizational memory. [← All articles](/blog/) Article # What a company brain is: a governed semantic layer for people and AI agents  2 Nov 2026 [Knowledge sharing](/blog/?category=knowledge-sharing) 8 min read A company brain is a durable, governed semantic layer over the systems you already run. Here is what it holds, the two-layer stack behind it, and how we are building it into Gluesync Core Hub. A company brain is a durable, governed semantic layer over the systems a company already runs, where people and AI agents read from and write back to the same organizational memory. That is the whole definition. The chat box, the search bar and the graph visualisation are interfaces on top of it. The term went mainstream in 2026. Y Combinator put "Company Brain" in its Summer 2026 Request for Startups, in an entry written by partner Tom Blomfield. A July 2026 survey of 149 AI-forward teams by Slite found that 70% had heard the term and 19.6% had a company brain that works. Most companies know the name. Very few have built the thing. This post explains what the thing is. ## Why the term took off now Four ideas arrived within a few months of each other. - **Andrej Karpathy's LLM wiki.** In his [llm-wiki idea file](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f), an LLM builds and maintains a persistent, interlinked set of markdown pages between you and your raw sources. Knowledge is "compiled once and then kept current, not re-derived on every query." - **Garry Tan's GBrain.** Garry Tan open-sourced [GBrain](https://github.com/garrytan/gbrain) under the MIT license in April 2026. It is a markdown-first memory layer that runs his own OpenClaw and Hermes agents. - **YC's Request for Startups.** Blomfield's entry, as [quoted by openfor.co](https://www.openfor.co/post/yc-summer-2026-requests-for-startups-an-independent-reading): "We need Garry's G-Brain, but for every business in the world. A system that pulls knowledge out of all these fragmented sources, structures it, keeps it current, and turns it into an executable skills file for AI." He calls it "a living map of how a company works: how refunds get handled, how pricing exceptions are decided or how engineers respond to incidents." - **Foundation Capital's context graphs.** In December 2025 Jaya Gupta and Ashu Garg argued that [the next systems of record will capture decision traces](https://foundationcapital.com/ideas/context-graphs-ais-trillion-dollar-opportunity). Their context graph is "a living record of decision traces stitched across entities and time so precedent becomes searchable". It records what happened and "why it was allowed to happen." The pressure behind all four is the same. MIT NANDA's _The GenAI Divide: State of AI in Business 2025_ reported that [95% of enterprise generative AI pilots deliver no measurable P&L impact](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/). The report blames brittle workflows and a lack of contextual learning, not model quality. The models are good enough. What they lack is the company. ## Three things a company brain gets confused with ### A chatbot A chatbot is an interface. A company brain is what the interface reads from. One brain serves many interfaces: an in-product agent, Claude in a desktop app, a script in a CI job, a person in a browser. They all ask the same memory and get the same governed answer. A company that buys a chatbot gets one more place where knowledge ends up. A company that builds a brain gets one place that every tool reads. ### A wiki Karpathy's wiki has the right instinct: compile knowledge once and keep it current. At company scale three things break it. Permissions: the payroll table and the incident runbook have different readers. Conflicting sources: the CRM and the billing database disagree about the same customer, and somebody has to decide which one wins. Upkeep: Slite found that 55% of the teams that built their own company brain gave up, almost always because of maintenance. A company brain has to be fed by the work itself: every run, every query, every approved action. ### A data warehouse A warehouse stores rows. A company brain stores meaning: which systems exist, how their tables relate, which procedure answered which question last time, who is allowed to see what, and which action is allowed to run. The rows stay in the systems of record and in the stores you already replicate to. The brain knows where they are and how to reach them under the caller's permissions. ## What the brain has to hold Strip away the branding and a working company brain holds five things: 1. **Permissions.** Every read and every write runs as a real identity. The brain enforces the permissions the source systems already enforce. 2. **Governance.** Policy lives in the execution path, not in a committee. Gartner predicted in 2024 that [80% of data and analytics governance initiatives will fail by 2027](https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-). Governance that has to be applied by hand loses to governance that runs on every call. 3. **Conflicting sources.** The brain records where each fact came from, so a disagreement between two systems is something you can see and resolve. 4. **Shared trust.** People trust provenance. In the same Slite survey, 78% said a named human owner who verified a document is what makes them trust it. The brain carries the trail: who wrote a memory, which run produced it, which approval let an action through. 5. **Write-back.** Agents and people both write. A procedure that worked becomes a reusable skill. A decision becomes a trace the next agent can find. ## The two-layer stack A company brain has two layers. Memory gets the attention. Execution is where autonomy succeeds or fails. ### Layer 1: ambient memory This is context and recall. The schema of every system the company runs, the relationships between tables, the notes agents leave after a task ("the churn number comes from these two tables, filtered by this status"), the skills people publish. The agent asks, and memory answers with a small, relevant subgraph instead of a dump of every table. ### Layer 2: semantic execution This is where business intent becomes governed, verifiable, auditable action. "Pause the pipeline feeding the finance mart and notify the owner" is intent. The execution layer turns it into steps, checks each step against policy, parks every write for approval, records exactly what happened, and marks anything it could not observe. This is the layer that prevents silent failures. An autonomous workflow has two classic ways to lie: a retry that performs the same write twice, and a timeout that gets reported as success. A semantic execution layer persists each step before it runs, knows which actions are safe to retry and which must run at most once, and surfaces an unobservable outcome as _ambiguous_ for a human to settle. Every run can be reconstructed from its steps, policies and approvals. Memory tells the agent where to look. Execution makes what the agent does provable. ## How we are building it in Gluesync Core Hub We come at this from data integration. Gluesync already knows the databases a company runs, because it connects them. That is the natural starting point for a company brain. **Shipped today (Gluesync 2.2).** The [Core Hub MCP server](https://docs.molo17.com/gluesync/latest/gs-modules/corehub-mcp.html) runs inside the Core Hub JVM and exposes 55 tools to any MCP client, such as Claude Code or Claude Desktop. It holds no credentials of its own: every call carries the caller's bearer token, so RBAC, license and audit checks run exactly as they do in the web UI. `GLUESYNC_MCP_READ_ONLY=true` hides every write tool, and dynamic database tools let a client reach the SQL-capable agents behind Core Hub under the caller's Query Studio permissions. More in [our Core Hub MCP post](/blog/gluesync-core-hub-mcp-server/). **In development on the Gluesync 2.3 line.** The 2.3 documentation is in preview and these features are unreleased. We are building both layers into Core Hub. The **Enterprise brain** is the memory layer: - A dedicated SQLite database, `gluesync-ai-brain.db`, beside `gluesync.db`, included in support snapshots and backups. It holds the schema graph, agent memory, AI Studio conversations, skill attachments and approved remote MCP servers. - A schema graph built by walking the schemas, tables and columns of every SQL-capable agent. The walk streams page by page, checkpoints so an interrupted build resumes, and swaps generations atomically. - Agent memory that records location and procedure: which tables answered a question, which filter mattered. It stores no result rows, and password, token, secret and API key assignments are redacted before anything is written. Memory is shared by default across everyone who uses an agent and private when the user asks for it. - Keyword search (SQLite FTS5 plus a foreign-key walk) always on, with embeddings offered when an embedding-capable model is configured. - Agents that publish the procedure they just executed as a skill, and approved HTTPS MCP servers (GitLab, Notion) registered behind a host allow-list and published as tool bundles. - MCP tools, including `search_enterprise_brain`, `start_agent_run` and `publish_skill`, so external clients query the brain under their own permissions. The **durable tool runtime** is the execution layer: - Every provider turn and tool call is persisted as a step before it executes, moving through `PENDING`, `RUNNING`, `WAITING_APPROVAL` and a terminal state: `SUCCEEDED`, `FAILED`, `CANCELLED` or `AMBIGUOUS`. - Every write waits for an approval that only a signed-in user can resolve. API keys and schedulers never approve. - Each capability declares whether it is idempotent, reconcilable or at-most-once. An interrupted at-most-once write becomes `AMBIGUOUS` and goes to an operator, who settles it with the full step record in hand. - A run can be reconstructed from its immutable versions, ordered events, steps, policies and audit records. Everything lives in your Core Hub, on your infrastructure. ## A brain is only as fresh as the data feeding it The memory layer holds schema and procedure. The answer to "what is our open pipeline this quarter" still comes from the tables, read at question time under the caller's permissions. If those tables are a day old, the brain gives a confident answer that is a day old. This is where real-time integration matters. Gluesync keeps target stores current with change data capture chosen per connector: [IBM i journals](https://docs.molo17.com/gluesync/latest/agents/ibm-i-series-change-data-capture-journal.html), [PostgreSQL WAL](https://docs.molo17.com/gluesync/latest/agents/postgresql-change-data-capture-wal.html), [Oracle LogMiner](https://docs.molo17.com/gluesync/latest/agents/oracle-logminer-intro.html), [SQL Server change tracking](https://docs.molo17.com/gluesync/latest/agents/ms-sql-server-agent-change-tracking-intro.html), and triggers on sources such as [SAP HANA](https://docs.molo17.com/gluesync/latest/agents/saphana-triggers.html). The connector architecture is in [Agents 101](https://docs.molo17.com/gluesync/latest/agents/agents-101.html). A company brain on top of fresh data answers with today's numbers, and the agents acting on it act on today's state. ## What to ask before you buy one - Does every read and write run as the caller, with the permissions the source systems already enforce? - Where does the memory live, and who can export or delete it? - Does memory store rows and secrets, or location and procedure? - What happens when a write times out: retry, success, or an explicit ambiguous state? - Can you reconstruct a run end to end from its steps, policies and approvals? - How fresh are the tables the answers are read from? A company brain is a durable, governed semantic layer over the systems you already run, where people and agents read from and write back to the same organizational memory. That is what we are building into Gluesync Core Hub. The Core Hub MCP docs are [here](https://docs.molo17.com/gluesync/latest/gs-modules/corehub-mcp.html). I am around. [← Older article Gluesync Live Lab: Let's Play with Data, build your first pipeline live](/blog/lets-play-with-data-gluesync-live-lab/) ## Keep reading 1. [Mentioned in this article Gluesync Core Hub MCP server: pipelines, SQL, and ops from your AI client Embedded Model Context Protocol server inside Core Hub: 55 RBAC-safe tools, SSE and streamable HTTP, dynamic Query Studio database tools. Available in Core Hub 2.2.10.x. 9 Sep 2026](/blog/gluesync-core-hub-mcp-server/) 2. [Knowledge sharing First Components – Labels & Buttons 🧑🏻‍💻 In case you haven’t read the Compose introduction yet, I suggest you read this article As promised, here I am with a second article about Jetpack Compose. We now \[…\] 28 Feb 2022](/blog/first-components-of-jetpack-compose-labels-buttons/) 3. [Knowledge sharing Doing vs being: lessons on building agile culture Since 2015 MOLO17 creates innovative digital solutions with a 30-people strong team, about 20 of which are related to software development. At date, we have in our portfolio banks, \[…\] 23 Sep 2020](/blog/doing-vs-being-practical-lessons-on-building-an-agile-culture/) [Back to all articles](/blog/) [More in Knowledge sharing →](/blog/?category=knowledge-sharing)