Factors 9-12: Keep Agents Small and Stateless

You've made significant progress in understanding how to build production-ready AI agents. In previous lessons, you learned to control the LLM interface through Factors 1-4 and mastered state and control flow through Factors 5-8. These eight factors gave you the foundation for building agents that work reliably in production. Now it's time to complete the methodology with the final four factors that determine whether your agents can grow in complexity while remaining maintainable, debuggable, and scalable.

This lesson covers Factors 9-12, the architectural principles that separate demos from production systems. You'll learn to feed failures back to the model for self-correction, create minimal single-responsibility agents, decouple agent logic from any interface, and treat agents as pure functions. By the end of this lesson, you'll have mastered the complete 12-Factor Agents methodology and be equipped to build AI systems that scale successfully.

The ninth factor introduces a powerful principle for agent resilience: when operations fail, provide feedback to the agent so it can adapt its next steps. One of the remarkable capabilities of LLMs is their ability to reason about failures and adjust their approach. If an agent attempts an action that fails, the agent can often figure out what went wrong and try a different approach. However, this self-correction capability only works if the agent actually receives information about the failure.

Factor 9 says: treat errors as valuable feedback that should flow back into the agent's context window, just like successful tool results. When a tool call fails, include information about what went wrong in the next prompt to the LLM. The agent can then reason about the error and decide how to proceed — perhaps by trying a different approach, asking for clarification, or escalating to a human. Once you establish this feedback mechanism, you have many options for how to handle errors in your control flow: you might include retry counts, compact errors in different formats depending on the situation, or even remove error feedback from context once things work.

Let's see this in practice. Imagine an agent trying to create a payment link for a customer. The agent produces this tool call:

{
  "action": "create_payment_link",
  "amount": -50,
  "recipient": "alice@example.com"
}

Your system attempts to execute this, but the payment API rejects it because the amount is negative. Instead of crashing or hiding this error, you feed it back to the agent. Here's one way you might format that feedback:

{
  "tool": "create_payment_link",
  "status": "error",
  "error": "Invalid amount: must be positive. Received: -50"
}

This tells the agent what went wrong. In the next reasoning step, the agent sees this error in its context and can adjust.