How legacy asset management software lost ease of use — and how agentic AI brings it back
Ask a public works crew what they think of their maintenance management system and you rarely hear about missing features. You hear about clicks. The eleven screens to close a work order. The report that only one person in the department knows how to run. The custom field somebody added in 2019 that is now required and nobody remembers why. The system does everything, and every one of those things takes too long.
This is not because anyone designed it badly. It is what happens to enterprise software over twenty years of adding capability without ever being allowed to remove any.
How ease of use erodes
Every customer request that gets built adds a screen, a field, a setting, or a step. None of them are wrong individually. Collectively they turn a work order form into a wall of inputs, most of which do not apply to the task in front of you, all of which you have to scan past. Configuration follows the same path: the more a product can be tailored, the more its setup becomes a specialty, and the more the people who could tailor it become a bottleneck or a consulting line item.
The result is a familiar pattern in small and mid-size agencies. A handful of people become fluent and everyone else routes through them. Field staff avoid the system and write things down to enter later, or not at all. Reports get run quarterly because running them is a project. The software is present in the office and absent from the work.
Vendors have historically responded with training, with a redesigned skin over the same underlying screens, or with a simplified “lite” mode that removes exactly the capability you eventually need. None of those change the fundamental transaction: to get anything done, a person must know which screen, which field, and which sequence.
What “agentic” actually means, and why it is different
An agentic assistant is one that can carry out a task, not just talk about one. The distinction sounds small. In practice it inverts the relationship between the user and the software. Instead of the person learning the system’s structure, the person states an intent — in the words they would use with a colleague — and the assistant maps it onto the system’s structure on their behalf.
“Create a hydrant service work order at 720 Coltrane, assign it to Dan, high priority, due the 30th.” That sentence contains a record type, a location that needs geocoding, an employee lookup, a priority, and a date. In a traditional interface it is five screens or one long form. To an agentic assistant it is a single request that produces a valid, fully populated record — the same record the form would have produced, because it goes through the same rules.
The same holds for questions. “How many work orders are overdue and which department has the most?” is, in a legacy system, a saved report someone has to have built. Here it is answered on the spot, against live records, with a chart and a link to the rows behind it. The person asking did not need to know a report existed, let alone how to run it.
Why this restores ease of use rather than just adding a feature
The screens are still there. A supervisor who wants to walk the form can walk the form. What changes is that expertise in the software stops being a prerequisite for using it. The person who joined last month can file work and get answers on day one. The field tech who never opened the desktop app can close a work order by saying what they did. The director who used to wait for the monthly report can ask the question in the meeting.
There is a second-order effect that matters for small agencies in particular. The bottleneck people — the one person who knows the reports, the one who knows how to configure a type — stop being single points of failure. When that person retires, the knowledge did not leave with them, because the assistant carried it all along.
The tools that ship on day one
In CentricityIQ, the assistant — IQ — is available on every screen from the first sign-in, and it comes with the capabilities described here rather than a waitlist for them. It answers questions against live work orders, requests, inspections, assets, fleet, and inventory, rendering the result as a number, chart, or table you can drill into. It creates and updates records from plain English and performs bulk actions across many records at once. It builds dashboards and reports on request. It helps configure the system itself — types, checklists, notifications — and can propose a starting configuration from your existing documents and GIS layers. Every action it takes is logged, permission-bound to the person using it, and undoable.
It also knows what it does not know. If a record does not exist, it says so rather than inventing one. If a question cannot be answered from the data, it says that too. An assistant that is easy to use but occasionally confident and wrong would not be an improvement, so the grounding rules are strict: it may not assert what it did not look up.
A fair test
The way to evaluate any of this is not a feature list. It is to sit someone down who has never used the product, hand them a real task from your backlog, and time how long it takes them to finish it correctly. Then do the same with your current system. The number of screens they had to learn is the answer.
We are happy to be on the receiving end of that test. Ask for a demo at centricityiq.com and bring your own work.