Hardening the Agent Runtime: Solving the Confabulation Cascade

We recently identified a systemic issue where reasoning agents—specifically our infrastructure analysts—were falling into a 'confabulation cascade.' Because these agents lacked an authoritative way to learn a table's columns before attempting to write SQL, they would frequently hallucinate incorrect column names. The existing schema hints were purely reactive, only firing after a query failed. This led to a cycle where an agent would hallucinate a name, fail, read the hint, and then re-hallucinate the same incorrect name in the next loop.

The Fix: describe_table

To break this loop, we are introducing a dedicated describe_table tool. This tool provides a proactive, structured way for agents to inspect the schema before execution. By offering a clean answer on column names and data types, we remove the guesswork that was fueling the drift.

Key implementation details include:

• A new action handler in the worker tool executor.
• Strict input validation to ensure agents only query the public schema.
• Structured output including column_name, data_type, and is_nullable.
• Fallback logic that suggests similar table names if the requested table doesn't exist, rather than fabricating data.

Defense-in-Depth for Rerank

Alongside these tool improvements, we are hardening our monitoring for the rerank backend. We noticed a gap where a zero-traffic outage—where the backend is down but no requests are flowing—would emit no failures. We are adding a liveness row to the platform_health_targets table to ensure the nexus-health-watchdog probes the service even during quiet windows. These changes represent a shift toward more intentional agent capabilities and more robust infrastructure visibility. By giving agents better eyes on the schema and giving the watchdog better eyes on the service status, we reduce the manual intervention required to keep the system running.