Kahuna Labs Blog

By Chaitanya Potluri, Co-Founder, Kahuna Labs, and Gurmeet Singh Manku, Co-Founder and Chief AI Officer, Kahuna Labs

A complex ticket arrives. The customer’s production environment is failing intermittently after a routine upgrade. On the surface it looks like a configuration issue, but the symptoms are ambiguous.

What makes this case hard is that the answer depends on the full context: the customer’s specific implementation, their environment, the patches they’ve applied, the product version they’re running, and the history of prior issues on this account.

The relevant knowledge is scattered across several places, for example:

• A knowledge base article covers similar symptoms but was written for an older product version.
• A resolved ticket from eight months ago followed a completely different diagnostic path and arrived at a fix that may or may not apply here.
• An internal note documents a compatibility edge case for this product line that was never published to the KB.
• Configuration-specific behavior that only surfaces under certain environmental conditions was discussed in an engineering thread but never shared.

The engineer finds the KB article in twenty minutes. The rest stays buried.

This plays out thousands of times a day across enterprise support organizations. Every instance means a longer resolution cycle, another frustrated customer, and another senior engineer spending time rediscovering what the organization already knew.

Troubleshooting Requires More Than “Search, Then Generate”

As enterprises have looked to AI for help with technical support, most have reached for RAG (Retrieval-Augmented Generation), the conventional approach for grounding language models in company data. The concept is straightforward: take a question, retrieve the most relevant documents, and feed them to a language model to generate an answer.

RAG was designed for scenarios where the question is clear and the answer lives in a well-written document. But in enterprise technical support for complex products, KB coverage is structurally thin. The combinatorial space of product versions, customer configurations, and deployment environments is too large to document comprehensively. Products evolve faster than documentation, engineers resolve cases and move on, and the knowledge accumulates in ticket histories and tribal memory. In cases where RAG has been force-fitted into technical product support, the results have been consistently disappointing. The cases that drive escalations, consume senior engineering time, and frustrate customers stubbornly remain out of reach. Enterprise troubleshooting demands something fundamentally different.

Support tickets are noisy, multi-turn conversations where the problem statement itself evolves as the engineer and customer exchange information. The initial description of “the system is slow” could point to a network issue, a misconfiguration, a version-specific bug, resource contention, or something entirely novel. A single retrieval pass commits to one interpretation of the problem before the problem is even fully understood.

Beyond the query problem, a standard RAG pipeline produces one ranked list of results. A compatibility note competes for the same retrieval slots as a past ticket and a KB article. The ranking is based on semantic similarity to the query, not on whether the source type is appropriate for the kind of problem being investigated. And when retrieved documents disagree, as they often do across product versions and customer configurations, the language model is left to reconcile contradictions on its own, frequently producing responses too vague to act on.

A Glimpse into How Experts Actually Solve Problems

When we watched a senior support engineer work through a hard case and we saw that patterns emerged. They do not follow a single retrieval path. They consult multiple knowledge sources, weigh them differently depending on the situation, and synthesize a recommendation that no single source contains on its own.

They often start with official product documentation to establish expected behavior, then check past cases to see how similar symptoms were resolved in practice. They know past cases are noisy and incomplete, but they also know those cases contain real-world signals that documentation often lacks. They might cross-reference a compatibility matrix to rule out a known conflict, or recall an informal pattern from experience where a cluster of similar issues pointed to a root cause that was never formally documented.

Each knowledge source has different structure, different reliability, and different relevance depending on the case at hand. The expert’s skill lies in knowing which sources to consult, how much to trust each one, and how to combine their insights into a coherent recommendation. This process can be studied, decomposed, and systematized.

How Multi-Agent Architecture Works

The architectural insight directly follows how experts operate. If troubleshooting requires reasoning across multiple knowledge sources with different characteristics, the system that automates it should be designed the same way.

A multi-agent architecture deploys a collection of specialized agents, each designed to extract troubleshooting guidance from a different type of knowledge, using techniques tuned to that knowledge type’s unique structure and noise profile. These agents work in parallel on the same problem. Each contributes its best recommendation along with a confidence signal that reflects how certain it is in its output.

A coordination layer evaluates these parallel recommendations, selects the highest-confidence outputs, resolves conflicts between them, and synthesizes a unified response that draws on multiple perspectives.

The key properties of this design matter in production:

• Modular. Each agent can be improved or replaced without disrupting the rest of the system.
• Debuggable. When a recommendation is wrong, the trace shows exactly which agent contributed it and the reasoning behind it.
• Extensible. When new knowledge sources become available, whether a new documentation set, a new class of historical data, or a new product line, a new agent can be added without re-architecting the core system.

Extensibility, however, introduces a real engineering risk: agent sprawl. Our philosophy, at Kahuna, is that every agent must earn its place. As each one requires dedicated engineering to build, evaluate, and maintain, adding surface area to the system, and technical debt.

Each agent needs a justification grounded in two questions: does the knowledge this agent handles have fundamentally different structure or noise characteristics from what others already cover, and what measurable fraction of problem scenarios will it address? This discipline is crucial to make sure the number of agents in the system reflects the true structure of the collective knowledge rather than it proliferating unchecked.

Learning from Traces of Past Troubleshooting and Expertise

One of the most valuable capabilities this architecture enables is learning from how experts have solved problems in the past. Resolved cases contain decision traces: the diagnostic paths engineers chose, the reasoning behind their steps, and the outcomes of those choices.

It is worth noting that these traces vary enormously in quality. Some tickets are thoroughly documented with clear reasoning and confirmed resolutions. Others are incomplete, outdated, or low-credibility because the customer never responded to confirm the fix, or because the workaround was applied under time pressure and never validated.

A case from two years ago on a deprecated version carries different weight than a well-documented resolution from last quarter on the current release.

A multi-agent architecture can assess the quality of these decision traces and weight them accordingly. Rather than treating all past cases as equally valid retrieval candidates, the system can evaluate credibility, completeness, and relevance before incorporating historical expertise into its recommendations. The result is that the accumulated judgment of an organization’s best engineers becomes a structured, quality-weighted asset rather than an unfiltered archive.

Implications for Support Organizations

The practical implications of this architecture center on the quality and trustworthiness of AI-generated recommendations:

• Measurable accuracy. Because each agent specializes and produces confidence signals, the overall system’s accuracy can be measured and improved at the level of individual agents. When a recommendation misses, the organization can identify where and why, and improve that specific agent rather than trying to tune a monolithic pipeline where failures are opaque.
• Independent calibration. If a particular knowledge type is producing lower-quality outputs for a class of cases, it can be adjusted without destabilizing the system’s performance on other case types.
• Transparent reasoning. Support engineers receiving AI-generated troubleshooting steps can see the reasoning behind them. This changes the dynamic from an opaque suggestion to a transparent recommendation that an engineer can evaluate, trust, and act on with confidence.
• Pluggable growth. New product lines, new documentation sources, and new types of historical data can each be onboarded by adding specialized agents rather than re-engineering the existing system. The architecture adapts to the complexity of the knowledge landscape rather than forcing that landscape into a single pipeline.

At Kahuna, we are building our platform around this multi-agent architecture because these properties are what it takes for AI to earn a real place in enterprise support. The quality of recommendations, the ability to trace and debug them, and the confidence that the system can be established and extended over time: these are the requirements that the prevailing single-pipeline approach cannot meet.