Habr AI explains how to build a production agent with durable state, steps and events

For an AI agent to live properly in production, it isn't enough to keep everything in process memory: after a restart, it must remember what exactly the user asked for, which plan was already built, which tools have run and where execution stopped. In the first part of a new practical walkthrough on Habr AI, the author proposes building this durable state around three basic entities (a turn, a step and an event) and shows why, without them, long agent scenarios quickly turn into an opaque, brittle pipeline.

The starting point is simple: if an agent keeps its state only in memory, any service crash wipes out the task. That is tolerable for a demo, but a production agent may analyze documents, wait for user confirmation and execute a long chain of actions, so after a failure it needs to recover from the database, not from scraps of a prompt. As the minimal set of persistent entities, the author lists AgentTurn, AgentPlanItem and AgentEvent, and notes that ApprovalGrant, SessionContext and BackgroundJob almost inevitably show up alongside them.

The idea is that durable state describes not only the final answer but the entire path to it: the original request, the normalized command, confirmation flags, execution statuses and any error.

In this scheme, AgentTurn is a full record of a single user turn. It stores the session identifier and turn_id, the message text, the normalized command and a processing status such as created, planned, awaiting_approval, running, completed or failed. Importantly, the turn also records the final output_text and the error if execution failed. This removes a critical dependence on the model's "memory": the backend can understand at any moment what happened to a request, even if the process restarted. For long tasks this matters especially, because a single request rarely comes down to one model call; more often it involves a chain of file reads, tool calls, verification and result preparation.

The next layer is AgentPlanItem, a separate step within a turn. If a user asks the agent to analyze a project and prepare a report, the agent can break the task into several actions: find documents, read the relevant files, check the data and assemble the final answer. For each step, the author suggests storing its own item_id, sequence number, tool name, arguments, confirmation mode and status.

The article stresses that the safe_readonly, confirm_once and mutating modes are not there for show: they let the system separate safe read operations, actions confirmed once and potentially dangerous mutations in advance. As a result, the system knows not just that "the agent is doing something" but which tool should start next, what has already finished, what can be retried and where execution got stuck.

The third required entity is AgentEvent, a timeline of what happens. Events turn a turn from a black box into an observable system. Instead of a single vague state, the frontend can read turn_started, tool_started, tool_progress, tool_completed, approval_requested, tool_failed and turn_completed, and then show clear progress.

The example in the text is down to earth, and therefore useful: the agent launches collect_documents and finds 12 documents, then at the analyze_documents step reports progress of 40 out of 100, and in case of failure records an external service timeout and marks the error as retryable. For the user this means a decent UX instead of an endless "agent is thinking"; for the development team it means the ability to debug the pipeline, run audits, investigate incidents and restore tasks after a restart without reconstructing the history by hand.

The main takeaway from the Habr AI piece is that a production agent in 2026 is not a clever prompt with some wiring around it but a stateful system with an execution log. If an agent has no durable state at the level of turn, step and event, it survives failures poorly, is opaque to the interface and is almost impossible to maintain. That means the next stage in the evolution of agent applications lies less in new models than in backend architecture discipline: in how we record state, control approvals and turn the model's work into a reproducible operational process.