pranav_rajs

We built Faultline at Chatwoot to help our team debug infrastructure incidents faster. It's an AI agent you can ask questions in plain English — it autonomously queries your monitoring tools, cloud infrastructure, and codebase, then comes back with a root cause analysis.

It connects to New Relic, Sentry, AWS, GitHub, and PagerDuty using MCP (Model Context Protocol) servers and native integrations. You ask something like "Why is the API latency high?" and the agent loops through your tools — pulling APM metrics, checking error rates, scanning recent deploys — until it has enough data to give you an answer.

Stack: Rails 8 + Sidekiq backend, Python/FastAPI agent service using OpenAI, Vue 3 frontend, PostgreSQL, Redis. All integrations are configured through the UI, credentials encrypted at rest.

It doesn't replace an SRE — but it does the first pass of pulling data from five different dashboards and correlating timelines, which usually takes 10-15 minutes manually.

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.