HomeLLMAgentConsortium ChainDigital humanWebsite buildAPPIntellectual PropertyCase studiesArticlesTech stack在线演示 Technical consulting

Home / Case studies / Equipment maintenance agent

In-House Product / Agent

Equipment Operations Agent

Capture the vendor's fault expertise in a knowledge base so on-site staff can run a first check themselves.

Background

Venues and training centres have many kinds of equipment — a single venue may hold dozens of categories.

When equipment fails, on-site staff first call the vendor, who then dispatches an engineer. The process takes from one to several days, during which the equipment is out of service, disrupting training and visits.

In reality most faults are common issues that an experienced person can pinpoint in a few sentences. The problem is that the experience sits with very few people.

Solution

In-house fault diagnosis agent: historical faults are organised into a knowledge base; on-site staff describe the symptom and the agent gives likely causes and recommended actions.

The knowledge base is organized by equipment type and fault symptom, covering common faults and handling steps.

Integrated with WeCom so on-site staff can ask questions from a phone without opening a computer.

We provide both PC and mobile clients, covering duty shifts, inspections and field work.

Technical composition

The table below lists this project's technical elements so clients can verify them independently.

Tech stack

Knowledge Base402 real fault records
Asset Ledger66 devices · 55 types
IntegrationWeCom / PC / mobile
CapabilitiesSymptom description → cause identification → recommended action
ExtensionThe knowledge base keeps accumulating and gets more accurate with use

Outcomes

  • Common faults can be diagnosed on site without help, reducing dependence on the vendor.
  • The diagnostic process and recommendations are traceable, which supports review and knowledge capture.
  • Three access channels: duty desk, inspection and field work are all covered.
  • The knowledge base keeps accumulating, so new staff gain access to veteran experience.

Capabilities Used

Discuss a similar scenario

01 / Constraints

The constraints the project was built under

Project stories without constraints are fiction. This section sets out four constraints: time, site, staffing and compliance.

These constraints directly shape the solution; every problem under 'Key challenges' below is forced out by one of them.

Four kinds of constraint

KnowledgeFault know-how was scattered across the heads of veteran engineers and a few handwritten logs, never systematised.
UserOn-site operators are not engineers: they do not follow the technical jargon and cannot describe the fault clearly.
EnvironmentWorkshops are loud and poorly lit; typing on a phone is not realistic.
ResponsibilityIf an agent's advice leads to a wrong action, how is liability allocated?
02 / Key challenges

Where It Actually Gets Stuck

It is not “we worked hard”; it is “what the problem looked like, how we solved it, and what it cost”.

Turning veteran know-how into a knowledge base

We wanted to interview veteran engineers and document it, but they cannot explain it — 'you can tell by the sound' does not translate into checklist entries.
How we solved it: switched to 'case capture' — instead of asking 'how do you judge it', we asked 'last time that machine failed, how did you notice, what did you look at, what did you touch, what turned out to be the cause'. One record per case; after four hundred-plus records the patterns surfaced on their own.

Operators cannot describe faults clearly

An operator says 'the machine sounds wrong', and the agent cannot tell whether it is a bearing, a belt or the motor.
How we solved it: changed input from free-text description to 'options + sound samples' — pick the equipment type, then the symptom (abnormal noise / overheating / vibration / oil leak), with some symptoms offering recordings to compare against. No specialist knowledge needed to enter a report.

How is liability allocated when advice leads to a wrong action?

If the agent says check the belt first and the operator takes the belt off, stopping production — who is liable?
How we solved it: repositioned the agent from 'giving advice' to 'giving a diagnostic order' — it outputs 'check A first, if A is normal check B', and every step says what to stop at and hand over to an engineer. The scope of action is written into each recommendation, and it makes no judgement beyond it.
03 / Reusable elements

What other projects can borrow directly

This section is for peers. If you are doing something similar, these points will save you a few detours.

Replace experience interviews with case collection

Tacit experience cannot be stated outright, but people can recall specific incidents. Collecting by case is far more effective than interviewing for knowledge.

Input has to fit on-site conditions

In workshops, underground or outdoors, text input is usually the worst option.

Give a troubleshooting order, not a conclusion

For safety-related agents, the output should be a procedure, not a judgement.

04 / Retrospective

If we did it again

Talking only about successes is unconvincing. This section covers what we got wrong or did too late.

Doing it again, we would spend more time validating the knowledge base. A fair share of the 400-plus cases are wrong or outdated, and feeding them into the model unvalidated amplifies the errors.

We added voice input too late. Typing on a workshop floor is not realistic: voice is a hard requirement, yet the first version only offered text input, and feedback from the floor was poor.

We underestimated how much veteran workers would distrust the system. Experienced staff resisted at first; acceptance came gradually once they were involved in reviewing the knowledge base.

← All case studies Back to home