Repeated Tool Failure
RULE-REPEATED-TOOL-FAILURE: Flags repeated operational tool failures that indicate persistent dependency or API breakage.
At least two distinct operational failures associated with a single tool within the same execution trace.
Distinct timestamped tool_result events with status='failed' for the same operation identifier.
Implement tool fallback logic, mock handlers, or circuit breakers to gracefully divert execution when a tool fails consecutively.
Rule Specification
When an autonomous agent invokes a tool (such as an external search API, vector database, SQL connection, or file parser), transient failures can occur. However, if the same tool fails multiple times during a single session, the probability that the agent can self-heal without structural fallback logic approaches zero.
Detection Logic & Invariants
The deterministic engine maintains a map of failures grouped by operation: failures_by_tool: Dict[str, List[Event]]. As the JSONL stream is ingested:
- Every tool_result event with status == 'failed' increments the failure counter for that tool.
- If failures_by_tool[op] >= 2, the rule transitions to MATCHED state.
- The engine records the exact line indices and timestamps of all contributing events.
Evidence Requirements
To eliminate false positives, the rule requires explicit evidence:
Remediation Guide
When this rule fires, update your agent code with these concrete safeguards:
- Tool Circuit Breaker: Trip the breaker after 2 consecutive failures and return a synthetic response instructing the agent to choose an alternate strategy.
- Secondary Fallback Provider: Configure secondary API providers (e.g. switch from primary Milvus cluster to local ChromaDB).
- Input Validation: Verify that the agent is not passing malformed or invalid arguments that trigger deterministic 400 Bad Request responses.