Factors 5-8: Manage State and Control Flow

In the previous lesson, we established control over the LLM interface through Factors 1-4. You learned to produce structured outputs, treat prompts as versioned code, actively engineer your context window, and handle tool calls as structured data. These four factors gave us predictable inputs and outputs — we know what the LLM sees and what it produces.

However, production AI agents face challenges beyond a single request-response cycle. Real-world agents need to handle long-running tasks that span multiple steps, recover from failures without losing progress, wait for external events like human approvals, and maintain transparency about what they're doing. In this lesson, we'll cover Factors 5-8, which address these challenges by establishing principles for state management and control flow. These factors ensure your agent systems remain transparent, controllable, and resilient as they handle real-world complexity.

The fifth factor addresses a critical problem that emerges as agent systems grow more complex: as much as practical, maintain a single source of truth by unifying the agent's execution state with your application's business-relevant workflow state.

When you first build an agent, it's tempting to let the framework or LLM manage its own internal state — perhaps storing conversation history in memory, tracking what tools have been called, or maintaining some notion of "where it is" in a workflow. Meanwhile, your application maintains its own state in a database: orders, users, transactions, and so on. This separation seems natural at first, but it creates serious problems as your system evolves. The problem is that you now have two sources of truth that can diverge. The agent thinks it's in one state, but your database shows something different. When something goes wrong, you can't reconstruct what happened because the agent's internal state is opaque or lost.

Factor 5 says: unify these into a single, durable state representation that both the agent and the rest of your application use. This shared state serves as the definitive record of where the agent is, what it's done, and what needs to happen next.

You have choices in how to implement this unified state:

State objects — maintain a single state object that captures the current snapshot of both execution progress and business data. This object gets updated as the agent progresses and can be loaded to resume from any point.

Event logs — maintain a chronological timeline of everything that has happened. The current state becomes a projection derived from replaying these events. This approach, inspired by event sourcing, provides a complete audit trail.

Hybrid approaches — combine both patterns, using events for history and auditability while maintaining a current state snapshot for efficient access.

Regardless of which approach you choose, the critical principle is the same: one clear source of truth for the workflow and no hidden agent state that can diverge from the application.