Use Parallel web search by default in OpenTag

[RowanAldean]

I work in developer partnerships at Parallel.

This configures Parallel as the default web search provider in OpenTag's shipped setup. With no extra search credentials, the agent can discover public sources and read selected URLs through Parallel's free Search MCP. WEB_SEARCH_PROVIDER=none disables these tools; WEB_SEARCH_PROVIDER=tavily explicitly selects the existing Tavily integration and requires its API key. Existing Tavily credentials alone no longer choose the provider.

Parallel Fast is on the cost–quality Pareto frontier for DeepSearchQA, making it a strong choice for web research in this workflow.

The change keeps one primary web_search tool, adds follow-up web_fetch for Parallel, preserves source links and partial failures, and documents that tool queries, research objectives and requested URLs are shared with the selected service. An optional PARALLEL_API_KEY supports authenticated use. Internal-source permissions and write approvals stay in the existing application flow.

Validation

• Python suite: 560 tests passed, including default/override/disabled tool registration, input validation, bounded source results, partial extraction and cancellation. Compiled-graph regressions cover both tools through the real MCP transport with simulated HTTP 429, timeout, malformed responses and MCP errors; extraction failures preserve error type and HTTP status.
• Runtime: type check and 436 tests passed; Railway configuration generated successfully.
• AWS deployment template: type check and 19 tests passed, including provider selection and opt-in secret injection.
• Live free-tier smoke: one synthetic search returned five sources and one follow-up fetch succeeded, without warnings or errors.
• Authenticated Parallel calls, live Tavily, Slack/Teams delivery and deployment were not exercised.

[jerelvelarde]

Reviewed commit e5c6878. Two actionable findings:

1. [P2] Provider failures abort the entire agent turn — agent/parallel_tools.py:63–66

   _call_parallel raises RuntimeError for provider failures. The current tool middleware rethrows these exceptions, and LangGraph's default tool error handler does not convert them into model-visible tool errors. I reproduced this with a simulated HTTP 429 through the real MCP transport and a compiled ToolNode graph: the graph aborted with RuntimeError instead of returning an error the model could explain or retry. Please return a sanitized error result or handle these expected provider failures in middleware, and add a graph-level regression test.

2. [P2] Extraction failure details are discarded — agent/parallel_tools.py:97

   Normalization reads error and message, but the live MCP server returns error_type and http_status_code. A live fetch of a nonexistent example.com page returned {"error_type":"http_error","http_status_code":404,"content":null}, which became only "Extraction failed". This prevents the agent from distinguishing missing pages from retryable failures. Please preserve the error type and HTTP status, and test the actual response shape.

Validation run against this commit:

• pnpm check-types — passed.
• pnpm test — 436 passed.
• (cd agent && uv run --frozen pytest) — 547 passed.
• node node_modules/railway/dist/iac/bin.js — configuration generation passed.
• AWS deployment pnpm build and pnpm test — type check passed; 19 tests passed.
• Anonymous MCP tool discovery and fetch exercised; simulated 429 and live 404 checked.

Authenticated Parallel, live Tavily, Slack/Teams delivery, and deployment were not exercised.

[RowanAldean]

Thanks, Jerel. Both findings are addressed in 3ea17e0. Provider failures now return sanitized tool results without aborting the turn, and extraction errors preserve error_type and http_status_code.

Added graph-level regressions for both tools, including simulated 429s and timeouts, plus the reported 404 response shape. All 560 Python tests pass. Could you take another look for approval?

[jerelvelarde]

Re-reviewed current head 3ea17e0, part of this PR, following the two findings in the earlier review.

Both findings are resolved:

• Provider failures now return sanitized, model-visible tool results rather than aborting the turn. The compiled-graph regressions exercise both tools through the real MCP transport, covering 429s, timeouts, malformed responses, and MCP tool errors. Cancellation still propagates.
• Extraction errors retain error_type and http_status_code, including the reported 404 response shape, alongside successful source results.

I found no remaining merge-blocking issues in the reviewed changes. This clears the two earlier code-review concerns; please wait for the remaining required CI checks before merging.

Validation re-run against this head:

• cd agent && uv run --frozen pytest -q — 560 passed.
• pnpm check-types — passed.
• pnpm test — 436 passed.
• node node_modules/railway/dist/iac/bin.js — configuration generation passed.
• AWS deployment pnpm build and pnpm test — type check passed; 19 tests passed.

This follow-up used simulated provider failures; I did not re-run live provider calls, authenticated Parallel/Tavily usage, Slack/Teams delivery, or a deployment.

[jerelvelarde]

Re-reviewed commit 3ea17e0. Both previous findings are addressed: provider failures now reach the model as sanitized results, and extraction failures preserve error_type and http_status_code. The compiled-graph regressions exercise both tools through the real MCP transport for rate limits, timeouts, malformed responses, and tool errors. No additional actionable findings.

Fresh validation passed: pnpm check-types; pnpm test (436 tests); agent uv run --frozen pytest (560 tests); node node_modules/railway/dist/iac/bin.js; AWS pnpm build and pnpm test (19 tests). GitHub CI is also green.

Authenticated Parallel, live Tavily, Slack/Teams delivery, and deployment were not exercised.