feat: add optional you.com research provider

[mouse-value-add]

Why

This project already has a dedicated research bridge, but today it assumes a Playwright-driven Perplexity flow. This keeps the default behavior intact and adds an optional You.com-backed research path for cases where a direct API integration is a better fit.

What changed

• added an optional provider setting to the research config
• added a You.com Research API path in ResearchBridge
• kept Perplexity as the default behavior
• documented the new env vars and setup
• added config and research-bridge test coverage for the new provider path

Setup

export AUTOMATED_LOOP_RESEARCH_PROVIDER=youcom
export YDC_API_KEY=your-key-here

Optional config:

{
  "perplexity": {
    "provider": "youcom"
  }
}

Usage

Existing usage stays the same. If the provider is set to youcom, research requests go through the You.com Research API instead of the Playwright browser flow.

Validation performed

• python3 -m pytest tests/test_config.py -q
• python3 -m py_compile research_bridge.py loop_driver.py config.py
• python3 -m pytest tests/test_research_bridge.py tests/test_config.py -q (blocked during collection in the existing test suite because tests/helpers.py uses float | None, which the local python3 interpreter does not support)

Fallback and error handling

• default behavior remains Perplexity unless the provider is explicitly switched
• missing YDC_API_KEY returns a clear MISSING_API_KEY error
• HTTP, timeout, and parse failures return explicit error codes

Tracking issue: youdotcom-oss/integration-tracking#39

Happy to adjust the shape if you'd prefer this setting to live under a more generic research section instead.

[intellegix]

Thanks @mouse-value-add — and the You.com team — this is a genuinely clean PR. A few things I appreciated on read-through:

• The provider abstraction keeps it fully opt-in: the default stays on the Playwright/Perplexity path unless someone explicitly sets AUTOMATED_LOOP_RESEARCH_PROVIDER=youcom. Zero impact on existing users — exactly the pattern I want for third-party providers.
• No new dependencies (stdlib urllib), explicit error codes that match the existing Result pattern, and you added both config and research-bridge test coverage. That's the bar.

One thing I want to get right before merging: the Research API returns a sources array alongside output.content, and content carries inline citation markers like [[1, 2]]. Right now the integration reads content and drops sources — so anyone who opts in gets research text with dangling [[1,2]] references that resolve to nothing. Since citation-backed answers are the whole value of the Research API, that's a user-visible gap worth closing.

Ask: surface sources (even a simple appended Sources: list works) — or, if you'd rather keep it minimal, strip the [[…]] markers before returning the text. Your call, since you know the response schema best.

Optional, only if you're already in there: you flagged the provider field living under the perplexity config block — I'd happily take you up on moving it to a neutral research section, but that's a nice-to-have, not a blocker.

Once the citations are handled I'm ready to merge, and I'll credit you and the You.com team in the changelog. Really appreciate the quality here — this is a great template for how integrations should land in the toolkit. 🙌