The Job Ends on the Device
A ticket is a record of a request. The work of resolving it happens somewhere the record cannot see. What a real re-test looks like, and why it decides whether automation earns trust.
Marius Mihalec, Founder, GenticFlow
A ticket is a record of a request. Someone could not print, or could not reach the VPN, or Outlook closed on launch three times before nine. The ticket holds who asked, when, and what they said. It does not hold the machine.
That distinction sounds small. It is the whole shape of the job.
Seema Amble at Andreessen Horowitz put it well in a recent essay on where AI agents are landing in enterprise software: the job is bigger than the record. Complete work spans systems and places that no single record covers. In IT support, the place the record does not cover is the endpoint, and the endpoint is where the ticket actually gets resolved.
The job is bigger than the record.
The same essay ranks agents by how much they decide: Retrieval reads, Process does, Policy decides within rules the organization already wrote, Principal decides what to do. It is a useful ladder, and it measures one thing, authority. It says nothing about where the agent is standing when it acts.
That is the gap in IT support. Work done inside the record, at any rung of the ladder, cannot observe the endpoint. Is the spooler running? How many jobs are queued? Did the restart take? The ticket does not know, and nothing that lives in the ticket has a way to check.
For most of the routine queue, that boundary is the entire job. Printer offline, VPN will not connect, Outlook crashing, disk full, a service that needs restarting. The fix is on the device. The proof is on the device. Planning the work and routing it produces a better ticket. The issue is still open.
So beneath the authority ladder there is an execution boundary, and it has two sides. On one side, collecting live evidence from the endpoint and running the approved fix there. On the other, reading the device again before the ticket can close. Neither is a new level of autonomy. They are what Process and Policy require in order to mean anything on a support ticket.
A completed action is not a completed ticket. Verification is the difference.
Verification is the step most people skip when they draw these diagrams, and it is the one that decides whether a team can trust routine automation. A restart that ran is an event. A restart that ran, followed by a second read showing the service up and the queue drained, is a resolution. If the second read fails, the ticket stays open for a technician, with the commands, the outputs, and the failed check written to it. That rule is what lets a team hand routine work to a system without manually checking every run.
What counts as a real re-test matters, because a second read is not automatically proof. The check has to target the original failure condition, not the action. For the printer, that means the spooler is running and the queue is empty, not merely that the restart command returned zero. For a VPN ticket it means the gateway resolves and the tunnel is up. Some failures are only observable by the user, an application that looks wrong on screen, for instance, and for those the honest outcome is a fix with a request for confirmation, not a closed ticket.
It also changes what you measure. Close rate rewards the fastest path to a closed status, which is how teams end up with automation they quietly stop trusting. Verified resolution rewards the outcome the user wanted, and it counts an escalation that arrives worked as a win, because it is one.
The essay separately describes what it takes to become the best at doing a job rather than holding the record of it. Reading it as a support engineer, four things stand out, and here is what each looks like when the job is a ticket.
Repeated work. A short list of ticket classes accounts for a large share of the routine queue, and each one looks like the last in the ways that matter and differs in the ways that need evidence.
Learning loop. When a technician rates an investigation down, that investigation stops being reused as evidence for similar cases. Playbook changes still go through review, which is the right place for them.
Performance standard. Verified resolution, not close rate. A ticket counts when the device confirms the fix or the escalation arrives worked.
Curriculum. The playbook catalogue. Each playbook is a written, approved resolution path with a risk tier on every action. The system does not improvise its way to a fix.
One more thing, because it is easy to hear all of this as an argument for a smarter model. In IT support, being good at the job is mostly about being trusted to touch the machine, and that trust comes from structure. Actions that are blocked cannot be approved by anyone. Actions that need sign-off wait for someone with the permission to give it, with the investigation attached. Every command and its result is recorded against the ticket. We chose Policy as the ceiling on purpose. The objective, the allow-list, and the hard case stay with the technician.
Your ticketing system is the system of record. The system of action sits on the device.
Practically, for anyone evaluating support automation, one question does most of the sorting. After the agent acts, what re-tests the original failure condition? If the answer is that the user replies, you have a better ticket. If the answer is a second read on the machine against the thing that was broken, you have a resolution.
Keep the ticketing platform. It owns the record. The job continues past the record, onto the device, and back into the record with proof. That is where we build. The how it works page shows the loop stage by stage, and the interactive demo runs it on a real ticket.