Why building a company brain for your team is so hard

In the last few months we’ve spoken to 100+ AI-pilled founders about what they’re building on evenings and weekends.

There’s a clear pattern:

1. They started out building tools and agents to solve personal problems.

2. Now, they’re (frantically) trying to adapt those personal systems into company-wide solutions to help their teams benefit from the same gains.

A company brain gives a team’s AI agents shared knowledge, memory, and instructions for doing work. Building one means reconciling conflicting records, keeping context current, and respecting access permissions, while making the system useful to people who didn’t build it.

A popular project keeping these founders busy in their downtime is tinkering with a personal AI brain, or ‘second brain’; typically, it’s a collection of notes, research, and working context stored as Markdown files and organized in a tool like Obsidian.

Y Combinator president Garry Tan explains the value of his:

When a founder emails me about a crisis, before I even finish reading that email, my agent has already pulled every prior conversation with that founder, three portfolio companies that hit the same wall, and what actually worked for those people.

When my agent does anything, it does everything knowing what I already know. That's the difference between an assistant and a colleague.

Garry has done more than just popularize the idea: he's been building and iterating on gstack, which gives coding agents reusable workflows, and GBrain, which gives agents persistent knowledge across sessions.

Founders are connecting these brains to their usual ChatGPT or Claude sessions, and to more advanced personal agents like OpenClaw and Hermes, often running on a spare Mac Mini under a desk or in a home networking closet.

With that context, a personal agent with the right setup can help with tasks like these:

• Research a prospect or account before a call and draft the follow-up using what you already know about the customer.

• Help draft a weekly company update from meeting notes and project activity, using the team’s usual format.

• Compare new customer feedback with past interviews and flag what might change your product priorities.

Some founders are already saving hours with these systems. Others have something that works just well enough to keep them spending their weekends optimizing it.

This post shares what we’ve learned about why turning that personal AI progress into something a whole team can rely on is still so hard.

From a personal brain to a company brain

Once a personal brain starts helping a founder, rebuilding it for the team feels like the obvious next step.

For these builders, a company brain feels like the holy grail.

Making that shared context useful starts with choosing what an agent needs for the task in front of it. The LLM it uses has a context window: a limit on how much information it can process in a single request, measured in tokens (chunks of text or other data).

An agent can search files and fetch more information as it works, but it still has to choose what to include alongside its instructions, conversation history, and tool results. Context engineering is the work of assembling the instructions and information an agent needs for a task, within the model’s context window.

This becomes more important when a second brain automatically saves the agent’s own summaries and conclusions. A mistaken summary can become context for the next task, and several agents can build more work on top of it. Without checks on what gets saved and reused, one error can spread well beyond the original answer.

Garry describes it as choosing which books from a library to open on a desk:

Your company is not three books. Your company is a library. Every email, every meeting, every decision, its reasoning, every customer conversation, every post-mortem.

The question that determines whether your agents are geniuses or goldfish is who decides which three books are open on that desk. That's context engineering. And this is what a company brain is. It's the library plus the librarian.

Things get harder when you go from single player to multiplayer. The system has to reconcile conflicting information, keep up as the company changes, and respect what each person can see and change. Corrections need to reach the next person or agent using that context. Even a factually correct answer can miss the point: a weekly update might list every completed task without flagging the customer problem that needs the founder’s attention.

In practice, the way most small to mid-size companies generate value is a product of their own habits and processes, often with plenty of chaos.

When it comes to adopting AI, it’s still often one or a handful of AI-pilled founders and team members building and rebuilding tools and workflows as the tools and techniques evolve. They’re getting much of the benefit themselves and struggling to spread those gains across the company.

Building with customers and using agents in our own team has made us increasingly opinionated about this problem. If you’re building a company brain and want help making it useful across your team, get in touch.

Five problems keep coming up:

• Builder dependence: the system works best for the person who built it.

• Conflicting records: agents need to reconcile multiple versions of the same work.

• Context drift: saved information falls behind the company.

• Permissions: private context can travel into shared output.

• Maintenance: someone has to keep the system useful.

1. The system is glued to the person who built it

One founder I speak to has spent hundreds of hours building a personal Hermes agent running on a spare Mac Mini. It connects to his email, Slack, CRM, and call recordings, keeps ongoing notes on deals, and helps him research prospects and prepare for customer conversations. In one sense, he’s living the dream.

He walks me through an event-planning example: a saved workflow finds people in his LinkedIn network in the right city, checks them against CRM history, and builds an invitation list with contact details and photos. He says it takes him about 15 minutes to produce a list a teammate has been working on for days. His team now brings him (the CEO) work because his setup can finish it faster than they can. I wouldn’t let that become a habit.

He wants to give them the same capability. But using the system means understanding how it thinks, which tools it can use, and how to recover when it breaks. It also runs through his personal accounts and contains private context, which makes sharing it a separate problem. He is glued to a system that works best when he operates it.

After spending that much time building an agent, you learn the nuances of how it works (and where it doesn’t). Much of what makes the system work exists in your head.

This founder wants reusable workflows that help his customer success manager turn usage data into a customer deck with the business judgment he brings to it. Until he can make that judgment part of the workflow, his team still needs him to guide the work.

2. Duplicate and conflicting records confuse agents and teammates

Another team describes several people using different note-taking tools on the same sales call. That leaves three slightly different versions of the same conversation. Each person’s agent may work happily from their own notes and draft a follow-up.

A company-wide agent can inherit all three, then has to recognize that they describe the same call, reconcile any differences, and check whether someone has already acted. Someone still has to work out which notes to trust and update the CRM manually. The tools save individuals work while creating another job for the shared system.

Another example from a Toyo customer is a weekly company update. It summarizes what happens across the business using meeting notes and activity in connected tools. To report who does what, the agent needs a company roster that connects GitHub usernames to the right people. Access to each tool doesn’t give it that consistent picture of the team.

Matching different usernames to the same person is an entity-resolution problem. The agent needs to know that records refer to the same person before it can report their work accurately.

3. Context drift leaves agents working from an old version of the company

Context drift happens when the company changes but the information an agent relies on does not keep up. People leave, responsibilities move, and decisions change while old context remains available to reuse.

One technical founder describes an agent that keeps suggesting a former employee’s quote for a landing page. The person no longer works at the company, so the founder doesn’t want to feature them on its sales page. The agent lacks that context. Now the founder has to work out how to update its memory so it stops making the suggestion.

Any AI knowledge base needs a way to keep up. A source link lets you check where an answer came from, but this isn’t enough: you (or your agent) still need to know whether that source applies today.

When several agents work from the same stale context, they can spread the mistake through reports, drafts, and team updates. People spend time checking and correcting work that was supposed to help them. In the teams we’re speaking to, this is one of the biggest reasons a promising first version loses users or gets abandoned: the company keeps moving, and nobody keeps the agents’ context current.

Corrections need a route back into shared AI agent memory. If a correction stays in one person’s chat, the next agent can repeat the mistake.

The team needs a way to update the shared context and make clear which information replaces the old version.

4. Your personal agent knows things your team shouldn’t

The founder from the first example can’t hand over his Hermes setup because it accesses Slack and email through his own accounts. It sees what he can see, and its memory mixes useful company knowledge with personal context and sensitive internal discussions. Giving colleagues the same interface would also give them access to information he doesn’t intend to share.

Another founder describes what happens when his team’s Hermes agent references a sensitive HR discussion in a public Slack channel. He handles the situation, but says trust in the system drops off a cliff afterwards.

Access boundaries have to hold when an agent reads a source, saves a summary, and shares its answer. Information it can use in a private answer to a founder may not belong in a team channel. A summary can expose the same sensitive information as the original source.

Companies already struggle to manage who can access which systems and what each role is allowed to do. A company brain adds another layer: who can read the shared context, change an agent’s instructions, and share its output?

In our experience, flatter teams with fewer access restrictions have an easier time getting these systems working across the company. Larger organizations have more roles, reporting lines, and information silos to account for. The brain has to respect those boundaries even when it combines information from several tools.

5. Keeping it useful becomes somebody's job

Another founder describes a company agent that answers questions from contracts, project history, and retrospectives. Then a software update breaks it, and fixing it requires a manual repair on another computer. She’s busy putting out fires in the business, nobody else owns the upkeep, and the agent goes unused.

The founder experimenting with agents still has a business to run. Investigating weird output and repairing connections take time away from the work the system is supposed to help them finish.

We see this in our work with Toyo customers. One pilot uses an agent to draft a weekly company update from meeting notes and activity across connected tools. Two weeks into making it reliable, we’re still tuning the reporting window, source references, and information returned by those tools.

A mostly correct update can frustrate a founder who needs to make decisions from it. If an agent invents a completed task or credits the wrong person, someone has to investigate before relying on the rest of the report. The summary saves time to produce but creates more work for the person reading it.

It feels like an 80/20 problem: the first 80% gets you a plausible update, while the last 20% gets you something you can rely on. That last stretch takes repeated testing and tuning, and it can demand more work than getting the first version running. Founders rarely have spare time to give it.

A recurring workflow needs an owner who notices failed runs, investigates odd answers, and checks that it still helps the team.

Judge your company brain by the work it actually helps finish

It's easy to lose the forest for the trees with agentic systems. The payoff founders want is a system that saves people time and helps agents complete valuable work across the business. That promise makes it tempting to keep connecting sources, organizing memory, and rebuilding workflows without checking whether the team is getting more useful work done.

The gains people see from coding agents don't automatically carry over to other knowledge work. Compilers and tests give an agent concrete feedback on some mistakes. Code can pass those checks and still be wrong, but they give the agent something to work with as it iterates.

A research summary or company update has more shades of gray. It can read well and get its facts right while missing the point. Whether it's useful depends on who needs it, the decision it supports, and what the company is trying to achieve.

A research lead at a large design agency describes the trade-off to me: AI helps her team move through discovery and research planning much faster, but they still have to check the output in detail. Even with reusable instructions and guardrails, models invent details or get facts wrong. Summaries and decks need careful human review before the team can use them to make decisions or share them with clients.

The time saved in research comes with work elsewhere: checking sources, correcting mistakes, and deciding whether the conclusions hold up. The useful measure is how much effort it takes to get to an output the team can trust.

Pick one recurring job and collect examples of an output the team would trust. Put the workflow in a colleague’s hands and run it more than once. Count the time spent reviewing, correcting, and maintaining it when deciding whether it saves time or money, or creates enough additional value to justify the work.

Your company brain needs someone to look after it

In October 2026, building a system that saves and shares company context is still hard to get right. Keeping a company brain consistently useful can feel like a product management job inside the company: deciding what it should do, testing the output, and keeping up as people and priorities change.

The teams pushing hardest with AI are already busy building, trying new tools, and taking on more work. They rarely have a spare product manager to dedicate to the system that’s supposed to save them time.

If you or an AI freak on your team has the time and aptitude, you may be able to build a company brain that delivers what you need. Account for the time it takes to manage it and keep it working, as well as the initial build.