I built a recommender for support tickets. Its job was pretty simple: look at the ticket and the work queue, then suggest what should happen next and why.
That part is useful. It can save somebody from staring at twenty things that all look urgent. But a recommender that only talks is still like a guy standing beside the tool crib saying, “You oughta grab that wrench.” Helpful, maybe. Not exactly getting work done.
The brain was not the hard part
The technician can look at a suggested next move, accept it, or say it is wrong and leave a reason. That correction matters. It gives the system a trail of what people actually did, not just a pile of AI guesses.
I did not want it silently taking responsibility for a person's work. The human still owns the ticket. The system is there to help with the first pass and handle repeatable little chores when the rules are clear.
A ticket can mean two pretty different things. An incident is something broken. A service request is somebody needing something. Mixing those together makes routing and reporting worse, so even that simple distinction needs to survive the handoff.
Then it needed hands
The old problem was not that the recommender could not make a good suggestion. The problem was that some of the obvious ticket actions were not available through a clean, dependable connection. A person could do them in the browser. Software could not do them without trying to click around a screen like a very fast intern.
That visual approach can be a last-resort bridge for old software. It is also fragile as hell. Move a button, change a screen, time out a page, and now your little robot is clicking on the wrong thing.
A modern service-management API changes the picture. An API is just a supported way for one system to ask another system to do a specific job. If the right controls are available, the helper can make a narrow change: route a ticket, update a status, add a label, leave a comment, or start an approval step.
Not everything should be automatic. That is the whole damn point.
The boundary is the product
The setup I am after has confidence bands. A high-confidence, low-risk move can be prepared for action. A medium-confidence one gets shown to a person. A low-confidence one stays in the queue for dispatch instead of making up an answer.
- Narrow permissions. The helper gets only the specific actions it needs. It does not get a master key to the whole service desk.
- Human ownership. Sensitive calls, exceptions, and anything that changes accountability stay with a person.
- A receipt for every action. What changed, why it changed, who or what asked for it, and whether it can be undone all need a record.
- A way back out. If a rule is wrong, stop it, reverse the safe part, and learn from the correction. Do not just hope it behaves better next time.
That is less exciting than saying “AI runs the help desk now.” It is also a hell of a lot more useful.
What I am not claiming
This is a sanitized build note, not a claim that an unattended agent is already running somebody's support department. I am leaving out company names, ticket data, access rules, confidence thresholds, and all the other parts that do not belong on the public internet.
The useful lesson is still public: a good AI idea is not finished when it can explain itself. It needs a small, reliable path into the real workflow, and somebody needs to be able to see what it did after the fact.
That is the part I keep coming back to with AI projects. Give the thing a job. Give it boundaries. Keep the person who owns the outcome in the loop. Then make sure it leaves receipts.
Earlier notes: why I did not need another chatbot, why the dashboard is for the human, and what it took to finish the plumbing on another agent system.