A Feature in My AI Agent System Went Unused for 40 Days

I had a feature in my AI agent system that looked complete.

The design document existed. The code worked in isolation. The usage instructions were written. I had already moved it into the “done” column.

Then I checked the execution history.

The feature had not activated once in 40 days.

It was not broken. The runtime simply never chose it.

The 40-day period comes from my own development log. It is not an industry benchmark or a general claim about AI agents. But it exposed a mistake in how I defined completion.

A callable capability is not an operational capability

The feature was intended to run several tasks in parallel. I had described the situations in which it would be useful, and I could trigger it directly during a test.

That was not enough.

In the real workflow, the agent needed a route from the current task to the capability. Nothing reliably forced that decision. The feature was available, but availability did not make it part of the operating path.

This distinction matters in agent systems because there are at least three separate questions:

1. Can the capability run?
2. Will the system select it when the right conditions appear?
3. Can I detect both activation and non-activation?

My implementation answered only the first question.

The same pattern appeared elsewhere

Once I looked for zero-use capabilities, I found similar cases in other parts of the system. Some write paths ran without corresponding read paths. Some maintenance routines existed but were not scheduled correctly. Some pre-run checks were callable but absent from the normal route.

Each component was “implemented” when inspected alone. As part of the system, it was inert.

That changed my definition of done.

My new definition of done

I now treat a capability as operational only when all three conditions are true:

1. Activation: it runs in the situations it was built for.
2. Evidence: every activation leaves a trace I can inspect.
3. Missing-activation detection: the absence of an expected activation becomes visible.

This is stricter than checking whether a function can be called. It asks whether the capability participates in the real workflow and whether that participation can be audited.

Three controls around activation

I added three layers to reduce the chance of another silent capability.

1. Log every activation

The activation event must leave enough evidence to answer basic questions:

• Which capability ran?
• What condition triggered it?
• Which task or request was it serving?
• What happened next?

The goal is not to log everything. It is to make activation inspectable.

2. Monitor for missing activations

An activation log tells me what happened. It does not tell me what should have happened but did not.

For capabilities that are expected to run periodically or under known conditions, I now watch for an empty window. A zero count over the expected interval is treated as a signal to inspect routing, scheduling, or trigger conditions.

The threshold depends on the capability. The important part is that silence becomes a state the system can surface.

3. Force an explicit runtime decision

Before execution, the system must decide whether the current task requires the capability. That decision should be explicit rather than left to vague availability in a prompt or tool list.

The outcome can still be “do not use it.” What matters is that the route is considered and the result can be inspected.

Together, these layers cover three different failure modes:

• the capability runs but leaves no evidence,
• the capability never runs and nobody notices,
• the runtime never evaluates whether it should run.

One layer cannot replace the others.

A practical review checklist

When I add or audit an agent capability now, I ask:

• What exact runtime condition should select it?
• Where is that selection implemented?
• What evidence proves that it ran?
• How will I notice if the activation count stays at zero?
• Is “do not activate” also recorded as an explicit decision?
• Can I test the route through the normal workflow, not only by calling the capability directly?

This checklist does not prove that an agent system is reliable. It only closes one specific gap: confusing documented capability with operational capability.

What the 40 days changed

I used to mark a feature complete when the code worked and the documentation existed.

Now I wait for operational evidence.

A capability is not complete because it exists. It becomes operational when the system selects it in the intended situation, leaves evidence of that decision, and exposes the silence when selection never happens.

Documented capability is not operational capability.

That is the rule I took from 40 days of zero activations.

---

Ghosty.AI is the pen name I use to document where AI systems break in real work and which operating rules I change afterward.

The original failure record is also available in Japanese on note.