[Feature] Define one provider-neutral web search capability contract #28

What outcome should OpenMuse handle?

OpenMuse should expose one stable public-web search capability to its agents even when the backing provider changes.

There are currently two open implementations of the same search_web capability:

• Add Parallel as the built-in web search provider #22 adds Parallel through a shared SearchService, with input shaped as { objective, search_queries[] } and results shaped around URLs/titles/excerpts/warnings/truncation.
• feat: add optional you.com search integration #26 adds You.com directly in the conversation agent, with input shaped as { query, count } and a different result shape.

Both are reasonable provider integrations, but the fact that two contributors independently needed the same tool name with incompatible contracts suggests that provider identity is leaking into the agent-facing capability boundary.

Proposed behavior

Define one small, provider-neutral search_web contract owned by OpenMuse, then put provider adapters behind it.

The important invariant would be:

agent capability identity != provider identity

A minimal version could standardize:

• one request schema for the model-facing tool;
• one bounded result schema with source URL, title, excerpt/snippet, optional publication metadata, warnings, and truncation;
• cancellation/deadline behavior;
• treatment of results as untrusted evidence rather than authority;
• how delegated tasks persist search evidence;
• provider selection/configuration separately from the tool contract.

This does not need a generic plugin framework. A narrow SearchProvider/adapter seam would be enough if that is the smallest shape that keeps the model/tool contract stable.

That would let Parallel, You.com, or a future provider compete behind the same capability without changing prompts, model schemas, persisted evidence, or tests each time.

How would we verify it works?

• Contract-test at least two provider adapters against the same request/result fixtures.
• Run the same native-chat and delegated-task test against each adapter.
• Verify provider failures remain visible rather than becoming empty success.
• Verify cancellation and response-size bounds are preserved.
• Verify delegated-task evidence has the same shape regardless of provider.
• Verify changing providers does not change the model-visible tool schema.

This seems worth agreeing on as an issue first because it affects connector placement and architecture, per CONTRIBUTING.md.

AI-use note: I used an AI assistant to compare the current #22/#26 implementations and draft this issue; I verified the incompatible schemas and runtime placement against their current PR heads before filing.