The context
The same equipment manufacturer now had the data from its fleet. That left a problem telemetry does not solve: interpreting what it says.
A technician on an intervention looked for answers in PDFs, in a car park, on an unreliable connection. The documentation exists, and it is good — but it is spread across manuals, procedures and a parts catalogue, each varying by version and by equipment configuration. Finding the right page assumes you already know which one you are looking for.
In the back-office the problem was the mirror image: the fleet-management and after-sales interfaces had grown to the point where a new joiner had to learn the menu tree before being able to answer a customer.
What we did
We built an assistance layer on top of the existing platform, grounded in the technical reference material rather than in a model’s general knowledge.
- The company’s technical documents indexed with Knowledge Bases. Manuals, procedures and service notes are ingested from S3, chunked, embedded and made retrievable by the service, which then serves as the agent’s source. The vector store behind it is Amazon S3 Vectors, which avoids running and paying for a dedicated vector database at this scale. Using a managed knowledge base rather than assembling the ingestion, chunking and retrieval ourselves is the difference between a component the client can re-index by dropping a new revision in a bucket and a pipeline someone has to keep alive.
- An MCP server over the sources that stay live: the parts catalogue with its compatibility rules, equipment configurations, and the fleet telemetry. These are queried as they are rather than indexed, because a pre-computed index of stock, compatibility or machine state is a confidently wrong answer waiting to happen. One interface over sources that did not share a shape, which also avoids re-integrating each of them into the next tool that wants to read them.
- A troubleshooting agent on Amazon Bedrock, drawing on both: the indexed documentation for how the equipment is meant to work, and the history of the specific machine for how this one has actually been behaving. The distinction matters: an answer about the generic model is almost always useless, because configurations differ from one unit to the next.
- Navigation assistance in the back-office. A user states what they need in plain language and lands on the right screen with the filters already applied, instead of learning where the function lives. The menu tree stays available for those who know it: the agent is a shortcut, not a replacement.
- Generated 3D exploded views. From the assembly model matching the equipment’s configuration, the agent produces an exploded view of the sub-assembly concerned: which parts come out, in what order, and under which reference. A stock diagram would have been easier to serve, and wrong as soon as a configuration departs from the nominal case.
The outcome
The technician arrives with the part. In this trade that is the only measure that really counts: the second visit, the one that costs a full trip because the right reference was not identified in time, is becoming rare.
The support desk answers faster, and a new joiner becomes useful in days rather than weeks, because they no longer have to memorise where things are before they can help anyone.
The most useful lesson is about trust. An agent that is confidently wrong costs more than an agent that declines to answer: it sends someone to site with the wrong part. So every answer cites the document and section it came from, and the agent says explicitly when the reference material does not support a conclusion. Knowledge Bases returns the passages it actually retrieved, which is what makes that citation worth something: it is a fact of the retrieval rather than something the model was asked to supply, and a model asked to cite its sources will invent one. That is not a legal precaution, it is what keeps a technician using the thing after its first mistake.