The Core Problem
Most agent failures are silent. Most failures occur in components that showed zero issues during testing. Why? Because we treat agents as black boxes - query goes in, response comes out, and we have no idea what happened in between.
The Solution: Component-Level Instrumentation
I built a fully observable agent using LangGraph + LangSmith that tracks:
Component execution flow (router \u2192 retriever \u2192 reasoner \u2192 generator)
Component-specific latency (which component is the bottleneck?)
Intermediate states (what was retrieved, what reasoning strategy was chosen)
Failure attribution (which specific component caused the bad output?)
Key Architecture Insights
The agent has 4 specialized components:
Router: Classifies intent and determines workflow
Retriever: Fetches relevant context from knowledge base
Reasoner: Plans response strategy
Generator: Produces final output
Each component can fail independently, and each requires different fixes. A wrong answer could be routing errors, retrieval failures, or generation hallucinations - aggregate metrics won't tell you which.
To fix this, I implemented automated failure classification into 6 primary categories:
Routing failures (wrong workflow)
Retrieval failures (missed relevant docs)
Reasoning failures (wrong strategy)
Generation failures (poor output despite good inputs)
Latency failures (exceeds SLA)
Degradation failures (quality decreases over time)
The system automatically attributes failures to specific components based on observability data.
Component Fine-tuning Matters
Here's what made a difference: fine-tune individual components, not the whole system.
When my baseline showed the generator had a 40% failure rate, I:
Collected examples where it failed
Created training data showing correct outputs
Fine-tuned ONLY the generator
Swapped it into the agent graph
Results: Faster iteration (minutes vs hours), better debuggability (know exactly what changed), more maintainable (evolve components independently).
For anyone interested in the tech stack, here is some info:
LangGraph: Agent orchestration with explicit state transitions
LangSmith: Distributed tracing and observability
UBIAI: Component-level fine-tuning (prompt optimization \u2192 weight training)
ChromaDB: Vector store for retrieval
Key Takeaway
You can't improve what you can't measure, and you can't measure what you don't instrument.
The full implementation shows how to build this for customer support agents, but the principles apply to any multi-component architecture.
Happy to answer questions about the implementation. The blog with code is in the comment."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai","agent"],"value":"Show HN: How to fix AI Agents at the component level"},"story_url":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai","agent"],"value":"https://ubiai.tools/building-observable-and-reliable-ai-agents-using-langgraph-langsmith-and-ubiai/"}},"_tags":["comment","author_Mesterniz","story_46245184"],"author":"Mesterniz","comment_text":"I wanted to share some hard-learned lessons about deploying multi-component AI agents to production. If you've ever had an agent fail mysteriously in production while working perfectly in dev, this might help.
The Core Problem
Most agent failures are silent. Most failures occur in components that showed zero issues during testing. Why? Because we treat agents as black boxes - query goes in, response comes out, and we have no idea what happened in between.
The Solution: Component-Level Instrumentation
I built a fully observable agent using LangGraph + LangSmith that tracks:
Component execution flow (router \u2192 retriever \u2192 reasoner \u2192 generator)
Component-specific latency (which component is the bottleneck?)
Intermediate states (what was retrieved, what reasoning strategy was chosen)
Failure attribution (which specific component caused the bad output?)
Key Architecture Insights
The agent has 4 specialized components:
Router: Classifies intent and determines workflow
Retriever: Fetches relevant context from knowledge base
Reasoner: Plans response strategy
Generator: Produces final output
Each component can fail independently, and each requires different fixes. A wrong answer could be routing errors, retrieval failures, or generation hallucinations - aggregate metrics won't tell you which.
To fix this, I implemented automated failure classification into 6 primary categories:
Routing failures (wrong workflow)
Retrieval failures (missed relevant docs)
Reasoning failures (wrong strategy)
Generation failures (poor output despite good inputs)
Latency failures (exceeds SLA)
Degradation failures (quality decreases over time)
The system automatically attributes failures to specific components based on observability data.
Component Fine-tuning Matters
Here's what made a difference: fine-tune individual components, not the whole system.
When my baseline showed the generator had a 40% failure rate, I:
Collected examples where it failed
Created training data showing correct outputs
Fine-tuned ONLY the generator
Swapped it into the agent graph
Results: Faster iteration (minutes vs hours), better debuggability (know exactly what changed), more maintainable (evolve components independently).
For anyone interested in the tech stack, here is some info:
LangGraph: Agent orchestration with explicit state transitions
LangSmith: Distributed tracing and observability
UBIAI: Component-level fine-tuning (prompt optimization \u2192 weight training)
ChromaDB: Vector store for retrieval
Key Takeaway
You can't improve what you can't measure, and you can't measure what you don't instrument.
The full implementation shows how to build this for customer support agents, but the principles apply to any multi-component architecture.
Happy to answer questions about the implementation. The blog with code is in the comment.","created_at":"2025-12-12T15:44:24Z","created_at_i":1765554264,"objectID":"46245185","parent_id":46245184,"story_id":46245184,"story_title":"Show HN: How to fix AI Agents at the component level","story_url":"https://ubiai.tools/building-observable-and-reliable-ai-agents-using-langgraph-langsmith-and-ubiai/","updated_at":"2026-03-05T23:10:26Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"rtbruhan00"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"We implemented an AI-powered customer support triage system that initially looked promising in testing. In production, it actually increased our support costs by ~30% because:
The AI would confidently misroute 15-20% of tickets, requiring human review of ALL AI decisions\nand the Customers lost trust after a few bad experiences and started explicitly requesting human agents\nalso Support agents spent more time correcting AI mistakes than they saved
The breaking point was data quality - our training data was too clean compared to real customer queries. We ended up rolling back to rule-based routing with AI as an optional suggestion tool instead."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai"],"value":"Ask HN: What 'AI feature' created negative ROI in production?"}},"_tags":["comment","author_rtbruhan00","story_46731015"],"author":"rtbruhan00","children":[46731544],"comment_text":"We implemented an AI-powered customer support triage system that initially looked promising in testing. In production, it actually increased our support costs by ~30% because:
The AI would confidently misroute 15-20% of tickets, requiring human review of ALL AI decisions\nand the Customers lost trust after a few bad experiences and started explicitly requesting human agents\nalso Support agents spent more time correcting AI mistakes than they saved
The breaking point was data quality - our training data was too clean compared to real customer queries. We ended up rolling back to rule-based routing with AI as an optional suggestion tool instead.","created_at":"2026-01-23T11:41:38Z","created_at_i":1769168498,"objectID":"46731329","parent_id":46731015,"story_id":46731015,"story_title":"Ask HN: What 'AI feature' created negative ROI in production?","updated_at":"2026-03-05T23:23:59Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"chris-orgmenta"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"This is a compelling use case for AI, and a solution that was sorely needed.
- If you refer to it as '(payables) bills' not '(receivables) invoices' it will tie in more neatly with your customers' payables departments, and employees will be less likely to confuse it with receivables. It also future proofs your dictionary for when you scale. It also opens you up to B2C (Individuals refer to their bills as bills, not invoices).
- This is too small in scope for the long term (presumably preaching to the choir). Businesses can't have one integration per entity class. I.e.: If a business installs this, then they will also need another LLM agent scanning for customer tickets, another for sales, etc. Having 100s of integrations is a security problem, on top of cost and complexity considerations.
- Thus, presumably your plan is to introduce more integrations for more entity classes over time, a single agent scanning and each routing different entities into their respective bucket. The low hanging fruit is probably: Other supplier comms/tickets, Customer leads/sales/rfqs, Customer tickets/support, Customer complaints, Outgoing invoices (detect when a recurring invoice has not been issued, for example), RMM augmentation (e.g. warranty/domain expiry warning emails), Marketing notifications to correct campaigns.
- The pricing is interesting, as the lower tier is in a range that will be very price elastic for 'small businesses that are not particularly profitable'. I.e., tiny water-treading companies tend to quibble over $20/month (despite it preventing >$100 in equivalent labour) as they will assume that it is one of many necessary other integrations. Adjusting price down would bring in many more customers, but they would arguably not be 'ideal' customers (less of a problem since this is a subscription pay-in-advance system, though).
- I like the clear simple copy (a neat springboard for target audience to think 'this will save me so much effort'). I suppose some people would argue that you should go harder on the 'This will save you lots of employee time and prevent catastrophes' message.
- Far more transparency please - Website sparse on details (inc. privacy, data storage). You can't really onboard EU customers until then.
- Upcoming integrations with Xero, MYOB et al?
Great entry point into what can evolve into an 'IFTTT-v2' business routing system. If you're getting <0.1% false negatives then well done, you're onto something."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Invoice Detector \u2013 All your invoices in one place, every month"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://invoicedetector.com/"}},"_tags":["comment","author_chris-orgmenta","story_40876981"],"author":"chris-orgmenta","children":[40883406],"comment_text":"This is a compelling use case for AI, and a solution that was sorely needed.
- If you refer to it as '(payables) bills' not '(receivables) invoices' it will tie in more neatly with your customers' payables departments, and employees will be less likely to confuse it with receivables. It also future proofs your dictionary for when you scale. It also opens you up to B2C (Individuals refer to their bills as bills, not invoices).
- This is too small in scope for the long term (presumably preaching to the choir). Businesses can't have one integration per entity class. I.e.: If a business installs this, then they will also need another LLM agent scanning for customer tickets, another for sales, etc. Having 100s of integrations is a security problem, on top of cost and complexity considerations.
- Thus, presumably your plan is to introduce more integrations for more entity classes over time, a single agent scanning and each routing different entities into their respective bucket. The low hanging fruit is probably: Other supplier comms/tickets, Customer leads/sales/rfqs, Customer tickets/support, Customer complaints, Outgoing invoices (detect when a recurring invoice has not been issued, for example), RMM augmentation (e.g. warranty/domain expiry warning emails), Marketing notifications to correct campaigns.
- The pricing is interesting, as the lower tier is in a range that will be very price elastic for 'small businesses that are not particularly profitable'. I.e., tiny water-treading companies tend to quibble over $20/month (despite it preventing >$100 in equivalent labour) as they will assume that it is one of many necessary other integrations. Adjusting price down would bring in many more customers, but they would arguably not be 'ideal' customers (less of a problem since this is a subscription pay-in-advance system, though).
- I like the clear simple copy (a neat springboard for target audience to think 'this will save me so much effort'). I suppose some people would argue that you should go harder on the 'This will save you lots of employee time and prevent catastrophes' message.
- Far more transparency please - Website sparse on details (inc. privacy, data storage). You can't really onboard EU customers until then.
- Upcoming integrations with Xero, MYOB et al?
Great entry point into what can evolve into an 'IFTTT-v2' business routing system. If you're getting <0.1% false negatives then well done, you're onto something.","created_at":"2024-07-05T11:20:53Z","created_at_i":1720178453,"objectID":"40881799","parent_id":40876981,"story_id":40876981,"story_title":"Show HN: Invoice Detector \u2013 All your invoices in one place, every month","story_url":"https://invoicedetector.com/","updated_at":"2024-09-20T17:26:24Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"tang8330"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN, cofounder of Artie here. I\u2019ve been working on real-time database replication using CDC (Postgres/MongoDB into Snowflake, BigQuery, Redshift) with my wife for the last three years. Last time I posted here, people had to book a call with us to get access, but that\u2019s no longer the case. You can connect your source and destination and start streaming immediately.
I encountered this problem firsthand as a heavy data warehouse user at prior jobs. Our warehouse data was always lagged and analytics were always stale. The most visceral version of this today: imagine an AI agent making decisions \u2013 on pricing, support routing, risk scoring \u2013 off a data warehouse that's 3-12 hours behind.
When we started, I thought the hard part was reading the WAL. The real problems:
Schema drift: CDC events carry row data but not column metadata, so when an engineer adds a column in prod, events with that column start arriving at the destination before you've run ALTER TABLE. In this case, you wouldn\u2019t get an error \u2013 you would just silently drop data.
Backfill race conditions: the typical approach (snapshot first, then start CDC) means by the time your snapshot finishes on a large table, the stream has moved on. If you stitch them together wrong, you overwrite newer data with older snapshots.
Kafka offset commits: this sounds obvious but they\u2019re difficult to execute. You can only commit after a successful merge into the destination, or you double-write on replay. Partial failures across a distributed system compound this quickly.
TOAST columns: Postgres omits unchanged TOAST columns (large text/JSON/bytea \u2013 think JSONB config fields, long descriptions, binary blobs) from WAL events entirely for storage optimization. A naive pipeline reads \u2018missing\u2019 as \u2018set to null\u2019 and silently wipes valid data, which can mean a customer's entire config blob gets wiped out because an unrelated column on the same row got updated. The fix is merge logic that treats absent columns as \u2018don't touch\u2019 rather than \u2018set to null,\u2019 which breaks most off-the-shelf UPSERT patterns.
Curious whether others have hit these same walls building in-house, and would love feedback."},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Artie \u2013 Real-time data replication to your data warehouse, self-serve"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://www.artie.com"}},"_tags":["story","author_tang8330","story_48464686","show_hn"],"author":"tang8330","created_at":"2026-06-09T17:47:17Z","created_at_i":1781027237,"num_comments":0,"objectID":"48464686","points":3,"story_id":48464686,"story_text":"Hey HN, cofounder of Artie here. I\u2019ve been working on real-time database replication using CDC (Postgres/MongoDB into Snowflake, BigQuery, Redshift) with my wife for the last three years. Last time I posted here, people had to book a call with us to get access, but that\u2019s no longer the case. You can connect your source and destination and start streaming immediately.
I encountered this problem firsthand as a heavy data warehouse user at prior jobs. Our warehouse data was always lagged and analytics were always stale. The most visceral version of this today: imagine an AI agent making decisions \u2013 on pricing, support routing, risk scoring \u2013 off a data warehouse that's 3-12 hours behind.
When we started, I thought the hard part was reading the WAL. The real problems:
Schema drift: CDC events carry row data but not column metadata, so when an engineer adds a column in prod, events with that column start arriving at the destination before you've run ALTER TABLE. In this case, you wouldn\u2019t get an error \u2013 you would just silently drop data.
Backfill race conditions: the typical approach (snapshot first, then start CDC) means by the time your snapshot finishes on a large table, the stream has moved on. If you stitch them together wrong, you overwrite newer data with older snapshots.
Kafka offset commits: this sounds obvious but they\u2019re difficult to execute. You can only commit after a successful merge into the destination, or you double-write on replay. Partial failures across a distributed system compound this quickly.
TOAST columns: Postgres omits unchanged TOAST columns (large text/JSON/bytea \u2013 think JSONB config fields, long descriptions, binary blobs) from WAL events entirely for storage optimization. A naive pipeline reads \u2018missing\u2019 as \u2018set to null\u2019 and silently wipes valid data, which can mean a customer's entire config blob gets wiped out because an unrelated column on the same row got updated. The fix is merge logic that treats absent columns as \u2018don't touch\u2019 rather than \u2018set to null,\u2019 which breaks most off-the-shelf UPSERT patterns.
Curious whether others have hit these same walls building in-house, and would love feedback.","title":"Show HN: Artie \u2013 Real-time data replication to your data warehouse, self-serve","updated_at":"2026-06-10T09:47:24Z","url":"https://www.artie.com"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"mohannad"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"$1,000 per process + $250/mo for maintenance and orchestration.
We focus on actual workflow automation, not AI hype: lead routing, email triage, customer support agents, appointment scheduling, data extraction, CRM updates, multi-step business logic, and custom agents.
Most small businesses know they \u201cshould\u201d use AI but don\u2019t know where to start. So we map their process, build the automation, deploy it in a few days, and maintain it.
We\u2019re starting with Montreal, Toronto, and NYC \u2014 simple pricing, fast builds, and clear outcomes. No vague consulting, no 6-month discovery cycles, no enterprise pricing games.
Happy to answer questions, share how we build these workflows, or walk through our approach."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"[dead]"}},"_tags":["comment","author_mohannad","story_46082889"],"author":"mohannad","comment_text":"$1,000 per process + $250/mo for maintenance and orchestration.
We focus on actual workflow automation, not AI hype: lead routing, email triage, customer support agents, appointment scheduling, data extraction, CRM updates, multi-step business logic, and custom agents.
Most small businesses know they \u201cshould\u201d use AI but don\u2019t know where to start. So we map their process, build the automation, deploy it in a few days, and maintain it.
We\u2019re starting with Montreal, Toronto, and NYC \u2014 simple pricing, fast builds, and clear outcomes. No vague consulting, no 6-month discovery cycles, no enterprise pricing games.
Happy to answer questions, share how we build these workflows, or walk through our approach.","created_at":"2025-11-28T21:25:13Z","created_at_i":1764365113,"objectID":"46082890","parent_id":46082889,"story_id":46082889,"story_title":"[dead]","updated_at":"2026-03-05T23:09:50Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"macklinkachorn"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN \u2014 We're Jacky and Mac from Trellis (https://runtrellis.com/). We\u2019re building AI-powered ETL for unstructured data. Trellis transforms phone calls, PDFs, and chats into structured SQL format based on any schema you define in natural language. This helps data and ops teams automate manual data entry and run SQL queries on messy data.
There\u2019s a demo video at https://www.youtube.com/watch?v=ib3mRh2tnSo and a sandbox to try out (no sign-in required!) at https://demo.runtrellis.com/. An interesting historical archive of unstructured data we thought it would be interesting to run Trellis on top of are old Enron emails which famously took months to review. We\u2019ve created a showcase demo here: https://demo.runtrellis.com/showcase/enron-email-analysis, with some documentation here: https://docs.runtrellis.com/docs/example-email-analytics.
Why we built this: At the Stanford AI lab where we met, we collaborated with many F500 data teams (including Amazon, Meta, and Standard Chartered), and repeatedly saw the same problem: 80% of enterprise data is unstructured, and traditional platforms can\u2019t handle it. For example, a major commercial bank I work with couldn\u2019t improve credit risk models because critical data was stuck in PDFs and emails.
We realized that our research from the AI lab could be turned into a solution with an abstraction layer that works as well for financial underwriting as it does for analysis of call center transcripts: an AI-powered ETL that takes in any unstructured data source and turns it into a schematically correct table.
Some interesting technical challenges we had to tackle along the way: (1) Supporting complex documents out of the box: We use LLM-based map-reduce to handle long documents and vision models for table and layout extraction. (2) Model Routing: We select the best model for each transformation to optimize cost and speed. For instance, in data extraction tasks, we could leverage simpler fine-tuned models that are specialized in returning structured JSONs of financial tables. (3) Data Validation and Schema Guarantees: We ensure accuracy with reference links and anomaly detection.
After launching Trellis, we\u2019ve seen diverse use cases, especially in legacy industries where PDFs are treated as APIs. For example, financial services companies need to process complex documents like bonds and credit ratings into a structured format, and need to speed up underwriting and enable pass-through loan processing. Customer support and back-office operations need to accelerate onboarding by mapping documents across different schema and ERP systems, and ensure support agents follow SOPs (security questions, compliance disclosures, etc.). And many companies today want data preprocessing in ETL pipelines and data ingestion for RAG.
We\u2019d love your feedback! Try it out at https://demo.runtrellis.com/. To save and track your large data transformations, you can visit our dashboard and create an account at https://dashboard.runtrellis.com/. If you\u2019re interested in integrating with our APIs, our quick start docs are here: https://docs.runtrellis.com/docs/getting-started. If you have any specific use cases in mind, we\u2019d be happy to do a custom integration and onboarding\u2014anything for HN. :)
Excited to hear about your experience wrangling with unstructured data in the past, workflows you want to automate, and what data integration you would like to see."},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai"],"value":"Launch HN: Trellis (YC W24) \u2013 AI-powered workflows for unstructured data"}},"_tags":["story","author_macklinkachorn","story_41236273","launch_hn"],"author":"macklinkachorn","children":[41236481,41236508,41236514,41236605,41236635,41236694,41236767,41236799,41236812,41236984,41236989,41237006,41237147,41237219,41237225,41237307,41237341,41237383,41237398,41237428,41237481,41237490,41237527,41237563,41237784,41237794,41237893,41238002,41238047,41238066,41238112,41238260,41238450,41240023,41240335,41240447,41240672,41241137,41242209,41242377,41243161,41243239,41244088,41244215,41258680,41271582],"created_at":"2024-08-13T15:14:47Z","created_at_i":1723562087,"num_comments":116,"objectID":"41236273","points":234,"story_id":41236273,"story_text":"Hey HN \u2014 We're Jacky and Mac from Trellis (https://runtrellis.com/). We\u2019re building AI-powered ETL for unstructured data. Trellis transforms phone calls, PDFs, and chats into structured SQL format based on any schema you define in natural language. This helps data and ops teams automate manual data entry and run SQL queries on messy data.
There\u2019s a demo video at https://www.youtube.com/watch?v=ib3mRh2tnSo and a sandbox to try out (no sign-in required!) at https://demo.runtrellis.com/. An interesting historical archive of unstructured data we thought it would be interesting to run Trellis on top of are old Enron emails which famously took months to review. We\u2019ve created a showcase demo here: https://demo.runtrellis.com/showcase/enron-email-analysis, with some documentation here: https://docs.runtrellis.com/docs/example-email-analytics.
Why we built this: At the Stanford AI lab where we met, we collaborated with many F500 data teams (including Amazon, Meta, and Standard Chartered), and repeatedly saw the same problem: 80% of enterprise data is unstructured, and traditional platforms can\u2019t handle it. For example, a major commercial bank I work with couldn\u2019t improve credit risk models because critical data was stuck in PDFs and emails.
We realized that our research from the AI lab could be turned into a solution with an abstraction layer that works as well for financial underwriting as it does for analysis of call center transcripts: an AI-powered ETL that takes in any unstructured data source and turns it into a schematically correct table.
Some interesting technical challenges we had to tackle along the way: (1) Supporting complex documents out of the box: We use LLM-based map-reduce to handle long documents and vision models for table and layout extraction. (2) Model Routing: We select the best model for each transformation to optimize cost and speed. For instance, in data extraction tasks, we could leverage simpler fine-tuned models that are specialized in returning structured JSONs of financial tables. (3) Data Validation and Schema Guarantees: We ensure accuracy with reference links and anomaly detection.
After launching Trellis, we\u2019ve seen diverse use cases, especially in legacy industries where PDFs are treated as APIs. For example, financial services companies need to process complex documents like bonds and credit ratings into a structured format, and need to speed up underwriting and enable pass-through loan processing. Customer support and back-office operations need to accelerate onboarding by mapping documents across different schema and ERP systems, and ensure support agents follow SOPs (security questions, compliance disclosures, etc.). And many companies today want data preprocessing in ETL pipelines and data ingestion for RAG.
We\u2019d love your feedback! Try it out at https://demo.runtrellis.com/. To save and track your large data transformations, you can visit our dashboard and create an account at https://dashboard.runtrellis.com/. If you\u2019re interested in integrating with our APIs, our quick start docs are here: https://docs.runtrellis.com/docs/getting-started. If you have any specific use cases in mind, we\u2019d be happy to do a custom integration and onboarding\u2014anything for HN. :)
Excited to hear about your experience wrangling with unstructured data in the past, workflows you want to automate, and what data integration you would like to see.","title":"Launch HN: Trellis (YC W24) \u2013 AI-powered workflows for unstructured data","updated_at":"2025-08-28T01:08:57Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"lunarcave"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN,
We're John and Nadeesha. We created Inferable. [1]
After years of working in operationally-intensive startups, we got tired of watching our internal tools gather dust and break. We've all been there - you build a tool, it works great for a while, then the API changes and suddenly you're back to square one. Sure, Retool and similar tools help, but someone still has to maintain them, and the backlog of "quick fixes" and the mountain of glue code keeps keeps growing.
We started Inferable to see whether LLMs can help here.
Inferable helps developers create conversational AI agents that act as the orchestration layer between existing internal APIs and human intent. Instead of building custom scripts or internal tools, developers can quickly set up these agents as conversational experiences [2].
We natively integrate with Slack and email (more coming), while also supporting Zapier and HTTP APIs for more advanced workflows.
Our SDKs can wrap existing functions, or existing APIs (REST, GraphQL). We use long polling for message delivery, which means these instances don\u2019t have to open ports / configure network ingress.
A Re-Act agent dynamically searches through these tools based on user context, schedules jobs as tool calls, and iterates based on the result.
We prioritize using existing codebases as deterministic guardrails. For additional verifications, we provide primitives to easily implement human-in-the-loop processes, custom authn, and authz, all backed with your existing codebases.
Our customers use Inferable to:
- Interact conversationally with internal APIs and databases (with restricted connections)
- Programmatically process Datadog alerts - automatically tagging them and routing them with enriched context
- Programatically or conversationally enrich Zendesk support tickets by automatically adding context from multiple internal systems
To achieve this functionality, we've developed:
- A built-in Re-Act (reasoning + action) agent
- A distributed job queue for managing long-running tasks
- End to end chat state, and message serialisation for tool calls
- Service discovery and function registry for tools
- Context-aware dynamic tool search
- Native SDKs for Node.js, Golang, C#, and other languages
We\u2019re open-source (MIT) and fully self-hostable within existing infrastructure. Happy to receive any feedback or answer questions.
---
[1] https://github.com/inferablehq/inferable
[2] Acknowledging that calling an LLM every time is costlier than using a script, we\u2019re solving the problem of repeating these flows without LLM intervention in our next iteration."},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai","agent"],"value":"Show HN: Open-source conversational AI agents for internal tools"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/inferablehq/inferable"}},"_tags":["story","author_lunarcave","story_42772862","show_hn"],"author":"lunarcave","children":[42772939,42773241],"created_at":"2025-01-20T20:45:55Z","created_at_i":1737405955,"num_comments":4,"objectID":"42772862","points":11,"story_id":42772862,"story_text":"Hey HN,
We're John and Nadeesha. We created Inferable. [1]
After years of working in operationally-intensive startups, we got tired of watching our internal tools gather dust and break. We've all been there - you build a tool, it works great for a while, then the API changes and suddenly you're back to square one. Sure, Retool and similar tools help, but someone still has to maintain them, and the backlog of "quick fixes" and the mountain of glue code keeps keeps growing.
We started Inferable to see whether LLMs can help here.
Inferable helps developers create conversational AI agents that act as the orchestration layer between existing internal APIs and human intent. Instead of building custom scripts or internal tools, developers can quickly set up these agents as conversational experiences [2].
We natively integrate with Slack and email (more coming), while also supporting Zapier and HTTP APIs for more advanced workflows.
Our SDKs can wrap existing functions, or existing APIs (REST, GraphQL). We use long polling for message delivery, which means these instances don\u2019t have to open ports / configure network ingress.
A Re-Act agent dynamically searches through these tools based on user context, schedules jobs as tool calls, and iterates based on the result.
We prioritize using existing codebases as deterministic guardrails. For additional verifications, we provide primitives to easily implement human-in-the-loop processes, custom authn, and authz, all backed with your existing codebases.
Our customers use Inferable to:
- Interact conversationally with internal APIs and databases (with restricted connections)
- Programmatically process Datadog alerts - automatically tagging them and routing them with enriched context
- Programatically or conversationally enrich Zendesk support tickets by automatically adding context from multiple internal systems
To achieve this functionality, we've developed:
- A built-in Re-Act (reasoning + action) agent
- A distributed job queue for managing long-running tasks
- End to end chat state, and message serialisation for tool calls
- Service discovery and function registry for tools
- Context-aware dynamic tool search
- Native SDKs for Node.js, Golang, C#, and other languages
We\u2019re open-source (MIT) and fully self-hostable within existing infrastructure. Happy to receive any feedback or answer questions.
---
[1] https://github.com/inferablehq/inferable
[2] Acknowledging that calling an LLM every time is costlier than using a script, we\u2019re solving the problem of repeating these flows without LLM intervention in our next iteration.","title":"Show HN: Open-source conversational AI agents for internal tools","updated_at":"2025-02-06T06:59:41Z","url":"https://github.com/inferablehq/inferable"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"adilhafeez"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN \u2014 I\u2019m Adil from Katanemo (with Salman, Shuguang, and Meiyu)
We previously shared an early version of this project as ArchGW. Based on customer feedback, the scope expanded from \u201cLLM routing and model access\u201d into something broader: delivery infrastructure for agentic applications. We renamed it to Plano and reworked the architecture accordingly.
The problem
On-the-ground AI practitioners will tell you that calling an LLM is not the hard part. The really hard part is delivering agentic applications to production quickly and reliably, then iterating without rewriting system code every time. In practice, teams keep rebuilding the same concerns that sit outside any single agent\u2019s core logic:
This includes model agility \u2014 the ability to pull from a large set of LLMs and swap providers without refactoring prompts or streaming handlers. They need to learn from production by collecting signals and traces that tell them what to fix. They need consistent policy enforcement for moderation and jailbreak protection, rather than sprinkling hooks across codebases. And they need multi-agent patterns like handoff and specialization without turning their app into orchestration glue.
These concerns get rebuilt and maintained inside fast-changing frameworks and application code, coupling product logic to infrastructure decisions. It\u2019s brittle, and pulls teams away from core product work into plumbing they shouldn\u2019t have to own.
What Plano does
Plano moves core delivery concerns out of process into a modular proxy and dataplane designed for agents. It supports inbound listeners (agent orchestration, safety and moderation hooks), outbound listeners (hosted or API-based LLM routing), or both together.
Plano provides the following capabilities via a unified, protocol-native, framework-friendly dataplane:
- Orchestration: Low-latency routing and handoff between agents. Add or change agents without modifying app code, and evolve strategies centrally instead of duplicating logic across services.
- Guardrails & Memory Hooks: Apply jailbreak protection, content policies, and context workflows (rewriting, retrieval, redaction) once via filter chains. This centralizes governance and ensures consistent behavior across your stack.
- Model Agility: Route by model name, semantic alias, or preference-based policies. Swap or add models without refactoring prompts, tool calls, or streaming handlers.
- Agentic Signals\u2122: Zero-code capture of behavior signals, traces, and metrics across every agent, surfacing traces, token usage, and learning signals in one place.
The goal is to keep application code focused on product logic while Plano owns delivery mechanics.
More on Architecture
Plano has two main parts:
Envoy-based data plane. Uses Envoy\u2019s HTTP connection management to talk to model APIs, services, and tool backends. We didn\u2019t build a separate model server\u2014Envoy already handles streaming, retries, timeouts, and connection pooling. Some of us are core Envoy contributors at Katanemo.
Brightstaff, a lightweight controller written in Rust. It inspects prompts and conversation state, decides which upstreams to call and in what order, and coordinates routing and fallback. It uses small LLMs (1\u20134B parameters) trained for constrained routing and orchestration. These models do not generate responses and fall back to static policies on failure. The models are open sourced here: https://huggingface.co/katanemo
Plano runs alongside your app servers (cloud, on-prem, or local dev), doesn\u2019t require a GPU, and leaves GPUs where your models are hosted.
Repo https://github.com/katanemo/plano + docs https://docs.planoai.dev/"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai","agent"],"value":"Show HN: Plano \u2013 Edge and service proxy with orchestration for AI agents"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/katanemo/plano"}},"_tags":["story","author_adilhafeez","story_46517177","show_hn"],"author":"adilhafeez","children":[46517254,46563685],"created_at":"2026-01-06T19:20:42Z","created_at_i":1767727242,"num_comments":2,"objectID":"46517177","points":8,"story_id":46517177,"story_text":"Hey HN \u2014 I\u2019m Adil from Katanemo (with Salman, Shuguang, and Meiyu)
We previously shared an early version of this project as ArchGW. Based on customer feedback, the scope expanded from \u201cLLM routing and model access\u201d into something broader: delivery infrastructure for agentic applications. We renamed it to Plano and reworked the architecture accordingly.
The problem
On-the-ground AI practitioners will tell you that calling an LLM is not the hard part. The really hard part is delivering agentic applications to production quickly and reliably, then iterating without rewriting system code every time. In practice, teams keep rebuilding the same concerns that sit outside any single agent\u2019s core logic:
This includes model agility \u2014 the ability to pull from a large set of LLMs and swap providers without refactoring prompts or streaming handlers. They need to learn from production by collecting signals and traces that tell them what to fix. They need consistent policy enforcement for moderation and jailbreak protection, rather than sprinkling hooks across codebases. And they need multi-agent patterns like handoff and specialization without turning their app into orchestration glue.
These concerns get rebuilt and maintained inside fast-changing frameworks and application code, coupling product logic to infrastructure decisions. It\u2019s brittle, and pulls teams away from core product work into plumbing they shouldn\u2019t have to own.
What Plano does
Plano moves core delivery concerns out of process into a modular proxy and dataplane designed for agents. It supports inbound listeners (agent orchestration, safety and moderation hooks), outbound listeners (hosted or API-based LLM routing), or both together.
Plano provides the following capabilities via a unified, protocol-native, framework-friendly dataplane:
- Orchestration: Low-latency routing and handoff between agents. Add or change agents without modifying app code, and evolve strategies centrally instead of duplicating logic across services.
- Guardrails & Memory Hooks: Apply jailbreak protection, content policies, and context workflows (rewriting, retrieval, redaction) once via filter chains. This centralizes governance and ensures consistent behavior across your stack.
- Model Agility: Route by model name, semantic alias, or preference-based policies. Swap or add models without refactoring prompts, tool calls, or streaming handlers.
- Agentic Signals\u2122: Zero-code capture of behavior signals, traces, and metrics across every agent, surfacing traces, token usage, and learning signals in one place.
The goal is to keep application code focused on product logic while Plano owns delivery mechanics.
More on Architecture
Plano has two main parts:
Envoy-based data plane. Uses Envoy\u2019s HTTP connection management to talk to model APIs, services, and tool backends. We didn\u2019t build a separate model server\u2014Envoy already handles streaming, retries, timeouts, and connection pooling. Some of us are core Envoy contributors at Katanemo.
Brightstaff, a lightweight controller written in Rust. It inspects prompts and conversation state, decides which upstreams to call and in what order, and coordinates routing and fallback. It uses small LLMs (1\u20134B parameters) trained for constrained routing and orchestration. These models do not generate responses and fall back to static policies on failure. The models are open sourced here: https://huggingface.co/katanemo
Plano runs alongside your app servers (cloud, on-prem, or local dev), doesn\u2019t require a GPU, and leaves GPUs where your models are hosted.
Repo https://github.com/katanemo/plano + docs https://docs.planoai.dev/","title":"Show HN: Plano \u2013 Edge and service proxy with orchestration for AI agents","updated_at":"2026-03-05T23:17:38Z","url":"https://github.com/katanemo/plano"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"dhorthy"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN! I'm Dex, building HumanLayer (https://humanlayer.dev), an API that lets AI agents contact humans for feedback, input, and approvals. We enable safe deployment of autonomous/headless AI systems in production. You can try it with our Python or TypeScript SDKs and start using it immediately with a free trial. We have a free tier and transparent usage-based pricing. Here\u2019s a demo: https://youtu.be/5sbN8rh_S5Q?t=51
What's really exciting is that we're enabling teams to deploy AI systems that would otherwise be too risky. We let you focus on building powerful agents while knowing that critical steps will always get a human-in-the-loop. It's been dope seeing people start to think bigger when they consider dynamic human oversight as a key ingredient in production AI systems.
This started when we were building AI agents for data teams. We wanted to automate tedious tasks like dropping unused tables, but customers were (rightfully!) opposed to giving AI agents direct access to production systems.
Getting AI to "production grade" reliability is a function of "how risky is this task the AI is performing". We didn't have the 3+ months it would have taken to sink into evals, fine tuning, and prompt engineering to get to a point where the agent had 99.9+% reliability\u2014and even then, getting decision makers comfortable with flipping the switch on was a challenge. So instead we built some basic approval flows, like "ask in Slack before dropping tables".
But this communication itself needed guardrails\u2014what if the agent contacted the wrong person? How would the head of data look if a tool he bought sent a nagging Slack message to the CEO? Our buyers wanted the agent to ask stakeholders for approval, but first they wanted to approve the "ask for approval" action itself. And then I started thinking about it... as a product builder + owner, I wanted to approve the "ask for approval to ask for approval" action!
I hacked together a human-AI interaction that would handle each of these cases across both my and my customers' Slack instances. By this time, I was convinced that any team building AI agents would need this kind of infrastructure and decided to build it as a standalone product. I presented the MVP at an AI meetup in SF and had a ton of incredible conversations, and went all in on building HumanLayer.
When you integrate the HumanLayer SDK, your AI agent can request human approval at any point in its execution. We handle all the complexity of routing these requests to the right people through their preferred channels (Slack or email, SMS and Teams coming soon), managing state while waiting for responses, and providing a complete audit trail. In addition to "ask for approval", we also support a more generic "human as tool" function that can be exposed to an LLM or agent framework, and will handle collecting a human response to a generic question like "I'm stuck on $PROBLEM, I've tried $THINGS, please advise" (I get messages like this sometimes from in-house agents we rolled out for back-office automations).
Because it's at the tool-calling layer, HumanLayer's SDK works with any AI framework like CrewAI, LangChain, etc, and any language model that supports tool calling. If you're rolling your own agentic/tools loop, you can use lower level SDK primitives to manage approvals however you want. We're even exploring use cases where HumanLayer is used for human-to-human approval, not just AI-to-human.
We're already seeing HumanLayer used in some cool ways. One customer built an AI SDR that drafts personalized sales emails but asks for human approval in Slack before sending anything to prospects. Another uses it to power an AI newsletter where subscribers can have email conversations with the content. HumanLayer handles receiving inbound emails and routing them to agents that can respond, and giving those agents tools to do so. One team uses HumanLayer to build a customer-facing DevOps agent\u2014their AI agent reviews PRs, plans and executes db migrations, all while getting human sign-off at critical steps and reaching out to the team for steering if it encounters any issues.
We have a free tier and flexible credits-based pricing. For teams building customer-facing agents, you get whitelabeling and additional features and priority support.
If you want to integrate HumanLayer into your systems, check out our docs at https://humanlayer.dev/docs or book a demo at https://humanlayer.dev.
Thank you for reading! We\u2019re admittedly early and I welcome your ideas and experiences as it relates to agents, reliability, and balancing human+AI workloads."},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai"],"value":"Launch HN: Human Layer (YC F24) \u2013 Human-in-the-Loop API for AI Systems"}},"_tags":["story","author_dhorthy","story_42247368","launch_hn"],"author":"dhorthy","children":[42247375,42247514,42247613,42247814,42247825,42247838,42247861,42248002,42248089,42248100,42248101,42248106,42248194,42248197,42248229,42248246,42248267,42248296,42248302,42248313,42248382,42248395,42248441,42248481,42248485,42248539,42248610,42248612,42248679,42248805,42248835,42249032,42249035,42249131,42249488,42249504,42249629,42249655,42249692,42249739,42249851,42250103,42250228,42250256,42250306,42250307,42250310,42250404,42250461,42250544,42250557,42250624,42250793,42250955,42251303,42251329,42251504,42251760,42251973,42252024,42252109,42252945,42253552,42253876,42254040,42254312,42254805,42254831,42255431,42255566,42257395],"created_at":"2024-11-26T16:57:12Z","created_at_i":1732640232,"num_comments":196,"objectID":"42247368","points":354,"story_id":42247368,"story_text":"Hey HN! I'm Dex, building HumanLayer (https://humanlayer.dev), an API that lets AI agents contact humans for feedback, input, and approvals. We enable safe deployment of autonomous/headless AI systems in production. You can try it with our Python or TypeScript SDKs and start using it immediately with a free trial. We have a free tier and transparent usage-based pricing. Here\u2019s a demo: https://youtu.be/5sbN8rh_S5Q?t=51
What's really exciting is that we're enabling teams to deploy AI systems that would otherwise be too risky. We let you focus on building powerful agents while knowing that critical steps will always get a human-in-the-loop. It's been dope seeing people start to think bigger when they consider dynamic human oversight as a key ingredient in production AI systems.
This started when we were building AI agents for data teams. We wanted to automate tedious tasks like dropping unused tables, but customers were (rightfully!) opposed to giving AI agents direct access to production systems.
Getting AI to "production grade" reliability is a function of "how risky is this task the AI is performing". We didn't have the 3+ months it would have taken to sink into evals, fine tuning, and prompt engineering to get to a point where the agent had 99.9+% reliability\u2014and even then, getting decision makers comfortable with flipping the switch on was a challenge. So instead we built some basic approval flows, like "ask in Slack before dropping tables".
But this communication itself needed guardrails\u2014what if the agent contacted the wrong person? How would the head of data look if a tool he bought sent a nagging Slack message to the CEO? Our buyers wanted the agent to ask stakeholders for approval, but first they wanted to approve the "ask for approval" action itself. And then I started thinking about it... as a product builder + owner, I wanted to approve the "ask for approval to ask for approval" action!
I hacked together a human-AI interaction that would handle each of these cases across both my and my customers' Slack instances. By this time, I was convinced that any team building AI agents would need this kind of infrastructure and decided to build it as a standalone product. I presented the MVP at an AI meetup in SF and had a ton of incredible conversations, and went all in on building HumanLayer.
When you integrate the HumanLayer SDK, your AI agent can request human approval at any point in its execution. We handle all the complexity of routing these requests to the right people through their preferred channels (Slack or email, SMS and Teams coming soon), managing state while waiting for responses, and providing a complete audit trail. In addition to "ask for approval", we also support a more generic "human as tool" function that can be exposed to an LLM or agent framework, and will handle collecting a human response to a generic question like "I'm stuck on $PROBLEM, I've tried $THINGS, please advise" (I get messages like this sometimes from in-house agents we rolled out for back-office automations).
Because it's at the tool-calling layer, HumanLayer's SDK works with any AI framework like CrewAI, LangChain, etc, and any language model that supports tool calling. If you're rolling your own agentic/tools loop, you can use lower level SDK primitives to manage approvals however you want. We're even exploring use cases where HumanLayer is used for human-to-human approval, not just AI-to-human.
We're already seeing HumanLayer used in some cool ways. One customer built an AI SDR that drafts personalized sales emails but asks for human approval in Slack before sending anything to prospects. Another uses it to power an AI newsletter where subscribers can have email conversations with the content. HumanLayer handles receiving inbound emails and routing them to agents that can respond, and giving those agents tools to do so. One team uses HumanLayer to build a customer-facing DevOps agent\u2014their AI agent reviews PRs, plans and executes db migrations, all while getting human sign-off at critical steps and reaching out to the team for steering if it encounters any issues.
We have a free tier and flexible credits-based pricing. For teams building customer-facing agents, you get whitelabeling and additional features and priority support.
If you want to integrate HumanLayer into your systems, check out our docs at https://humanlayer.dev/docs or book a demo at https://humanlayer.dev.
Thank you for reading! We\u2019re admittedly early and I welcome your ideas and experiences as it relates to agents, reliability, and balancing human+AI workloads.","title":"Launch HN: Human Layer (YC F24) \u2013 Human-in-the-Loop API for AI Systems","updated_at":"2026-01-05T00:55:20Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"yixn_io"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN,
I'm Daniel, solo dev from Germany. I built ClawHosters (https://clawhosters.com), a managed hosting platform for OpenClaw, the open-source AI agent framework.
Quick timeline: domain registered February 5th. First paying customer six days later. I probably should have spent more time on it, but it works.
If you haven't seen OpenClaw, it lets you run a personal AI assistant that connects to Telegram, Discord, Slack, and WhatsApp. Self-hosting it is absolutely possible, but it's a pain. You're dealing with Docker setup, SSL certs, port forwarding, security hardening, keeping the image updated. Most people don't want to deal with any of that. They just want the thing running.
That's what ClawHosters does. You pick a tier (EUR 19-59/mo), click create, and you've got a running instance with a subdomain. About 60 seconds if we have prewarmed capacity, maybe 90 seconds from a cold snapshot.
Some technical details that might interest this crowd:
*Subdomain routing chain.* Every instance gets a subdomain like `mybot.clawhosters.com`. The request path is Cloudflare -> my production server -> Traefik (looks up VPS IP from Redis) -> customer's Hetzner VPS -> nginx on the VPS (validates Host header) -> Docker container (port 18789) -> OpenClaw gateway. All subdomains require HTTP Basic Auth, configured per-instance through Traefik Redis middleware keys. The VPS itself only accepts connections from my production server's IP via Hetzner Cloud Firewall. No way to hit it directly.
*Prewarmed VPS pool.* Even from a snapshot, Hetzner VPS creation takes ~30-60 seconds. That felt too slow. So I maintain a pool of idle, pre-provisioned VPS instances sitting there ready to go. When someone creates an instance, we claim one from the pool, upload the config via SCP, run docker-compose up, done. The pool refills in the background.
*Security is 4 layers deep.* Hetzner Cloud Firewall restricts all VPS inbound traffic to only my production server IP. Host iptables (baked into the snapshot) add OS-level rules with SMTP/IRC blocking. SSH is key-only on both host port 22 and container port 2222, so brute-forcing isn't happening. fail2ban on top of that, and the Docker daemon runs with no-new-privileges. Probably overkill. I'm fine with that.
*SSH into the Docker container.* Users can enable SSH access to their actual container (port 2222). I built a custom image extending OpenClaw with an SSH server, key-only auth, no passwords. Fair warning though: enabling SSH permanently marks the instance as no_support. Once you're installing your own stuff in there, I can't guarantee stability anymore.
*Container commit for state preservation.* This one was tricky to get right. Users can install packages (apt, pip, npm) inside their container. Before any restart or redeploy, `CommitContainerService` runs `docker commit` to save the full filesystem as a new image. Next startup uses the committed image instead of the base one. Basically snapshotting your container's state so nothing gets lost.
I wrote a more detailed technical post about the architecture here: [link to blog post]
The whole thing runs inside a single Rails app that also serves my portfolio site (https://yixn.io). One person, one codebase, real paying customers. I'm happy to answer questions about the architecture, the Hetzner API, or the tradeoffs I made along the way.
Source isn't open yet, but I'm thinking about open-sourcing the provisioning layer. Haven't decided.
https://clawhosters.com"},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: I built managed OpenClaw hosting with 60s provisioning in 6 days"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://clawhosters.com/blog/posts/how-i-built-60-second-vps-provisioning"}},"_tags":["story","author_yixn_io","story_46973691","show_hn"],"author":"yixn_io","created_at":"2026-02-11T11:35:25Z","created_at_i":1770809725,"num_comments":0,"objectID":"46973691","points":9,"story_id":46973691,"story_text":"Hey HN,
I'm Daniel, solo dev from Germany. I built ClawHosters (https://clawhosters.com), a managed hosting platform for OpenClaw, the open-source AI agent framework.
Quick timeline: domain registered February 5th. First paying customer six days later. I probably should have spent more time on it, but it works.
If you haven't seen OpenClaw, it lets you run a personal AI assistant that connects to Telegram, Discord, Slack, and WhatsApp. Self-hosting it is absolutely possible, but it's a pain. You're dealing with Docker setup, SSL certs, port forwarding, security hardening, keeping the image updated. Most people don't want to deal with any of that. They just want the thing running.
That's what ClawHosters does. You pick a tier (EUR 19-59/mo), click create, and you've got a running instance with a subdomain. About 60 seconds if we have prewarmed capacity, maybe 90 seconds from a cold snapshot.
Some technical details that might interest this crowd:
*Subdomain routing chain.* Every instance gets a subdomain like `mybot.clawhosters.com`. The request path is Cloudflare -> my production server -> Traefik (looks up VPS IP from Redis) -> customer's Hetzner VPS -> nginx on the VPS (validates Host header) -> Docker container (port 18789) -> OpenClaw gateway. All subdomains require HTTP Basic Auth, configured per-instance through Traefik Redis middleware keys. The VPS itself only accepts connections from my production server's IP via Hetzner Cloud Firewall. No way to hit it directly.
*Prewarmed VPS pool.* Even from a snapshot, Hetzner VPS creation takes ~30-60 seconds. That felt too slow. So I maintain a pool of idle, pre-provisioned VPS instances sitting there ready to go. When someone creates an instance, we claim one from the pool, upload the config via SCP, run docker-compose up, done. The pool refills in the background.
*Security is 4 layers deep.* Hetzner Cloud Firewall restricts all VPS inbound traffic to only my production server IP. Host iptables (baked into the snapshot) add OS-level rules with SMTP/IRC blocking. SSH is key-only on both host port 22 and container port 2222, so brute-forcing isn't happening. fail2ban on top of that, and the Docker daemon runs with no-new-privileges. Probably overkill. I'm fine with that.
*SSH into the Docker container.* Users can enable SSH access to their actual container (port 2222). I built a custom image extending OpenClaw with an SSH server, key-only auth, no passwords. Fair warning though: enabling SSH permanently marks the instance as no_support. Once you're installing your own stuff in there, I can't guarantee stability anymore.
*Container commit for state preservation.* This one was tricky to get right. Users can install packages (apt, pip, npm) inside their container. Before any restart or redeploy, `CommitContainerService` runs `docker commit` to save the full filesystem as a new image. Next startup uses the committed image instead of the base one. Basically snapshotting your container's state so nothing gets lost.
I wrote a more detailed technical post about the architecture here: [link to blog post]
The whole thing runs inside a single Rails app that also serves my portfolio site (https://yixn.io). One person, one codebase, real paying customers. I'm happy to answer questions about the architecture, the Hetzner API, or the tradeoffs I made along the way.
Source isn't open yet, but I'm thinking about open-sourcing the provisioning layer. Haven't decided.
https://clawhosters.com","title":"Show HN: I built managed OpenClaw hosting with 60s provisioning in 6 days","updated_at":"2026-03-07T06:59:01Z","url":"https://clawhosters.com/blog/posts/how-i-built-60-second-vps-provisioning"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"abuhl98"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN, I\u2019m Austin, founder of Salestrics (salestrics.com).
The Problem: > Most AI agents today are trapped in chat windows. While models are smart enough to run complex multi-step workflows, giving them production access to business context (CRM, support, billing) usually means managing unsafe local API keys or hacking together fragile point-solution scripts.
What We Built:\nWe built Salestrics to serve as both an all-in-one revenue workspace (CRM, service desk, billing, docs, email) and a production-grade Model Context Protocol (MCP) execution proxy.
How It Works:
Unified Context: Instead of fragmenting data across five SaaS tools, customer records, tickets, and invoices live in a single data layer.
165-Tool MCP Server: You connect your local AI environment (Cursor, Claude Desktop, local LLMs) once via our MCP proxy.
Full-CRUD Execution: Your agent gets zero-config execution access across native apps and third-party tools (Stripe, PostHog, Sentry)\u2014allowing it to do things like resolve support tickets, issue refunds, or update pipeline stages directly from your IDE or chat client.
Human-in-the-Loop Governance: High-impact agent actions (deleting records, mass messaging, issuing payouts) trigger explicit approval gates and immutable audit logs before execution.
Traction & Tech Stack:\nWe launched two months ago and currently power 320+ active organizations. The backend is built with high-throughput node/TypeScript orchestration, connected to a dual-model AI routing engine (Salestrics-AI-v1/v2).
Try It Out:\nWe have a Free Forever tier for solo builders. You can grab your MCP keys and test the proxy immediately without putting down a credit card.
I\u2019d love to hear your thoughts on our MCP architecture, human-in-the-loop security patterns, or what tools/actions you'd want added to the MCP server next!"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai"],"value":"Show HN: Salestrics \u2013 An open MCP server and CRM for AI-native revenue teams"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://www.salestrics.com/"}},"_tags":["story","author_abuhl98","story_49218097","show_hn"],"author":"abuhl98","children":[49246429],"created_at":"2026-08-08T01:32:41Z","created_at_i":1786152761,"num_comments":0,"objectID":"49218097","points":1,"story_id":49218097,"story_text":"Hey HN, I\u2019m Austin, founder of Salestrics (salestrics.com).
The Problem: > Most AI agents today are trapped in chat windows. While models are smart enough to run complex multi-step workflows, giving them production access to business context (CRM, support, billing) usually means managing unsafe local API keys or hacking together fragile point-solution scripts.
What We Built:\nWe built Salestrics to serve as both an all-in-one revenue workspace (CRM, service desk, billing, docs, email) and a production-grade Model Context Protocol (MCP) execution proxy.
How It Works:
Unified Context: Instead of fragmenting data across five SaaS tools, customer records, tickets, and invoices live in a single data layer.
165-Tool MCP Server: You connect your local AI environment (Cursor, Claude Desktop, local LLMs) once via our MCP proxy.
Full-CRUD Execution: Your agent gets zero-config execution access across native apps and third-party tools (Stripe, PostHog, Sentry)\u2014allowing it to do things like resolve support tickets, issue refunds, or update pipeline stages directly from your IDE or chat client.
Human-in-the-Loop Governance: High-impact agent actions (deleting records, mass messaging, issuing payouts) trigger explicit approval gates and immutable audit logs before execution.
Traction & Tech Stack:\nWe launched two months ago and currently power 320+ active organizations. The backend is built with high-throughput node/TypeScript orchestration, connected to a dual-model AI routing engine (Salestrics-AI-v1/v2).
Try It Out:\nWe have a Free Forever tier for solo builders. You can grab your MCP keys and test the proxy immediately without putting down a credit card.
I\u2019d love to hear your thoughts on our MCP architecture, human-in-the-loop security patterns, or what tools/actions you'd want added to the MCP server next!","title":"Show HN: Salestrics \u2013 An open MCP server and CRM for AI-native revenue teams","updated_at":"2026-08-10T17:01:55Z","url":"https://www.salestrics.com/"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"longtermop"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Every agentic system I see has the same hidden tax: the model keeps rereading the same context.
Tickets, Slack threads, docs, customer history, database notes, runbooks, logs, prior decisions. You can cache static prefixes, route to cheaper models, or set team budgets, but none of those fixes the underlying behavior: agents start most tasks trying to re-explore everything.
We built Parcle as a shared memory layer for AI agents. It ingests operational context, indexes what happened, and lets agents retrieve a small, relevant memory set for the next step instead of pasting everything back into the prompt - or worse, letting the agent go explore on it's own and burning tokens.
We started tracking our tokens consumed on tasks with and without our memory layer just with indexing of local files. In our deployments/evals, the biggest reduction we\u2019ve seen is up to 70% lower token spend on agentic tasks, with roughly 2x faster task completion. The median was ~30% less tokens spent. The biggest savings often come from data and context-heavy workflows; when the agent needs to retrieve data and context from multiple locations and sources. The best cases so far are support, ops, research, sales, and finance workflows where the agent otherwise reloads the same account/workflow/history context again and again.
Why I think this matters now:
Pylon\u2019s AI cost post made us ask the question:
How much are companies paying because their agents keep looking for the same context? Is this a hidden tax that memory could solve?
We built Parcle to make agents remember. The surprise was that memory does not just make agents more useful. It also cuts down on tokens consumed. Less tokens spent figuring where things are, and more time spent doing actually productive work.
- Anthropic says agents use about 4x more tokens than chat. We think this is an understatement,\n- OpenAI and Anthropic both have prompt caching because repeated prompt context is expensive, but caching mostly helps when the reusable content is stable enough to hit the cache. But this doesn't resolve the fact that prompt caching is forfeited after 5min-15mins of inactivity.\n- \u201cLost in the Middle\u201d and Chroma\u2019s \u201ccontext rot\u201d work both point at the same issue: more context is not the same thing as usable memory.\n- The context-engineering crowd seems to be converging on this: the hard part is deciding what the model should see at each step.
Parcle is our attempt at making that operational: memory outside the model, selected into context only when useful.
I\u2019d love feedback from people running real agents in production:
1. Where are your tokens actually going: repeated input context, tool traces, retries, output, evals, or something else?\n2. Have prompt caching and model routing been enough?\n3. What would you need to trust an external memory layer inside an agent loop?"},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: We cut >60% of tokens from agentic tasks by removing repeated context"},"url":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai"],"value":"https://parcle.ai/"}},"_tags":["story","author_longtermop","story_48580512","show_hn"],"author":"longtermop","children":[48580529,48582893,48618520,48625263],"created_at":"2026-06-18T03:39:26Z","created_at_i":1781753966,"num_comments":0,"objectID":"48580512","points":1,"story_id":48580512,"story_text":"Every agentic system I see has the same hidden tax: the model keeps rereading the same context.
Tickets, Slack threads, docs, customer history, database notes, runbooks, logs, prior decisions. You can cache static prefixes, route to cheaper models, or set team budgets, but none of those fixes the underlying behavior: agents start most tasks trying to re-explore everything.
We built Parcle as a shared memory layer for AI agents. It ingests operational context, indexes what happened, and lets agents retrieve a small, relevant memory set for the next step instead of pasting everything back into the prompt - or worse, letting the agent go explore on it's own and burning tokens.
We started tracking our tokens consumed on tasks with and without our memory layer just with indexing of local files. In our deployments/evals, the biggest reduction we\u2019ve seen is up to 70% lower token spend on agentic tasks, with roughly 2x faster task completion. The median was ~30% less tokens spent. The biggest savings often come from data and context-heavy workflows; when the agent needs to retrieve data and context from multiple locations and sources. The best cases so far are support, ops, research, sales, and finance workflows where the agent otherwise reloads the same account/workflow/history context again and again.
Why I think this matters now:
Pylon\u2019s AI cost post made us ask the question:
How much are companies paying because their agents keep looking for the same context? Is this a hidden tax that memory could solve?
We built Parcle to make agents remember. The surprise was that memory does not just make agents more useful. It also cuts down on tokens consumed. Less tokens spent figuring where things are, and more time spent doing actually productive work.
- Anthropic says agents use about 4x more tokens than chat. We think this is an understatement,\n- OpenAI and Anthropic both have prompt caching because repeated prompt context is expensive, but caching mostly helps when the reusable content is stable enough to hit the cache. But this doesn't resolve the fact that prompt caching is forfeited after 5min-15mins of inactivity.\n- \u201cLost in the Middle\u201d and Chroma\u2019s \u201ccontext rot\u201d work both point at the same issue: more context is not the same thing as usable memory.\n- The context-engineering crowd seems to be converging on this: the hard part is deciding what the model should see at each step.
Parcle is our attempt at making that operational: memory outside the model, selected into context only when useful.
I\u2019d love feedback from people running real agents in production:
1. Where are your tokens actually going: repeated input context, tool traces, retries, output, evals, or something else?\n2. Have prompt caching and model routing been enough?\n3. What would you need to trust an external memory layer inside an agent loop?","title":"Show HN: We cut >60% of tokens from agentic tasks by removing repeated context","updated_at":"2026-06-27T02:36:43Z","url":"https://parcle.ai/"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"Theeldarwes"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN.
I've built an AI inbound SDR for websites because I couldn't find one.
It engages every visitor and can schedule calls, send lead magnets, and help users navigate websites.
it all started when I was looking for a sales chatbot to increase conversions for one of the companies I was previously working with.
I found a few and all of them cost at least a few thousand per month and were built weirdly (bad routing, not actually AI, required humans, bad onboarding, poor UX).
So I've decided to build one based on these principles:\n- no human involvement\n- easy self-serve onboarding (it takes 5 minutes to launch an agent on your website)\n- ONLY natural language processing, no forms or non-human interaction\n- it shouldn't wait for a visitor to start a conversation (so it must be proactive)\n- focused on end-user UX
Here's how I implemented this:\n- we are only showing the chatbot to prospects, not existing customers. Therefore, no customer support functionality is needed.\n- we A/B test every message and tailor it to the website's tone of voice.\n- we send 1 report per week on how the agent is doing\n- we support integration to 6000+ providers through Zapier and Make.com\n- you just need to copy and paste the code to make the chatbot work\n- we scan the whole website for knowledge-base
The difference between us and others is that we send highly personalised, context-aware messages even before visitors decide to open a chatbot. Compared to other chatbots we have 800-1000% more conversations because we nailed proactive messaging & personalisation.
We've since launched it with 10+ companies and 90% of them got 2-5x more conversions and leads from their corporate website.
I've enabled a free plan for anyone who wants to try it out and share some feedback.
We have the highest conversion rates and return on investment when I tried other "revenue-generating chatbots".
Check it out here: https://hachlyai.com/. Cheers!"},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Got tired of looking for sales chatbot, so built my own"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://www.hachlyai.com"}},"_tags":["story","author_Theeldarwes","story_41715263","show_hn"],"author":"Theeldarwes","created_at":"2024-10-01T23:04:06Z","created_at_i":1727823846,"num_comments":0,"objectID":"41715263","points":1,"story_id":41715263,"story_text":"Hey HN.
I've built an AI inbound SDR for websites because I couldn't find one.
It engages every visitor and can schedule calls, send lead magnets, and help users navigate websites.
it all started when I was looking for a sales chatbot to increase conversions for one of the companies I was previously working with.
I found a few and all of them cost at least a few thousand per month and were built weirdly (bad routing, not actually AI, required humans, bad onboarding, poor UX).
So I've decided to build one based on these principles:\n- no human involvement\n- easy self-serve onboarding (it takes 5 minutes to launch an agent on your website)\n- ONLY natural language processing, no forms or non-human interaction\n- it shouldn't wait for a visitor to start a conversation (so it must be proactive)\n- focused on end-user UX
Here's how I implemented this:\n- we are only showing the chatbot to prospects, not existing customers. Therefore, no customer support functionality is needed.\n- we A/B test every message and tailor it to the website's tone of voice.\n- we send 1 report per week on how the agent is doing\n- we support integration to 6000+ providers through Zapier and Make.com\n- you just need to copy and paste the code to make the chatbot work\n- we scan the whole website for knowledge-base
The difference between us and others is that we send highly personalised, context-aware messages even before visitors decide to open a chatbot. Compared to other chatbots we have 800-1000% more conversations because we nailed proactive messaging & personalisation.
We've since launched it with 10+ companies and 90% of them got 2-5x more conversions and leads from their corporate website.
I've enabled a free plan for anyone who wants to try it out and share some feedback.
We have the highest conversion rates and return on investment when I tried other "revenue-generating chatbots".
Check it out here: https://hachlyai.com/. Cheers!","title":"Show HN: Got tired of looking for sales chatbot, so built my own","updated_at":"2024-10-01T23:08:13Z","url":"https://www.hachlyai.com"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"aftergibson"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Yeah, I\u2019m not disputing that AI-assisted engineering is a real shift. It obviously is.
My issue is that we\u2019ve now got a million secondary \u201cparadigm shifts\u201d layered on top: agent frameworks, orchestration patterns, prompt DSLs, eval harnesses, routing, memory, tool calling, \u201cautonomous\u201d workflows\u2026 all presented like you\u2019re behind if you\u2019re not constantly replatforming your brain.
Even if the end-state is \u201cengineers code less\u201d, the near-term reality for most engineers is still: deliver software, support customers, handle incidents, and now also become competent evaluators of rapidly changing bot stacks. That cognitive tax is brutal.
So yes, follow where the ball is going. I am. I\u2019m just not pretending the current proliferation is anything other than noisy and expensive to keep up with."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai"],"value":"Ex-GitHub CEO launches a new developer platform for AI agents"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://entire.io/blog/hello-entire-world/"}},"_tags":["comment","author_aftergibson","story_46961345"],"author":"aftergibson","comment_text":"Yeah, I\u2019m not disputing that AI-assisted engineering is a real shift. It obviously is.
My issue is that we\u2019ve now got a million secondary \u201cparadigm shifts\u201d layered on top: agent frameworks, orchestration patterns, prompt DSLs, eval harnesses, routing, memory, tool calling, \u201cautonomous\u201d workflows\u2026 all presented like you\u2019re behind if you\u2019re not constantly replatforming your brain.
Even if the end-state is \u201cengineers code less\u201d, the near-term reality for most engineers is still: deliver software, support customers, handle incidents, and now also become competent evaluators of rapidly changing bot stacks. That cognitive tax is brutal.
So yes, follow where the ball is going. I am. I\u2019m just not pretending the current proliferation is anything other than noisy and expensive to keep up with.","created_at":"2026-02-10T22:53:27Z","created_at_i":1770764007,"objectID":"46968149","parent_id":46967088,"story_id":46961345,"story_title":"Ex-GitHub CEO launches a new developer platform for AI agents","story_url":"https://entire.io/blog/hello-entire-world/","updated_at":"2026-03-05T23:34:23Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"anuj0456"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Key Features
Hierarchical Agent System: Manager/worker hierarchies, intelligent task routing, and specialized agent implementations
Production Ready: Asynchronous processing, dynamic scaling, load balancing, and fault tolerance
Advanced Memory: Semantic storage, task history tracking, and context preservation
Integrations: Support for multiple LLM providers (OpenAI, Anthropic, Google)
The framework includes pre-built specialized agents for customer service, document processing, email handling, research, marketing, sales, social media, and web search.
I built PilottAI to address the challenges of orchestrating multiple AI agents in production environments. I'd love feedback from the HN community, especially from those working with multi-agent architectures."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["agent"],"value":"Show HN: PilottAI \u2013 A Python framework for building scalable multi-agent systems"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://pilottai.com"}},"_tags":["comment","author_anuj0456","story_43390929"],"author":"anuj0456","children":[43391993],"comment_text":"Key Features
Hierarchical Agent System: Manager/worker hierarchies, intelligent task routing, and specialized agent implementations
Production Ready: Asynchronous processing, dynamic scaling, load balancing, and fault tolerance
Advanced Memory: Semantic storage, task history tracking, and context preservation
Integrations: Support for multiple LLM providers (OpenAI, Anthropic, Google)
The framework includes pre-built specialized agents for customer service, document processing, email handling, research, marketing, sales, social media, and web search.
I built PilottAI to address the challenges of orchestrating multiple AI agents in production environments. I'd love feedback from the HN community, especially from those working with multi-agent architectures.","created_at":"2025-03-17T18:06:09Z","created_at_i":1742234769,"objectID":"43391134","parent_id":43390929,"story_id":43390929,"story_title":"Show HN: PilottAI \u2013 A Python framework for building scalable multi-agent systems","story_url":"https://pilottai.com","updated_at":"2025-03-17T19:35:16Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"pranav_rajs"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN,
Thanks for all the support you folks gave us in the past[1]. At Chatwoot[2], we are developing an open-source[3] customer support platform as an alternative to Intercom and Zendesk. I'm glad to announce our latest AI update. We have been working with the latest LLMs to see if we can assist support staff in reducing their workload.
We have observed large-scale Chatwoot deployments with over 10 million messages. From our discussions with the teams handling these deployments, we noticed two types of queries. The first type consists of simple questions, sometimes with minor tweaks. The second type requires human intervention and typically involves more complex support queries. Many tools first employ an FAQ bot, now an AI bot, before transferring to a human. This process can be frustrating for both the user and the support agent. We have found that customers, especially when they are already frustrated, dislike having to interact with a bot before reaching a human to resolve their issue.
The issue we face is the lack of distinction between the two types of queries. Not all queries are inherently support queries. Sometimes, the customer may not want to search through the documentation, or the documentation may not be well-organized enough to find the answer. Having a chat common chat interface makes it harder for everyone.
We believe that a clear UX distinction can make a significant difference. Here is how we plan to split these conversations.
a/ *Universal search interface*: This is a Chat GPT-like chat that you can integrate into your application. Users can click on the search icon or use CMD+K to access it. They can find answers using your help desk articles and carry out tasks through natural language queries like "Where is my order?" or "When is the next billing date?". We have found this can improve the quality of support requests received.
b/ *Live Chat SDK*: To address complex issues, your customers can communicate directly with you with the live chat SDK.
This approach will clarify expectations for the end customer. Use the search function for straightforward queries and engage with an agent for more complicated ones.
Along with these, we also introduced some updates to the agent interface. These updates will help agents prioritize conversations by auto-tagging them and routing them to the appropriate teams.
We are launching it as a closed beta at the moment to work closely with teams with scale and unique problems. Also, we have not yet figured out how we can add support for the open-source LLMs in different environments, as our installations are one-click at the moment. Adding those would make it complex for everyone.
[1] https://news.ycombinator.com/item?id=26501527
[3] https://github.com/chatwoot/chatwoot"},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai"],"value":"Show HN: AI-powered open-source alternative to Intercom"},"story_url":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai"],"value":"https://www.chatwoot.ai"}},"_tags":["comment","author_pranav_rajs","story_38359533"],"author":"pranav_rajs","comment_text":"Hey HN,
Thanks for all the support you folks gave us in the past[1]. At Chatwoot[2], we are developing an open-source[3] customer support platform as an alternative to Intercom and Zendesk. I'm glad to announce our latest AI update. We have been working with the latest LLMs to see if we can assist support staff in reducing their workload.
We have observed large-scale Chatwoot deployments with over 10 million messages. From our discussions with the teams handling these deployments, we noticed two types of queries. The first type consists of simple questions, sometimes with minor tweaks. The second type requires human intervention and typically involves more complex support queries. Many tools first employ an FAQ bot, now an AI bot, before transferring to a human. This process can be frustrating for both the user and the support agent. We have found that customers, especially when they are already frustrated, dislike having to interact with a bot before reaching a human to resolve their issue.
The issue we face is the lack of distinction between the two types of queries. Not all queries are inherently support queries. Sometimes, the customer may not want to search through the documentation, or the documentation may not be well-organized enough to find the answer. Having a chat common chat interface makes it harder for everyone.
We believe that a clear UX distinction can make a significant difference. Here is how we plan to split these conversations.
a/ *Universal search interface*: This is a Chat GPT-like chat that you can integrate into your application. Users can click on the search icon or use CMD+K to access it. They can find answers using your help desk articles and carry out tasks through natural language queries like "Where is my order?" or "When is the next billing date?". We have found this can improve the quality of support requests received.
b/ *Live Chat SDK*: To address complex issues, your customers can communicate directly with you with the live chat SDK.
This approach will clarify expectations for the end customer. Use the search function for straightforward queries and engage with an agent for more complicated ones.
Along with these, we also introduced some updates to the agent interface. These updates will help agents prioritize conversations by auto-tagging them and routing them to the appropriate teams.
We are launching it as a closed beta at the moment to work closely with teams with scale and unique problems. Also, we have not yet figured out how we can add support for the open-source LLMs in different environments, as our installations are one-click at the moment. Adding those would make it complex for everyone.
[1] https://news.ycombinator.com/item?id=26501527
[3] https://github.com/chatwoot/chatwoot","created_at":"2023-11-21T05:05:00Z","created_at_i":1700543100,"objectID":"38359540","parent_id":38359533,"story_id":38359533,"story_title":"Show HN: AI-powered open-source alternative to Intercom","story_url":"https://www.chatwoot.ai","updated_at":"2024-09-20T15:41:46Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"bhaviav100"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Many teams now allow AI systems to draft customer-facing messages across support, CRM, and billing workflows.
This introduces a specific failure mode:\nAI can generate text that constitutes an irreversible business commitment\n(refunds, credits, billing changes, contractual promises).
Once emitted, the commitment exists. Detection after delivery is irrelevant.
This project implements a hard authority boundary.
Model\n--------\nAI systems propose messages.\nThey do not decide whether those messages are allowed to commit the company.
A gateway enforces that decision.
AI drafts message\n \u2193\nAuthority Gateway\n \u2193\nSend | Block \u2192 Approval
Behavior\n---------\nFor each outbound message:
Inspect text for commitment signals
Classify outcome as reversible or irreversible
If reversible \u2192 allow
If irreversible \u2192 block and require explicit approval
Log decision and evidence
No attempt is made to assess advice quality, intent, or correctness.\nOnly enforceability is considered.
API surface\n------------\n/v1/messages/send\nEnforces authority on outbound messages
/v1/support/messages/decide\nDecision-only endpoint for support systems\nReturns structured reasons and a safe fallback reply
Properties\n----------\nDeterministic enforcement
Idempotent execution
Explicit approval for irreversible actions
No reliance on prompt discipline or training hygiene
No agent autonomy
This is a sandbox implementation to test whether a narrow authority layer is useful in practice.
Feedback welcome from teams already routing AI-generated messages into real customer workflows."},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["customer","ai"],"value":"Show HN: An authority gate for AI-generated customer communications"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://authority.bhaviavelayudhan.com/"}},"_tags":["story","author_bhaviav100","story_46481176","show_hn"],"author":"bhaviav100","created_at":"2026-01-03T20:28:04Z","created_at_i":1767472084,"num_comments":0,"objectID":"46481176","points":4,"story_id":46481176,"story_text":"Many teams now allow AI systems to draft customer-facing messages across support, CRM, and billing workflows.
This introduces a specific failure mode:\nAI can generate text that constitutes an irreversible business commitment\n(refunds, credits, billing changes, contractual promises).
Once emitted, the commitment exists. Detection after delivery is irrelevant.
This project implements a hard authority boundary.
Model\n--------\nAI systems propose messages.\nThey do not decide whether those messages are allowed to commit the company.
A gateway enforces that decision.
AI drafts message\n \u2193\nAuthority Gateway\n \u2193\nSend | Block \u2192 Approval
Behavior\n---------\nFor each outbound message:
Inspect text for commitment signals
Classify outcome as reversible or irreversible
If reversible \u2192 allow
If irreversible \u2192 block and require explicit approval
Log decision and evidence
No attempt is made to assess advice quality, intent, or correctness.\nOnly enforceability is considered.
API surface\n------------\n/v1/messages/send\nEnforces authority on outbound messages
/v1/support/messages/decide\nDecision-only endpoint for support systems\nReturns structured reasons and a safe fallback reply
Properties\n----------\nDeterministic enforcement
Idempotent execution
Explicit approval for irreversible actions
No reliance on prompt discipline or training hygiene
No agent autonomy
This is a sandbox implementation to test whether a narrow authority layer is useful in practice.
Feedback welcome from teams already routing AI-generated messages into real customer workflows.","title":"Show HN: An authority gate for AI-generated customer communications","updated_at":"2026-03-05T23:18:54Z","url":"https://authority.bhaviavelayudhan.com/"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"tetha"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Similar to the sibling comment, helpdesk ticket routing.
The volume of helpdesk tickets large enterprises deal with is very easily and vastly underestimated. If you can even route 30% away from the central triage with 90+% accuracy and drop everything else back to the central triage... you suddenly safe 2 FTEs in that spot in some places. And increase customer satisfaction for most of those tickets because they get resolved faster.
Or, as much as people hate it, chatbots as a customer front. Yes, everyone here as an expert in a lot of tech has had terrible experiences with chatbots. Please mark your hate with the word "Lemon" in the comments. But decently implemented chatbots with a few systems behind them can resolve staggering amounts of simple problems from non-techies without human interaction from the company deploying them. It remains important to eventually escalate to humans - including the history from all of these interactions to avoid frustrations, sure.
Or, ticket/request preprocessing. Remember how spelling that 10 digit account number to a call center agent hard of hearing sucks? Those 4 retries because of you not using a better way to communicate that number also costs the company. Now, you can push a few of these retries into an AI system. If you mail them, an AI system can try to extract information like account numbers, intent, start of the problem, problem descriptions and such into dedicated fields to make the support agents faster.
Companies are certainly overdoing it at the moment, I'm not denying that. But a lot of the support/helpdesk pre-screening can be automated with current AI/ML capabilities very decently. Especially if you learn to recognize and navigate it."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["ai"],"value":"Ask HN: What are some actual use cases of AI Agents right now?"}},"_tags":["comment","author_tetha","story_39373662"],"author":"tetha","children":[39376725,39376885,39377539,39377634,39382347],"comment_text":"Similar to the sibling comment, helpdesk ticket routing.
The volume of helpdesk tickets large enterprises deal with is very easily and vastly underestimated. If you can even route 30% away from the central triage with 90+% accuracy and drop everything else back to the central triage... you suddenly safe 2 FTEs in that spot in some places. And increase customer satisfaction for most of those tickets because they get resolved faster.
Or, as much as people hate it, chatbots as a customer front. Yes, everyone here as an expert in a lot of tech has had terrible experiences with chatbots. Please mark your hate with the word "Lemon" in the comments. But decently implemented chatbots with a few systems behind them can resolve staggering amounts of simple problems from non-techies without human interaction from the company deploying them. It remains important to eventually escalate to humans - including the history from all of these interactions to avoid frustrations, sure.
Or, ticket/request preprocessing. Remember how spelling that 10 digit account number to a call center agent hard of hearing sucks? Those 4 retries because of you not using a better way to communicate that number also costs the company. Now, you can push a few of these retries into an AI system. If you mail them, an AI system can try to extract information like account numbers, intent, start of the problem, problem descriptions and such into dedicated fields to make the support agents faster.
Companies are certainly overdoing it at the moment, I'm not denying that. But a lot of the support/helpdesk pre-screening can be automated with current AI/ML capabilities very decently. Especially if you learn to recognize and navigate it.","created_at":"2024-02-14T22:38:24Z","created_at_i":1707950304,"objectID":"39376552","parent_id":39375226,"story_id":39373662,"story_title":"Ask HN: What are some actual use cases of AI Agents right now?","updated_at":"2024-09-20T16:28:58Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"abwahab"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Introduction
Customer support is the heartbeat of every e-commerce business. From answering product questions to handling returns, the quality of support often decides whether a customer comes back or leaves for good. Traditionally, companies relied on teams of human agents, but Artificial Intelligence (AI) is now transforming the industry. The big question is: Can one AI agent outperform five human agents in e-commerce support?
The Importance of E-Commerce Customer Support
In online shopping, trust and convenience are everything. Customers expect fast, accurate, and friendly responses. When support fails, it leads to abandoned carts, bad reviews, and lost sales.
However, human agents face challenges such as high ticket volumes during busy seasons, repetitive questions like \u201cWhere\u2019s my order?\u201d, limited working hours, and rising costs for salaries and training. This is where AI customer support solutions step in.
Human Customer Support Agents: Strengths and Weaknesses
Human agents bring empathy and emotional intelligence\u2014qualities machines cannot fully replicate. They can calm down angry customers, handle unique cases, and provide a personal touch that builds strong relationships.
But there are limits:
They can only work a set number of hours.
Response times slow down during peak demand.
Businesses must hire, train, and manage larger teams as they grow.
The Rise of AI in Customer Support
AI agents are powered by machine learning and natural language processing, enabling them to understand and respond to customer queries instantly. They are now integrated into live chats, help desks, and voice systems across leading e-commerce platforms.
Key benefits include:
24/7 availability with no downtime.
Instant replies, reducing customer frustration.
Scalability, managing thousands of inquiries at once.
Lower costs, since one AI agent can replace multiple human agents for routine tasks.
Studies show that businesses adopting AI in customer service can reduce costs by up to 30% while improving customer satisfaction.
Human vs AI: Who Performs Better?
Human agents shine in complex, emotionally charged situations where empathy matters most. But AI dominates when it comes to speed, volume, and consistency. Since most e-commerce queries are repetitive\u2014tracking orders, return policies, or product availability\u2014AI is far more efficient than a team of five human agents.
In short:
Humans = Best for empathy and unique problems.
AI = Best for speed, scalability, and repetitive tasks.
Why AI Agents Are a Smarter Choice
Scalability: AI can handle surges in demand, like holiday shopping seasons, without hiring extra staff.
Consistency: AI delivers the same accurate response every time.
Cost Savings: Businesses save on salaries, training, and overhead.
Data Insights: AI analyzes patterns in customer behavior, helping businesses improve products and services.
Customer Satisfaction: Faster responses mean happier, more loyal customers.
Conclusion
Customer support is critical for e-commerce growth. Human agents bring empathy and understanding, but they are limited by time, cost, and workload. One AI agent, however, can provide instant, 24/7 support at scale\u2014making it a clear winner in most situations.
The future of e-commerce support isn\u2019t about replacing humans entirely. Instead, it\u2019s about using AI to handle repetitive tasks while allowing human agents to focus on complex, high-value cases. For businesses aiming to improve efficiency and customer satisfaction, AI customer support solutions are the smarter, more scalable choice."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"[dead]"}},"_tags":["comment","author_abwahab","story_44968916"],"author":"abwahab","comment_text":"Introduction
Customer support is the heartbeat of every e-commerce business. From answering product questions to handling returns, the quality of support often decides whether a customer comes back or leaves for good. Traditionally, companies relied on teams of human agents, but Artificial Intelligence (AI) is now transforming the industry. The big question is: Can one AI agent outperform five human agents in e-commerce support?
The Importance of E-Commerce Customer Support
In online shopping, trust and convenience are everything. Customers expect fast, accurate, and friendly responses. When support fails, it leads to abandoned carts, bad reviews, and lost sales.
However, human agents face challenges such as high ticket volumes during busy seasons, repetitive questions like \u201cWhere\u2019s my order?\u201d, limited working hours, and rising costs for salaries and training. This is where AI customer support solutions step in.
Human Customer Support Agents: Strengths and Weaknesses
Human agents bring empathy and emotional intelligence\u2014qualities machines cannot fully replicate. They can calm down angry customers, handle unique cases, and provide a personal touch that builds strong relationships.
But there are limits:
They can only work a set number of hours.
Response times slow down during peak demand.
Businesses must hire, train, and manage larger teams as they grow.
The Rise of AI in Customer Support
AI agents are powered by machine learning and natural language processing, enabling them to understand and respond to customer queries instantly. They are now integrated into live chats, help desks, and voice systems across leading e-commerce platforms.
Key benefits include:
24/7 availability with no downtime.
Instant replies, reducing customer frustration.
Scalability, managing thousands of inquiries at once.
Lower costs, since one AI agent can replace multiple human agents for routine tasks.
Studies show that businesses adopting AI in customer service can reduce costs by up to 30% while improving customer satisfaction.
Human vs AI: Who Performs Better?
Human agents shine in complex, emotionally charged situations where empathy matters most. But AI dominates when it comes to speed, volume, and consistency. Since most e-commerce queries are repetitive\u2014tracking orders, return policies, or product availability\u2014AI is far more efficient than a team of five human agents.
In short:
Humans = Best for empathy and unique problems.
AI = Best for speed, scalability, and repetitive tasks.
Why AI Agents Are a Smarter Choice
Scalability: AI can handle surges in demand, like holiday shopping seasons, without hiring extra staff.
Consistency: AI delivers the same accurate response every time.
Cost Savings: Businesses save on salaries, training, and overhead.
Data Insights: AI analyzes patterns in customer behavior, helping businesses improve products and services.
Customer Satisfaction: Faster responses mean happier, more loyal customers.
Conclusion
Customer support is critical for e-commerce growth. Human agents bring empathy and understanding, but they are limited by time, cost, and workload. One AI agent, however, can provide instant, 24/7 support at scale\u2014making it a clear winner in most situations.
The future of e-commerce support isn\u2019t about replacing humans entirely. Instead, it\u2019s about using AI to handle repetitive tasks while allowing human agents to focus on complex, high-value cases. For businesses aiming to improve efficiency and customer satisfaction, AI customer support solutions are the smarter, more scalable choice.","created_at":"2025-08-21T04:02:19Z","created_at_i":1755748939,"objectID":"44968917","parent_id":44968916,"story_id":44968916,"story_title":"[dead]","updated_at":"2026-03-05T22:32:14Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"robin_sidekick"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["customer","support","ai","agent","routing"],"value":"Hey HN community, we are building an AI assistant, specifically focused on being the single point of contact between a customer and any business, whose product or service that customer might be using. Customers understandably are already quite frustrated when they reach out to a business for support, because in most cases, they have had an unpleasant experience (either bill surprise, or product or device failure, or routine maintenance) that they wish to rectify. Now, most of us don't have a pleasant experience with support. Besides the time we have to take out to reaching support, navigating IVR, or navigating self-help options, talking to an agent (or a bot) and eventually reaching a human. A lot of companies are building agent co-pilot solutions for enterprises, to empower their agents, and fortify their self-serve options. We believe the incremental opportunity here is to focus on the consumer side and provide an AI assistant (always available) that you can speak to any time, and convey the problem you are facing for which you seek a resolution. And, this AI agent will go about figuring out, how to drive that issue to resolution, whether it's through a businesses self-serve options, their IVR, talking to a bot, or a human agent, whatever it takes. Wanted to seek the community's advice here, from a capability standpoint (we are building a prototype) if others have attempted this and found some fundamental limitations with agentic workflows today, and also from a idea standpoint, whether you believe, if this existed, it would be something you would pay for, to not have to deal with any business support directly ever again. thanks!"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["customer","support","ai"],"value":"Ask HN: Advice on AI as a personal assistant, for customer support use cases"}},"_tags":["story","author_robin_sidekick","story_40934851","ask_hn"],"author":"robin_sidekick","children":[40934903],"created_at":"2024-07-11T09:12:35Z","created_at_i":1720689155,"num_comments":2,"objectID":"40934851","points":1,"story_id":40934851,"story_text":"Hey HN community, we are building an AI assistant, specifically focused on being the single point of contact between a customer and any business, whose product or service that customer might be using. Customers understandably are already quite frustrated when they reach out to a business for support, because in most cases, they have had an unpleasant experience (either bill surprise, or product or device failure, or routine maintenance) that they wish to rectify. Now, most of us don't have a pleasant experience with support. Besides the time we have to take out to reaching support, navigating IVR, or navigating self-help options, talking to an agent (or a bot) and eventually reaching a human. A lot of companies are building agent co-pilot solutions for enterprises, to empower their agents, and fortify their self-serve options. We believe the incremental opportunity here is to focus on the consumer side and provide an AI assistant (always available) that you can speak to any time, and convey the problem you are facing for which you seek a resolution. And, this AI agent will go about figuring out, how to drive that issue to resolution, whether it's through a businesses self-serve options, their IVR, talking to a bot, or a human agent, whatever it takes. Wanted to seek the community's advice here, from a capability standpoint (we are building a prototype) if others have attempted this and found some fundamental limitations with agentic workflows today, and also from a idea standpoint, whether you believe, if this existed, it would be something you would pay for, to not have to deal with any business support directly ever again. thanks!","title":"Ask HN: Advice on AI as a personal assistant, for customer support use cases","updated_at":"2024-09-20T17:25:09Z"}],"hitsPerPage":20,"nbHits":38,"nbPages":2,"page":0,"params":"query=customer+support+AI+agent+routing&advancedSyntax=true&analyticsTags=backend","processingTimeMS":53,"processingTimingsMS":{"_request":{"roundTrip":15},"afterFetch":{"format":{"highlighting":5,"total":6},"merge":{"mergeLoop":{"prepareNextHit":2,"total":2},"total":4},"total":4},"fetch":{"query":18,"scanning":29,"total":48},"total":53},"query":"customer support AI agent routing","serverTimeMS":60}