Pick the search provider for the retrieval job, then pick the execution route for the risk. A good agent workflow separates those decisions: provider fit answers which search surface; Resolve and estimate answer which governed path can safely run this call now.
Start with the search job, not the logo
Web search APIs are not interchangeable once an agent loops over them. Some are better at semantic recall, some at answer packaging, some at SERP freshness, and some at index independence. The wrong abstraction is “best search API.” The right abstraction is “best search route for this repeat workflow.”
Semantic research
The agent needs concept-level matches, related pages, or research recall rather than a literal keyword result.
Watch: semantic score drift and source-evidence gaps
Agent-ready answer packaging
The loop wants cleaned snippets, depth controls, include/exclude domains, and answer-shaped retrieval for downstream synthesis.
Watch: over-trusting packaged answers without preserving raw source context
Fresh SERP-style lookup
The workflow depends on current public web ranking, news, local/fresh pages, or Google-like result ordering.
Watch: treating discovery-qualified SERP access as a verified governed execution lane
Independent index coverage
The agent should avoid dependence on one dominant search backend or needs privacy/index independence as part of the operator constraint.
Watch: ranking/coverage differences that change recall without an explicit fallback rule
Then route the call safely
A search comparison page can identify a candidate provider. It cannot prove that your current credential path, quota owner, result shape, denied-domain rule, and retry budget are safe for a live agent. That proof starts when the call becomes a capability route.
Name the search job
Write the job in one sentence: research a market, verify a URL, find recent incidents, enrich one company, or collect source-backed alternatives. The job decides the provider class before the score does.
Resolve before execution
Use a capability route such as search.query to check whether Rhumb has a current managed path. Resolve is a read/preflight step; it is not permission to spend budget or call every scored provider.
Estimate the rail
Estimate the concrete provider, credential mode, and cost envelope before the first paid or authorized call. If the estimate cannot name the rail, do not let the agent loop.
Preserve trace evidence
Keep query, normalized provider path, result count, denied domains, credential rail, budget owner, and source evidence together so a bad result can be debugged as retrieval drift, auth drift, quota pressure, or contract drift.
Use search.query as the bounded first workflow
If the workflow is “my agent needs web research,” do not wire a provider SDK directly into an unattended loop on day one. Resolve search.query, estimate the concrete rail, then execute only after the key or payment path is explicit.
1. Resolve
curl "https://api.rhumb.dev/v1/capabilities/search.query/resolve"2. Estimate
curl "https://api.rhumb.dev/v1/capabilities/search.query/execute/estimate"3. Execute
curl -X POST "https://api.rhumb.dev/v1/capabilities/search.query/execute" \
-H "X-Rhumb-Key: rhumb_live_..." \
-H "Content-Type: application/json" \
-d '{"body":{"query":"best CRM for seed-stage B2B SaaS","max_results":5}}'Broken free search MCPs are a routing problem, not a reason to widen authority
When free Google-search MCPs hit bot checks, the tempting fix is to swap in a browser-like workaround and let the agent keep going. That hides the real operator question: which bounded search lane can explain auth, quota, denial, fallback, and source evidence for this repeat workflow?
- Treat anti-bot breakage as route evidence, not as permission to give the agent a broader browser or scraper surface.
- Name whether the search job needs Google-like freshness, semantic recall, independent index coverage, or answer packaging before selecting the provider lane.
- Preserve quota owner, blocked-domain policy, result source URLs, retry budget, and fallback rule so a CAPTCHA, 429, or empty result does not become an unbounded research loop.
- If the route cannot explain denial and fallback in the trace, keep it in discovery mode instead of promoting it to a repeat execution path.
Preflight questions before the first repeat search
- What result shape does the agent need: URLs, answer text, snippets, highlights, crawled page content, or source-backed citations?
- What is the freshness boundary: today, last week, stable documentation, or evergreen conceptual recall?
- Which domains or result classes must be denied before provider calls happen?
- Which credential rail burns budget: governed Rhumb key, wallet/x402, BYOK, Agent Vault, or direct provider pinning?
- What retry rule prevents a bad query, empty result, 429, or provider outage from becoming a runaway research loop?
- What evidence would convince you the answer was routed safely enough to repeat tomorrow?
Common failure modes
Ranking confidence becomes execution confidence
A provider can be the right research pick and still be the wrong first managed execution rail for your workflow. Keep comparison, resolve, estimate, and execute as separate decisions.
Freshness beats source evidence
Fresh web results are useful only if the agent preserves source URLs and enough context to explain why a result was trusted, skipped, or denied.
One query turns into an unpriced loop
Agents rephrase, retry, fan out, and synthesize. Put result-count caps, retry budgets, and cost ceilings on the search job before the first unattended run.
Discovery-only providers get treated as callable
A scored service can be discoverable without being verified for the current governed execution path. That distinction should be visible to the agent before it chooses a route.