Launch HN: Hyper (YC P26) – Company brain to power agentic development
Models have gotten good enough that they can (mostly) take on long-horizon, complex tasks. We believe the bottleneck now is that these smart-enough models often lack information about your company, which is scattered in people's heads, Slack threads, stale docs, and in back-and-forth convos with AI.
MCP is useful for getting some info in front of an agent, but there are problems: (1) Once the session dies, so does the insight, so instead of copy-pasting a whole doc each time you're telling the agent to dig through Drive each time - not much of a win; (2) Even when MCP works, what it gathers isn't comprehensive, because people decide things on a whiteboard, brainstorm out loud, post a little in Slack, and scribble the rest in a doc, which leaves the agent working from partial information; (3) And even if it had everything, it doesn't do the meta-reasoning required to do a great job. If you paste in a Notion doc and it won't learn your design taste or your writing style unless you tell it to, and it won't know why a decision was made or when.
As undergrads 5 years ago, we were into the tools-for-thought wave and became power users of Notion, Obsidian, Roam, Anki, real believers in building a second brain. After GPT-3.5 came out we started to realize how much more powerful that second brain could be if an AI could actually read it, because suddenly it would know our backstory, our taste, our preferences, and unlock genuinely new capabilities. That’s why we’re building Hyper.
We know it’s not for everybody! But for people who do want to be on the cutting edge, this is a force multiplier that makes agents faster and better. It increases the number of tasks they can do, and how effectively they do them.
Hyper works by ingesting everything you give it access to, Docs, Slack, Email, Calendar, Granola, and synthesizes it into a knowledge graph of facts and their relationships with embeddings for semantic search. The memory system we’ve built is hybrid, with two modalities. Episodes are the raw source items kept as the source of truth. Facts are the meaning pulled out of each episode, stored as subject-predicate-object records with a plain summary and timestamps for when the fact was introduced and when it was invalidated (subject=person, predicate=works_at, object=company). Facts form a graph with typed edges between them: X is in tension with Y, A is derived from B, J supersedes K. Every time a new fact comes in we update the facts in its neighborhood, so the graph stays current, and that's how we handle stale information. When "we'll ship Friday" is later contradicted by "we're shipping Monday," the new fact supersedes the old one instead of both looking equally true, and we never auto-discard the superseded version, so you can still ask how you landed on Monday.
Every fact carries provenance back to its source and access-control tags for who is allowed to see it. At retrieval we query-expand, then fuse semantic search over embeddings with Postgres full-text search using reciprocal rank fusion, and we only ever evaluate a query against the facts and episodes that person has access to, which means two people on the same team can ask the same question and get different answers. We keep information fresh with webhooks where they exist and polling where they don't, hashing contents to catch changes for sources that don’t handle native dedupe. Agents read and write through two paths: lifecycle hooks in tools like Claude Code, Cowork, Codex, and Cursor, where we inject relevant context on every prompt and pull interesting facts out of every response, and plain MCP...
50 comments
[ 3.2 ms ] story [ 88.9 ms ] threadHyper doesn't copy your Gmail inbox or Notion workspace onto our servers. We extract the meaningful signal — decisions, insights, key facts and context — and discard the rest.
This sentence does you no good, it just says we exfiltrate what matters.
Your data is hosted on managed AWS infrastructure with AES-256 encryption at rest at the storage layer and TLS in transit.
This sentence is like a code smell right up there with military grade. The first claim applies to effectively every hard drive these days, the second claim applies to every website with http"s". They do not differentiate you, instead they show you don't know what claims matter. These copy-pasta claims work only for buyers who don't actually have any regulations to comply with.
and we're blazing towards making our compliance fit your needs as quickly as possible
Again, this does you no good.
• • •
PS. Did you get rights for Jetsons footage? On the one hand, copyright might not apply as it's a short clip and the form seems unsuitable for uses that would compete with the commercial purpose of the original, but by using it in marketing you could open yourselves up to failure to license and compensate the content owner for the implied endorsement.
How are you handling cases where multiple sources of truth contradict each other?
Does Hyper assume best guess or is there any human in the loop verification?
2. How do you deal with conflicting facts? In tech, the new is constantly replacing the old.
3. Is knowledge extraction real time? How fast is it in general?
Made me think this was for companies working on self-driving.
This looks great and congratulations on the launch.
I am also building in this space and wanted to get your views on a few things.
1. Are you building your own connectors to 3p systems? 2. How are you finding the sales motion? I found people to get the problem fast, but actually converting them seems rather slow.
Good luck!
Right now our measurements are primarily subjective; we have several customers tell us "Hyper let my agent draft outbound/do market research/run experiments overnight with no intervention or follow-ups, when I would have to constantly babysit it in the past." We have also run Hyper's algorithms on common benchmarks versus more traditional methods. I don't want to claim numbers before we've verified them, but Hyper performs significantly better.
We do not use RAG in the traditional sense (semantic similarity across chunked source documents). We use hybrid retrieval methods to fetch relevant information across our carefully designed knowledge graph, and then have shallow agents consolidate retrieved information into a format that the invoking agent can understand.
That said, this is the ultimate moat. Once everything about how to operate a business lives in your product, the business must rely heavily on it. I personally would only use something like this if I knew it was open source and that data could live on my own servers. If agents and my own team are consulting Hyper for things and you go out of business or move upmarket or something, it's pretty much back to the stone age for us.
Very useful idea though with a lot of potential, especially for companies like OpenAI and Anthropic looking for a moat!
I've always thought that knowledge graphs/expert systems, and even the broader concept of entity-attribute-value storage, got an unfairly bad reputation because of the 1970s/1980s "AI Winter."
And I think that perhaps this reputation is why so much of the oxygen in the RAG space has been consumed by the notion that "RAG = retrieval of fragments by vector similarity."
The difference now from decades ago, of course, is that now LLMs can do both the job of maintaining that graph at scale, and being able to agentically run successive queries to explore for best practices in any situation! And these have reached the scalability where any small business can build and use their own expert system.
I really want to see this approach win, because I think there's such an opportunity to explore even more data structures and approaches from the past and how their impact can be reimagined. If LLMs do indeed approach AGI, it will be in large part due to the ability to use tools (there's some evolutionary irony there, too) - and we should be trying every kind of underlying storage for those tools that we can, standing on the shoulders of giants.
(And curious what database you use for the knowledge graph - those are also a place where we stand on the shoulders of giants!)
You loose sooooooo much meaningful context and information when you transform something into a knowledge graph. Simple cases like "Gabe is CEO of Valve" map nicely to a graph, but things like "Matt Garman is CEO of AWS" don't represent that AWS is a sub-company of Amazon (with it's own CEO).
Additionally, one of my biggest gripes of Claude's memories and every memory system I've worked with is they completely fail to capture intent. The architecture notes I documented while doing a wild spike on a critical infrastructure component absolutely should not be referenced in every day work. Yet, somehow, that type of memory always works it's way into unrelated sessions.