LLM WIKI in Practice: Making Agents Truly Understand Enterprise Business — Building a Troubleshooting Agent from Scratch

Many teams have built agents, but their response accuracy is abysmal. The problem isn't the model — it's that the agent simply doesn't understand the enterprise's business. Based on a real-world deployment case of an order customer service troubleshooting agent, this article breaks down how to use LLM WIKI to turn codebases and business logic into knowledge that agents can understand, covering the complete chain from concepts and principles to repository construction, incremental updates, MCP server integration, and troubleshooting in practice.

Why Doesn't Your Agent "Understand the Business"?

According to a Bilibili creator (lead instructor of the Ma-style Education large model course), he called his job-seeking students over the past three months, and almost all of them complained: the agents they built for clients went live, but the response accuracy was terrible. Upon further questioning, the single most core reason emerged — the agent didn't truly understand the enterprise's business.

This judgment was emphasized repeatedly in the video and is the starting point for all subsequent solution design. When enterprise business is brought to agents, teams commonly get stuck on three practical obstacles:

• Business descriptions aren't written down: Take customer service as an example. Typically a customer service manager trains a few assistants and regular employees hands-on, and that's the end of it. No one writes the business rules and boundaries into documentation.
• Business processes are incomplete: No one tells you the full process — they only give you a part, and the rest relies on the "veterans'" experience, which also never makes it into written form.
• Business staff aren't cooperative: Many people on the business side feel it's "not their problem" and expect FD engineers to figure out the business line themselves. At most, leadership says, "Just shadow the business line for a week."

The result: whether you want to generate text, organize authoritative business people to go through rules one by one, or trace the process from start to finish, none of it moves forward in reality. This isn't a technical problem — it's an organizational collaboration problem. And what LLM WIKI aims to solve is precisely this stalemate of "nobody will write the documentation for you."

What Is LLM WIKI: Turning the Codebase into an Agent's Business Knowledge Base

The creator didn't stop at theory — he directly simulated an order customer service business line, likewise with no written business rules and no complete process documentation. What he wanted to verify was: under the premise of "zero documentation," can an agent handle order customer service issues on its own?

The LLM WIKI approach can be understood as: letting the agent reverse-extract business knowledge from the codebase and systems, forming a structured, searchable Wiki, which is then exposed to the troubleshooting agent through an MCP server. The difference from traditional RAG is that RAG typically relies on manually curated document chunks, whereas LLM WIKI's knowledge source is the codebase itself — the code contains order state transitions, exception branches, and interface constraints, which are the most authentic business rules.

According to the creator's demo, the conversational model used was DeepThink Flash (1017 version), and what was built was an "order fault diagnosis customer service assistant" that answers consumer questions like "Why hasn't my order shipped yet?" This scenario looks simple, but behind it the agent needs to understand the complete chain of an order from placement to shipment to delivery, as well as the handling rules when problems occur at each stage.

RAG (Retrieval-Augmented Generation) is the common paradigm for agents to access external knowledge today: humans first chunk and vectorize documents into a vector store; when a user asks a question, the most relevant fragments are retrieved and assembled into the prompt, and the large model generates the answer. Its bottleneck is that the knowledge source depends on manually curated high-quality documents, and chunk granularity and recall quality are highly dependent on document structure. LLM WIKI swaps the knowledge source for the codebase and the systems themselves: state machines, conditional branches, interface validations, and exception handling in code naturally carry structured semantics and are strictly consistent with online behavior. The two are not mutually exclusive — the Wiki can serve as the upstream knowledge production stage for RAG, translating code into semantically complete entries before retrieval, thereby bypassing the prerequisite dependency of "nobody writes documentation."

Repository Construction: Extracting Business Knowledge from the Codebase

The key action in building an LLM WIKI repository is distilling business logic from the codebase into entries that an agent can retrieve. Based on the case, this can be broken down into three layers:

1. Entity and state layer: What states does an order have (pending payment, paid, pending shipment, shipped, in transit, signed for), how do states transition, and which transitions are exception branches.
2. Rules and boundaries layer: Under what conditions is an order judged "problematic" — for example, overdue without shipment, inventory lock failure, payment callback exception — and what handling action applies to each case.
3. Process and role layer: What customer service needs to know about the delivery process when handling order issues, who to contact when delivery problems arise, and what process to follow.

In code, this information is often scattered — the state machine definition in one file, exception handling in another, interface validation elsewhere. The value of LLM WIKI is aggregating them into a readable, searchable, updatable knowledge base, rather than having the agent read the entire codebase from scratch every time.

Incremental Updates: Keeping the Knowledge Base in Sync with Business Changes

Business code changes daily. If the knowledge base can only be built once, it will quickly become outdated. Incremental updates are the prerequisite for LLM WIKI to remain usable long-term.

From the case's engineering approach, incremental updates need to solve two problems: first, identifying changes — which files and functions affect business rules after a code commit; second, local reconstruction — updating only the affected knowledge entries rather than rerunning everything. This controls cost while ensuring the business rules the agent receives are consistent with the online code.

This is especially important in troubleshooting scenarios — if the troubleshooting agent's conclusions are based on outdated rules, it will actually mislead customer service.

Incremental updates in engineering typically rely on two types of signals: first, change information from the version control system, such as file- and function-level changes given by git diff; second, the code's static structure, such as the abstract syntax tree (AST) and call graphs, used to determine which business entries reference a given function. With this dependency mapping, you can translate "which lines of code changed" into "which business rules are affected," and then rebuild only the affected Wiki entries. In contrast, full rebuilds grow linearly in cost with codebase size and are nearly unsustainable in teams with high-frequency business iteration. Engineering also needs to handle idempotency and version alignment: rebuilding the same entry multiple times should yield stable results, and the corresponding code commit version should be recorded for traceability of conclusions during troubleshooting.

MCP Server: Exposing Wiki Capabilities to Agents

Once LLM WIKI is built, a standardized channel is needed for agents to call it. The MCP (Model Context Protocol) server plays this role: encapsulating the Wiki's retrieval and query capabilities as tools that agents can invoke on demand during troubleshooting.

The benefit is decoupling — knowledge base construction and updates can iterate independently, and the agent only cares about "what to ask and what to get." In the demo, the creator also mentioned that most students have learned large models, agents, and RAG techniques, and know they need to define tools, add context, and incorporate short-term and long-term memory — but what really stumps them is that "the agent doesn't understand what the business specifically does." Connecting the MCP server to LLM WIKI fills exactly this gap in business understanding.

MCP (Model Context Protocol) is an open protocol for large model applications that exposes external data sources and capabilities to model clients in the form of standardized "tools/resources." It uses a client-server architecture: the MCP server declares which tools it provides along with their input/output parameter structures, and the client on the agent side discovers these tools at runtime and invokes them on demand, without writing separate adapter code for each data source. For LLM WIKI, this means capabilities like retrieving entries, querying state transitions by entity, and reading exception handling rules can be encapsulated as several tools for reuse by different agents. Its value lies in the decoupling enabled by interface standardization: the knowledge base's storage structure and update strategy can evolve independently, and as long as the tool contract remains unchanged, the agent side needs no modification.

Troubleshooting in Practice: How the Order Customer Service Agent Works

Back to the demonstrated order fault diagnosis assistant. When a user asks "Why hasn't my order shipped yet?", the agent's workflow is roughly:

• Call LLM WIKI via MCP to retrieve order state transition rules and shipping conditions;
• Combine with the order's actual current state to determine which stage it's stuck at;
• Based on the exception handling rules in the Wiki, provide the corresponding explanation and next steps.

In this process, the agent doesn't need to be "taught" all business details in advance — it treats the Wiki as a queryable business manual. For FD engineers, this means no longer relying on business staff to cooperate in writing documentation — the codebase itself is the knowledge source, and LLM WIKI is responsible for translating it into a form the agent can use.

Who This Approach Is For

From the case, we can summarize the applicable boundaries: teams whose business logic is primarily embedded in code and systems are best suited to use LLM WIKI to fill in business understanding; if business rules exist mostly as offline verbal experience and are barely reflected in systems, then LLM WIKI can extract only limited content and still requires manual curation.

Another practical constraint is the engineering quality of incremental updates — if change identification is coarse, the knowledge base will become inaccurate. This wasn't elaborated in detail in the video and is an area that needs focused validation during deployment.

Overall, LLM WIKI offers an actionable engineering path for "agents that don't understand the business": instead of relying on business stakeholders to write documentation, it reverse-builds knowledge from the codebase and then connects it to the troubleshooting agent via MCP. For teams currently struggling with agent accuracy, this pipeline is worth running through hands-on.