Rendered at 11:07:43 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
btown 12 hours ago [-]
> 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!)
kanyesrthaker 12 hours ago [-]
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.
btown 11 hours ago [-]
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!)
kanyesrthaker 7 hours ago [-]
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
jameslk 12 hours ago [-]
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!
kanyesrthaker 12 hours ago [-]
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.
danielrmay 10 hours ago [-]
How does this relate to your privacy policy? Will you train on or sell the data that you host? Or inferences about it?
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.
ibmmmm 2 hours ago [-]
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).
SkyPuncher 11 hours ago [-]
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.
kanyesrthaker 6 hours ago [-]
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.
zizhouwang 9 hours ago [-]
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?
kanyesrthaker 6 hours ago [-]
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.
ianpri11 17 hours ago [-]
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?
kanyesrthaker 17 hours ago [-]
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.
andy_ppp 15 hours ago [-]
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.
kanyesrthaker 15 hours ago [-]
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.
BillStrong 11 hours ago [-]
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.
alansaber 2 hours ago [-]
How does this compare to gstack?
dennisy 15 hours ago [-]
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!
kanyesrthaker 15 hours ago [-]
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.
dennisy 15 hours ago [-]
Thanks for the replies!
Would love to swap notes at some point if you are up for it?
kanyesrthaker 13 hours ago [-]
sure thing, feel free to shoot an email to founders@heyhyper.ai :) looking forward to it
implexa_founder 16 hours ago [-]
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!
kanyesrthaker 15 hours ago [-]
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 :)
jpathm 14 hours ago [-]
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.
jpathm 13 hours ago [-]
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.
kanyesrthaker 13 hours ago [-]
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.
m_kovar 16 hours ago [-]
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.
kanyesrthaker 15 hours ago [-]
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.
FailMore 14 hours ago [-]
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?
kanyesrthaker 13 hours ago [-]
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.
esafak 16 hours ago [-]
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?
shalinshah 16 hours ago [-]
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 :)
This raises a follow-up question: what is your differentiation?
kanyesrthaker 13 hours ago [-]
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.
SkyPuncher 11 hours ago [-]
How'd you get the license to use "The Jetsons" cartoons?
dtagames 11 hours ago [-]
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.
bensyverson 16 hours ago [-]
How are you planning to handle California's CCPA?
kanyesrthaker 16 hours ago [-]
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
dbbk 15 hours ago [-]
This isn't a business
shalinshah 15 hours ago [-]
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?
oliver236 14 hours ago [-]
arent there a bunch of products just like this one?
kanyesrthaker 12 hours ago [-]
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.
nilirl 16 hours ago [-]
> The self-driving company brain
Made me think this was for companies working on self-driving.
shalinshah 16 hours ago [-]
Yes that's super fair feedback, we're changing the wording soon :)
oliver236 14 hours ago [-]
why not just vibe code this?
kanyesrthaker 13 hours ago [-]
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!
asdev 13 hours ago [-]
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
kanyesrthaker 12 hours ago [-]
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.
vdineshk 2 hours ago [-]
[dead]
sanreds 11 hours ago [-]
[flagged]
donbventures 13 hours ago [-]
[flagged]
felixlu2026 7 hours ago [-]
[flagged]
mycelos 16 hours ago [-]
[flagged]
hiroto_lemon 17 hours ago [-]
[dead]
robshippr 16 hours ago [-]
[flagged]
kanyesrthaker 17 hours ago [-]
Hey HN! Kanyes here, one of the cofounders of Hyper. Here all day to answer any questions :)
throw-hyper-01 17 hours ago [-]
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. :/
kanyesrthaker 17 hours ago [-]
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?
nils_transload 17 hours ago [-]
Congrats!!
kanyesrthaker 17 hours ago [-]
Thanks Nils!
zpoliczer 17 hours ago [-]
Congrats!
kanyesrthaker 17 hours ago [-]
Thank you! Very hot space right now and excited to be building in it
codelemons 16 hours ago [-]
congrats!
shalinshah 16 hours ago [-]
thank you !
MagicMoonlight 16 hours ago [-]
[flagged]
dang 16 hours ago [-]
Comments like this break the site guidelines - e.g. this one: "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
- as well as the Show HN guidelines, which apply when people are sharing their work:
"Be respectful. Anyone sharing work is making a contribution, however modest."
"When something isn't good, you needn't pretend that it is, but don't be gratuitously negative."
You're welcome to make your substantive points thoughtfully, but please don't post like this.
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!)
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.
(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!)
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!
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.
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.
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?
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.
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.
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!
Would love to swap notes at some point if you are up for it?
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 :)
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.
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?
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 :)
This raises a follow-up question: what is your differentiation?
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.
Made me think this was for companies working on self-driving.
- as well as the Show HN guidelines, which apply when people are sharing their work:
"Be respectful. Anyone sharing work is making a contribution, however modest."
"When something isn't good, you needn't pretend that it is, but don't be gratuitously negative."
You're welcome to make your substantive points thoughtfully, but please don't post like this.
https://news.ycombinator.com/showhn.html
https://news.ycombinator.com/newsguidelines.html