Resilient AI State Machines: Designing Watchdog Reconcilers
Published on June 10, 2026 by remii team
When an AI agent runs a complex multi-step workflow in the background—such as monitoring customer emails, parsing PDF attachments, updating database rows, and posting Slack notifications—it relies on numerous external systems and third-party APIs.
In a traditional script, if any of these external APIs experience rate limits, network timeouts, or unexpected 500 errors, the script crashes, the process exits, and the work is lost. For an AI employee to be viable, it must be exceptionally fault-tolerant. At remii, we achieve this reliability by running all background agent workflows on top of a resilient state machine architecture managed by active **watchdog reconcilers**.
### The Fragility of Inline Execution
Many initial AI prototypes use a simple inline loop: 1. Prompt the LLM. 2. LLM requests a tool call. 3. Execute the tool call (e.g., fetch a URL). 4. Send the result back to the LLM.
If step 3 fails because the target URL times out, the function throws an exception. Unless the developer has meticulously wrapped every single tool call in robust try-catch-retry blocks, the entire execution halts. Furthermore, if the server hosting the agent restarts during a deployment, all active in-memory runs are destroyed.
### Durable Execution via State Machines
To prevent these failures, remii breaks workflows down into structured state transitions stored in a durable database. Each step (e.g., 'Planning', 'Tool Execution', 'Awaiting User Input', 'Completed') is logged in a PostgreSQL state database before it is executed.
- **Idempotent Actions**: Because the state is saved, if a step fails, the system knows exactly where the loop stopped. When the system recovers, it resumes from the last known state without duplicating previous actions. - **Workflow Pausing**: This architecture natively supports long-running workflows. If an agent needs to wait for user approval to send an email, it transitions to a `WAITING_APPROVAL` state and suspends the process, freeing up server resources.
### Designing the Watchdog Reconciler
While the state machine ensures data durability, we still need a mechanism to actively monitor and recover stalled processes. This is where the Watchdog Reconciler comes in.
The Watchdog is a background daemon that runs independently of the main agent execution nodes. Its sole responsibility is to audit the state database and ensure forward progress.
#### 1. State Auditing Every 30 seconds, the watchdog queries the database for active runs: `SELECT * FROM agent_runs WHERE status = 'PROCESSING' AND last_updated < NOW() - INTERVAL '5 minutes'`
If a run has been in the `PROCESSING` state for over 5 minutes without emitting any logs or updating its timestamp, the watchdog assumes the process has hung (e.g., due to a zombie container or an infinite loop).
#### 2. Process Termination and Cleanup The watchdog identifies the specific worker node and process ID responsible for the stalled run. It issues a forceful termination signal (SIGKILL) to terminate the frozen execution, preventing resource leaks. It then cleans up any dangling ephemeral sandboxes.
#### 3. Reconciler Recovery Loop Once the stalled process is cleared, the reconciler initiates recovery: - **Analyze Latency**: It checks if the failure was due to an external service rate limit (HTTP 429). - **Exponential Backoff**: If rate-limited, it applies an exponential backoff delay (e.g., 2s, 4s, 8s, 16s) before requeuing the task. - **Task Requeue**: The run is transitioned from `STALLED` back to `QUEUED`, allowing a healthy worker node to pick it up and resume from the exact step where it failed.
### Handling LLM Hallucinations
Third-party APIs are not the only point of failure; the LLM itself can fail by hallucinating invalid tool arguments. If an agent tries to call a database query tool but passes a malformed JSON string, the tool will throw an error.
Our state machine architecture catches these validation errors and feeds the error message directly back to the LLM as a new state transition. The LLM sees: *"Error: Invalid JSON format. Expected key 'table_name'."* This allows the agent to self-correct and try the tool call again, dramatically improving workflow success rates.
### Conclusion
By decoupling execution logic from state storage and employing active watchdog reconcilers, remii ensures that AI agents can survive network latency, API outages, server deployments, and their own hallucinations. This fault-tolerant architecture transforms brittle scripts into robust, enterprise-grade digital employees capable of handling mission-critical business automation.