kanyesrthaker

the predicates are determined by Hyper. this lets hyper shape a "custom" memory system for every organization based on the shape of information coming in.

You are correct. In the onboarding process we install hooks to your machine (and also give an MCP option for unsupported agents that don't have a hook protocol). We do this because MCP is inherently unreliable -- you are at the whim of the calling agent to recognize the connection between the tool call description and the user's query. Hooks let you reliably run side effects as part of the lifecycle. All of this is configurable from our desktop UI.

Hyper's focus is on the entire end-to-end experience from data coming in to agents performing work. We have made several distinct architectural decisions that we think make a significant difference, though we will be verifying this more officially with benchmarks in the near future. The bigger picture is that we see Hyper as a product that exists beyond the memory framework. Memory is a core technology to get right, but we are handling the full roadmap from data coming into the system to the actual agent orchestration out the other end. Hyper already supports a limited set of agentic operations.

Appreciate the feedback. We are not currently a good fit for highly-regulated industries like gov't or medical, though we are working to meet those requirements. We currently run Hyper on our (cloud) infra because it's far and away the lowest-friction option for teams that are comfortable with it. Understand that it's not for everyone, and our security and compliance posturing will mature with time and iteration (we are a very new company!).

appreciate the congrats! This is a good question. The core thesis is that the brain is continually self improving. If your initial information is really bad or messy, then Hyper is going to only be able to start with that. But we provide manual refinement and correction options that will gradually make the brain strictly better. For example, we expose skills like `/correct` via MCP that make explicit, hard corrections against the brain. Over time, the longer Hyper is active, the more refined the knowledge will get. It's a very anti-entropy system :)

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.

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.

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

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.

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.

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.

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.

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.

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.