Self-improving enterprise software: use writes the next version
Operating well does not end at keeping the software healthy. We lay in telemetry that signals whether the software is being used the way it was intended — and when it is not, the gap becomes a proposed enhancement: ranked, argued on the steering call, and built by the same factory that shipped the system.
What the signals sound like
- Started, and abandoned at step four.
- Exported to a spreadsheet, finished elsewhere.
- Approved in email, pasted back in.
Why software should not wait for a change request
Most enterprise software improves by complaint. Somebody escalates, a ticket is raised, a committee ranks it against whatever else was shouted that quarter, and the software lurches forward once a year. The people who quietly route around a broken screen never file anything — so the loudest voice writes the backlog, and the biggest gaps stay invisible.
The alternative is to let use write the backlog. The software watches how it is actually worked — not to grade the people using it, but to grade itself — and proposes its own next version. That is what we mean by self-improving: not software that changes itself unsupervised, but software whose evidence for the next change is always current, always concrete, and never dependent on who complained.
Four signals, and what each one means
Uptime cannot say any of this. These are the kinds of events we instrument — each one a hypothesis about intent, written into the software at build time:
01 · The abandoned path
An intake is started and dropped at the same step, again and again. The form is asking for something people do not have at hand — the enhancement is to move or defer that field, not to retrain the users.
02 · The spreadsheet export
A report is opened, exported, and finished elsewhere. The system's view is missing the column that matters; the export button is where it is being told so.
03 · The out-of-band approval
An approval happens in email and the result is pasted back in. The process model and reality have diverged, and every metric downstream of that step is quietly wrong.
04 · The silent module
One team uses a feature daily; a second team never opens it. The split says whether it is a fit gap or a training gap — and those have very different fixes.
Hard problem one: deciding what telemetry to lay in
Choosing the signals is design work, and it happens at build time, not after go-live. Every workflow ships with the few events that reveal whether its purpose is being met — started and finished, the step where it stalls, the exit into another tool. Telemetry is an acceptance criterion of the build, which is why day one of operating starts with eyes open.
The discipline is restraint. Too little telemetry and the operate stage is guessing; too much and the signal drowns in a swamp of events nobody reads. The test for every event is the same: could this change what we build next? If it cannot, it is not laid in.
Hard problem two: turning readings into a ranked backlog
Signals do not rank themselves. A reading has to become a hypothesis — why the path is abandoned, why the export happens — and the hypothesis has to become a proposal with a size on it: the expected movement in the business number the engagement is priced on. Ranked that way, the list is honest. The enhancement that would settle claims a day sooner outranks the one requested most often.
That ranked list is the same one the weekly reports carry, and it is where the loop closes: the top rows are the next turn's brief.
Where AI works, and where a person decides
AI agents work both stages of this. On the telemetry side, they watch the event streams for pattern breaks a weekly dashboard would smooth over — the abandonment that started last Tuesday, the export volume that doubled after a release. On the interpretation side, they draft the reading, assemble the evidence behind it, and propose the enhancement candidates with a first estimate of expected movement.
What the agents do not do is decide. People judge the drafted list on the steering call — the same discipline as the factory's gates: the system prepares every decision, and a person makes it. Accepted rows enter the factory as tasks and run the same two stages as everything else: co-planned, implemented, validated, signed. The system that built the software keeps improving it — that is the promise the word self-improving is standing on.
Software that improves itself still needs someone to decide what better means.
We read the signals with you, on a standing call.