Monitoring an AI operation involves discovering the causes of failures, choosing changes, and checking their effects on real work. See how to organize this routine between operations and engineering, using a service handoff to a person as an example.
The operation serves customers, the integration responds, and the dashboard shows closed conversations. Even so, the team reports that people need to explain everything again when they reach human service. The problem appears in the routine, but it has not yet been framed in a way that allows it to be corrected. That gap between perception and change is what we address here.
Choose a unit of work that has consequences
In this fictional example, a company uses AI to receive maintenance requests. The agent identifies the equipment, gathers information, and refers specific situations to a representative. Responsibility for the service remains with the company's team. The purpose of the handoff is to allow the representative to take over with enough context to continue handling the request.
Counting messages or closed conversations does not answer whether this happened. To investigate, we will follow a request from intake to the first useful action by the person who took over. This scope includes the conversation, the queue record, the data that reached the representative, and what they needed to ask again.
The scope also establishes a boundary. We are not evaluating the entire maintenance service or attributing results to the agent that depend on inventory, travel, or field execution. We can observe these dependencies without confusing responsibilities.
Turn the complaint into hypotheses that can be tested
“The agent hands off without context” is a good signal to start with, but it still allows for different causes. Perhaps it did not collect the equipment information. Perhaps it collected it and the integration discarded the field. Perhaps everything arrived, but the screen does not show the information where the representative works.
Select examples with the people who received the handoffs. Include problematic situations and situations the team considers good, preserving the context needed for comparison. The intention is to understand the mechanism of the failure; a sample selected for investigation should not be presented as a statistical picture of the entire operation.
| Hypothesis | Evidence to look for | Possible change |
|---|---|---|
| The information was not collected | Original request and questions asked before the handoff. | Review collection and the handling of incomplete responses. |
| The information was lost in the integration | Prepared content and record received in the queue. | Correct the mapping and monitor delivery failures. |
| The information arrived but was not useful | Representative's screen and context used to decide. | Reorganize the presentation with the team taking over. |
A change to the agent's instruction text may help with the first hypothesis. For the other two, it would leave the cause intact. Record the explanation as a hypothesis until you can check it against the records and observed behavior.
Take the investigation across product boundaries
Suppose the agent collected the equipment information and summarized the problem correctly. The integration sent the summary in a notes field, but the representative only sees that field when opening a secondary tab. The main queue only shows “request received”. The experience makes the representative repeat questions even when the information exists.
We now have a concrete change to discuss: presenting the equipment, reported problem, and reason for the handoff where the person takes over the task. The operations team helps choose the order. Engineering checks where the fields come from, whether they can arrive empty, and how to distinguish information provided by the customer from the agent's interpretation.
Bringing process and implementation together is the role we assign to FDE work: investigating alongside the people who operate the process, turning the need into a change, and monitoring its adoption. The team composition and scope of this work are defined in each project; the term does not replace explicit owners and deliverables.
Make changes with an acceptance criterion and a path back
Before changing the screen, write down how to recognize a good handoff. In this example: the representative finds the reported equipment, understands the request, sees the reason for the transfer, and knows what still needs confirmation. If information is missing, that absence should be clearly visible.
Prepare situations that challenge the change: unidentified equipment, contradictory responses, unavailable integration, a request referred twice, and abandonment before completion. Use these examples to evaluate the complete path, including what the person taking over can do.
The first release may be limited to a queue or group that agrees to monitor the change. Agree on who observes, where to record problems, and under what circumstances to return to the previous version. Choosing a smaller scope reduces the volume of simultaneous situations to investigate, although it requires care before generalizing what was learned.
- Hypothesis
The context is difficult to find.
- Change
Useful fields appear in the intake queue.
- Check
The team can continue without repeating data collection.
- Decision
Keep, adjust, revert, or expand the scope.
Compare effects without hiding what changed along the way
After the release, observe complete requests again. Check whether the context arrived, whether the representative used it, and whether repeated questions had another justification. Confirming a piece of information before a decision can be part of the process; it is not automatically repeated work.
If the team wants to track a measure, define what is included in the count. “Handoff with usable context”, for example, needs shared criteria among those classifying the cases. Also record the period, queue, version, and relevant changes, such as training new representatives or a change in the type of request.
If the expected effect does not appear, the investigation continues. The screen may have improved while the main problem lies in the quality of collection. A change may resolve one stage and increase effort at another. The decision to keep or expand it needs to consider the path as well as the point that was modified.
Organize a routine that produces decisions
One possible routine separates three moments. In daily monitoring, the team addresses failures and pending situations. In a periodic review, operations and engineering choose patterns that deserve investigation. In the scope review, they assess which improvements justify expanding integrations, changing the process, or starting another area of work.
Each improvement needs a described problem, a hypothesis, an owner, a proposed change, and a way to check the effect. The record can be simple. Its usefulness lies in allowing another person to understand why the decision was made and what remains to be learned.
Interaction analysis and questions posed to the data can support this routine. They gain value when the finding reaches someone who can act and when the change comes back for evaluation. Without this connection, the dashboard adds information, but the operation continues working in the same way.
Questions to discuss with your team
- What part of the work does the team need to repeat, and in which situation?
- Which hypothesis explains the problem, and what evidence could contradict it?
- Who participates in the correction besides the person who configures the agent?
- What needs to happen to keep, revert, or expand the change?
When the Applied AI operation goes into production, the opportunity to learn from usage emerges. A routine of continued development turns that learning into verifiable changes, with participation from those who build and those who face the consequences every day.
References for further reading
- NIST AI RMF Playbook · Measure 1.1 and 1.2 ↗
Provides guidance on choosing measures appropriate to the context, documenting what was not measured and reviewing the assessment when conditions change. It is an evaluation reference; the examples and criteria in this material are proposed ways of working.