Agent Loops & Deterministic State Machines
Naive while-loop agent implementations hallucinate function arguments, enter cyclic tool-calling spirals, and silently burn thousands of tokens without completing tasks. This article models agent execution as a Finite State Machine (FSM) with explicit transition guards, maximum step budgets, and structured error recovery for the Workspace autonomous research agent.
Full-Stack AI Architecture: From Streaming Foundations to Resilient Agentic Systems in Node.js & React
Agent Loops & Deterministic State Machines
A while (true) loop with tool calling looks like an agent. In a demo, it works. In production, it burns $400 in API tokens cycling through the same failed tool call, hangs indefinitely on network timeouts, or hallucinates circular chains of function arguments that reference each other's phantom outputs. The loop has no exit conditions beyond max_tokens, no structured error recovery, and no audit trail.
This article replaces the naive loop with a Finite State Machine (FSM) agent runtime: explicit states with guarded transitions, a step budget that terminates runaway loops, and structured tool error recovery that feeds error context back to the model rather than crashing the process.
Who this is for: Engineers who have built LLM agents with ReAct loops and hit runaway costs, infinite loops, or agents that silently fail to complete tasks. FSM modeling eliminates these failure modes structurally.
1. The FSM Model for Agent Execution
1.1 States and Transitions
Each arrow in the diagram corresponds to a guarded transition function in code. There is no escape hatch — the agent cannot be in an undefined state.
In this synchronous implementation, AWAITING_RESULT is a transient state — set and resolved
within the same callTool() call before the event loop yields. Part 17 shows how Inngest durable
steps make this genuinely async: the runtime serialises the full FSM context at AWAITING_RESULT
and resumes it only after a human approval event — surviving server restarts in between.
2. TypeScript FSM Agent Implementation
3. Tool Error Recovery
3.1 Structured Error Context
Tool failures must not crash the agent — they must be fed back as structured context so the model can adapt its plan.
Summary
| Pattern | Problem Eliminated |
|---|---|
| FSM states | Undefined/impossible agent states that cause unpredictable behaviour |
| Step budget | Runaway loops consuming thousands of tokens without task completion |
| Structured errors | Uncaught tool exceptions crashing the agent process |
| Planning phase | Hallucinated tool arguments from reactive immediate tool calls |
What's Next
Part 16 replaces proprietary function-calling with the open Model Context Protocol (MCP). We implement a custom MCP server using TypeScript SDK v2, expose enterprise tools via Streamable HTTP transport, and secure the server with OAuth 2.1 bearer token validation.
This article was developed with AI-assisted deep search, specification cross-referencing, and technical research synthesis.