Building a Loop That Asks for Help When Stuck

Most agent advice treats asking for help as a failure — the goal is always more autonomy, fewer human interruptions, an agent that handles everything alone. That's exactly wrong when the stakes are real. An agent that guesses on a high-stakes decision it's genuinely unsure about isn't being autonomous; it's being reckless. An agent ask for help loop knows the difference between a problem it should solve and one it should escalate, and that judgment is what makes an agent trustworthy enough to deploy on anything that matters.

This is a teardown of a loop with no escalation path, why silent guessing hurts more than asking, and the rewrite that adds a clean way for the agent to pull in a human when it should.

Before: The Weak Prompt

Here's the standard fully-autonomous loop. Its instructions leave the agent exactly one way to end a run: produce an answer, no matter what.

You are an autonomous assistant. Work through the task using your
tools until you can provide a complete answer. Always give the user
a definitive response. Do not defer or leave the task unfinished.

What this does: It pushes the agent toward always answering and explicitly discourages deferring — which sounds decisive but forces the agent to fabricate a confident response even when it's genuinely stuck, because "ask a human" isn't among the options it's given.

Why It Fails

The prompt fails because it gives the agent no acceptable outcome other than answering, so when the agent hits something it can't handle, it does the only thing it's allowed to do: guess and present the guess confidently. "Always give a definitive response" sounds like good product design and is actually a recipe for confident errors on exactly the cases where a wrong answer costs the most.

Consider what "stuck" really means. Sometimes the agent lacks information no tool can provide — a judgment call, a missing permission, an ambiguous situation that needs human context. Sometimes the stakes are high enough that even a well-supported answer should get human sign-off. In both cases, the right move is to escalate, and a loop with no escalation path can't make that move. It converts every "I should ask" into "I'll guess," which is the worst possible substitution on high-stakes work.

⚡ Pro tip: The absence of an escalation path doesn't make an agent more autonomous — it makes it dishonestly confident. An agent that can say "I need help with this specific thing" is more trustworthy, not less, because you can actually rely on its answers when it does give them. Removing the ask-for-help option doesn't remove the uncertainty; it just hides it behind a confident guess.

There's a subtler failure too. Without a designed escalation path, teams that do want human oversight bolt it on crudely — routing everything to humans, or using brittle keyword triggers. Both are bad: routing everything defeats the point of the agent, and keyword triggers fire on the wrong things. A proper agent ask for help loop makes escalation a first-class, well-targeted action, not an afterthought.

It helps to see why "always answer" feels safe to build and is actually the riskiest choice. A forced-answer agent has a great demo — it always produces something, it never leaves the user hanging, it looks decisive and capable. The failures are invisible until they're in production and someone acts on a confident wrong answer the agent should have flagged as uncertain. An agent ask for help loop looks slightly less impressive in a demo because it occasionally says "I need input on this" — but that occasional honesty is exactly what makes its confident answers trustworthy. You're trading a flashier demo for an agent people can actually rely on, which on high-stakes work is not a close call.

⚡ Pro tip: Measure your agent's "confidently wrong" rate, not just its overall accuracy. An agent that's right 90% of the time and honestly uncertain the other 10% is far more valuable than one that's right 90% and confidently wrong 10%, even though their accuracy is identical. The confidently-wrong answers are the ones that cause real damage, and an escalation path converts most of them into honest hand-offs. Accuracy hides this distinction; the confidently-wrong rate exposes it.

After: The Improved Prompt

The rewrite gives the agent an explicit escalation action and clear criteria for when to use it, so asking for help becomes a legitimate, well-scoped outcome rather than a forbidden one.

You have three ways to end a task:
1. ANSWER: give a complete response when you're confident and the
   stakes don't require sign-off.
2. ASK_HELP: when you're genuinely stuck or lack information no tool
   can give you, escalate with: what you were trying to do, what you
   found, the specific blocker, and what you need from the human.
3. ESCALATE_APPROVAL: when you have an answer but the action is
   high-stakes and irreversible, present it for human approval before
   acting.

Prefer ANSWER when you can. Use ASK_HELP instead of guessing on
something you can't determine. Never present a guess as a confident
answer.

What this does: It gives the agent three legitimate endings instead of one, defines exactly when to escalate versus answer, and requires a structured hand-off — so a stuck agent asks a targeted question instead of fabricating confidence, and a high-stakes action gets sign-off.

In code, escalation is a first-class outcome the loop handles cleanly.

[object Object], ,[object Object],(,[object Object],):
    ,[object Object], _ ,[object Object], ,[object Object],(max_steps):
        action = model_decide(state, tools + [ask_help, escalate_approval])
        ,[object Object], action.name == ,[object Object],:
            ,[object Object], {,[object Object],: ,[object Object],, ,[object Object],: action.args[,[object Object],]}
        ,[object Object], action.name == ,[object Object],:
            ,[object Object], {,[object Object],: ,[object Object],, ,[object Object],: action.args}   ,[object Object],
        ,[object Object], action.name == ,[object Object],:
            ,[object Object], {,[object Object],: ,[object Object],, ,[object Object],: action.args}     ,[object Object],
        state = update_state(state, action, run_tool(action))
    ,[object Object],
    ,[object Object], {,[object Object],: ,[object Object],, ,[object Object],: build_stuck_report(state)}

What this does: It treats asking for help and requesting approval as proper loop outcomes alongside answering, and — critically — escalates rather than force-answering when the agent exhausts its steps, so running out of budget produces an honest hand-off instead of a desperate guess.

Breaking Down Each Element

The structured hand-off is what makes escalation useful rather than annoying. "I need help" with no context forces the human to reconstruct everything. "I was verifying this address, the records show two conflicting entries, and I need you to confirm which is correct" lets the human resolve it in seconds. The quality of the escalation determines whether human oversight is a smooth backstop or a bottleneck.

The distinction between ask-help and escalate-approval matters. Ask-help is "I can't proceed without you." Escalate-approval is "I can proceed, but I shouldn't without sign-off." These are different situations needing different human responses, and collapsing them loses information the human needs.

The exhausted-steps escalation is the quiet hero. The most dangerous moment for a forced-answer agent is when it runs out of budget with no answer — that's when it produces its worst guesses. Making step exhaustion trigger an honest escalation instead of a forced answer removes the single worst failure mode.

⚠️ Common mistake: Making escalation so easy the agent overuses it. The opposite failure of never asking is asking constantly, routing trivial uncertainty to humans until the agent is more work than doing the task manually. Calibrate the bar: escalate on genuine blockers and high stakes, not on every small uncertainty. Tie the threshold to consequences, and review your escalation logs — if the agent is escalating things a human finds trivial, tighten the criteria.

⚡ Pro tip: Log every escalation with its eventual human resolution, and mine the patterns. If the agent repeatedly escalates the same kind of question and the human always resolves it the same way, you've found either a tool the agent is missing or a rule you can encode — turning a recurring escalation into an automated capability. Escalation logs are a roadmap of exactly where your agent needs to grow.

Variations for Different Contexts

For a medical or legal agent, escalate-approval is mandatory before any consequential output — the agent drafts, a professional signs off, and the loop is designed around that handoff rather than treating it as an exception.

For an internal ops agent, ask-help routes to a Slack channel where a human can respond and the agent resumes with the answer, keeping the human in the loop without blocking the agent entirely. An operations lead at a logistics company told me this pattern let one human supervise a fleet of agents, stepping in only on the genuine blockers.

For a customer-facing agent, calibrate escalation to protect the experience — better to escalate a confusing edge case to a human agent than to give a customer a confident wrong answer that creates a worse problem downstream.

For a data-pipeline or infrastructure agent, escalate-approval belongs before any destructive or wide-blast-radius operation — dropping a table, deploying to production, deleting a resource. The agent does all the diagnosis and proposes the exact action, but a human confirms before the irreversible step runs. This keeps the agent fast on everything reversible while putting a deliberate pause exactly where a mistake would be catastrophic. A platform engineer I know frames it as "the agent can do anything it can undo, and must ask before anything it can't."

⚡ Pro tip: Make the escalation asynchronous where you can, so a stuck agent doesn't block a worker while it waits for a human. Park the run, notify the human, and resume when they respond — rather than holding an open loop idle for minutes or hours. Synchronous escalation is simpler to build but ties up resources and doesn't scale; asynchronous escalation lets one human calmly handle escalations from many agents without any of them burning compute while they wait.

Save and Reuse This

An escalation path is something every agent handling real stakes should have, and the wording of the escalation criteria and the structure of the hand-off take iteration to get right. Once you've built a version that escalates on the right things with useful context, keep it.

A prompt library like PromptABCD is a good home for your ask-help and approval prompts and the hand-off structure, so every agent you give real responsibility inherits a clean escalation path instead of the false autonomy of an agent that can only ever guess. The teams that treat "knowing when to ask" as a designed capability rather than a failure are the ones whose agents earn enough trust to be handed anything that matters.