What Competitor Articles Cover (and What They Miss)

The actual SERP for "workflow automation" (checked 2026-04-28, top 10 via DuckDuckGo HTML) splits cleanly into two shapes:

Product landing pages — n8n.io at #1, Zapier's blog at #2, Atlassian at #4, Microsoft Copilot at #5. Each positions its own tool as the answer. Useful if you're evaluating buy options.

"Best tools" listicles — workflowautomation.net ("Top 14 Tools Ranked"), guideflow.com ("15 best platforms for SaaS"), invensislearning.com ("14 Best"), thedigitalprojectmanager.com ("21 Best AI Workflow Automation Software"). These rank the same 10–15 tools (Zapier, Make, n8n, Power Automate, Workato) with minor reordering.

Plus definitional content: TechTarget at #8 with "What is Workflow Automation?", Atlassian's definition page, the github.com/topics/workflow-automation tag page at #6.

What's missing from all ten: anyone writing about what the workflow should do when it hits a step it structurally can't complete. The definitional pages assume all steps succeed. The listicles rank tools by integration count. None of them address AI agent workflows specifically, because traditional automation was built on a fundamentally different assumption: every step is deterministic and can be retried. Send this HTTP request. Write this row to Airtable. Post this Slack message. If it fails, retry 3 times, then error out.

AI agent workflows break that assumption completely. A step like "sign into the customer's vendor portal and download last month's invoices" involves reading a page the agent has never seen, filling a form whose field names rotate, handling a popup that might or might not appear, and getting past an MFA gate that the vendor added last week. Every single action is probabilistic. Retry three times won't fix the MFA gate — no amount of retrying produces an OTP.

The gap in the existing content: nobody is writing about how to hand off gracefully when the workflow hits a step that structurally requires a human. That's the hole this article fills.

The Three Silent Failure Modes in AI Workflows

Before the fix, the failure. When a vanilla AI workflow hits a non-deterministic step it can't complete, one of three things happens:

Failure 1 — Infinite Retry

The LLM generates a plan that's almost right, executes it, fails, observes the failure, and generates the same plan again. Nothing changed on the page — the MFA input is still waiting — so the model produces the same output. Loop until the runner's wall-clock timeout kills the job, usually 30–60 minutes later, burning tokens the whole time.

Failure 2 — Fake Success

The agent sees a redirect, sees the URL change, and concludes the task is complete. But the redirect was to an error page, or the agent landed on a "please verify" intermediate screen that it misread as the dashboard. The workflow reports success. Your downstream step sees an empty result set. Silent.

Failure 3 — Missing Signal

The agent truly gets stuck, exits, but the surrounding workflow tool has no idea what happened. No state dump. No explanation. The ops team sees "job failed at step 3 of 7" and has to rerun from scratch, paying for the first 2 steps twice.

All three share a common root cause: the workflow runner has no language for "I'm stuck in a way that retrying won't fix, and here is specifically why." Policies are that language.

Policy #1 — Credential Login

When it fires: the page requests a username, password, OTP, device verification, or any other credential, and no cached session or stored credential applies.

What happens: the agent pauses, emits a Human Assist URL, and waits for a human to complete the sign-in. Once the human submits the form, the agent captures the post-auth session state, caches it with a configurable TTL, and continues from exactly where it left off.

Configuration:

policies:
  credential-login:
    action: human-assist
    notify: slack://#workflows-handoff
    timeout: 900  # seconds to wait for the human
    session_ttl: 7d

Scenario in a production workflow: a finance automation pulls invoices from twelve vendor portals every Monday morning. Vendor #7 adds device-trust MFA over the weekend. Without the policy, the Monday run burns 47 minutes looping on the "approve this device" prompt. With the policy, the agent stops at minute 0:30, posts a link to Slack, the ops lead on call approves the device in 10 seconds, the agent resumes, and the Monday run completes on time. For the next 7 days, the cached session skips the MFA entirely.

Policy #2 — Captcha Unsolvable

When it fires: the integrated captcha solver fails after N attempts, where N is configurable.

What happens: instead of retrying indefinitely or aborting the job, the agent emits the Human Assist URL pointing to the exact page with the captcha. A human completes the captcha, and the agent resumes.

Configuration:

policies:
  captcha-unsolvable:
    action: human-assist
    notify: slack://#workflows-handoff
    max_solver_attempts: 2
    session_ttl: 1h

Scenario: a lead-enrichment workflow hits a site protected by Cloudflare Turnstile. The first attempt passes because the fingerprint is clean. The second attempt, 3 hours later, gets flagged as suspicious and presents an interactive captcha. Without the policy, the solver retries 10 times, all fail, the job errors out. With the policy, the second failure triggers handoff; a human clicks the captcha box once; the session is cached for an hour; the workflow continues enriching the remaining leads.

Policy #3 — Payment Confirmation

When it fires: the URL pattern matches a known payment gate. URL patterns are configurable via glob.

What happens: the agent pauses automatically when it reaches a payment confirmation page. No handoff is emitted (this is a hard stop by design). The workflow records the pre-payment state and exits with a specific code indicating payment was reached.

Configuration:

policies:
  payment-confirmation:
    action: pause
    url_patterns:
      - "*/checkout/confirm*"
      - "*/payment/*"
      - "*/billing/purchase*"
    exit_code: 42
    state_dump: ./artifacts/pre-payment-state.json

Scenario: you're testing a purchasing workflow in CI. An agent is iterating on a shopping cart flow to verify checkout UX. Without this policy, a test run might actually submit the card. With it, every payment page is a guaranteed hard stop — no accidental real charges. This is also why many teams keep payment flows entirely out of their test suite; this policy lets you bring them back into scope without risk.

Policy #4 — Operation Stuck

When it fires: the agent retries the same action N times without progress, or no progress has been made in a configurable time window.

What happens: the agent stops, dumps the last-known state (DOM snapshot, last 10 actions, last LLM response) to a file, and exits non-zero.

Configuration:

policies:
  operation-stuck:
    action: stop
    max_retries: 3
    stall_timeout: 180
    report: ./artifacts/stuck-state.json

Scenario: the LLM generates a selector for "Checkout button" that matches a hidden legacy button instead of the visible new one. The agent clicks, nothing happens, retries. Without the policy, you get "job timed out after 1800s" with no diagnostic. With it, after 3 retries the agent exits with a JSON dump showing the clicked element, the page screenshot at that moment, and the LLM's reasoning. Debugging goes from "no idea where it stopped" to "wrong selector on this specific button, here's the fix" in under 2 minutes.

Wiring Policies Into Your Existing Stack

You do not need to replace your workflow orchestrator. Policies are configured per-task, read by browser-act at runtime, and emit standard webhooks that any existing tool can consume.

n8n

Add an HTTP Request node that watches a webhook endpoint for the Human Assist URL. When a task hands off, n8n receives the URL, posts it to a Slack channel via the Slack node, and pauses the workflow. When the human completes the step, a Resume webhook from browser-act reaches n8n and the next node fires.

LangGraph

Wrap each browser-act task as a node. The policy handoff surfaces as a specific exception class the graph can catch. Route the exception to a human_assist node that emits the URL to the user's preferred channel, then route back to retry the original node with --session pointing at the cached session.

Custom Python

Launch browser-act as a subprocess. The policy will exit with a specific code and print a JSON line containing the Human Assist URL. Parse the line, post it wherever your team looks, and wait on a file/webhook signal to resume.

import subprocess, json
proc = subprocess.run(
    ["browser-act", "stealth-extract", url,
     "--policies", "./policies.yaml",
     "--session", "vendor-7"],
    capture_output=True,
)
if proc.returncode == 10:  # credential-login policy
    line = next(l for l in proc.stdout.decode().splitlines() if l.startswith("{"))
    handoff = json.loads(line)
    post_to_slack(handoff["assist_url"])
    wait_for_resume(handoff["session_id"])

Zapier

Zapier has no direct integration because Zapier's model assumes deterministic triggers. You would typically route the Human Assist URL through a Webhooks by Zapier step that triggers a Slack message. The resume path is weaker here — Zapier's model doesn't pause mid-zap. Use n8n or LangGraph if policy-based handoff is core to your workflow.

When Traditional Automation Still Wins

Policies exist because AI agent steps are probabilistic. If your workflow doesn't include probabilistic steps, you don't need policies — and you probably don't need an AI agent at all.

Zapier, n8n, Make, and Power Automate are the right choice when:

• Every step is a deterministic API call, file operation, or database write.
• The sites you touch expose public APIs you can authenticate to directly.
• Your workflow is low-volume and the cost of a failed step is low (you manually rerun).
• You need hundreds of pre-built connectors that already exist in the no-code marketplace.

The policy model is overkill for "post to Slack when a Google Sheet row is added." Keep Zapier for Zapier's problems. Reach for browser-act and policies when the workflow crosses into a real browser against a real, non-deterministic web UI.

Conclusion

Workflow automation as a category was defined when every automation step was an API call. The category's vocabulary — triggers, actions, filters, delays — assumes determinism. When AI agents took over the "doing browser work" part of workflows, the vocabulary didn't expand to cover what happens when a step structurally requires a human.

Policies are that expansion. Four triggers. Each one names a specific reason the agent can't proceed alone. Each one routes to a human in seconds and caches the result so the next run doesn't need to ask again.

If your team runs AI workflows in production today, the fastest audit you can run is this: grep your workflow logs for jobs that ran longer than 30 minutes. Each long job is almost certainly stuck in one of the four policy categories. Each one is a policy waiting to be added.

Get Started

• Install: npm install -g browser-act (or brew install browser-act)
• Docs for v1.1.0 policies: browser-act/skills/browser-act
• Fastest way to try: pick the next workflow in your queue that sometimes gets stuck on login, add a credential-login policy, wire the URL to Slack. One sign-in covers the next seven days of runs.

The workflow you stopped running because it loops on Mondays is the one the policy was built for.