Building AI Agents That Don't Break in Production

Most agent development starts with a library like LangChain or a simple Python script calling the Claude API. These are excellent for prototyping but their default agent runners lack production-grade error handling. A LangChain agent built with a ReAct loop will enter a recursive error state or simply halt if a tool's API returns a 502 Bad Gateway error. It has no built-in concept of retries with exponential backoff, nor can it differentiate a transient network failure from a fatal 401 Unauthorized error that requires a human to update an API key.

Consider an agent designed to process inbound lead emails, extract contact info, and create a lead in a CRM. The prototype works perfectly on 10 test emails. In production, the first real-world lead has a non-standard signature containing multiple phone numbers. The LLM's tool call to `create_crm_lead` includes an array for the `phone_number` field, but the CRM API expects a single string. The API returns a 400 Bad Request with a JSON body explaining the error. The basic agent lacks logic to parse this error. It gets stuck in a loop, repeatedly calling the failing tool with the same bad data until it hits its context limit.

This failure isn't just a technical glitch; it's a business process failure. While the agent is stuck on one malformed email, 50 other valid leads queue up behind it, untouched. The sales team's response time plummets from minutes to hours, and valuable opportunities are lost. The developer who built the prototype has to be pulled off other work to manually debug the agent's state, find the problematic email, and restart the entire process, losing all progress.

The structural problem is that these agent frameworks treat tool calls as simple, stateless function executions. They lack a persistent state machine to track the progress of a multi-step task. Without a record in a database like Supabase, the system cannot know that step 2 of a 5-step process failed. Therefore, it cannot gracefully roll back, try an alternative tool, or park the task for human review. It is an all-or-nothing execution model that is too brittle for business-critical workflows where partial failures are the norm, not the exception.

We start by mapping your workflow into a formal state machine diagram. For a customer support triage agent, we'd identify at least 5 distinct states: 'New Ticket', 'Classifying', 'Awaiting Tool', 'Resolved', and 'Escalated'. We then define the specific errors that can occur during each state transition, such as a Claude API timeout (HTTP 503) or a malformed response from your helpdesk API (HTTP 400).

Syntora implements this state machine using LangGraph, which represents the workflow as a stateful graph. This graph is managed by a central orchestrator we built with FastAPI. State is persisted in a Supabase PostgreSQL database. When a sub-agent fails, the orchestrator catches the specific Python exception. A `requests.Timeout` error triggers an automatic retry with exponential backoff, starting with a 5-second delay. A `pydantic.ValidationError` escalates immediately to a human review queue. After 3 failed retries for any transient error, the task is moved to a dead-letter queue for manual inspection.

The final system is a containerized FastAPI application deployed on your infrastructure. It's designed to process events with a P99 latency under 500ms for state transitions. You receive the complete Python source code, a Terraform script for deploying the infrastructure on AWS Lambda or DigitalOcean, and a runbook for monitoring logs and handling the review queue. This architecture typically costs less than $100/month to operate for moderate workloads.