An AI Chat for a Grown Business Application: What We Learned Building It
The starting point
An equipment database, in production for years, with thousands of entries: measuring instruments, workstations, tools, each with location, availability, calibration status and technical attributes. The data is there, maintained and complete.
And still, the most common question in daily work was: “Could you check whether we have something like this?”
That is not a data problem. It is an access problem. Anyone who wants to find something has to know the right search mask, know which field holds the attribute they are after, and then assemble the results themselves. The five people who use the system daily can do that. Everyone else asks those five people.
This is exactly where an AI chat comes in – and exactly where the interesting decisions begin.
What the dialogue looks like
Before the decisions, here is the concrete flow. The devices are invented, the pattern is real.
User: Compare the available oscilloscopes by location and calibration status.
Assistant: Found three available oscilloscopes:
| Device | Location | Calibration | Status |
|---|---|---|---|
| Model TX-2040 | Building C, Lab 3 | valid until 04/2027 | available |
| Model TX-1180 | Building A, Test Room | valid until 11/2026 | available |
| Model RS-880 | Building C, Lab 1 | overdue since 06/2026 | blocked |
The RS-880 is blocked due to overdue calibration and cannot be selected for loan.
Nobody asked for a table – the assistant chooses it because the question calls for a comparison. And the blocked entry is not quietly omitted, but shown with its reason.
The second step is the more interesting one:
User: Move the TX-1180 to Building C, Lab 3.
Assistant: Proposed change – please review and confirm:
| Model TX-1180 · Location | |
|---|---|
| before | Building A, Test Room |
| after | Building C, Lab 3 |
Permission checked: inventory maintenance Building C
[ Confirm change ] [ Discard ]
This is where the essential thing happens: nothing is saved. The assistant puts forward a proposal, shows the permission it checked, and waits. Why it has to work this way is the second of the three decisions.
Decision 1: MCP instead of direct database access
The obvious route would have been to give the language model access to the database: hand it the schema, let it generate SQL, execute. That works beautifully in demos and does not hold up in enterprise use.
A model allowed to write SQL can read everything in the database. Including the columns that are nobody’s business. Including the joins you never want to see in a report. You can contain this with views and restricted rights, but that only shifts the question: what permissions does the chat actually have?
We chose the route via the Model Context Protocol (MCP). The model receives no database access, but a manageable set of clearly defined tools: a search function with defined parameters, a comparison function, a modification function. Every tool has a signature, a permission check and a fixed notion of what it returns.
The difference is fundamental. With the SQL approach you ask: what must the model not do? With the tool approach you ask: what may it do? The second question can be answered, verified and, if it comes to it, explained to an auditor.
A welcome side effect: personal and contact data never leave the system in the first place. They are not part of any tool’s return value, so the model never sees them – no matter how cleverly someone phrases a question.
Decision 2: approval instead of autonomy
Reading is one half. It gets interesting when writing: “Change the location of this device.”
There are systems that simply do it. We decided against that, not out of caution, but because it changes how the thing is used. An assistant that writes unnoticed either goes unused or becomes feared. Both are bad.
The sequence is therefore always the same:
- The assistant formulates the change as a proposal with a concrete before-and-after comparison
- It shows which permission it checked
- The user confirms or discards
- Immediately before saving, user, permission and source data are checked again
Point 4 is the one that is easily forgotten. Time passes between proposal and confirmation – sometimes seconds, sometimes a coffee break. In that window the record may have changed, or the user’s permission. Checking only at proposal time builds in a gap that rarely shows up in daily work and immediately shows up in an audit.
Decision 3: the existing rights system applies
The chat gets no identity of its own and no special privileges. It always acts on behalf of the logged-in user, with exactly their permissions.
That sounds obvious and is not. The temptation is strong to give the assistant a technical user with broad rights – it makes implementation simpler and debugging more pleasant. The price is that every answer potentially contains data the person asking should never have seen. And that your audit log becomes worthless, because everything runs under the same technical user.
Context awareness: the underestimated difficulty
The part that took the most work to build is also the part you notice least while using it: the chat has to know where in the application the user currently is.
“Change the location of this device” is only answerable if it is clear what “this” means. If the user is in a detail view, it is that one device. If they are in a result list, “the displayed devices” is the currently filtered set – not the entire inventory.
Without that context the user has to spell out full identifiers every time, and the chat feels like a worse search mask. With it, the chat feels like a colleague looking over your shoulder.
Documents: the unexpected winner
Originally planned as a side feature, document processing turned out to be the part that saves the most time.
Creating a new device used to mean: open the datasheet, look up the technical values, transfer them into the form, pick a classification. Twenty minutes for one device, more for unfamiliar manufacturers.
Now you drop the PDF into the chat. A specialised document AI extracts values, classifications and parameters, and from those a structured proposal for the record is created. The user reviews and confirms – the same approval pattern as any other change.
What is notable is that the benefit here does not come from language ability, but from the ability to turn unstructured information into structure. That is the work people used to do because machines could not.
Where the limits are
In fairness, three things such an assistant does not do:
It does not replace reporting. For recurring reports with fixed metrics, a report is better: reproducible, formatted, schedulable. The chat is strong at the one-off, unanticipated question.
It is only as good as your data quality. If a location is maintained in three different spellings, even a language model will not reliably find everything. AI does not make bad data good – it makes it more visible.
It needs clear tool boundaries. Every function you hand the model has to be thought through. A tool cut too coarsely produces answers that look plausible and are wrong. The effort is not in connecting the model, but in shaping the tools.
What transfers
The pattern is not tied to equipment data. It fits anywhere structured data sits in a grown business application and is regularly queried, compared and maintained: test and calibration data, contract and supplier data, spare part and material master data, plant and maintenance data.
What matters is not the domain but the starting position: there is an application that works and is maintained, but whose knowledge is accessible to only a few. That application does not need replacing. It needs a language interface – with the same permissions, the same approvals and the same audit logging as before.
If that sounds like your situation: we will look at your data structure and tell you honestly whether the pattern holds.