Hyper Company Brain: Engineering an AI Agent Knowledge Base

When you ask Claude Code to change code, it does not know why your team deleted that branch three months ago. When you ask ChatGPT about a product decision, it has to reread every document before it can answer. Explaining project history on every call is one of the real differences between agents and regular RAG: RAG is good at retrieving static documents, but company knowledge has three dimensions it does not handle natively: fact validity, permission scope, and the reasoning chain behind decisions.

On Hacker News, Hyper described itself as a “company brain.” That can sound like marketing language, but the architecture details its founder shared in the launch thread are useful: two-layer memory with episodes and facts, typed edges, a timestamp model, and two injection paths through hooks and MCP. This is not a product review. I am using those public details to unpack the design problem behind company memory: a five-layer checklist, a 7-day pilot path, and a risk table for evaluation.

Three Types of Context Regular RAG Cannot Handle

RAG retrieves documents, returns chunks, and lets the model answer. That workflow works for a static knowledge base, but company knowledge has three dimensions that regular RAG does not handle by default.

Traditional RAG ranks by recency or relevance. It cannot tell whether a piece of information has been superseded by a newer fact. Hyper assigns two timestamps to each fact: introduced_at records when it first appeared, and invalidated_at records when it became invalid. Retrieval filters out invalid facts instead of relying on the document update date.

Permission scope is more sensitive in a multi-person organization. An agent call may represent a specific team member, and that agent should not read content outside that member’s project scope. Hyper uses access-control tags to mark the visibility of each fact, and the retrieval layer filters results by caller identity before returning them. This is more granular than ordinary enterprise search, which often stops at document-level permissions. A company brain needs fact-level filtering.

Decision reasoning is where regular RAG struggles most. If you ask, “Why did we choose PostgreSQL instead of MongoDB?”, RAG might return the conclusion paragraph from an architecture document. That paragraph may not include the technical debate from three months earlier, the trade-offs, or the final decision logic. Hyper’s episodes layer keeps original conversation nodes, while the facts layer points to source episodes through derived from typed edges. Retrieval can then follow the relationship back to the reasoning chain, not just the result.

Hyper’s Two-Layer Memory Architecture

Hyper organizes memory into two layers: Episodes as the raw store, and Facts as the structured layer, connected by a knowledge graph.

Episodes layer: Episodes keep the original conversation nodes and do not discard context. They act as provenance anchors for facts. When an agent needs to trace a decision process, it can follow a derived from edge from a fact back to the original conversation snippet instead of reading only a summarized conclusion.

Facts layer: Facts use a subject-predicate-object structure. Each fact has a subject, relation, and object, plus timestamps and typed edges. The founder publicly described three types of typed edges:

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

View Pricing →Ad

Timestamp model: Each fact has two timelines. The T timeline records when the event happened, such as “the decision was made in March.” The T’ timeline records when the system ingested the fact, such as “this fact was written into the knowledge base in June.” The distinction matters because company knowledge often arrives late. Meeting conclusions may be recorded a week later, so the system needs to separate when something happened from when the system learned it.

Core architecture points:

• Episodes are not summarized away; they preserve the original conversation nodes, according to the HN founder comments and the Zep paper context.
• Facts are structured as triples, each with timestamps and typed edges, based on the public HN details.
• introduced_at / invalidated_at mark fact lifecycles, and the retrieval layer filters invalid content.
• Typed edges let the graph store relationships, not just facts, which is the main difference from a plain vector database.

The point of this architecture is not to store more data. It is to let agents find context by following relationships. A regular vector database returns similar chunks, but it does not know the logical dependency, replacement relationship, or conflict between chunks. Typed edges plus timestamps let retrieval results carry metadata such as where this fact came from, whether it is still valid, and whether it has been replaced.

The Two Paths: Retrieval and Injection

After knowledge is written, agents can use it through two paths: retrieval, where the agent actively queries, and injection, where the agent passively receives context.

Retrieval mechanism based on the founder’s HN comments:

• Postgres full-text search: keyword matching for exact queries such as the definition of a specific API endpoint.
• Embedding semantic search: vector similarity search for fuzzy questions such as “what did we decide last time about performance optimization?”
• Reciprocal Rank Fusion (RRF): combines full-text and semantic recall and returns results by an aggregate ranking.
• Access-control tag filtering: trims results by caller identity to preserve permission boundaries.

This differs from a pure vector database. Pure semantic recall may miss results for exact keyword queries. Hyper uses RRF to combine both recall paths and account for keyword matches and semantic similarity during ranking.

Injection path comparison: hooks and MCP are different data channels.

The two paths can coexist. Hyper’s founder said hooks are used for real-time context injection into agents, such as loading project docs when you open Claude Code, while MCP is used when an agent actively calls external tools, such as querying Notion or Gmail. But some HN commenters questioned hook transparency: does the user clearly know which data is automatically injected into the agent conversation?

During evaluation, check two things: whether hooks have explicit installation prompts, and whether the MCP server permission scope is controlled by an admin. OpenAI’s developer mode documentation says MCP apps require security verification, and Enterprise plans can use RBAC to control access. That makes the MCP governance model relatively mature, while hook transparency depends on product design.

A Five-Layer Company Brain Checklist

If you build or evaluate a company brain, check whether all five layers have a concrete answer. Missing any layer will show up in real use.

Layer 1 is data source ingestion.

• Tool selection: Notion, Gmail, Slack, GitHub, Linear, Jira, depending on the team’s workflow.
• Ingestion method: webhooks for real-time updates or polling for scheduled checks; webhooks are faster but require support from the source system.
• Data cleaning: filter noise, such as casual Slack channels; mark sensitive information; normalize encoding.
• Initial import: all history versus only new data. Historical data may contain many stale facts.

Layer 2 is the fact schema.

🔥 Stop wasting months on unwanted products! Validate your SaaS selling points with Adsterra on a tiny budget →

Test MVP Now →Ad

• Fact shape: subject-predicate-object triples stored in a consistent format.
• Timestamps: introduced_at for first appearance and invalidated_at for invalidation. Without both, lifecycle judgment is weak.
• Typed edges: at least derived from for provenance, supersedes for replacement, and tension for conflict.
• Conflict handling: automatically mark tension for human review, or choose the newer fact by timestamp when appropriate.

Layer 3 is retrieval.

• Recall mix: full-text keyword search plus semantic embeddings plus RRF fusion. Pure semantic recall can miss exact queries.
• Permission filtering: fact-level access-control tags that trim results by caller identity.
• Ranking: combine recency, relevance, and fact validity, and filter invalid facts.
• Latency target: retrieval response under 500 ms in practice; otherwise agent calls start to feel slow.

Layer 4 is injection.

• Path selection: hooks for real-time context injection and MCP for agent-initiated access. The two can coexist.
• Agent compatibility: whether Claude Code, Cursor, ChatGPT, and Codex support the chosen path.
• Governance model: whether hooks have transparent installation prompts and whether admins control MCP server permissions.
• Context size control: cap injected context length to avoid token overrun, and prioritize high-relevance facts.

Layer 5 is governance.

• Permission inheritance: map source permissions to fact-level visibility. Facts from a private Slack channel should not become visible to everyone.
• Audit logs: who injected which fact when, and which facts an agent read. Incidents need traceability.
• Human correction: mark wrong facts, design an invalidated flow, and support manual clarification facts.
• Data export: verify whether the complete fact store can be exported as JSON or CSV to assess lock-in risk.

The logic behind the checklist is simple. The source layer decides where data comes from. The fact layer decides what structure is stored. The retrieval layer decides how the system finds information. The injection layer decides how context reaches the agent. The governance layer decides who controls, corrects, and audits it. If any layer is missing, the knowledge base will get stuck in practice.

A 7-Day Pilot Path

A small team should not connect all Slack, email, or CRM data in the first week. Permissions are complex, and the noise is high enough to expose governance problems too early. Start with low-risk sources, then validate recall and correction before expanding.

Days 1-2: Choose low-risk data sources

• Public Notion docs, such as product roadmaps and technical specs.
• GitHub README files and Wikis, such as project architecture and API docs.
• Exclude private Slack channels, historical email, and CRM customer data because they are permission-sensitive and noisy.

Day 3: Design the fact schema

• Use 3-5 fields: subject, predicate, object, introduced_at, source.
• Do not aim for a perfect schema. The pilot is about validating the retrieval path; the schema can evolve.
• Define naming conventions. Use a consistent subject format such as ProjectX, and predicates as verbs such as uses.

Days 4-5: Test retrieval and injection

• Retrieval test: prepare 5-10 queries and check whether key facts are found.
• Injection test: choose one agent, such as Claude Code or Cursor, and verify that it can read the injected context.
• Record latency: check whether retrieval is under 500 ms and whether the agent cites facts correctly after injection.

Days 6-7: Replay and human correction

• Replay historical queries and check whether results include wrong or stale facts.
• Record errors: list facts that need to be invalidated and design the marking flow.
• Design correction: let humans add clarification facts and mark wrong facts with an invalidated_at timestamp.

Do not do these in week one:

• Do not connect Slack, email, or CRM, because permissions and noise are too complex.
• Do not chase a perfect schema; validate the retrieval path first, then iterate.
• Do not connect production data sources; use test data or public docs to validate the flow.

At the end of the pilot, you should have a working retrieval-plus-injection flow, 5-10 verified facts, and a correction process. Those are the prerequisites for expanding data sources: first verify that the system can find, read, and correct facts, then connect more tools.

KiloClaw - Managed OpenClaw for enterprise, enabling AI Agent orchestration and smart model routing

Get Started →Ad

Risk Table for Evaluation

Check seven risk dimensions before making a decision. Each one should carry a source and confidence level.

Of these seven dimensions, data export and vendor lock-in need the most attention during evaluation. The founder said in HN comments that export is supported, but I could not verify a full official commitment. That means you need to confirm whether the export format is structured, such as JSON or CSV; whether it includes the full fact store, typed edges, and timestamps; and how much cleanup would be required to migrate to another system.

Hook transparency is another risk that is easy to miss. Hooks inject context on the client side, and users may not know which data was automatically loaded into the agent conversation. During evaluation, confirm whether the product provides clear installation prompts and whether users can inspect or control the injected data scope.

Permission inheritance has a public technical direction through access-control tags, but the inheritance rules are not public. The practical questions are concrete: how does a fact from a private Slack channel map to fact-level visibility, and how does CRM customer data get trimmed by team? Whether you buy or build, this mapping logic needs a design.

Next Steps and Related Reading

If you want to go deeper into agents and knowledge bases, these related BetterLink posts are good next stops:

• RAG + Agent: Next-Generation AI Application Architecture — how retrieval results can drive agent decisions.
• AI Agent Memory Systems: Helping Agents Remember Context — personal agent memory architecture and how it differs from company-level shared memory.
• Workers AI + Vectorize RAG Tutorial — practical Cloudflare Vectorize details for building a small RAG system.
• AI Agent Monitoring and Self-Recovery — how to connect memory with execution so failures can be detected and retried.
• Agent Tool Calling in Practice — MCP and tool-calling details that complement the injection path.

Conclusion

Hyper is still an early product. Its public architecture details, including two-layer memory, typed edges, the timestamp model, and the dual hooks/MCP path, are still a useful case for learning how company memory should be designed. For small teams evaluating or building this kind of system, the three biggest checks are data export, hook transparency, and conflict handling.

Start with a narrow workflow: public Notion docs or a GitHub README, then validate retrieval recall and correction before connecting Slack or email. Do not start by chasing a perfect schema. Fact lifecycles, permission inheritance, and human correction flows all need real testing.

If your team already uses Claude Code or Cursor, a small next step is to try injecting project docs through hooks and observe whether the agent cites facts correctly. After that, connect memory with execution through monitoring and recovery, so failures can be detected and retried instead of repeated silently.