> 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.

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!)

really great perspective. A lot of techniques from the past aren't conceptually wrong, we just have the tools today to make them efficient. The intuition behind them was always reasonable, if you could amortize the cost of making them work at scale. Appreciate the vote of confidence!

And re: the graph -- Postgres stays king here. There are a lot of fancy database mechanisms for building systems like this, but the convenience of a SQL data structure that can tie the graph into structured metadata is pretty unbeatable. This may evolve with time as well.

Yay for Postgres! Curious if you find yourself using recursive queries in Postgres to traverse the graph - or is there an LLM in the mix that's looking at the "frontier" of relevant facts and choosing whether to go deeper, and whether an entity has an alias?

(Along those lines, I recall lots of this getting messy in a pre-LLM project the moment someone said "merge these two CRM accounts and their histories, but oh whoops turns out they were different all along, and only some of the updates should have applied" - there's a whole set of interesting challenges around attributing EAV when the very notion of object identity evolves over time. Whether a fact is relevant is really a judgment that can only be made with full context - but we now have tools that eat context for breakfast!)

very sharp questions, love 'em. Yes, your intuition is correct. We by default will gather information k layers removed from the "frontier", and then have a shallow agentic step that can determine if we need to go further and at what nodes (essentially doing a graph traversal without a fixed termination condition). Relevance detection is a hard problem; we think we have something good, and we're experimenting/iterating towards something great

It's a good idea to bet on this. There's a lot of business and domain knowledge trapped in random places and mostly aggregated in employees heads. Not very accessible to AI agents currently.

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!

Appreciate the vote of confidence! And definitely hear the concerns re: data control. We're of the opinion that it's much easier to have a trusted vendor securely handle the system, keep it up-to-date, fix issues with some SLA, etc. and prioritize that part of the user experience. Your data is always yours to export, port, delete, whenever you want it. And should something catastrophic happen, we'd make sure that we give you enough resources/guidance to make sure you don't lose any of your hard-built intelligence.

How does this relate to your privacy policy? Will you train on or sell the data that you host? Or inferences about it?

We do not train on any data, or sell the data that we host. Information on privacy can be found in our FAQ https://heyhyper.ai/faq and our privacy policy https://heyhyper.ai/privacy

Congratulations on the launch! Really intriguing product.

How well would it work for a company that has the kinds of artifacts that you mentioned, but that lacks the quality/precision/accuracy that Hyper might need?

I'm especially thinking about mature companies that don't sell software and that have made a lot of mistakes and memorialized inconsistencies.

Is Hyper just a bad fit for them? Or could there be a path toward refinement and correction that eliminates ambiguities, etc.? For companies like this, Hyper could provide the clarity that such a company lacks day-to-day.

How does your technical approach actually create accurate fact extract?

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.

In your specific example, we can use on external tool calls to supplement limited information. If the memory system isn't rich enough to get a good answer, we can always call back into the original data source for more information. Extraction is good when it's eager (extract more than you think you need) and rely on deduplication + graph orchestration mechanics to keep the graph size bounded.

There is also a capture problem. Imagine you hire an intern and you tell them "John Smith is the CEO of Foo". If they've never heard of Foo, it would be impossible to infer anything about the nature of Foo, unless they're allowed to look into the outside world. No system (even humans!) can capture 100% of information, but that doesn't mean the system is broken. The question is, can you organize and collect enough information to be able to (a) address most queries and (b) initiate deeper investigation if the information is incomplete? We believe the answer is yes.

Intent is very much the same way. Will hybrid search uncover your architecture notes at some point, for an unrelated reason? Almost certainly. Should there be enough surrounding context to indicate that this was written for a spike? Also yes (this is where Claude/markdown memories fail). It should be enough to still be (net) massively useful, and the error rate will go down over time.

Curious about the focus on subject-predicate-object records, are the predicates you are interested in configured somewhere, or is this automated (decides what are important predicates).

Curious, does it connect to my claude code, or ChatGPT automatically and constantly inject some kind of context in it. Or do you have to connect to some kind of a MCP.

Congrats on the launch!

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?

The current conflict resolution is fairly simple: always trust humans, and trust recent human info more than old human info. We're very aware that as the knowledge system gets more complex, we'll need more sophistication, including: - Human-in-the-loop verification - Role-based ranking, i.e. be more skeptical when an intern contradicts the CEO

Unlike many other memory systems, Hyper never actually deletes memories. It constantly reranks them based on confidence, which factors into how they're retrieved. So every statement has a full history and system of record for how it got there, and you can trace (with attribution) why Hyper gives the answers it does. If there's something that Hyper misses, we provide tools in-app and in-terminal-plugin that let a human explicitly correct what Hyper knows.

The intern probably knows more about their work than the CEO in 99% of orgs. The leaf nodes who do the work know more about anything than their managers (who think they know everything but, in most organisations, understand very little). Your system must keep the managers happy to be successful, which could prove a tricky circle to square.

fair enough :) that's why it's a hard problem! different people have different levels of "trustworthiness" and this is exactly the kind of implicit mental model that employees form over years of working at a company. Hyper aims to learn these things by being an active listener, and make decisions based on that knowledge.

That is a relatively simple system. It cuts out use cases.

For instance, history, newer information is mixed with older authoritative information.

The same thing for religious institutions, where the older items may be the more authoritative for the purposes.

Congrats on the launch! Where do you think the core differentiator is right now? I feel like there's a grave yard of Glean for small teams no? Maybe I'm imagining it?

Thanks for the congratulations :) There is no magic sauce when it comes to differentiation in this space. Ultimately it comes down to having a very deep understanding of the problem, and a lot of empathy and love for our users. We have certain threads we've discovered along the way that we're pulling on, but a lot of the differentiation in the long run will come from relentless iteration against user feedback. I am not sure what happened to any of the other companies that have attempted this challenge in the past, but we fully intend on capturing the market by not compromising on product/service as we iterate.

Hey!

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!

Thanks! We build as much in-house as possible. We've found that this is the only way to really build an excellent end-user experience without putting any of the burden on the user. Regarding sales, we've found that the most useful thing has just been putting the product in people's hands and demonstrating that it gives upfront value. The hard part with memory is that most of the value comes with compounding, so we've had to get creative with how we can show in 5 minutes how Hyper lets you do things you couldn't do before.

Thanks for the replies!

Would love to swap notes at some point if you are up for it?

sure thing, feel free to shoot an email to founders@heyhyper.ai :) looking forward to it

I totally support you guys so don't take it as a dig! But isn't this mindblowing that while you were building and launching, Opus 4.8 launched and made a bunch of things you mentioned above irrelevant? for example, memory between sessions is way better, dynamic workflows will spin up a ton of agents to do work in parallel, and the ecosystem must provide better apis to be relevant (salesforce, uipath goind headless). Again always support startups so cheering for you, but man things are changing so fast!

totally, honestly it's super inspiring to see how fast the field is moving. That being said though, I think there's a long way to go in this category. Efficient memory across tools, especially in a multiplayer/collaborative setting, is largely unsolved. And it's really hard to build something so elegant and simple that it appeals to all the people in the world that really have this problem, beyond the power-users in industries that already have high AI/engineering adoption.

Every new advancement from the model providers helps unlock new capabilities, but we are confident this "brain" idea is going to be core infrastructure for every company in the future. It extends beyond code and project management: we think about "what does the 'office of the future' look like? Ambient recording in every room? Smart whiteboards that turn drawings -> CAD -> kick off 3d printers?" and it's exciting to see how many unsolved challenges are on that road. Appreciate the support and excited to keep building :)

Pretty cool. I understand the concept, but I wasn't able to get a clear answer on what the app actually does. Is it an MCP server? Or some viewer for my agent-compiled notes? Or just a UI for me to set up integrations? I got to the integrations page, but I'd like to understand what the app does before I just start connecting all my data.

Update: turns out that when you run the app it installs a hook to run every time you start a session, submit a prompt, or agent ends a turn on all your coding agents / platforms. Zero notice was given, pretty shady. I get it, you want to ingest data, but installing things onto my system without being transparent isn't great.

We use hooks because they're the only reliable way to interact with the lifecycle of an agent without relying on the agent to constantly remember to make a tool call. It's much more reliable and guarantees a better end-user experience. We do explicitly say that we use hooks in the application, on the same page that you use to connect and manage your agents, but recognize that we can be more clear about it in the onboarding flow. Appreciate you trying out the product and also appreciate the candid feedback.

Nice job! But here is my idea: why not build an agentic AI workflow that mimics the streamlined production methods of Ford in the early 20th century? We already have extremely powerful models and APIs, but we still tend to cram everything into one employee's workstation without giving out different tasks to different people.

Interestingly enough, this is how Hyper is structured under the hood. Rather than have one mega-agent whose job it is to go in and try to solve every problem simultaneously, we prefer a "production line" of narrowly scoped agents to make small decisions to keep the knowledge graph up to date. More broadly, agent orchestration is a problem tightly coupled to the "shared brain" problem. Definitely exploring what this means for Hyper as we grow.

Interesting product. I know others building in this space. How are things going with existing customers? And how are you measuring deltas vs standard agentic processes? Are you using RAG under the hood?

Thanks for asking! Existing customers use Hyper consistently to power agents for email drafting, managing inbound, generating marketing materials, improving debugging workflows, and as a "backbone" for long-running parallel coding agents. Having relevant, narrow context at all times greatly improves performance.

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.

Why oh why does the website start playing music user didn’t ask for?

How does this compare to gstack?

1. Have you measured the value provided by the knowledge graph layer over straight enterprise search (e.g., https://www.glean.com/) Benchmarks, please.

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?

Appreciate the thoughtful questions.

1. I'll address this in two parts.

(a) Memory vs. Enterprise Search. I consider search to address targeted, stateless retrieval whereas memory solves temporal, tacit, and derived problems. Glean can tell you why a ticket was filed or answer a specific question regarding a customer call. But in many companies, important questions are broader: "What went wrong the first time we went with this vendor?" "How has our brand shifted in tone over time?". These cannot be answered by a few documents, and it's not obvious whether this information would be in Slack or Notion or Drive. It requires an active, entropy-fighting system that is going to extract information and keep track of how it evolves over time.

(b) Benchmarks: absolutely. Don't want to claim anything before we've published results, but Hyper scores very well on LoCoMo and LongMemEval, and we are constantly trying to bolster our set of evals. We will publish results more openly in the coming weeks. I will caveat though: many SOTA memory providers are converging on the top end of these benchmarks, and yet we don't see mass adoption. We believe that UX affordances are underrated and critical to get "company brains" working in real, messy businesses. Many of our users have come to us from other providers purely because the competition was too difficult to use and maintain across the org.

2. Hyper maintains a graph of information where each node is an extracted "fact." This happens continuously, in the background, live from every connector or connected agent. At insertion-time, new information is compared against relevant information. Our system (a DAG of agentic nodes) determines the relationships between these facts and makes appropriate updates: X derives Y, A updates B. For now, we rely on recency as the primary indicator of conflict (i.e. we assume more recent information is generally more true than old information). We realize that this will need to become more sophisticated, and are iterating.

3. Knowledge extraction is real-time and asynchronous, and should add next to zero latency to any existing system. We continually update the graph in our backend, without relying on a nightly compaction/dreams cycle, so information from the world should be reflected in Hyper's responses in close to real time. Retrieval can be slightly more expensive, but the latency is negligible compared to the overhead of the calling agent. We recognize the importance of performance (we both worked on on-device robotics!) and are happy to publish numbers as we measure them :)

I made a mistake; apparently Glean uses knowledge graphs too: https://www.glean.com/resources/guides/glean-knowledge-graph

This raises a follow-up question: what is your differentiation?

Fair enough, i was drawing the comparison between traditional enterprise search and what we do. There are several companies that borrow the graph-based data structure; this part is not so unique. They do have different methods for how that information is orchestrated, but I think I would reframe a bit: the end user problem does not start and stop with the memory algorithm and technical layer.

The main thing we see in the world is that (a) teams already struggle to coordinate information over many different personalities and data sources. This was a more dull problem before when the actual IC/execution overhead was so large. But now with AI the execution overhead is way smaller, and "being on the same page" is a much bigger problem. (b) As agents do more and more of the mechanical work in the company, it's vital that they have a consistent big picture-view to perform tasks efficiently without errors.

Hyper aims to solve this problem end-to-end; the memory system is a vital part of this, but Hyper does more. We already support native agentic email-writing and LinkedIn-drafting automations, and will be expanding on that front. Today it's a "brain that knows everything," but so much of the value is in using that brain to perform work in a self-improving way. And on the other side, we need to make sure that getting information into the system is as frictionless as possible. We care a ton about UX -- one-click integrations, using hooks to get context in and out invisibly and reliably.

How'd you get the license to use "The Jetsons" cartoons?

I can answer that one. They're public domain as a result of a trademark lapse by Hanna Barbera many years ago. Widely available and downloadable on the Internet archive.

How are you planning to handle California's CCPA?

Good question. User data is the right of the user. We don’t have automations for everything yet (we’re super early!) but any user has total right to request deletion, updates, or deliverance of their data, which we seek to comply with fully. You can find more information on our privacy and compliance progress here: https://heyhyper.ai/faq

This isn't a business

Curious what you mean, why not? Business is just a group of people creating a product or service so valuable people are willing to pay more for it than it cost to build. In what way do you think Hyper does not fit that model?

arent there a bunch of products just like this one?

It's a hot space right now! No one yet knows how this is going to shape up. We've realized (through tons of talking to users) that UX is a criminally underrated aspect of building this system effectively. The algorithms, infrastructure, performance, security have to be airtight, that much is true. But the reason that there is no winner yet in this space (even those these types of companies have been around for years) is because they often fail to deeply understand how users work, and how to build their products in a way that solves user problems comprehensively. It is a massive product design challenge; this is a core piece of infrastructure for how companies are going to be built in the future.

> The self-driving company brain

Made me think this was for companies working on self-driving.

Yes that's super fair feedback, we're changing the wording soon :)

why not just vibe code this?

several of our customers have tried. Turns out the long tail is very long, and the amount of maintenance/edge cases/access control issues/quality issues explodes dramatically. It's a tremendous amount of work to get right, especially as a company grows. If you have been able to vibe code this and see great results, would love to learn what you've done!

aren't the edge cases not generalizable and specific to the business? It doesn't seem like a one size fits all solution would work

Let me rephrase: vibe-coding something that will solve 80% of a company's problems in this domain still takes a tremendous amount of work, more than it seems on first glance, and it isn't worth the effort for many teams. We focus on solving this problem to the Nth level, full time, so that a company can exclusively focus on the things that are truly specific to them.

Hey HN! Kanyes here, one of the cofounders of Hyper. Here all day to answer any questions :)

As a person with a career in heavily regulated space who would very much like to try a product like this so we stop spending time on it in-house:

Hyper 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.

Tried it, none of the integrations work, they do not connect, notion, slack, etc... I think you probably posted this a bit too soon, IMHO. :/

Very strange, haven't seen this before. Could you shoot us an email at founders@heyhyper.ai with some more details about what you're seeing?

Congrats!!

Thanks Nils!

Congrats!

Thank you! Very hot space right now and excited to be building in it

congrats!

thank you !