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.
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.
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!
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.
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.
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.
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 :)
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
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 1,600 number blew my mind, and then I realized Atlassian employs almost 16,000. Kind of crazy.
Either way, I'd expect that those 1,600 people using AI to solve Atlassian's big problems would be better for the company in the long-run than reducing headcount with the same level of output
we currently just run wakeword detection on-device, though we're certainly considering expanding (mostly for latency reasons). Will give switchboard a look!