Tool calling is table stakes. Every LLM API supports it now. But tool calling alone doesn't make an agent - it makes a chatbot with functions. The difference is the control loop.
Gursharan Singh's production guide to agentic workflows focuses on the architecture that wraps the model - the control loop, state management, and the patterns that turn a working demo into a reliable system.
What a Control Loop Actually Does
Your agent calls a weather API. The API times out. What happens next?
In a demo, nothing. The model hallucinates a response or the system crashes. In production, the control loop catches the timeout, decides whether to retry, logs the failure, and either falls back to cached data or tells the user the service is unavailable.
The control loop is the decision-making layer that sits between the model and the outside world. It handles retries, validates tool outputs, manages turn-taking in multi-step workflows, and enforces guardrails when the model tries to do something dangerous or nonsensical.
Without it, your agent is fragile. A single tool failure breaks the entire conversation. A user asking an unexpected question derails the workflow. The model calls the same tool in a loop because nothing stops it.
State Management - The Hardest Part
A conversation isn't stateless. The agent needs to remember what happened three turns ago, what tools succeeded, what the user confirmed, and what's still pending. But LLMs have context windows, and storing everything in the prompt is expensive and brittle.
Singh breaks down the state management challenge: what to store, where to store it, and when to clear it. Some state belongs in the prompt (recent conversation history, user preferences). Some belongs in a database (long-term user data, completed workflows). Some belongs in ephemeral memory (scratch space for multi-step reasoning that gets discarded after the task completes).
The mistake most teams make is putting everything in the prompt and hoping the model remembers. This works until the conversation gets long, the context window fills up, and critical information gets pushed out. Then the agent forgets what it was doing and starts over. Or worse, it confidently continues with hallucinated context.
Patterns That Work in Production
Singh's guide covers the patterns that separate working demos from production systems:
State machines for multi-turn workflows. When the agent needs to execute a sequence of steps - verify user identity, check account balance, process transaction, send confirmation - a state machine tracks progress. If a step fails, the system knows where it failed and can resume from that point. No starting over. No asking the user for information twice.
Retry logic with exponential backoff. Tools fail. APIs time out. The control loop needs retry logic, but naive retries hammer failing services and waste tokens. Exponential backoff - wait 1 second, then 2, then 4 - gives transient failures time to resolve without giving up too quickly.
Tool output validation. Just because a tool returns data doesn't mean the data is valid. The control loop validates tool outputs before passing them to the model. If the weather API returns a 500 error wrapped in JSON, the validation layer catches it before the model tries to parse it as weather data.
Graceful degradation. When a tool is unavailable, the agent shouldn't crash. It should fall back to cached data, use an alternative tool, or tell the user the service is temporarily down. This requires the control loop to know what fallbacks exist and when to use them.
Skills - Composable Agent Primitives
A skill is a unit of agent behaviour - a prompt, a tool call, validation logic, and error handling wrapped together. Singh's insight is that skills should be composable. You build them once, test them thoroughly, and reuse them across different agents.
Example: a customer support agent that processes refunds. The refund skill knows how to check eligibility, validate the request, call the payments API, handle failures, and confirm success. When you build a new agent that needs refund functionality, you don't rewrite it - you import the skill.
This is the pattern that scales. You don't rebuild everything for each new agent. You compose existing skills and add new ones when the domain demands it.
Why This Matters for Builders
If you're building agents for production, the model is the easy part. The hard part is the scaffolding around it - the control loop, state management, error handling, and retry logic that make the system reliable when real users touch it.
Singh's guide assumes you already know how to call an LLM API. What it teaches is how to build the architecture that turns API calls into systems that work. It's production-focused, pattern-driven, and open-source.
The gap between demo and production is the control loop. This guide shows you how to build it.