Launch HN: Agnost AI (YC S26) – Extract user feedback from agent conversations (agnost.ai)

85 points by laalshaitaan ↗ HN
Hey HN, we’re Shubham & Parth, childhood friends building Agnost AI (https://agnost.ai), product analytics for teams building chat and voice agents.

We read production conversations and find behavioral failures like users rageprompting (cursing at the agent), repeatedly rephrasing the same request, correcting the agent, asking for missing features, or leaving after an answer that was technically successful.

We have an interactive demo with no signup here: https://app.agnost.ai?demo=true

Here's a demo video: https://www.tella.tv/video/agnost-ai-launch-hn-demo-9haa

The core problem is that chat and voice products do not have the same metrics as web apps. When the product interface is language, clicks and funnels become much less useful. Users also rarely give explicit feedback, and when they do it's usually sugarcoated. I barely type /feedback in Claude or Codex myself. Most users just curse, ask again, correct the agent, or leave. So product engineers get technical visibility from latency, errors, and traces, but still have to guess whether users got what they wanted.

We got here after building around agents for the last year and got a couple of founders asking for something like a PostHog for conversations for the AI assistants they were building.

We are not trying to be in the observability or evals space. Observability tells you what happened technically. Evals validate cases you already know. We're more on the discovery side like what users wanted, where they got frustrated, what they asked for repeatedly, and what new evals should exist.

Teams send us agent conversation messages through SDKs or OTel, optionally with metadata like account, plan, source, organization, etc. We cluster conversations into product-specific intents. Feature requests and bugs are default categories; most other clusters are created dynamically from the customer’s data and evolve over time. You can create your own cluster in plain English. If a cluster gets too broad, we split it. If a new pattern appears, we suggest it.

One AI video editor company used Agnost AI to find feature requests hidden inside chat. The biggest one was that around 70 users wanted auto-subtitles, but users said it as “add this text in this frame” 12x in a single session, “can you caption it”, “give me transcript of audio” and variations across languages. The team later built the feature.

Doing this over millions of messages without sending everything to an LLM was the hard part initially. In ClickHouse, “fetch the last 50 events by time across conversations” and “fetch all events in this conversation” want different sort orders, so we had to iterate a lot on sorting keys, partitions, materialized views, and projections.

For finding new clusters, sending everything through an LLM was too slow and expensive. HDBSCAN-style embedding clustering also gets painful at scale because of pairwise comparisons. We first split conversations into segments based on cosine drift, run BIRCH to compress the candidate space, and then use HDBSCAN-like clustering on the smaller set. For matching existing clusters, we use embeddings, smaller classifiers/BERT-style models, and LLMs only as fallback for ambiguous cases.

We’re live with multiple companies and ingesting ~1M chat and voice messages per day. Pricing is public: Starter is free, Pro is $499/month, and Enterprise is for higher volume, security, retention needs. We use each customer’s data only for that customer. We are SOC 2 Type 1 compliant, Type 2 is in progress, and our SDKs are on PyPI and npm.

We’d love feedback from the HN community and people building chat or voice agents: how do you detect these signals today, what feedback methods have worked, and what would block you from trying this? Happy to a...

22 comments

[ 3.0 ms ] story [ 50.1 ms ] thread
why would i pay $499/month for this when codex costs $199/month and can do everything you described
> Rageprompting

Lovely name! I implemented profanity monitoring in my Hermes setup to identify "learning opportunities" for my agents. It is quite useful. If you are budget-conscious, one challenge is determining what is the smallest number of previous rounds that Hermes needs to correctly infer what it did wrong. Curiously, Claude Code is horrible at figuring out what it did wrong. I often read its memories, and they are rarely useful.

I thought startups wrapping prompts would require something a more complex than semantic analysis, which is literally what this is. And for 500 bucks. Wow. Props for being able to sell this.

I don't get the appeal of the UI, why is it so complex/convoluted.

Without using agnost, what are some basic SQL queries I can run on my data to find outliers I'd otherwise be missing?

How far can I get with just keywords, common phrases, boring traditional analysis?

Depending on what I measure there, when is the right time for me to consider upgrading to something like Agnost/what is a specific example of what it will find that traditional/rigid analytics approaches will miss?

Well, good luck with the launch, this seems like an interesting product with potential.

However privacy is central in a service like this and I think you should probably beef up your representation of how you deal with that.

eg. "We use each customer’s data only for that customer" - well that customer may have hundreds of staff; how are they being consulted and onboarded wrt their own voices (or is that transcripts?) and messages being used in this way?

ofc you might argue that nothing in work is private but I do think you have some margin for improving the detail here.

My junior developer has a Claude Cowork skill she built to do this over about 25,000 messages a week to our agent, and it seems to work pretty well. Struggling to understand what $499/month would buy us here?
I built an in-house version of this a couple of years ago for where I was working. My concern would be that by excluding observability, you might end up creating a really selective dataset, whose conclusions you're then asking companies to take seriously when allocating resources to different possible roadmaps.

My guess would be that agent logs would highlight obvious feature requests and bugs for smaller companies - like customers expecting an AI video editor product to be able to add subtitles to a video by itself.

For larger companies who deal with a higher volume of inbound customer support / agent requests, there will probably be big, noisy, already-known-by-the-team query clusters that make up big portions of the dataset - for example, "billing issue with my subscription". After those big clusters you'll likely have a really long tail of different queries, and - without deep observability - no real way to rank their importance. I also think you'd be unlikely to understand the root cause of the product issue in a complex developed product with lots of users solely from agent logs. Most product teams can't make good product decisions consistently, and they're working with a lot more data.

If coupled with staying out of evals (which, btw, I wouldn't find trust-building, if I were a potential customer of yours), I think that it might be difficult to provide genuine value in this space for larger orgs - without evals it's easily dismissed as just fancy & mostly-contextless sentiment analysis.

But I hope I'm wrong! I do think that (though each org's needs probably have to be catered to in a very boutique way) there are huge gains available by rolling LLMs & language analysis into existing product workflows, and that what you're pitching is absolutely a part of what companies should be doing. We are, of course, meant to actually listen to customers - and LLMs/agents should be making that easier, not harder. Absolute best of luck!

I see a fair number of comments here advocating for either codex to hand-roll this themselves, or to simply punt to SQL. I do want to advocate for the difficulty of the problem, even if I can't speak to the company itself.

At the scale of a few hundred to a few thousand documents, especially short documents, there are a few out of the box methods that can yield reasonable results, whether it be embedding clustering or leveraging LLMs for tagging.

However as your (1) datasets gets larger (2) documents expand from tweets and text messages to 30+ minute conversations and (3) you build downstream analytics on top of the learned semantic units, you really start to feel the limitations of LLMs and embedding for reliable annotation. That doesn't even get into the nuances associated with taxonomy management, seasonality, and model drift.

TLDR; this problem solved effectively has a lot of value and is a lot harder than it seems.

Great launch!! There’s a lot of very silly comments of people saying they will vibe code this… errr good luck being the slop version of this startup. :/

It’s a cool product and I’m curious to see where you go. We build an MCP factory, where our enterprise customers use our product to build MCPs that their employees use in Claude or Codex. What would be cool for me is if I could use this to surface insights to them, rather than just to our team.

Why... why do companies keep taking every tiny feature and trying to productize it?

In the tradition of boring software, even before LLMs it was much simpler to just use your existing tools and hand-roll. With LLMs I cannot fathom reaching for a product for something small like this.

[flagged]
The distinction between observability and discovery is important. Observability answers "what broke" — discovery answers "what should we build". How you handle sessions that span multiple interactions or context resets? A user might express frustration in message 3 of a conversation but the root cause was a tool failure in message 1 that the agent recovered from poorly!
Congrats on the launch. Question about the data side: conversations tend to contain a lot of PII (names, emails, account details users paste in). When you cluster and surface example messages in the dashboard, is there any redaction step before storage/display, or is that left to the customer to filter before sending through the SDK? Curious how much of SOC 2 scope covers the message content itself vs the infrastructure.
that on the customer's side to redact the PII as you are the ones sending it and you'd know better than us
Extracting feedback from agent conversations is harder than it looks because users don't give explicit feedback — they rephrase their query, which is implicit negative feedback, or they accept the output and move on, which is implicit positive. The signal-to-noise ratio in natural conversation is ~5-10% actionable feedback at best. I'd be interested in how Agnost handles the classification pipeline. Are you using an LLM-as-judge approach (costly but flexible) or a fine-tuned classifier (cheaper but needs retraining)? And how do you handle the cold-start problem where you have no labeled data to train the initial classifier? For enterprise deployments, the integration with existing support workflows (Zendesk, Intercom tickets) is often the deciding factor — can Agnost map agent conversations to existing ticket IDs?