Add experimental Parallel Responses subagent for DeepSeek Harness

[georgeatparallel]

Why we built this

We wanted to see if Parallel Responses could work as a research subagent inside DeepSeek Harness. The idea is simple: the parent hands off one complete research question, Responses works independently, and the parent gets back a cited answer.

If it worked well, the parent could delegate a substantial research job instead of managing many Search calls itself.

What this PR adds

This adds the opt-in @parallel-web/dsh-responses-subagent package and a parallel_research tool.

The parent sends one self-contained text prompt. The plugin makes one medium-effort Responses call and returns the final answer with citations. It does not send parent history, files, workspace state, tools, or ambient environment.

We kept v1 deliberately small: one-shot foreground research, cancellation, a two-request concurrency limit, a fixed timeout, and no retries or extra configuration.

How we tested it

We verified the package with unit tests, type checking, linting, builds, manifest and packed-artifact checks, a secret scan, installation and removal in a fresh Harness profile, live Responses calls, and cancellation coverage.

We then ran a matched evaluation against the unchanged Search plugin. Both arms used the same six research-heavy prompts, parent model, permissions, and time limit. The prompts covered:

• web-search APIs across OpenAI, Anthropic, Gemini, and xAI
• open-source agent integration targets
• the history of OpenAI's Responses API
• DeepSeek Harness changes from rc.6 to current master
• Responses API portability across Cloudflare, Azure, and OpenRouter
• choosing a hosted research API for 100 cited reports per day

Search could make as many calls as it needed. Responses had to make exactly one complete research call. We scored correctness, coverage, citations, synthesis, and directness, then manually checked five important claims from every answer against primary sources.

What we saw

Result	Search	Responses
Quality score	84	56
Prompt wins	3	0
Mean successful-run time	128.7s	128.5s
Provider calls	51	6
Parent requests	57	12
Provider failures	0	2

Three prompts had no winner: one was a tie, and two contained serious errors in both answers.

Responses clearly simplified orchestration, but it did not improve answer quality or speed. It often returned incomplete evidence from its single call, and it made serious mistakes around the Responses API timeline, Harness compatibility, and hosted-research pricing. Two of eight attempts failed and needed the only two allowed reruns.

Search was not perfect either. It made serious mistakes on Harness version history and Parallel pricing. The result is not that Search is always reliable. It is that parent-managed Search covered more of these research tasks and gave the parent more chances to repair missing evidence.

Known Responses spend for the six selected runs was $0.30 plus parent-model usage. Search provider cost was not exposed, so we do not have an honest total-cost comparison.

Recommendation

My recommendation is no-go for publishing this as a default tool or positioning it as a research-quality improvement over Search.

The implementation shape is still useful: it is small, private by default, and uses far fewer parent turns. I would keep it as an opt-in experiment only if that is cheap to maintain.

Before reconsidering, the Responses worker needs more reliable primary-source retrieval, especially for repositories and pricing pages, plus better provider reliability. Then we should rerun the same frozen prompts and require Responses to clearly beat Search without serious errors.