Live data from Hacker News

Launch HN: Hyper (YC P26) – Company brain to power agentic development

news.ycombinator.com

61–70 of 88 posts

Re: Launch HN: Hyper (YC P26) – Company brain to power agentic development

#63
post #57

Earlier quoted context omitted.

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 con…

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 wh…

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

Re: Launch HN: Hyper (YC P26) – Company brain to power agentic development

#64

Earlier quoted context omitted.

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…

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

Re: Launch HN: Hyper (YC P26) – Company brain to power agentic development

#65

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.

Re: Launch HN: Hyper (YC P26) – Company brain to power agentic development

#66

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 memo…

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.

Post reply on HN