The company brain: own the history it will be built from

Every chat session and coding session your company runs through a SaaS assistant produces two things. The first is the answer, which you keep. The second is the record: the prompt, the follow-up, the correction, the diff that got accepted or reverted. Today most companies hand that record to the provider and keep nothing.

That record is training-grade data. Which answer a person accepted, which one they argued with, whether the build passed after the agent’s change: this is exactly the signal that post-training runs on, and a large part of why frontier models improved as fast as they did. The labs understood early what session history is worth. Their customers mostly haven’t. Ask an enterprise for its own copy of two years of LLM interactions and the honest answer, in almost every case, is that there isn’t one.

The asymmetry was tolerable while the history had no obvious second use. It has one now.

What is a company brain?

A company brain is an agent, or a system of agents, connected to a company’s internal sources that accumulates tribal knowledge: the undocumented know-how of which systems hold the truth, how data and processes actually connect, and what the official documentation gets wrong. It gets more useful with every interaction instead of starting from zero each time.

The term isn’t ours. Y Combinator’s Summer 2026 Requests for Startups names “company brain” as a category it wants founded, and is careful to say what it isn’t: not company-wide search, not a chatbot over documents, but a living map of how a company actually works. When Y Combinator asks for a category by name, a wave of vendors follows. The definitional fight over what counts as a company brain is starting roughly now.

Personal-productivity readers will hear an echo of the “second brain.” Same instinct, different scope: one organizes an individual’s notes, the other an organization’s know-how. We admit some fondness for the naming pattern.

The knowledge nobody wrote down

At one large enterprise we’ve seen, onboarding a new hire takes three to six months. Not technical onboarding: the account exists on day one. What takes half a year is becoming useful.

Here’s what that looks like from inside. The new hire needs a marketing data mart. The wiki has a page, updated last week, linking to a document that names the warehouse it lives in. So they file the access ticket and wait. An experienced colleague could have told them in one sentence that this warehouse was decommissioned a year ago and the real data now lives somewhere the document never mentions. The page is fresh; the knowledge in it is dead.

Multiply that by every question. Revenue for one client exists in five systems (a warehouse table, two spreadsheets, an invoice folder, the accounting system), and they disagree. Which one is the source of truth is not written anywhere. It is known, by specific people, and learned by asking them one embarrassing question at a time. That is tribal knowledge, and three to six months is what it costs to transfer it to a single human.

A company brain is the attempt to make that knowledge accumulate in a system instead of walking out the door with every resignation.

Where would a company brain’s knowledge come from?

From the corrections. When an experienced analyst tells an agent “not that table — the finance one, the wiki is a year stale,” that message is tribal knowledge caught in the act of being written down. Nobody would ever put it in documentation. It surfaces only because an agent made the same mistake a new hire would have made, and someone who knew better was in the loop.

The correction an expert types into a chat is tribal knowledge, caught in the act of being written down.

So the raw material of a company brain is precisely your interaction history: thousands of exchanges where people who know how the company really works correct a system that doesn’t yet. If those exchanges happen inside a provider’s cloud, that signal is out of your reach. In the less pleasant case, it improves the provider’s model rather than anything of yours.

Public tooling is already moving toward this loop. Databricks announced Genie Agents in June 2026: domain-scoped data agents spun up from a prompt, shared, benchmarked, and rated by the people who use them, with the ratings feeding quality over time. The specifics will vary by vendor; the shape won’t. Every serious version of this pattern consumes interaction history, and whoever holds the history holds the input.

What are the logs worth before any brain exists?

You don’t need to believe in company brains to want the history. Accumulated interaction logs have three uses that pay off on ordinary timescales:

1. Usage analytics. Who uses what, on which models, at what cost, trending which way. Table stakes, but only if the requests crossed a point you can query.
2. An eval base for the next migration. Your provider raises prices or has a bad month, and someone asks whether you can move. Public benchmarks answer how models score on other people’s problems. Your own history lets you replay real workloads (your prompts, your data shapes, your edge cases) against a candidate model and answer with evidence instead of a hunch. Model diversity is normal practice now; the switching question comes up more often than anyone plans for.
3. Fine-tuning your own model later. If you ever tune an open-weight model to your domain, the training set is your accumulated sessions. GPU clouds now pitch this motion directly: Nebius shipped a Token Factory workspace for it in May 2026, under a title that says it plainly: “Your best dataset is already in your logs.”

Note what all three have in common. None of them can be started retroactively. The analytics, the eval base, and the training set all begin accumulating on the day the logs start landing in your storage, and not a day earlier.

What does it take to actually keep the history?

Mechanically, one thing: a point that all LLM traffic crosses, running on infrastructure you control. In practice that means an LLM gateway you own rather than a hosted one, plus chat history stored in your own database rather than a vendor’s tenant.

That is the shape SecondStack takes. The gateway, our LiteLLM fork (the differences from vanilla LiteLLM are here), sees every request from chat, IDEs, scripts, and agents, attributed per virtual key, with usage logs and spend in ControlTower. Chat history lives in your own PostgreSQL, next to the rest of the stack, under your retention rules. That covers the chat side of the asset today; the reasoning behind bundling it all into one self-hosted platform is in why we built SecondStack.

Coding sessions are the harder half, for everyone. Agent transcripts carry the densest correction signal there is: build results, reverted diffs, an engineer telling the agent why its approach was wrong. Capturing them in full is what the company-brain motion will demand from every platform in this space, ours included. If you’re evaluating any vendor against this future, ask where coding-session history lands and who can query it. It’s the question the category will be judged on.

How close is a company brain to reality?

Honestly: not close. Agents over corporate data work well on narrow, well-tuned domains and degrade fast at the scale of a whole warehouse, and that has held for years despite real effort across the industry. YC calls the category a request, not a product review, for a reason. A company brain in 2026 is a moonshot.

In our view, that makes the purchasing decision simpler, not harder. Nobody can sell you a company brain today, and you should be wary of anyone offering one. What you can do this quarter is small and reversible: route your LLM traffic through a point you own and let the history accumulate in your storage. If company brains arrive, you hold the input. If they don’t, you still got the analytics and the eval base. The system can be bought later; the history can’t be backfilled.

We wrote about the gateway half of this in What is an LLM gateway? If you’d rather see the owned-history setup live (gateway logs, chat history, your PostgreSQL), write to hello@secondstack.ai and we’ll walk you through ours.