Why bother with checkpointing?

In 2026, a single LLM call can solve a wide variety of simple problems. But most real problems that organizations deal with need task decomposition and multiple LLM calls. And not just that. In our experience, most problems worth solving cannot be completely delegated to a team of AI agents. Human experts steering the agentic workflow midway is unavoidable.

Enter the SMEs: steering your agents midway

Autonomous agents are impressive, but in enterprise work you rarely want them running unchecked from start to finish. An agent that has drafted a migration plan, a test strategy or a design should often pause so a domain expert can review it before anything expensive happens. Interim human steering is what turns a generic one-size-fits-all demo into something a team can trust and use.

So how do you build it? The naive approach is polling.

• The agent drafts a plan.
• It writes that plan somewhere a human can see it: a file on a shared drive, a simple DB entry, or even a JIRA ticket.
• It notifies the SME, then sits in a loop, checking every few seconds or minutes whether a response has arrived.
• When the SME edits the plan or approves it, the agent notices on its next poll, reads the feedback and carries on.
• Alternatively, we can have a mechanism for the SME to “resume” the workflow instead of the workflow polling the SME’s activity.

Nevertheless, there is a need for the SMEs and the agents to interface using a shared medium.

This works. Problem solved. For one agent, one steering point and one conversation, it is a perfectly reasonable weekend prototype. But what happens when enterprise-grade complexity enters the chat?

Why polling falls apart

The trouble is that real workflows do not have one steering point. They have several: approve the plan, review the generated artefacts, sign off before deployment. And they do not run one conversation at a time. A delivery team may have dozens of agent runs in flight, each waiting on a different person.

With several runs and several steering points, the waiting loops multiply and tangle.

Now your simple polling loop has to answer some awkward questions:

• Which pending request belongs to which run, and which step within that run?
• Where does the agent's state live while it waits? Hours, or even days, if the SME is on leave.
• Which SME has the permissions to execute which specific actions?
• What happens if the process crashes, the server restarts or you deploy a new version mid-wait?
• How do you avoid hundreds of idle loops burning compute while they poll?
• When feedback arrives, how does the agent restore exactly the context it had before it paused?

Every one of these is solvable. But you are now writing a state machine, a persistence layer, a notification system and a recovery mechanism, none of which has anything to do with your actual problem. The glue code ends up bigger than the agent. Do you want your AI Engineers to focus on the agents or the overall state management & polling mechanism?

Hello, checkpointing

Checkpointing replaces the waiting loop with a simpler idea: after each meaningful step, the system saves the full state of the run (inputs, intermediate outputs, decisions made, context built so far) to durable storage. When the agent reaches a steering point, it saves a checkpoint and stops. No loop, no running process, no complexity.

When the human responds, even days later, the system loads the checkpoint, injects the feedback and resumes exactly where it left off. Many steering points and many conversations become the same mechanism applied repeatedly, with each run identified by its own checkpoint history.

The design gives you several additional benefits beyond human steering.

The time travel point by itself is worth leveraging checkpointing. When an SME says “the plan was fine, but the third step went wrong”, you rewind to that step instead of starting over. That turns steering into a conversation rather than a restart.

Where Hazel comes in

Building this properly is real engineering. Durable storage, state serialisation, resume logic, notification hooks, versioning of checkpoints and a way to rewind safely are all hard to get right. And none of them is what you wanted to build in the first place. That’s why we built it for you. You are welcome.

At Hazel, checkpointing is built in by default. Every agent you build on the platform gets durable state, human steering points, retries from the last good step and time travel through the execution path without extra code. You can build the agents yourself on the platform, or have our team build them out for you.

You focus on your core business. We focus on the agentic AI engineering problems. If you are wrestling with long-running agents that need human steering, drop us a line here.