Agent Introspection Debugging

Use this skill when an agent run is failing repeatedly, consuming tokens without progress, looping on the same tools, or drifting away from the intended task.

This is a workflow skill, not a hidden runtime. It teaches the agent to debug itself systematically before escalating to a human.

When to Activate

• Maximum tool call / loop-limit failures
• Repeated retries with no forward progress
• Context growth or prompt drift that starts degrading output quality
• File-system or environment state mismatch between expectation and reality
• Tool failures that are likely recoverable with diagnosis and a smaller corrective action

Scope Boundaries

Activate this skill for:

• capturing failure state before retrying blindly
• diagnosing common agent-specific failure patterns
• applying contained recovery actions
• producing a structured human-readable debug report

Do not use this skill as the primary source for:

• feature verification after code changes; use verification-loop
• framework-specific debugging when a narrower ECC skill already exists
• runtime promises the current harness cannot enforce automatically

Four-Phase Loop

Phase 1: Failure Capture

Before trying to recover, record the failure precisely.

Capture:

• error type, message, and stack trace when available
• last meaningful tool call sequence
• what the agent was trying to do
• current context pressure: repeated prompts, oversized pasted logs, duplicated plans, or runaway notes
• current environment assumptions: cwd, branch, relevant service state, expected files

Minimum capture template:

## Failure Capture
- Session / task:
- Goal in progress:
- Error:
- Last successful step:
- Last failed tool / command:
- Repeated pattern seen:
- Environment assumptions to verify:

Phase 2: Root-Cause Diagnosis

Match the failure to a known pattern before changing anything.

Diagnosis questions:

• is this a logic failure, state failure, environment failure, or policy failure?
• did the agent lose the real objective and start optimizing the wrong subtask?
• is the failure deterministic or transient?
• what is the smallest reversible action that would validate the diagnosis?

Phase 3: Contained Recovery

Recover with the smallest action that changes the diagnosis surface.

Safe recovery actions:

• stop repeated retries and restate the hypothesis
• trim low-signal context and keep only the active goal, blockers, and evidence
• re-check the actual filesystem / branch / process state
• narrow the task to one failing command, one file, or one test
• switch from speculative reasoning to direct observation
• escalate to a human when the failure is high-risk or externally blocked

Do not claim unsupported auto-healing actions like “reset agent state” or “update harness config” unless you are actually doing them through real tools in the current environment.

Contained recovery checklist:

## Recovery Action
- Diagnosis chosen:
- Smallest action taken:
- Why this is safe:
- What evidence would prove the fix worked:

Phase 4: Introspection Report

…