Field noteOct 31, 20266 min read1 source

OpenDuet merges a public-web research skill with Parallel, Exa and Firecrawl setup guidance

In one minute

OpenDuet has merged a change that activates and documents its existing public-web research skill for the primary Bot, with setup guidance for Parallel, Exa, and Firecrawl. For teams building agent workflows, the material value is not simply web search: it makes connector permissions, source URLs, and unattended-run policy part of the documented deployment decision.

What changed: OpenDuet merged a public-web research skill with setup guidance for Parallel, Exa and Firecrawl; the prior documents cover Parallel APIs, not this integration.

What happened

CopilotKit merged OpenDuet pull request #85 on October 28, 2026. The change addresses a gap identified by its author: OpenDuet already defined a research-public-web capability, but its primary Bot did not hold that skill, and the repository’s root guide did not explain how to configure web research. The merged pull request assigns the existing skill and adds a README link to a shared setup guide.

That guide covers three research providers already present in the catalogue: Parallel, Exa, and Firecrawl. Parallel is the worked example, but the implementation and review describe the capability through provider-neutral roles, @research/search and @research/fetch, rather than presenting it as one vendor’s feature. The pull request author disclosed employment in developer partnerships at Parallel. The material says tool access is still controlled by an administrator’s grants through PluginStore.callTool; assigning a skill to a Bot does not itself grant those tools.

The documentation work is paired with explicit security guidance. The pull request describes the risk that a read-capable research connector can send private information outward if an agent follows malicious instructions encountered in email or other content. One safer configuration is a separate research Bot that receives research-tool access but not mail access. Another is an action-policy rule that refuses web_fetch when the initiating context is a routine. The contributor says the guide now covers tool grants, the risk of private data leaving through read tools, a separate research Bot, and such a policy example.

The change also tightens how tools are represented and how research output is handled. Parallel catalogue entries list two reviewed read tools, while future tools default to write controls until reviewed. Research-task instructions require source URLs in the saved page, and page citations are exempted from the ordinary Chat word limit and source-note rule. HTTP and HTTPS URLs in pages and slide text render as links; HTML, unsafe schemes, and URLs containing embedded credentials remain plain text.

The author reports 234 passing local tests across nine page, research, catalogue, policy, selection, and task suites. App and server type checks, changed-file linting and formatting, and relative documentation-link checks also passed. The policy example was tested through the policy evaluator for search and fetch across all six provider entries. But the contributor explicitly says no live sample was completed against a running OpenDuet Bot because the test environment lacked an Intelligence project key and a model API key. Automated tests covered URL rendering and policy behavior, not a model-generated cited brief; upstream CI also required maintainer action before it could run.

What the archive adds

We have not covered this before; it opens a new thread.

Trend signal

This supports the pattern that skills become a portable capability layer. OpenDuet treats public-web research as an assignable skill described through roles, while keeping actual tool grants with administrators. The same change also shows the limits of portability: provider setup, review status, policy, and data exposure still determine whether a capability is safe to deploy.

Why now

The immediate trigger was a product gap rather than a new research-provider launch. The skill already existed, but the primary Bot lacked it and the root documentation lacked setup instructions. The merged change makes that dormant capability deployable while adding warnings about unattended routines and external reads.

Why it matters

A web-research agent is often introduced as a retrieval upgrade, but this pull request frames it as an authorization problem. Search and fetch calls may look read-only from the agent’s point of view, yet they can transmit context to external services. Teams cannot evaluate this addition only by asking whether it returns better briefs.

The practical consequence is to separate capability assignment from permissions review. A team can use a shared research skill and choose among Parallel, Exa, or Firecrawl, but should decide which Bot receives those connectors, what other private systems that Bot can read, and whether unattended routines may invoke them. Requiring source URLs in saved research pages also makes the desired output more inspectable than a short chat response with no provenance.

The change is modest, but it offers a useful deployment template: give research work a bounded role, grant tools explicitly, preserve sources in the artifact, and write runtime policy for automation paths. That is more operationally meaningful than enabling a generic “browse the web” toggle.

What happens next

  • OpenDuet maintainers or contributors will run and document a live cited research brief. (3 months, 55%). Watch for: an example task and saved page produced by a running Bot.
  • Deployments will use a separate research Bot or routine-specific fetch restrictions where private connectors are present. (6 months, 60%). Watch for: policy examples or packaged configurations that split research from mail and calendar access.

Limits and uncertainty

The source is a merged pull request and its review discussion, not an independent deployment evaluation. It establishes that the code and documentation were merged and that local tests passed, but it does not establish result quality, latency, cost, provider differences, or production reliability. Most importantly, it does not demonstrate that a live OpenDuet Bot can produce the promised sourced brief: no end-to-end model call was run in the described environment. The material also does not show how administrators will configure permissions in practice, how often routines invoke the connectors, or whether the suggested safeguards prevent every route for prompt-injected data exfiltration.

Skill to build now

Map each research connector as an outbound data path before enabling it. This week, create a separate agent identity for web research, list every private system that identity can read, and add a policy test for routine-triggered search and fetch calls. Then require research artifacts to retain their source URLs. This turns a vague connector review into four checkable questions: who can invoke it, what context it can access, where requests go, and whether another person can inspect the evidence.

Reader takeaway

OpenDuet’s new public-web research setup is useful because it makes a previously unassigned skill deployable across Parallel, Exa, and Firecrawl. Its more durable lesson is that web research is not just an agent feature: it is a permissioned outbound capability that needs explicit grants, runtime policy, and preserved source evidence.

Open question

Will a live OpenDuet run reliably create a cited research page when its ordinary Bot instructions otherwise limit source notes and response length?

Evidence / sources

  1. 1github.com/CopilotKit/OpenDuet/pull/85
All Field Notes

Next reads

Read next

Open the graph
  1. 01topicEvalsExplore the evals topic hub.
  2. 02topicContext EngineeringExplore the context-engineering topic hub.
  3. 03archiveField NotesOpen the latest editorial analysis.
  4. 04source ledgerSource LedgerInspect the public source evidence graph.
Who read this page?Machine requests, hidden until opened

Loading the privacy-safe route aggregate...

Open the JSON contract