Error messages lie to agents. State verification tells the truth.

Our coding agent was stuck in a 47-minute debug loop yesterday. The error was clear: "Connection refused on port 3000." But instead of checking if the server was actually running, it spent nearly an hour optimizing connection pooling, adjusting timeouts, and rewriting network handlers.

The server wasn't running. A simple ps aux | grep node would have caught it in 10 seconds.

This is the verification gap that kills agent productivity. Agents read error messages like gospel, but error messages lie constantly. "Connection refused" doesn't mean your connection logic is broken — it usually means nothing is listening. "Permission denied" doesn't mean your auth is wrong — it might mean the file doesn't exist.

Here's the pattern that fixes it: teach your agent to verify the actual state before debugging the reported error.

The State-First Debug Protocol

Add this to your coding agent's instructions:

Before debugging any error:
1. Verify the expected state exists
2. Check if processes are actually running
3. Confirm files/endpoints/services are present
4. THEN debug the error message

For "Connection refused": Check if anything is listening on that port
For "File not found": Verify the path exists first
For "Permission denied": Check if the file/directory exists before fixing permissions
For "Command not found": Verify the binary is installed and in PATH

We built this into a simple verification checklist our agent runs before any debug session:

# Quick state verification
ps aux | grep [process_name]  # Is it running?
ls -la [file_path]           # Does it exist?
curl -I [endpoint]           # Is it responding?
which [command]              # Is it installed?

The results were immediate. Our 47-minute debug session became a 2-minute fix. Instead of optimizing connection logic, the agent ran ps aux | grep node, saw no process, and started the server.

Common Verification Patterns

• Database errors: Check if the database is running before debugging queries
• Import errors: Verify the module exists before fixing import paths
• Network timeouts: Check if the service is up before adjusting timeout values
• Build failures: Confirm dependencies are installed before debugging build configs

The key insight: error messages describe symptoms, not root causes. Your agent needs to diagnose the patient, not just treat the symptoms.

Pro tip: Track how often your verification catches false errors. If it's more than 30%, your error handling upstream needs work. If it's less than 10%, you might be over-verifying.

This pattern works beyond coding. Our support agent used to spend 15 minutes troubleshooting "account not found" errors before we taught it to verify the account actually exists first. Now it catches typos in 30 seconds.

State-first debugging turns agents from expensive error-chasers into efficient problem-solvers. The 2-minute verification that saves the 47-minute rabbit hole.