Product Catalog

HY

Hyperprobe

Hi HN, this is Shailendra and Karan here. We are building a fast and safe way for coding agents to debug issues live in production. When prod breaks, it lets Cursor, Claude, and others drop virtual breakpoints or probes safely in your running code, and extract the exact variable values that logs don’t have. All this saves time and effort for engineers who’d otherwise dig through logs and traces or redeploy with console.logs or print statements until they find the root cause. Here is the link to the video that explains this: https://www.youtube.com/watch?v=ivV7I--ta5c Agents write most of our code now. This shrinks the useful context engineers need to debug AI written code, a problem not helped by the limited telemetry added in the same code by AI. So when something breaks in prod, the first instinct for an engineer is to open logs or throw them to your agents. But if the line you are looking for is not there, agents will start guessing the root cause on non-existent data, forcing you to add a log, and redeploy. This analysis-inference loop of agents with existing data does not come cheap, burning a lot of tokens. And the add log, redeploy cycle is so slow and painful that it makes engineers hate on-call. Our approach lets agents capture telemetry on-demand at the exact moment and point of failure, killing the log-redeploy cycle and getting the most accurate RCA while burning fewer tokens. The obvious problem is making it work on a running service. You can't pause a live service the way you'd pause a debugger on your laptop. Getting the value out of a running process safely, without pausing a thread or slowing the host is the challenge.We are making this happen. Before this I ran engineering at a 100 member team. Then Karan and I spent three years on HyperTest which was a testing tool. At HyperTest, we turned production traffic into integration tests using OpenTelemetry. That was production instrumentation too. The hard parts of pulling real runtime state out of a running service without breaking it, were the hard parts we learnt to put together. We learnt some other lessons the hard way too. HyperTest tried to prevent bugs with better tests, and adoption was a fight every time. Calls kept getting cancelled because teams were firefighting production. Testing was hygiene. Broken prod was hair on fire. This made us see where priorities lie. This seeded the idea of building a truly autonomous on-call agent i.e. one that takes an alert, probes, diagnoses and fixes it in a few minutes. But this is how it works as of now: You talk to your coding agent the way you already do. Tell it what's wrong: "checkout returns 200 but some users are seeing their order fail, find out why." It locates the line in your local code, connects to us over MCP, and drops a probe on that line in the running service. The probe is read-only and sits dormant until real traffic hits. When hit, it captures the local variables at every frame of the call stack at that exact moment. It hands them to the agent, which diagnoses with real data. There are two pieces. An SDK that runs inside your service, and an MCP server your coding agent talks to. The SDK is what makes setting probes (virtual breakpoints, log or metric) possible without a redeploy. In Node and Python it hooks in-process. In Java it attaches as a JVM agent, instrumenting at the bytecode level. Either way the service keeps running and serving traffic. Nothing pauses. When your agent wants to look at a line, it calls the MCP server, which tells the SDK to place a probe there. When a request hits the line, the SDK captures what the probe asked for, sanitizes it in-process, and streams it back to the agent via the MCP. This can run inside prod, so a probe can read any value sitting in that variable. We ensure redaction happens in-process, inside your own container's memory. This is before anything goes on the wire. Keys like password, token, authorization, ssn and credit card are redacted by default and you add your own. Also the probes read but never write, and if you want no captured state to ever leave your network you can self host the server, broker, and even the database in your infra. On overhead: when idle, the SDK adds negligible memory and effectively nothing to throughput and response time. Probes only cost anything while actively capturing. Also captures are bounded. A separate monitor watches in real time and pulls every active probe if overhead ever spikes. Every log-and-trace tool hands the agent data that already exists and asks it to reason backward to what probably happened. We think it is more useful to give agents eyes and ears into the running code, so they capture what they need when they need it, right at the point of failure. This seems like the simplest and fastest way to debug prod incidents. We’d love the community to try this in any environment to debug any known or unknown issue by just chatting with your coding agent. And let us know what more features you need to make this a truly autonomous on-call agent Supported platforms: NodeJs, Java, Python.

AU

AuditBadger

Hi, Wanted to share something I've been working on for over a year. AuditBadger is a compliance management platform that uses AI to write policies (there are underlying "templates" with basic requirements), rewrite controls (or trust service criterions) to match the company context, help figure out your own controls, does initial risk assessment, and business continuity planning (which at least gives you an example of how the process should look like). Fun fact - I wanted to share this a year ago, but then I spotted something similar here. The most common comment was about lacking the SOC 2 report, so I decided to pick the fight. I got SOC 2 Type I first, and then recently finished SOC 2 Type II using the tool alone. It took some time - both learning the process, the SOC 2 gotchas, and implementing automatic evidence collection. We're now adding support for the European AI Act and NIS 2; HIPAA is already there (though it requires me to explicitly enable it for customers who want to test it), and CyberEssentials and ENS are coming later this year. The platform is now complete, but my business partner (ISO 27001 Lead Auditor) and I are still dog-fooding it. Everything we build is either based on our own pain points or our customers'—most of them joined our Slack where we try to help them if they get stuck. If you have any questions, I'll be happy to answer them all.

FA

FutureSearch, AI forecasting you can verify

*Title:* Show HN: FutureSearch, AI forecasting you can verify AI forecasting is now approximately superhuman. Today, FutureSearch is exiting our long public beta and launching. We started FutureSearch in August 2023. (We’re the original AI forecasting company, at least in a Tetlock-ian, “forecast anything” sense.) We’re currently #1 of 194 in the most competitive AI forecasting tournament [1], and we score above the #3 and #2 human forecasters in the premier mixed human-bot tournaments [2]. Many people on HN seem to equate forecasting with prediction markets and finance. FutureSearch is not a financial tool, in the same way that “deep research” is not a financial tool. Yes, we do evaluate our forecaster on prediction markets [3]. But forecasting is about being as accurate about the future as possible, and the real game is in forecasting scientific progress, geopolitics, and the future of humanity. Our founding team came from Metaculus, where we pushed human forecasting to the limit on questions like when AGI would arrive. At. FutureSearch, we co-authored the AI 2027 timeline forecast, where we predicted superhuman coding and research would come around 2032, longer than the other authors, but still shorter than skeptics [4]. Thousands of people used the FutureSearch beta and ran >10k high-effort forecasts, on all sorts of diverse topics. Ask it anything about the future. We now support decision forecasts too: “If I do X, will I achieve this outcome?” Forecasting, as a capability, is useful even at the level of expert human crowds. But we predict that we will soon have strongly superhuman forecasting. People who bet against AI capability trend lines tend to lose, and the trend line in AI forecast accuracy tells a pretty clear story [5]. There’s no reason to think the best human forecasters have figured out everything predictable about the world. There’s a lot more signal to be found. And if you’re skeptical, try it. We’ve seen our fair share of exaggerated claims about AI forecasting accuracy [6]. So part of the reason we made the free tier give a few of our highest effort forecasters free is to let anyone verify the quality. [1] https://www.metaculus.com/tournament/summer-futureeval-2026/ [2] evals.futuresearch.ai [3] markets.futuresearch.ai [4] https://ai-2027.com/research/timelines-forecast [5] https://www.astralcodexten.com/p/the-ai-superforecasters-are... [6] https://www.lesswrong.com/posts/uGkRcHqatmPkvpGLq/contra-pap...

HT

How to build and self-host a code review agent

Hey HN, I've had a side-project that I've slowly ticked away at over the last year called Tilde. Tilde is a harness SDK platform - I've tried to take the best things of OpenClaw, Hermes & other harnesses and decompose them and make them available as cloud API building blocks. You can use Tilde to create AI agents for your use case, fast and self-host the agent's yourself. The documentation (and attached blog post) leave a lot to be desired in terms of technical documentation but hopefully the attached git repo does a good job of showcasing the API. https://github.com/trytilde/examples

RS

Replicant Space

During Christmas 2025, I found myself burnt out from work. The last few years had been hard, and multiple redundancies saw the company I loved reduce down to just a handful of remaining staff. As a coping mechanism, I kinda disassociated for a while - throwing myself into my personal projects. AI was destroying the passion I had for coding. I tried to find some meaning in development again. After months of throwing myself into creating this game, I slowly fell back in love with coding. I taught myself a bunch of technologies that I was previously unfamiliar - Astro, Flask, Redis, Celery, Just. Anyway, this is Replicant Space. It's free. I love building and playing it. There's a cool story. Aliens are awesome. Feel free to poke the API and take over the galaxy.

FL

Flashpaper

Hi everyone! This is my first HN and I’m very new to the scene. My name is Min from Bangkok. At first, I just want to create a dead man's switch for personal use and for fun. then, I think about information that self destruct like a spy movie. after that, I try to come up with the better version of Privnote or Bitwarden with self-destruct and some kind of censoring or blocking download ability. Somehow, end up with this product. :O Flashpaper is for sending any information that would be burned after reading (with counting down timer like Mission Impossible movie ! or after 24 hrs max if not opened) Encryption happens in browser and because the key stays after # in the link; server never sees the key (Zero-knowledge for web use) and— because I’m a newbie. I don’t want to connect to database because I don’t have the money and I want things light and simple. So, that’s why Flashpaper keeps things in RAM-only, no database. For AI Agent side, Flashpaper provides a REST API and an MCP server so agents can create secret links easily in dead-drop style that can be claimed only once. The second claim would get a 404 which means someone already took it. However, for the agent API flow, the server sees the plaintext for a moment before encrypting, so this flow is not zero-knowledge like the web flow. Overall, I think it work quite well for web use, but for agent API use, I am not sure this is enough security. All the limitations are listed in SECURITY.md. Some feedback would be appreciated. I make it open source with MIT license, with honorware policy for Enterprise use, like self-hosted docker. Here is my repo https://github.com/mmmpym/flashpaper and you can try it here https://flashpaper.app Again ! Please feel free to tell me what I missed. Min

RI

Rise-reforming

Hi HN! This is George, Lucas, and Jona from Rise Reforming (https://www.rise-reforming.com/). We’re developing a process to convert gas produced at landfills, farms, and wastewater plants (“biogas”) into higher value chemicals. Our technology is modular, designed to be deployed and operated on-site. Think of us as a chemical project developer; we sit between biogas producers (suppliers) and chemical end users (customers). We pay biogas producers for their gas and we make money from selling our chemicals. We're starting with dimethyl ether (DME) as our beachhead chemical because of its high-margin use case in the cosmetics industry and ultimately targeting methanol – a versatile and widely used industrial chemical. Being in a two sided market allows us to target two large problems. (1) On the chemical side: The multi-trillion dollar U.S. chemical and fuel industries are vulnerable to geopolitical conflicts and climate-driven natural disasters. The Iran war has caused global methanol prices to skyrocket – even in the U.S., a net exporter of methanol. (https://www.spglobal.com/energy/en/news-research/latest-news... the US). In 2021, Winter Storm Uri wiped out 60% of U.S. organic chemicals production for at least a month (https://www.dallasfed.org/research/swe/2021/swe2102/swe2102c...). The problem? Centralized production and fossil-fuel dependence. The solution isn't unknown; decentralized, fossil-free production could insulate supply chains from these shocks. But distributed green chemical production has yet to become cost-competitive with the status quo. Unlocking it requires the right feedstock paired with the right process and strategy. Also, the chemical industry’s reliance on fossil fuels makes it responsible for 5-6% of global greenhouse gas emissions. About 40% of the industry’s well-to-gate emissions come from just the extraction, processing, and transportation of these fossil fuels (https://rmi.org/resources/chemistry-in-transition-charting-s...). (2) Biogas is an ideal feedstock to address Problem 1. It is decentralized, plentiful, and a large part of it is not properly utilized. Biogas is a mixture of methane (CH4) and carbon dioxide (CO2), produced as a result of anaerobic digestion at landfills, farms, and wastewater plants, and can be used as a raw material in chemical manufacturing. The U.S. produces around 780 billion cubic feet of biogas a year – if we converted all that biogas into methanol, that’s about $20 billion a year. Currently, about 60% of this biogas is either burned for power/heat (low-margin and unreliable) or flared altogether. The rest is used in the highly subsidized renewable natural gas (RNG) market (https://americanbiogascouncil.org/abcs-data-digest-lite-july...). The result: many biogas producers leave substantial revenue on the table and experience huge operational headaches. Our modular technology takes in biogas, electricity, and water as inputs. Co-location with biogas producers allows us to tap into their existing infrastructure and speeds up permitting vs a greenfield project. Our 3 step process is outlined below: Step 1: We clean the biogas of contaminants. That means running the gas over specialized adsorbents that trap any nasty sulfur-containing and silicon-containing compounds we don’t want in our process. Step 2: We reform that biogas into an intermediate gas called syngas through the bi-reforming process, which combines the novel dry methane reforming reaction with the legacy steam methane reforming reaction. Syngas is a versatile combination of H2 and CO and is the building block for many chemicals, allowing us to be a platform company. Step 3: Lastly, we upgrade that syngas into our end chemicals. We do this step using conventional catalysts and operating conditions. The modular approach paired with our patent-pending integrated process makes our solution one of the cheapest ways of making green chemicals. Where are we today? We’ve completed our proof-of-concept in the lab and just broke ground on our pilot plant at a Chicagoland wastewater plant that currently flares all of its biogas. We will convert that wasted biogas into methanol. Estimated commissioning is Q1 2027. We all met at the University of Chicago studying Molecular Engineering and started the company back in June 2024. Rise Reforming’s first iteration came after attending a talk from an Argonne National Laboratory researcher on low-carbon fuels. In that seminar, we heard about a reaction called “dry reforming” wherein one can react CH4 with CO2, effectively eliminating both pollutants and making useful syngas (CO + H2). We realized that this reaction could enable cheaper decarbonization of chemicals than the legacy electrolysis pathway and started to build a technoeconomic analysis. George has a background in energy generation, storage, and carbon capture. He was an early employee at Highland Electric Fleets (now a unicorn) and later worked at Nexamp, GenH, and Mantel Capture – researching various battery chemistries, building a first-of-a-kind (FOAK) modular hydropower system, and helping prove a novel point-source capture prototype. He also conducted battery research at UChicago's Patel Lab and Rowan Group, co-authoring two papers. Lucas led the design, procurement, construction, and operation of Rise Reforming’s bench-scale reforming unit with controls that operated successfully for over 1800+ continuous hours. Prior to Rise, he worked at Avangrid (Iberdrola Group) with the offshore wind project services team and did transmutation research of spent nuclear fuel at Argonne National Laboratory. Jona also studied Molecular Engineering at the University of Chicago. He grew up around the marine industry and brings deep knowledge of the space to the team. While at UChicago, he conducted research in the Patel Lab on batteries and sustainable polymer applications and built novel equipment for the lab, including a high-throughput cyclic voltammetry battery performance testing device. Our advisory board has 220+ combined years in aerosols, permitting/safety, low-carbon fuels, catalysts, scale-up, automated modular chemical plants, and wastewater treatment. Here’s our launch video if you want to put faces to the names: https://youtu.be/Bx_ASPapxlQ?si=PAlqvd1eUhW8kjJm. We’d appreciate any feedback, questions, or advice. Thank you for reading! George, Lucas, and Jona

UN

Unlayer

Hi HN, We’re Adeel and Umair, co-founders of Unlayer (https://unlayer.com/). We let you add content creation to your applications without having to build an entire editor, renderer, template, and export stack yourself. Unlayer lets you create emails, web pages, and documents inside your app, in three different ways: in code, visually, or with AI. Here’s a demo: https://www.youtube.com/watch?v=0HsDtNkdMpM. We started with an embeddable email editor because a lot of products eventually need one: CRMs, marketing tools, customer engagement platforms, marketplaces, internal tools, and vertical SaaS apps all run into this at some point. At first, it sounds like a small feature: "just" add a drag and drop editor. In practice, it turns into a big pain. You end up dealing with email rendering, Outlook quirks, responsive layouts, templates, merge tags, image uploads, exports, permissions, localization, versioning, and a long tail of edge cases that have nothing to do with your core product Over time, we saw the same problem beyond email. Apps also need landing pages, invoices, proposals, reports, contracts, and PDFs. Some of this content is best created visually by end users. Some of it is better generated in code by developers. Increasingly, some of it is also generated by AI agents. Many teams eventually need all three workflows. That is the direction we have been working toward with Unlayer. There are three parts we are showing today: (1) Unlayer Elements. This is our open-source React component library for creating emails, pages, and documents in code (repo: https://github.com/unlayer/elements, more at https://unlayer.com/elements). Instead of hand-writing raw HTML templates, developers can compose content using React components, reuse sections like headers, footers, CTAs, invoice rows, and branded blocks, keep templates in Git, and render them into production output. One newer use case we are seeing is AI-assisted content creation. If an AI agent is asked to create an email, invoice, report, or landing page, the output is usually raw HTML or markdown that becomes hard to maintain. With Elements, the agent can generate structured React components instead. A developer can review the result, refactor it, keep it in Git, and still pass the design into a visual builder later if someone needs to edit it. (2) Visual Builder. This is the drag and drop editor (repo: https://github.com/unlayer/react-email-editor, more at https://unlayer.com/email-builder) that can be embedded inside an app so non-technical users can create or edit content. In the demo, we show the email builder and the AI assistant inside the builder. The goal is not to replace the developer workflow, but to connect it with a visual workflow when marketers, admins, customers, or internal teams need to make changes themselves. (3) Document Builder. This is for structured documents such as proposals, reports, invoices, contracts, and PDFs. We have seen a lot of teams build separate systems for email templates, web pages, and document generation, even though the underlying primitives are similar: layout, content blocks, variables, assets, preview, export, and permissions. More: https://unlayer.com/document-builder The technical challenge is making these workflows share a common foundation. Developers should be able to build templates in code when that makes sense. End users should be able to edit visually when that makes sense. AI agents should be able to generate structured content instead of unmaintainable blobs. The final output should still be usable by the host application. We make money by selling hosted builder, template, export, and platform features to companies embedding this into their products. Elements is open source. The commercial product is the broader hosted platform around builders, collaboration, storage, exports, and production use cases. We were part of W22, so this is a late Launch HN. At the time, Unlayer was an embeddable email editor, and we did not think we had the right broader story for HN yet. Since then, the product has expanded into a more general content creation layer for products, including emails, pages, documents, APIs, open-source developer projects, and AI-assisted workflows. That felt like a better moment to bring it to HN and ask for feedback. We'd really appreciate thoughts from HN. This is one of those areas where a lot of people have strong opinions because they’ve been burned by editors, email HTML, document editing, or “simple” content workflows before. We'd love to hear what resonates, what sounds wrong, and what you think we should be thinking harder about!

TH

threadfork

Hi HN, I built threadfork. It's an AI notetaker where the whole pipeline runs locally on Apple Silicon. Your microphone and system audio gets captured without a meeting bot and most importantly your meeting data doesn’t get sent or saved anywhere. I've been building in the privacy + local LLM space for the past several years (I started DataFog, an OSS PII detection library with 300K+ downloads); keeping all the processing and data on-device was a day 0 condition for me when building this out. Granola's updated privacy policy, effective later this week, keeps non-enterprise users opted into model training on "de-identified" data by default. Having built PII detection for a living, I'll say plainly: de-identifying meeting transcripts is really hard. Names are the easy part; deal terms, client details, and health disclosures are the transcript. For the lawyers, consultants, and therapists I've been talking to, the only version of this that holds up is the model never seeing the data at all. It's macOS 14+ on Apple M-Series computers (for now), 14-day trial, no credit card. I have a user running this on an M1 8GB so older machines welcome. $40/month after that. I use this product daily and you can expect regular updates. Welcome any/all feedback.

LP

Libretto PR agents

Libretto PR agents is a free TypeScript library for maintaining Playwright browser automations. Add one line of code to your existing Playwright scripts and it lets an agent automatically open GitHub PRs fixing the script when it fails. A few months ago we released Libretto, a CLI + coding-agent skill for building deterministic browser automations. The idea was that for many browser workflows, especially repetitive business workflows, you don’t need an AI agent making decisions at runtime. You want deterministic Playwright scripts that are inspectable, faster to run, and much cheaper than repeatedly calling an AI browser agent. That helped us generate Playwright and network-request-based scripts, but websites can often change which breaks deterministic scripts. So maintaining a variety of scripts at scale is a headache. If you already have a bunch of functioning Playwright scripts, the last thing you want is to rewrite everything around a new runtime AI framework like browser-use or stagehand just to make maintenance easier. The Libretto PR Agent pulls your code from GitHub and connects via CDP to the browser session that just failed. It has an exec tool for injecting Playwright and javascript into the page, and once its inspected the failure, it opens a PR to your repo with a proposed code fix. You use it like this: try { await automationLogic(page); } catch (error) { await playwrightDebugger.debugFailure(error, page); throw error; } The agent is completely free and open source, lets you bring your own LLM provider API keys, and works with any browser provider (including self hosted). The source code is here: https://github.com/saffron-health/libretto/tree/main/package... We think this makes browser integrations much easier to maintain, especially for teams that already have Playwright browser automation scripts in production and don’t want a full migration to get AI-assisted debugging and repair. If you’re maintaining browser automations in production, would love to know what your debugging flow is currently and any feedback on this approach.

CO

Coasty

Hey HN, we’re Nitish and Prateek, the founders of Coasty (https://coasty.ai/computer-use). We’re building computer-use agents that can complete workflows inside legacy desktop software and web applications without usable APIs. Developers send Coasty a natural-language task either through our consumer app or through our API, select a machine or browser environment, and any relevant credentials or files. The agent then operates the interface through screenshots, mouse, and keyboard input, verifies the result, and returns a structured run record with screenshots, actions, outputs, and errors. Here is a raw demo of an agent completing a workflow in a legacy application(It’s a mockup): https://drive.google.com/file/d/1ZghU_3vsAYhHVz1bsvE0pkvZYk7... A lot of important software is still difficult to automate. Healthcare teams submit prior authorizations through payer portals, accounting teams enter data into desktop applications, and operations teams move information between internal systems, spreadsheets, and remote desktops. Many of these applications have no API, incomplete APIs, or integrations that take months to build. The usual alternative is RPA, record a sequence of clicks and replay it. That works when the interface and workflow are predictable, but it often breaks when a button moves, a pop-up appears, a page loads slowly, or the application enters an unexpected state. Coasty takes a different approach. The agent observes the current screen, decides what action to take, executes it, and then observes the resulting state before continuing. It does not require DOM access, an accessibility tree, selectors, or an application-specific integration, so the same API can operate browsers, remote desktops, and older Windows applications. A simplified request looks roughly like this: run = coasty.runs.create( environment="vm_123", task=""" Open the patient record in the billing portal. Enter the attached authorization data. Do not submit if the member ID or procedure code does not match. Return the confirmation number. """, files=["authorization.pdf"], approval_required=["final_submission"] ) The response includes the final status, extracted outputs, a replay URL, and a timestamped event log: { "status": "completed", "output": { "confirmation_number": "PA-184392" }, "replay_url": "...", "events": [ { "type": "verification", "field": "member_id", "result": "matched" } ] } The API can also pause a run for human approval, retry from a checkpoint, or return control to the developer when it encounters a condition the workflow did not anticipate. We started working on this last summer, because we saw that models were getting better at vision but kept seeing a gap between computer-use demos and the reliability needed for production workflows. Getting an agent to complete a task once is fairly straightforward. Getting it to repeat that task, recover from unexpected states, avoid silently entering incorrect data, and produce evidence of what it did is much harder. We built several layers around the underlying computer-use model. The system tracks the expected state of the workflow, detects when the application has diverged from that state, and can re-plan instead of continuing blindly. Developers can define invariants such as “the patient name must match the source document” or “never submit without approval,” and the agent checks those conditions during the run. Each run happens in an isolated virtual machine. We expose APIs for provisioning environments, uploading files, starting tasks, streaming events, inserting human approvals, and retrieving the full replay and audit trail. Environments can be kept alive across runs when the application has a long login flow or persistent local state. One problem we are still working through is the tradeoff between speed and reliability. The agent can move faster by taking fewer observations and verification steps, but that becomes risky in workflows involving patient records, payments, or regulatory filings. We currently bias toward slower execution with more checks and let developers configure approval points and verification policies. We are initially working with healthcare operations teams because their workflows combine many of the hardest conditions: payer portals, EHRs, PDFs, spreadsheets, remote desktops, and actions where quiet mistakes are expensive. We also expose the same infrastructure through the developer API for teams building their own agents and vertical automation products. We currently charge based on agent runtime and workflow volume, with separate pricing for dedicated environments and enterprise deployments. We’d especially appreciate feedback from people who have built and/or used browser agents, RPA systems, desktop automation, or agent infrastructure. We’re curious which parts of the API you would want direct control over, where you would prefer higher-level abstractions, and which failure modes have been hardest in your own automation systems. If you've hit weird failure modes automating software like this, we want to hear about them. We'll be here all day answering questions and taking notes!

AG

Agnost

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 answer questions and take criticism.