Back to blog

Production Agents Need a Runtime

A note on why prompts and tools are only the visible part of shipping real agents.

Tags: agentic-engineering , ai , workflow

This is the part most people miss.

A prompt plus tools is not a production agent.

It is a good demo shape. The model receives instructions. It can call a search tool, a file tool, a shell tool, maybe a database tool. It loops. It produces something that feels agentic.

That loop matters. Anthropic describes the Claude Agent SDK around a simple loop of gathering context, taking action, and verifying work, with tools giving the agent a computer to operate in. That is useful framing. But even Anthropic’s Agent SDK writeup is not only about prompts. It is about tools, context management, iteration, verification, and the environment the agent runs inside.

The prompt is only the visible interface.

Production lives in the runtime: state, sessions, recovery, and controlled execution environments.

Without that layer, you are not really operating agents.

You are supervising scripts and hoping they keep running.

State Is The Boundary

The model is mostly stateless. Your product is not.

A real agent needs to remember what it is doing, what it already tried, what tool results came back, what the user approved, what failed, and what should happen next. That memory cannot live only in the prompt window. It has to exist as product state.

This is why agent frameworks keep adding persistence as a first-class concept. LangGraph’s persistence docs describe checkpoints saved at each step of execution, organized into threads, so systems can support human-in-the-loop workflows, conversational memory, time travel debugging, and fault-tolerant execution. That is not decorative infrastructure. That is the difference between “try again from scratch” and “resume from where we left off.”

The same issue shows up in the OpenAI ecosystem. OpenAI’s Agents SDK session docs describe sessions as built-in memory that stores conversation history for a specific session across agent runs, with production-oriented backends like SQLAlchemy, MongoDB, Dapr, and server-managed OpenAI conversations.

That is the shape of a product surface.

Sessions are not just chat history. They are the handle that lets a user return, a worker restart, a job pause, or a workflow continue without pretending nothing happened before.

Recovery Is Product Behavior

If an agent can take real actions, then failure is not an edge case.

The process will crash. A deployment will restart. A tool call will time out. A rate limit will hit. A human approval will arrive hours later. A browser session will die halfway through a task. A background job will be interrupted after doing the first three steps but before doing the fourth.

Production software has to decide what happens then.

Temporal’s workflow documentation says workflows can keep running for years even if the underlying infrastructure fails, and that Temporal recreates pre-failure state by replaying an ordered event history. In its agent-specific writing, Temporal makes the point more directly: longer-running agents benefit from durable execution because the system can replay recorded decisions and resume without asking the model to invent a new path for work it already did.

That matters because agents are non-deterministic at the top and side-effectful at the edges.

If a model already decided to send an email, create a record, open a ticket, or charge a card, recovery cannot simply rerun the same prompt and hope for the best. The system needs durable records, idempotency, retries, compensation, and a clear boundary between reasoning and side effects.

Otherwise recovery becomes a person staring at logs, guessing what happened, and manually nudging the script forward.

That is babysitting.

The Environment Is Part Of The Agent

Tools are not abstract.

A shell tool runs somewhere. A browser has state. A file edit touches a filesystem. A database tool uses credentials. An MCP server may have its own session. A code interpreter has packages, network rules, CPU limits, and cleanup behavior.

The agent’s environment is part of the product, because the environment defines what the agent can safely and reliably do.

Cloudflare’s Agents documentation is explicit about this runtime layer. It says each hosted agent session has durable identity, local SQL storage, real-time connections, scheduled work, and recoverable execution. Its state documentation describes agent state as automatically persisted to SQLite and synchronized across clients.

That is a very different promise from “the model can call a function.”

It means the runtime owns identity, state, connections, scheduling, and recovery. It gives the agent somewhere to live.

Environment control also means security control. The more capable the tools are, the more important the boundary becomes. A production agent should not be a pile of unrestricted tool calls glued to a prompt. It needs scoped credentials, isolated execution, audit logs, resource limits, approval gates, and a way to stop or roll back risky work.

Prompt Engineering Is Not Enough

Prompts still matter.

Tool design matters. Context design matters. The model matters. The shape of the loop matters.

But a production agent is not just a clever prompt with a list of functions. It is a distributed system with an LLM in the middle. The boring parts are the parts that make it real: state, sessions, queues, checkpoints, retries, observability, permissions, sandboxes, and deployment behavior.

This is why demos feel so much easier than products.

A demo can assume one clean run. A product has to survive the second run, the broken run, the resumed run, the user who comes back tomorrow, the tool that fails halfway through, and the deployment that restarts while work is in progress.

The agent loop is the visible layer.

The runtime is the shipping layer.

References