The takeaway
A completed agent response is not a completed customer interaction. Monitor the handoff to the destination, not just the process producing the answer.
121 answers. Four unfinished handoffs.
We ran a live experiment with an AI support agent connected to a real messaging service. The agent generated 121 answers. Four interactions lacked confirmed delivery. Service health checks stayed green.
Clutta identified all four affected interactions.
These were naturally occurring failures in the experiment, not deliberately injected faults. The result describes this test run, not a production-wide reliability rate or a guarantee for every workload.
That is a frustrating kind of failure. The service remains available. The agent produces an answer. But the interaction is still unfinished, and the person waiting may be the first to notice.
Two definitions of done
For the agent, finishing means generating and saving an answer. For the delivery workflow, finishing requires confirmation from the destination. Those are separate events.
- Answer saved. The generated response exists.
- Delivery attempted. A worker tries to send it.
- Delivery accepted. The destination acknowledges it.
A successful attempt is not something we can infer from a healthy process. The workflow needs evidence of the final step, connected to the same answer.
Clutta connected saved answers to their expected delivery confirmations and surfaced the four incomplete interactions as individual cases to investigate.
The useful question was specific: which answers still lack confirmed delivery?
From a missing event to an actionable case
The connection matters: which answer was saved, which delivery belongs to it, and whether the required confirmation arrived within the agreed window. An isolated error message cannot answer all three.
For a team investigating an unfinished interaction, that narrows the starting point from a service to a particular piece of work. It does not remove the need to investigate the cause.
What the evidence does, and does not, mean
In this experiment, delivery confirmation means acceptance by the messaging service. It does not establish that a person received a notification, opened the message or read the answer.
Likewise, missing confirmation does not by itself prove why a handoff failed. An ambiguous network response and an unsent message require different follow-up. The finding identifies an incomplete contract, not an assumed root cause.
Scope of this result: this is a field observation, not a controlled accuracy benchmark. We are not claiming a measured detection-time guarantee, zero false positives across other workloads, or exactly-once external delivery.
Health monitoring and agent traces remain useful. Completion monitoring asks a complementary question: did the work finish beyond the agent's final response?
Make the outcome observable
Start with one customer-facing workflow. Define its opening event, the confirmation that means it finished, the identifier joining those events and a realistic deadline. Then test healthy completion before testing a missing final step.
The public Clutta playground provides a guided place to explore completion monitoring with synthetic workloads. Follow its currently documented scenarios; the AI delivery scenario is still being prepared for public self-service use.
For teams shipping customer-facing AI agents, an answer generated is progress. Confirmed delivery is another part of the promise.
Up is not done.
Over to you
Where does “done” end in your workflow?
At the model response, the queue acknowledgement, or the destination? Tell us which handoff is hardest to verify, or question the experiment's assumptions.
Send us your perspective →This opens your email app. Your reply goes to the Clutta team, not a public comment feed.