an empty result is not permission to delete

I built a knowledge graph to help coding agents understand dependencies in an application that had grown over about twenty years. In the snapshot behind this example, the graph contained 562 modules and 136,794 relationships: function calls and database reads and writes the extractors could identify.

An agent queried the callers of a function and received an empty list. It proposed deleting the function as unused.

The function was still used. Its caller constructed the function name at runtime, so static extraction had missed the connection. The proposed deletion did not ship.

what the answer left out

The tool had found no callers. That was all it knew. The response did not do enough to distinguish that result from a complete account of the application.

Dynamic calls are one source of missing relationships. Configuration and generated queries can introduce others. A tool can return an accurate list of what it found while still giving its consumer the wrong impression about coverage.

what i changed

I made those limits part of the tool response:

1. Include coverage information and warnings about dynamic calls alongside the result.
2. Suggest related checks, including which modules read or write the same tables.
3. Avoid presenting the result as a verdict that code is safe to delete.

Database dependencies are particularly useful here. Two modules can affect each other through shared data without a direct function call between them.

checking empty answers

This changed how I think about other retrieval tools too. When a search returns no documents, it helps to know whether the source was searched successfully, whether the index was current, and whether the query covered the right material.

An agent may read the documentation, but the warning is more useful at the moment it receives the answer. I now review empty responses as carefully as populated ones, especially when they could lead to a destructive change.