Should we build question answering or workflow first?

Two conditions decide it: whether the knowledge is reasonably stable, and whether the process already runs on systems. Stable knowledge and structured documents favour question answering; processes with data in systems — orders, work orders, approval flows — favour workflow agents, which are easier to value. If neither holds, fix data and documents first.

Does a knowledge base need a bigger model if answers are wrong?

Usually not. Retrieval quality depends first on the corpus: whether documents are cleaned and de-duplicated, whether chunking matches the granularity of questions, whether permissions are tiered, and whether there is a refresh mechanism. Without those four, a bigger model only makes errors read more smoothly. Start with 50–100 real questions as a baseline and classify the failures.

Should the data stay on premises?

It depends on data sensitivity and concurrency, not budget. Publicly listed appliances for local inference range from a few hundred thousand to several million RMB. For internal question answering at modest concurrency, the main argument for local deployment is keeping data inside the network, not performance. Where sensitivity is ordinary, metered APIs are more flexible and easier to stop during validation.

What is still needed after go-live?

At least three things: corpus refresh (new documents, expired content, permission changes), effect measurement (classifying wrong answers to real questions), and upkeep of scope and definitions. Where public projects fall out of use in year two, it is usually because nobody owns these three. Write them into the plan with named owners rather than buying a bigger model at the start.

Manufacturing

Enterprise AI agents and knowledge bases: what to build first

Updated 2026-10-17All figures from public sources

The first decision when adopting an enterprise AI agent is not which model to use but which use case to build first. Three are common: question answering (turning scattered documents into answers people can ask for), workflow (letting an agent follow processes that already run on systems), and analytics (consolidating data from several systems into a judgement). Choose the wrong starting point and everything afterwards feels awkward; choose the right one and a first version usually comes together quickly — what stretches the timeline is data access, not the model.

Three use cases: separate them before choosing

Use case	What it solves	What it depends on	Difficulty to start
Question answering	Policy, process, after-sales and training questions no longer go person to person	Corpus quality, chunking granularity, permission tiers	Low; results quickly
Workflow	Orders, work orders, approvals and exceptions advance and are chased by rule	Readable data in business systems; clear nodes and owners	Medium; value easy to quantify
Analytics	Cross-system consolidation of what needs action today	Multi-source access, unified definitions, metric ownership	Higher, but the largest decision value

The three can be combined, but not started at once. Common practice builds one first, then uses the data access and definitions it establishes for the second — which is why the second phase of such projects usually runs more smoothly than the first.

Three criteria for choosing what to build first

Is the knowledge stable? Policy and process documents suit question answering first. Content that changes constantly and travels by word of mouth will keep causing rework.
Does the process already run on systems? If it lives on paper and in chat groups, an agent has nothing to stand on and becomes another chat window.
What happens if it is wrong? Scenarios where users spot a wrong answer immediately are good starting points. Where errors are invisible and consequences heavy, insert human review first.

Four tasks of corpus governance

Most "wrong answers" are corpus problems, not model problems. Do these four in order:

Cleaning and de-duplication. Multiple versions of one document, scanned PDFs, expired notices. Retrieval treats the closest match as the answer, so version chaos becomes answer chaos.
Chunking granularity. Chunk by the granularity of questions, not by page. Process parameters by operation step, policies by clause.
Permission tiers. Who may ask what follows the existing permission model. Do not invent a second one.
Refresh mechanism. Who adds new documents, who retires expired ones, how often it is checked — with names and frequency.

Policy places governance up front as well. The Cyberspace Administration of China's guidelines on deploying large models in government affairs (October 2025) stress systematic planning, intensive development and secure, prudent rollout, with governance as necessary pre-deployment work — an order that applies equally inside a company.

Three technical decisions to settle early

Cloud or on-premises models. High sensitivity with steady volume argues for local deployment; ordinary sensitivity argues for metered APIs while validating the scenario, which is cheaper and easier to stop.
How retrieval is evaluated. Prepare 50–100 real questions as a baseline and rerun them each version, classifying failures as not found, found the wrong thing, or stale answer. Three failure types need three different fixes — not a general verdict of "poor results".
How boundaries are presented. Answers should cite their source, missing data should be declared missing, and uncertainty flagged. This decides whether users trust it.

What public data says about progress and the gap

IDC's 2025 survey of Chinese industrial enterprises found the share applying large models and agents rose from 9.6% in 2024 to 47.5% in 2025. The eight-department Action Plan on "AI + Manufacturing" issued in December 2025 targets 1,000 advanced industrial agents and 500 typical scenarios by 2027. At the same time, industry estimates suggest nearly 80% of enterprises have run a pilot and only about one in seven reached production — the gap sits in the corpus, data access and operational ownership. For how to structure the first-year budget, see splitting the first-year budget

Four common causes of failure

Treating the knowledge base as a folder upload. Without cleaning and chunking, retrieval is keyword luck.
Building the platform before the scenario. The platform lands, the use case is still under discussion, and it becomes a demo environment.
Nobody owns the refresh. Three months later documents are stale, a few answers are wrong, and users drift back to asking colleagues.
Rolling out company-wide immediately. Many departments and tangled permissions stall the project. Start with one department or one product line.

On data access and delivery models, see our enterprise AI agent deployment and custom delivery pages. To work out which use case fits your business, send us your scenario, existing systems and document situation (contact) and we will give a view, at no cost.

In one line: enterprise AI agents are decided by corpus and data access first, models second. Finish the four governance tasks and the rest opens up.

Sources: IDC's 2025 China industrial enterprise survey on large model and agent adoption (reported by Economic Information Daily, 9 March 2026); the Action Plan on "AI + Manufacturing" issued in December 2025 by the Ministry of Industry and Information Technology and seven other departments, targeting 1,000 advanced industrial agents and 500 typical scenarios by 2027; the Cyberspace Administration of China's guidelines on deploying large models in government affairs (October 2025); Cailianshe and other outlets on publicly listed appliance price ranges; public reporting on pilot-to-production ratios. Corpus and technical sections summarise public practice.

FAQ

Should we build question answering or workflow first?: Two conditions decide it: whether the knowledge is reasonably stable, and whether the process already runs on systems. Stable knowledge and structured documents favour question answering; processes with data in systems — orders, work orders, approval flows — favour workflow agents, which are easier to value. If neither holds, fix data and documents first.
Does a knowledge base need a bigger model if answers are wrong?: Usually not. Retrieval quality depends first on the corpus: whether documents are cleaned and de-duplicated, whether chunking matches the granularity of questions, whether permissions are tiered, and whether there is a refresh mechanism. Without those four, a bigger model only makes errors read more smoothly. Start with 50–100 real questions as a baseline and classify the failures.
Should the data stay on premises?: It depends on data sensitivity and concurrency, not budget. Publicly listed appliances for local inference range from a few hundred thousand to several million RMB. For internal question answering at modest concurrency, the main argument for local deployment is keeping data inside the network, not performance. Where sensitivity is ordinary, metered APIs are more flexible and easier to stop during validation.
What is still needed after go-live?: At least three things: corpus refresh (new documents, expired content, permission changes), effect measurement (classifying wrong answers to real questions), and upkeep of scope and definitions. Where public projects fall out of use in year two, it is usually because nobody owns these three. Write them into the plan with named owners rather than buying a bigger model at the start.