Quick take: when an agent’s API call breaks mid-task, most setups either stall out or send the same thing twice. This fallback prompt tells the agent to switch to the browser, finish the exact same draft, and leave proof behind. The block comes from u/investigatormaker, who dropped it in r/PromptEngineering this week as a copyable rule for any agent that already has browser access.
I’ve seen agents choke on a single failed API call and just stop. This prompt treats that moment as routine, not a crisis, and that’s what makes it worth stealing.
The Prompt
Continue the existing task from the last completed step.
If the API fails, open the target thread in the browser and finish the same draft.
Before sending, check the ledger and thread for a prior send. If its outcome is unclear, inspect it first.
Send once, reopen the result, and save its permalink.
If the browser is unavailable too, record the unfinished step and continue independent work.
Five lines. No fluff. Each one tells the agent exactly what to check before it moves.
Quick definition before we go further: a “ledger” here just means whatever record your agent already keeps of what it has done. That could be a spreadsheet row, a database entry, or a log line. The prompt doesn’t care which record system you use. It just insists the agent checks it before acting again.
Why It Works
This isn’t a creative prompt. It’s a recovery procedure, and that’s exactly the point.
- Task continuity: “Continue from the last completed step” stops the agent from restarting the whole job every time one tool hiccups.
- Tool fallback: line two hands the agent a backup channel, the browser, the second the primary one goes down.
- Idempotency check: line three is the clever part. Before sending anything, the agent has to check whether it already sent this exact thing. That single instruction kills duplicate posts, duplicate emails, duplicate anything.
- Proof of work: saving the permalink after sending gives you, or another agent down the line, a receipt to check later.
- Scoped recovery: the agent never tries to fix the outage itself. It works around the broken tool and keeps the task moving.
- Honest failure: if the API and the browser are both down, the agent doesn’t fake a result. It writes down what’s unfinished and keeps working on something else.
That last line is the one most prompts skip. Most instructions plan for success and maybe one failure path. This one plans for total failure and still tells the agent to keep moving instead of freezing up.
Use Cases 🎯
- Social and community agents: anything posting replies across threads, where a dropped API call can mean an accidental duplicate reply.
- Outreach and email agents: same risk, different channel. If the send API times out, the agent needs to check the ledger before it fires a second copy.
- Form-fillers and research agents: any multi-step agent with a browser tool as a fallback UI path, not just a nice-to-have.
- Support or ticketing bots: an unclear “did this actually send” moment is exactly where duplicate replies to a customer happen.
Try This Variation
The original is built for one send-and-verify loop. If your agent runs longer chains, add a logging step before the fallback kicks in:
Log the exact point of failure (task ID, last completed step, timestamp) before switching tools.
That gives you a clean audit trail. You’ll be able to see exactly why an agent jumped from the API to the browser halfway through a task. You could also swap the browser for any secondary tool your agent has access to. The pattern holds regardless of which tool catches the failure: don’t quit, don’t duplicate, don’t lie about what happened.
A second tweak worth trying: set a retry limit on the API step itself. That way the agent tries twice before falling back, instead of jumping to the browser on the first timeout. Browser automation is slower and heavier than an API call. Save it for when the API is actually down, not for a single flaky network blip.
Not everyone in the thread was sold. One commenter pushed back, saying the block reads more like a terms-of-service document than something a model can act on without getting confused. That’s a fair gut-check. A fallback procedure only earns its place if your agent actually follows it under pressure, not just on a clean test run.
It’s a small thread, a handful of upvotes, but the idea underneath it is bigger than the post itself. Most agent prompts are written for the happy path. This one is written for the day your API provider has an outage and your task still needs to ship. That’s the gap most people never plan for, and it’s exactly where agents quietly lose trust.
Head over to r/PromptEngineering to read the original thread and the full comment section. Worth a look if you’re running any agent with a browser fallback.
A fallback prompt for agents: preserve the task when an API route disappears
by u/investigatormaker in PromptEngineering