CAPTCHA Is a Product Decision, Not a Bug
We detect challenges and hand them to a human. That choice caps autonomous throughput — and it is the right trade for anyone who plans to keep their domains.
It is the first question anyone asks when they see an agent file a directory submission on its own: what happens when it hits a CAPTCHA? The expected answer is a vendor name. There is a mature market for solving challenges programmatically, the integration is a few hours of work, and it would let us claim a fully unattended pipeline.
We do not do it. The agent detects the challenge, freezes that submission, and hands it to an operator with everything already filled in. That is a deliberate cap on how much of a campaign can run without a person, and we would make the same call again.
What a solve service actually buys you
Two things you want and one you do not. You want the throughput, and you want the elimination of an awkward hand-off in the product. What you also get is a durable record, on someone else's infrastructure, that your client's brand was pushed through an anti-automation control that the publisher installed on purpose.
Directory operators are not passive about this. The ones worth submitting to prune listings, and the cheapest heuristic they have is to look for submissions that behaved like traffic they had explicitly tried to stop. A link that gets removed in month three is worse than a link that was never placed, because you have already reported it.
A CAPTCHA is a publisher telling you it does not want automated traffic. Routing around it does not change the answer. It changes who finds out, and when.
The routing table
Detection is not a single boolean. The agent classifies what it found and routes accordingly, because not every interruption deserves a human.
Email confirmation is the interesting row. It looks like a wall and is not one — it is an asynchronous step the pipeline already knows how to wait on, so the agent parks the submission, watches the campaign mailbox, follows the link, and resumes. A rate-limit response is the opposite: it halts the whole publisher, not just the attempt, because retrying is how a soft block becomes a hard one.
Detection is the hard part, not solving
Recognising a challenge the agent has never seen is a genuinely harder engineering problem than solving one. We look for known widget hosts in the page's network requests, for the iframe origins and data attributes the major providers render, and for the accessibility labels they attach. That catches the well-behaved cases.
The rest are caught after the fact, by a post-submit assertion. If the agent presses submit and the page neither navigates nor produces a success signal, that is treated as an unresolved challenge rather than a completed submission. The default on ambiguity is always to stop and ask.
That default matters more than the detector's accuracy. A false positive costs an operator thirty seconds. A false negative writes a submission into the report that never happened, and the client finds it before you do.
What the operator actually sees
The hand-off is only acceptable if it is cheap. When the agent freezes a submission it attaches the live URL, a screenshot of the page as rendered, and the field-by-field values it had already entered. The operator opens a browser session that resumes at exactly that point, clears the challenge, and presses submit. Verification, evidence capture and reporting continue on the automated path from there.
The work left for the human is the part a human is uniquely required for, and nothing else. That is the whole design goal of the queue.
The throughput math, stated up front
If a fifth of a campaign's qualified inventory is challenge-protected, then a fifth of that campaign needs a person, and no amount of agent engineering changes it. We surface that estimate during campaign planning rather than discovering it as a stall two days in. An honest number at the start is a better product than an impressive number that quietly degrades.