Agentic AI architecture with human-in-the-loop controls: where to put the checkpoint

This guide is for CTOs and engineering leads designing or reviewing an agent architecture, and for technical product owners deciding how much of a workflow an agent should run alone. Our AI agent vs workflow automation guide decides whether a task needs an agent at all; our AI agent security and human approval controls guide secures one approval gate against injection and non-compliant automated decisions. This page sits between them: once you have an agent and know a gate is needed, it designs where the gate sits in the control loop and how the system survives the wait.

In this guide

• The control loop has three places for a person, not one
• Choosing the pattern
• Building the checkpoint-placement matrix
• State and checkpoint design: what must survive the pause
• Where AI and the checkpoint design meet
• What delivery record exists, and what does not
• Alternatives and selection criteria
• Limits of this guide
• Frequently asked questions
• Next step

The control loop has three places for a person, not one

An agent runs a perceive-decide-act loop: it reads context, proposes a tool call, and (where a gate applies) waits for a decision before it acts. Most teams default to one checkpoint shape — a chat message that blocks until someone answers — because it is the easiest to build first. It is also the slowest at scale and, as our security and approval guide notes, the shape that trains approvers to stop reading. Three shapes exist, and an architecture should choose deliberately among them, not by default:

• Synchronous blocking. The run halts at the gated step; nothing downstream in that run proceeds until a person answers.
• Asynchronous queued. The gated action is written to a queue or a durable promise; the run continues other independent work, and the agent (or the next run) picks up the answer when it arrives.
• Optimistic execution with a compensating action. The step runs immediately, and a pre-built reversal (refund, unsend, revert) is queued; a person reviews after the fact and triggers the reversal if needed.

Choosing the pattern

State and checkpoint design: what must survive the pause

A synchronous gate can get away with holding state in a running process, because nothing else happens while it waits. Asynchronous and optimistic patterns cannot: the process may restart, the worker may die, and the wait may last hours. Durable execution platforms and agent frameworks converge on the same answer — persist state outside process memory, keyed by a run or thread id, and resume from exactly where the run paused rather than replaying it. Four fields matter most for an agent checkpoint: the inputs the agent had read so far (including any retrieved context, where the run touches a knowledge base as in our RAG architecture guide), the exact proposed tool call and its parameters, a stable run or thread identifier the approval response is bound to, and an idempotency key, because a resumed run commonly re-enters the paused step from the top and must not repeat a side effect such as a charge or a duplicate message. LangChain's interrupt-and-resume model persists a full state snapshot at the pause and restores it on resume; cloud workflow callback patterns (for example AWS Step Functions-style task tokens) keep the paused step visible and billable-idle rather than holding a live thread; durable-promise patterns such as Restate's awakeables bind the approval to a callback id that survives a process restart. None of this is a product endorsement: Netbase works with the major commercial and open-source AI tools and models, chosen per project, and designs the checkpoint around whichever orchestration layer a project already uses.

What delivery record exists, and what does not

• What exists. Netbase has delivered AI for clients that are not named, including the moderation and chatbot records above, where an agent's output or action waits on or syncs with a person-facing queue or CRM workflow. Netbase follows its own security practices (secure code review, TLS in transit and AES at rest, role-based access control, MFA for admin dashboards, vulnerability scanning and penetration testing) and holds ISO 27001 certification and a SOC 2 Type II attestation for its own operations; see security and compliance.
• What does not. No published Netbase record states a resume time, a queue depth, an approval rate, or an incident count for a paused agent run, and no record names which orchestration framework or workflow engine a given delivery used. Netbase's certifications cover Netbase's own operations; they are not extended to a client's system.

Alternatives and selection criteria

The same four criteria from the matrix above decide between these rows: reversibility of the worst case, the latency the business accepts, measured confidence on real cases, and whether a tested compensating action exists at all.

Limits of this guide

• It describes architecture patterns, not a specific framework's guarantees; every orchestration layer and workflow engine implements interrupt, callback and durable-promise patterns slightly differently, and the cited sources document their own product's behaviour, not a universal standard.
• It is general engineering guidance, not legal advice; whether an agent's decision needs human oversight under the EU AI Act or the GDPR is a legal assessment covered in our AI agent security and human approval controls guide, not this one.

Next step

Share the agent you are architecting, the actions it proposes and how long a decision can safely wait, and we will book a solution review to place its checkpoints and design the state it needs to resume. You can also see AI automation and agents or more Netbase insights.

Related services and solutions