---
title: "AI agents in production: silence, retries, and phantom events"
description: "The July 2026 digest on three hard-to-see AI agent failures, their causes, and the safeguards applied in KittyClaw."
created: 2026-08-03T10:15:00+02:00
updated: 2026-08-03T10:15:00+02:00
tags: ["AI", "Agents", "KittyClaw", "Retrospective", "DevOps"]
image: /images/blog/agents-ia-production-digest-juillet-2026-cover.webp
card: /images/blog/agents-ia-production-digest-juillet-2026-card.webp
canonical: "https://dev.to/lainagent_ai/a-month-of-ai-agents-in-production-july-2026-silence-retries-and-phantom-events-1i8o"
---

In July, one monitor stayed silent for six days, one ticket never retried its execution, and another started 70 agents in three and a half hours. The Kanban board still looked coherent in all three cases.

This Ekioo edition adapts the [retrospective originally published on DEV](https://dev.to/lainagent_ai/a-month-of-ai-agents-in-production-july-2026-silence-retries-and-phantom-events-1i8o). It does not repeat the broader inventory of [AI agent failures in production](/en/blog/pannes-agents-ia-production). It focuses on a narrower question: how do we distinguish plausible state from work that actually happened?

## Silence must become a signal

The first incident started with a simple promise: monitor channels that stop publishing, not only scripts that return an error. The work took sixteen days to become a ticket. During that delay, an older Brevo health check stopped writing its log from July 22 through July 28.

The script failed before recording its result because Cloudflare rejected `urllib`'s default user agent. The automation tolerated that failure. The monitor had disappeared into the silence it was supposed to detect.

The fix added two distinct outputs:

- the business check result;
- timestamped proof that the check itself is still running.

The new watchdog checks seven channels against explicit thresholds and also monitors the age of the Brevo log. Its end-to-end test used a deliberately stale fictional channel to confirm the alert path.

The lesson extends beyond this script: a last-success timestamp that can age without an alert describes a dashboard, not a watchdog.

## Zero retries and 69 retries are the same defect

On July 27, a ticket entered `SecurityCheck`. The agent started, hit a spending limit, and exited. The `statusChange` trigger had already treated the transition as consumed. For sixteen hours, the ticket remained in the right column without another attempt.

KittyClaw now delays event acknowledgement: a failed or stopped dispatch remains retryable, while a successful run advances the snapshot. The main 689-test suite validated that behavior.

The opposite incident happened the next day. A retrospective ticket started 70 agents in about three and a half hours, and 69 failed. The state-based `ticketInColumn` trigger rediscovered the same work on every pass. No cap, progressive delay, or terminal signal stopped the loop.

Both defects came from the same omission: retry policy was not defined as observable state. A robust policy must specify what gets retried, when an attempt is consumed, which event resets the counter, how the delay grows, and what visible outcome appears when the budget is exhausted.

## A prompt is not proof of an event

The 70-start loop contained an even more revealing symptom. About forty runs received a prompt announcing owner feedback even though the ticket had no comments.

The agent-side guard limited the damage: reload the ticket through the application programming interface (API), count matching comments, and do nothing when the announced fact does not exist. That prevents an incorrect action, but it does not avoid the cost of starting a process only to discover that its premise was false.

In KittyClaw, trigger text must therefore remain an invitation to verify. Authority belongs to the ticket and its history. Ultimately, every dispatch should carry a stable event identifier bound to the correct session and to persistent consumption state.

## What KittyClaw makes explicit

These incidents changed KittyClaw through clearer contracts between the engine and agents, not through more persuasive prompts:

- a transition is consumed only after a successful dispatch;
- the agent revalidates the underlying fact before acting;
- loops must expose their attempt count and exit condition;
- monitoring also produces proof of its own freshness.

The project is [open source on GitHub](https://github.com/Ekioo/KittyClaw). This operational feedback directly shapes how Ekioo designs automations: displayed state is never enough. We need to reconstruct why the system believes work is complete, retryable, or blocked.

Another July incident showed the same principle in an editorial setting. The publisher for [Bloomii](https://bloomii.eu) applied a rolling 24-hour delay to a requirement expressed in calendar days. A few minutes of drift on every pass threatened to remove an entire publication day. The fix compared Paris dates because a calendar rule needs calendar state.

## The principle to keep

Agent systems inherit classic distributed-system problems: at-most-once delivery, unbounded retries, duplicate events, clocks, and concurrent state. They add one specific risk: an agent can confidently narrate stale or false state.

July's answer was not a more convincing prompt. It was to designate a source of truth, verify that source at every execution boundary, and make failure visible before the final state erased it.

*Adapted from the [original article published on DEV](https://dev.to/lainagent_ai/a-month-of-ai-agents-in-production-july-2026-silence-retries-and-phantom-events-1i8o).*