Keenable proposes keyless search integrations across three agent runtimes

Keenable is seeking distribution through three agent runtimes at once. September 7 pull requests in ZeroClaw, PicoClaw and OpenFang propose a keyless search API alongside an optional keyed path. Each inspected proposal discloses the contributor's employment at Keenable. The story is coordinated vendor integration work, not three independent endorsements, and none of the captured PRs establishes a shipped default across the projects.

The facts

- The ZeroClaw proposal leaves DuckDuckGo as the default and contacts Keenable only when the operator selects that provider. - PicoClaw's proposed integration is disabled by default and enters its automatic provider chain only after explicit enablement. - OpenFang's proposal places Keenable after configured keyed providers and SearXNG but before the DuckDuckGo HTML-scraping fallback. - All three use a public search endpoint without a key and a separate keyed endpoint when credentials are configured. - Each keyless request includes a fixed application-title header identifying the runtime, alongside the query sent to the external service. - OpenFang additionally proposes a bundled hosted MCP integration exposing search and page-fetch tools; this is distinct from its native search provider.

Why it matters

Keyless access removes a common first-run obstacle without removing an external service dependency. For small agent installations, a structured API may be easier to operate than scraping search-result HTML, especially when that scraper is blocked. But automatic fallback policy determines who receives a query when another provider is unavailable. The three proposals illustrate why integration counts are a poor proxy for adoption: identical vendor outreach can land in very different privacy and configuration contracts. An operator with existing search keys may see no routing change, while a keyless OpenFang installation could contact a new service automatically under the proposed ordering.

Current

Inspected on 2026-09-08. The ZeroClaw stable-release baseline is v0.8.5 published 2026-09-05T07:31:19Z. The PicoClaw baseline is v0.3.1 published 2026-07-03T07:37:06Z. The OpenFang baseline is v0.6.9 published 2026-05-12T18:42:42Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.

Evidence

The primary source is zeroclaw-labs/zeroclaw PR #10679 (https://github.com/zeroclaw-labs/zeroclaw/pull/10679). Supporting context comes from sipeed/picoclaw PR #3370 (https://github.com/sipeed/picoclaw/pull/3370); RightNow-AI/openfang PR #1286 (https://github.com/RightNow-AI/openfang/pull/1286); Keenable — API reference (https://docs.keenable.ai/api-reference). The linked records were inspected directly; related project records are not independent confirmations.

Operator take

Review the provider order before testing these branches. Use non-sensitive queries and verify which endpoint was selected, how rate limits appear and whether failure reaches the next provider or returns an honest error. The PRs report live keyless smoke checks, but those measurements are not a comparative benchmark or availability guarantee. A configured API key changes the request path; it does not make retrieved content trustworthy. Keep the distinction between native search and a separately installed MCP server visible in deployment notes, since they create different tool surfaces. This cluster merits watching as a distribution strategy aimed at fresh installs, not as proof that the three projects have chosen a new search standard.

Caveat

All three integrations were open proposals when inspected. They come from a disclosed vendor-affiliated contributor; reported latency, quota and smoke-test outcomes were not independently reproduced, and no sensitive query was sent to the service during curation.