When everyone on a team connects AI to the same sources, each agent builds its own picture of the business. A shared company brain gives every agent the same trusted context.
This piece is adapted from an Operators Guild Focus Session on building a company brain, featuring Seth Greenberg and Aneesh Sachdeva of Glia Intelligence, and shaped by a live discussion among operators who are connecting AI to their meetings, inboxes, and systems and working out how to keep it all trustworthy.
Focus Sessions are small-group, member-only conversations where operators work through real problems together. If you want access to sessions like this, including the recordings and the community behind them, you can apply to join OG.
Most finance and ops teams have crossed the first AI threshold. People have Claude or ChatGPT connected to their email, calendar, Slack, and meeting notes, and they're getting useful work out of it every day.
The next problem shows up once a few teammates are working this way. Five people on the same project each have an agent pulling the same transcripts and threads, and each agent builds its own read on where things stand. That's a lot of repeated work, and the reads don't always match.
So the question for operators is shifting. It's less about how each person uses AI and more about how a whole team shares what its AI knows.
The hidden cost of everyone's AI working alone
Picture the typical setup today. Each person connects their AI assistant to the tools they use through connectors (sometimes called MCPs, a standard way to plug a tool like Gmail or Slack into an AI assistant). Every time they ask a question, their agent goes back to the raw material and rebuilds the context from scratch.
That creates two costs.
Repeated work. Every agent on the team processes the same meetings, emails, and messages on its own. Multiply that by every person and every question, and you're paying for the same thinking over and over, in both time and AI usage.
Conflicting interpretations. Two agents can read the same week of meetings and come away with different answers about what got decided or where a project stands. Nobody notices until two people show up to a meeting with different versions of the plan.
Neither cost shows up on a dashboard, and both grow with every person who adopts AI.
What a company brain is, in plain terms
A company brain is a shared layer that sits between your raw sources and everyone's AI. It connects to the same places your team already works (meetings, email, calendars, chat, and documents), processes that information once, and stores a cleaned-up, trusted version that anyone's agent can draw from.
One helpful way to think about it is raw context versus refined context. Transcripts and Slack threads are raw material: messy, repetitive, and sometimes contradictory. The brain turns them into the most trustworthy version of what your company knows, so nobody's agent has to start from the raw pile again.
A useful brain does three jobs:
- Lowers the cost of coordination. It handles the handoffs, status updates, and "where are we on this?" messages that eat up a team's week.
- Surfaces the problems most worth solving. Every business has more problems than people, and only a few matter at any given moment.
- Helps people solve them faster. When the busywork is handled, people can spend their judgment where it counts.
A few building blocks show up in almost every company brain: a log of decisions, a set of metric definitions (every company uses the same acronyms, but the math behind them differs), and a company wiki with pages for people, customers, and projects. The most valuable pieces are often shaped around the specific work your company does, so start by asking what your team asks its AI to figure out over and over.
Context only matters if someone uses it. Work backward from the jobs your team does every day, and let those decide what goes into the brain.
Build the judgment, buy the sensors
Once you know what a brain is for, the next question is what to buy and what to build. With the cost of building software falling fast, it's tempting to treat this as an either-or call. Most useful setups combine both.
A simple way to sort it: think of the tools that capture information as sensors. Note takers like Granola or Fireflies, databases, and AI platforms all collect information that wouldn't exist anywhere else without them. Those are usually worth buying.
The judgment layer is what you build. That includes your rules for what counts as a decision, how your company defines its metrics, and who should be able to see what. That logic is specific to your business, and it's the part that makes the brain yours.
Ownership matters here too. Keep your company's context portable, stored in formats like Markdown (plain text files any tool can read) or in a database you control. AI vendors have every incentive to hold onto your memory, and your context should be easy to move if your tools change.
Use what you learn to decide:
- Which of your current tools are sensors worth keeping
- Which definitions and rules only your team can write
- Where your company's context lives today, and whether you could move it tomorrow
Make it trustworthy before you make it big
A shared brain is only useful if people trust what's in it. Every update should follow the same four steps:
- Keep the source. Record where each piece of information came from, so anyone can check it.
- Propose the change explicitly. Treat each addition as an update to the company's official record.
- Log it. Keep an audit trail, a running history of what changed and when, so you can see what the brain knew at any point and undo a mistake.
- Assign an owner. No brain maintains itself. Finance should own metric definitions, engineering should own context about systems, and so on.
Sensitive information needs its own plan, especially for anyone who manages HR or finance. The practical approach is to label how sensitive information is when it comes in, then check who's asking before anything goes out, so people only see what their role allows. Bring your security team in early. In many cases the most valuable information for a brain isn't the most sensitive, and agreeing on boundaries up front makes everything smoother.
Once more than a handful of people rely on a shared brain, someone needs to own it. Many companies are creating an AI ops function to manage access, security, and upkeep.
Where to start: a decision log
All of this can sound like a big platform project. The session's advice was to start with one useful workflow and build from there. For most teams, that workflow is a decision log.
Every team needs to track its decisions, and AI meeting summaries tend to be full of false positives. A quick nod of agreement or a passing idea gets logged right alongside the calls that matter. A good decision log only captures the decisions your team would want an agent to remember, remind you of, or act on.
Here's the pattern members built during the session:
- Pull a sample of recent transcripts from your note taker.
- Ask your AI to label statements as decisions or not, and show its reasoning for each one.
- Correct it over two or three rounds. Explaining why something isn't a decision helps it improve fastest.
- Save the final rules as a skill, a reusable set of instructions your AI can run again.
- Schedule it to run on new meetings, and have it track what it's already processed so nothing gets logged twice.
Some teams add a third category for commitments, things someone agreed to do that aren't formal decisions but are still worth remembering. Your feedback decides what fits your business.
The same pattern of reading the source, applying your judgment, logging the result, and assigning an owner works for email and Slack too. A decision log is a small, contained way to learn the habits a bigger brain depends on.
What a decision log shows you
Once decisions are flowing into one place, a few things become visible that were hard to see before.
Overturned decisions. A decision made in a meeting sometimes gets reversed in Slack a day later. When decisions from every source land in the same log, the brain can flag the conflict and ask which one stands.
Meetings that are only updates. In one rollout at a company of roughly 500 people, logging decisions across every meeting showed which meetings produced decisions and which were pure coordination. That gave the team a clear list of meetings that could become async updates.
Better habits in the room. When people know decisions are being logged, they start naming them out loud. That makes the record cleaner and the decisions clearer.
Use what you learn to decide:
- Which recurring meetings could become written updates
- Which decisions need one official home, such as the quarterly financial plan
- What alerts you want, such as a heads-up when one of your decisions gets reversed
Join the conversations operators are having now
Company brains are moving fast, and most operators are figuring them out in real time. The teams making progress are starting small, keeping a human owner on every piece of context, and building on what works.
Operators Guild brings finance and ops leaders together to work through problems like this one in small, candid sessions. If you want to be part of those conversations, apply to join OG.