Hyper's Company Brain: How Should an AI Agent Knowledge Base Be Designed?

What made Hyper worth pausing on was not the phrase company brain. It was the way it names a problem many teams are already running into: AI agents can now edit code for several turns, write emails, and run scripts, yet they often have no idea which plan the team rejected yesterday. Ask Codex to change a checkout page and it may lean on product language from an old PR. Ask Claude Code to inspect an API constraint and it may re-open Drive while missing the later Slack decision. A human teammate naturally adds, “Don’t use that plan anymore.” An agent does not magically develop that shared memory.

I would treat Hyper as an architecture case study first. It is still early, and public materials are not the same as third-party validation. Still, the details on its YC page and in the Launch HN discussion are useful for clarifying what a company knowledge base for AI agents actually needs to do: it is not just document search, and it is not just an MCP connector. It is a way to let agents act inside the right, current, permission-aware company context.

Where Regular RAG Gets Stuck

Regular RAG is good at finding chunks in documents. You split Markdown, PDFs, and web pages into chunks, embed them, retrieve similar content at query time, and ask the model to compose an answer. BetterLink has covered that path in RAG + agent architecture, and it works well enough for knowledge Q&A, support FAQs, and codebase explanation.

Company context is messier. The agent does not only need to find similar content. It also needs to know whether the content is still valid, who can see it, and why the decision was made.

Old and New Information Collide

Take a small release decision. Monday’s meeting says, “Ship on Friday.” By Wednesday, customer feedback has changed, and the product owner moves the launch to next Monday. A vector database may store both statements. Which one comes first depends on the query, embedding, chunking, and ranking. If the agent retrieves the old “Friday” note, it will keep writing the wrong announcement and scheduling the wrong work.

A safer design keeps both facts but marks the new one as superseding the old one: who said it, when they said it, what scope it affects, and why the previous conclusion became invalid. Then, when the agent answers “Why was this delayed?”, it can trace the decision history instead of losing the old context.

Permissions Need to Happen Before the Answer

Once a company knowledge base feeds an action-capable agent, permissions stop being a detail. Sales, support, engineering, and leadership may ask about the same customer and should receive different scopes of information. OpenAI’s team connector guidance makes a similar point: ChatGPT only sees content the user is already allowed to access, and connectors respect existing permission boundaries.

That check should happen before retrieval, not after the model has already seen the context and is asked to behave. Filter out invisible data first; then retrieve, rank, and inject. Otherwise the agent can leak sensitive information through logs, drafts, or tool calls.

Agents Also Need the Reason Why

Many company documents record outcomes, not reasons. A design plan may have been rejected because the brand fit was wrong, sales heard customers push back, the technical debt was too high, or the team simply lacked bandwidth at that point. If the agent only sees the outcome, it may repeat the same mistake in a slightly different setting.

OpenAI’s memory update frames useful memory around carrying context forward, following preferences, and staying current over time. At the company level, I would add one more requirement: the system should explain the constraints behind a decision. Without that layer, an agent is just searching faster, not understanding the company better.

Alibaba Cloud - Top choice for developers, exclusive 15% off for Lighthouse servers

Get 15% Discount →Ad

What Hyper’s Public Materials Reveal

There are a few details in Hyper’s public launch that I care about. They do not prove the product is perfect, but they are more concrete than “put Slack and Drive into a vector database.”

The first detail is the split between episodes and facts. In the HN launch thread, the founders describe raw source items as episodes: documents, emails, calendars, Slack, Granola notes, and so on. Facts are the meaning extracted from those episodes. They are shaped like subject-predicate-object records, with a plain summary plus timestamps for when the fact was introduced and invalidated. The raw material remains available as the source of truth, while extracted facts support faster reasoning and retrieval.

The second detail is relationship edges between facts. The public discussion mentions facts being in tension with each other, derived from one another, or superseded by a newer fact. That matters for agents because company context is not a flat folder of notes. It is a history of changing decisions.

The third detail is hybrid retrieval. Hyper mentioned query expansion, embedding-based semantic search, Postgres full-text search, and reciprocal rank fusion. None of this is mystical, but it is practical. Semantic retrieval is good at meaning. Full-text search is better for exact customer names, ticket IDs, function names, and contract numbers. Fusion reduces dependence on a single retrieval path.

The fourth detail is permission tagging. Each fact carries provenance and access-control tags, and retrieval is evaluated only against facts and episodes that the user is allowed to access. Without this, a company brain quickly becomes a security liability.

The fifth detail is the split between hooks and MCP. The MCP documentation describes MCP as an open standard for connecting AI applications to external systems, and the OpenAI Agents SDK also supports multiple MCP integration options. MCP is useful when an agent actively queries a tool, but it depends on the agent recognizing when that tool should be called. Hyper said in the HN thread that for tools like Claude Code, Codex, and Cursor, it also uses lifecycle hooks to inject or extract context when a session starts, a prompt is submitted, or an agent turn ends. That trade-off is controversial, especially around installation transparency, but it points to a real issue: some context cannot depend on the agent remembering to ask.

Build a Company Brain as Checkable Pieces

If your team does not want to introduce a new vendor yet, you can still build a small version. Do not start by connecting every data source. Start by separating the system into pieces you can actually review.

Source: Raw Inputs Must Be Replayable

The source layer does not need full coverage on day one. Better starting points are product decision Markdown files, recent PR summaries, public issues, and support knowledge-base articles. Slack, email, and CRM data are dense, but they are also noisy and permission-heavy. Add them later.

Each source item should carry basic metadata: source type, original URL or file path, created time, updated time, author, visibility scope, and a hash. If a fact is extracted incorrectly later, the team must be able to return to the original text.

Fact: A Fact Should Be More Than a Summary

A usable fact needs fields such as subject, predicate, object, summary, source, introduced time, invalidated time, permission tags, confidence, and human correction records. This is not field-hoarding. It gives the agent boundaries when it answers.

For example:

Fact extraction will not be perfect on the first try, so you need a human correction path. In the HN discussion, when someone asked about messy and contradictory mature-company data, Hyper’s founder mentioned hard corrections through an MCP skill such as /correct. That direction is worth copying: let a human explicitly say, “This is wrong; use this instead,” and keep the correction trail.

Retrieval: Hybrid Search Is More Reliable Than One Path

Vector retrieval is useful for fuzzy meaning, but customer names, SKUs, ticket IDs, function names, and contract numbers often need keyword matches. I would split retrieval into three steps:

1. Filter by the user’s identity, project, data source, and permissions.
2. Run semantic search, full-text search, and graph-neighborhood expansion in parallel.
3. Fuse or rerank the results, then inject only a small set of highly relevant facts.

More context is not always better. If the context is too wide, the model will treat unrelated facts as hints. A better default is to inject 5-15 narrow facts with provenance and confidence. If the information is missing, the agent should ask a follow-up or check the original source.

Injection: MCP, Hooks, and Manual Context Have Different Boundaries

MCP is an entry point, not a complete memory system. It lets agents access tools and data sources, and it can expose capabilities such as search_company_facts, correct_fact, or get_decision_history. You can extend the pattern from agent tool calling and expose the company knowledge base as a tool.

Railway - Modern deployment platform, zero-config, go live in minutes

Start Now →Ad

Hooks are steadier because they can inject context automatically when a session starts or a prompt is submitted, without waiting for the model to call a tool. They also carry risk. Users need to know what was installed, when it runs, what it reads, and how to disable it. This point triggered pushback in the HN comments, and small teams should make notices, logs, and toggles visible.

Manual context is still useful. For high-risk tasks, letting a human choose which project knowledge is allowed for this run can be safer than full automation. AI-first does not mean every step should be unattended.

Governance: Correction, Export, and Audit Should Come Early

The more useful a company brain becomes, the more expensive it is to migrate away from. People on HN raised vendor lock-in concerns, and they are reasonable. If every agent depends on the same knowledge layer, export, deletion, backup, and audit are not bonus features.

I would ask these questions during the pilot: Can facts be exported as JSON or CSV? Can raw episodes be deleted? Does a permission change trigger re-filtering? Is there a log of which fact an agent used in which task? Does a human correction overwrite an old fact or preserve a history chain? Asking early saves debt later.

How to Choose Between the Options

These options solve different problems, so the names can be misleading.

If employees only need to ask, “Where is the expense policy?”, enterprise search or regular RAG is enough. If an agent is going to edit code, send emails, write sales follow-ups, or summarize customer risk, the system needs more: Is this fact still valid? Is the source trustworthy? Is the user allowed to see it? Does the action need confirmation?

OpenAI’s team connectors already bring content from team tools into conversations. The MCP ecosystem is making it easier for agents to connect to more tools. A company brain sits between those layers: it turns scattered content into company context that is continuously updated, traceable, permission-filtered, and reusable by different agents.

A 7-Day Pilot: Start With One Narrow Workflow

You do not need to connect the whole company to test a company brain. Pick one low-risk, high-frequency agent workflow and run it for a week.

Days 1-2: Choose the Workflow and Sources

Pick a clearly bounded scenario, such as “Ask Codex to update a small feature based on the latest product constraints” or “Ask a support agent to draft a reply from recent bug notes.” Connect only three source types: product decision docs, recent PR summaries, and public issues. Do not start with all Slack, email, and CRM data.

Write down the forbidden scope: no real emails, no production configuration changes, no finance or HR data, and no unsourced facts treated as conclusions.

Days 3-4: Extract Facts and Conflict Relationships

Extract 50-100 facts from those sources. Do part of it manually, then use a model to assist. Each fact should include source, time, permissions, and confidence. When facts conflict, do not rush to delete the old one. Mark the relationship: supersedes, supplements, conflicts with, or needs confirmation.

You can start with a simple schema. A complex graph database is not required for a pilot. Postgres tables, JSONB, full-text indexes, and vector extensions can carry a small experiment. Hyper’s public discussion also mentioned that Postgres remains convenient in this kind of system because structured metadata and graph-like relationships can live close together.

Days 5-6: Inject Context and Replay Tasks

Add a tool or hook for the agent: given the current task, return 5-15 relevant facts with provenance. Then replay 20 real tasks and track three numbers:

Vultr - High-performance NVMe VPS with 32 global locations, one-click Docker deploy

View Pricing →Ad

• How often do humans still need to add background context?
• How often does the agent cite stale or wrong facts?
• Does any unauthorized fact appear, or does broad context make the agent drift?

Do not judge only by whether the output looks polished. The value of a company brain is reducing repeated explanations, reducing stale-fact mistakes, and making the agent more cautious when evidence is incomplete.

Day 7: Expand, Pause, or Change Direction

If only a few of the 20 tasks benefit, do not expand to the whole company yet. The workflow may not fit, or the fact extraction may be too coarse. If follow-up questions drop, stale citations go down, and no unauthorized facts appear, add one more source, such as meeting notes or a curated Slack channel.

The next step is to combine this with AI agent monitoring and recovery: when the agent uses a low-confidence fact, a conflicting fact, or a high-risk action, route it to human confirmation.

Make the Risks Explicit Before Adoption

Once a company knowledge base connects to agents, it is no longer a simple information-retrieval project. A few risks should be written into the plan early.

The first is privacy and training boundaries. Hyper’s founder said in the HN comments that they do not train on or sell hosted data, and pointed readers to the FAQ and privacy policy. Because the official privacy page was not readable through my crawler, I would not infer the details. Teams should review contracts, data-processing terms, retention windows, and deletion workflows instead of relying on a launch post.

The second is hook transparency. Automatic context injection is more reliable than hoping an agent remembers to call MCP, but users need to know what is installed on their machines. Installation notices, runtime logs, disable switches, and visible configuration should be obvious.

The third is polluted history. Mature companies often have old documents that contradict each other, and newer is not always more authoritative. In legal, finance, religious, or government workflows, an older document may be the governing source. The system cannot simply rank everything by recency. Different sources and roles need different weights.

The fourth is vendor lock-in. The longer a company brain is used, the more it resembles part of the company’s operating system. Export formats, backup strategy, self-hosting options, and disaster exit plans need to be checked early. Without them, the short-term flow can become a long-term trap.

Let the System Say It Is Unsure

I like the direction Hyper is pushing into: if agents are going to move deeper into team workflows, they need more stable company context than regular document retrieval can provide. But implementation should stay grounded. Before calling it a whole-company brain, make sure the system can distinguish old and new facts, return to sources, filter by permissions, accept human corrections, and say “I’m not sure” when the evidence is thin.

A small team can start with one narrow workflow: three low-risk source types, a few dozen facts, and 20 real tasks. Run that first, then decide whether to expand. It is less flashy, but for agents that need to deliver actual work, it is much closer to usable.