Skip to content

ID-71 Lane B — Third-party tooling sweep (2026-06-09)

Lane B of ID-71 {71.1}: evaluation of twelve third-party candidates from Liam’s collected notes. Every repo/site was checked live on 2026-06-09 (GitHub API metadata: stars, licence, created/pushed dates). Verdicts use the lane vocabulary: ADOPT-CANDIDATE (take into {71.2+} scoping), WATCH (re-check at a defined trigger), REJECT (drop, with reason recorded).

#CandidateWhat it actually is (verified)FitVerdict
1Graph-DB-backed ontology (NebulaGraph posts)Vendor thought-leadership for NebulaGraph Enterprise; the concept, not a toolPlatform (grounding)REJECT (vendor pitch; KG-in-Postgres first via ID-101)
2simplifaisoul/osirisOSINT world dashboard (“Palantir alternative”) — not security-awareness trainingNeitherREJECT
3MCPJam (MCPJam/inspector)MCP server/app testing + debugging platform, open-core Apache-2.0Dev-workflowADOPT-CANDIDATE
4Ontos-AI/knowhereSelf-hostable document extraction/parsing → agent-ready chunks + doc hierarchyPlatform (pipeline)WATCH
5rowboatlabs/rowboatPersonal “AI coworker” Electron app (email/calendar → local knowledge graph); 3rd pivotNeither (comparable product)REJECT
6strukto-ai/mirageUnified virtual filesystem for agents (mount S3/Drive/Slack/GitHub as one tree)Both (future in-platform agents)WATCH
7nexu-io/html-anythingAgentic single-file-HTML deliverable editor (WeChat/X/Zhihu export focus)NeitherREJECT
8Claude for Small Business (Anthropic)Free Cowork plugin: 15 agentic workflows + 15 skills + SMB connectorsBoth (pattern source)ADOPT-CANDIDATE (patterns, not dependency)
9iii-hq/iiiRust backend orchestration platform (Motia LLC rebrand); engine Elastic-2.0Platform (re-architecture)REJECT
10firstbatchxyz/watchmenSkill-mining over Claude Code/Codex session transcripts → reusable skills + CLAUDE.md briefsDev-workflowWATCH (cheap pilot possible)
11asupermemoryai/supermemoryHosted memory API + MIT SDK/client repo — engine is closed, self-host = enterprisePlatform user memoryWATCH
11bmoorcheh-ai/memantoTyped agent memory (MIT client) hard-wired to proprietary Moorcheh cloud DBPlatform/dev memoryWATCH (lean reject for platform)
12Raindrop (raindrop.ai) + raindrop-ai/workshopHosted agent observability ($15M seed, YC) + MIT local agent-eval debugger “Workshop”Dev-workflow now, platform laterADOPT-CANDIDATE (Workshop, dev-workflow scope)

1. Graph-DB-backed ontology — NebulaGraph posts

Section titled “1. Graph-DB-backed ontology — NebulaGraph posts”

What it actually is. Two NebulaGraph marketing/thought-leadership posts (“The Missing Link in Enterprise AI”, published 2026-06-04, and “From Theory to Production Reality”, 2026-05-25). Argument: ontology = “cognitive architecture”, graph DB = “operational engine”; LLM grounding needs deterministic semantics; four-stage maturity journey ending in NebulaGraph Enterprise Edition. Both posts are authored by the vendor and explicitly funnel to the commercial product. The underlying OSS DB (vesoft-inc/nebula, checked 2026-06-09) is genuinely mature: 12.2k stars, Apache-2.0, distributed C++ graph DB, last pushed 2026-05-18 — but it is a horizontally-scalable cluster product (metad/graphd/storaged daemons) built by vesoft (Chinese-origin vendor, enterprise arm).

KH derivation check. KH’s ontology approach derives from Jessica Talisman’s Ontology Pipeline (checked 2026-06-09), which is explicitly methodology-first: controlled vocabulary → metadata standards → taxonomy → thesaurus (SKOS) → knowledge graph. It does not mandate a graph database — semantic middleware (Graphwise, TopQuadrant) is named as enabling tooling only. The NebulaGraph posts agree on the destination (KG as grounding layer) but skip the discipline stages KH has already built and jump straight to “buy a graph cluster”.

Overlap with KH. KH already has the early pipeline stages live: DB-driven taxonomy (contexts/taxonomy-context.tsx, taxonomy_sync_state), lib/ontology/ (content-type registry, schemas, loader), entity machinery (lib/entities/ — aliases, dedup, temporal reconciliation, entity_pair_resolutions table), pgvector embeddings, and citations. Critically, the KG stage is already roadmapped on KH’s own terms: spec dir id-101-cocoindex-entity-relationship-extraction exists (entity/relationship extraction inside the cocoindex pipeline). The natural next stage is entity/relationship tables + recursive-CTE traversal in Supabase Postgres — single operational surface, RLS-governed, UK/EU residency already solved — not a second stateful cluster.

Verdict: REJECT (NebulaGraph adoption now; the concept continues via ID-101). The posts are a vendor pitch whose genuinely correct premise (KG grounding) KH already holds via Talisman’s pipeline. A dedicated graph DB introduces a second database to operate, secure, and keep residency-compliant for a one-developer team, solving a scale problem (billions of edges, multi-hop at ms latency) KH does not have. Build the KG stage in Postgres first (ID-101); re-open a graph-DB evaluation only if traversal queries demonstrably outgrow recursive CTEs/pg-native options. (Checked 2026-06-09.)

What it actually is. The one-liner in the notes is wrong — this is not a cyber-security-awareness tool. simplifaisoul/osiris is an “Open Source Global Intelligence Platform — Real-Time OSINT Dashboard — A Palantir Alternative”: a Next.js 16 + MapLibre GL consumer dashboard aggregating flight tracking, maritime AIS, CCTV, earthquakes, conflict maps, news feeds, crypto wallet tracing, and OFAC sanctions checks (demo: osirisai.live).

Maturity. MIT, 5,136 stars / 1,044 forks but created 2026-05-12 (<1 month old — pure hype velocity), single independent maintainer funded via Patreon, 172 commits, no releases. Last push 2026-06-09 (active). No company backing.

Fit/overlap. Neither platform nor dev-workflow. The only tangential relevance is KH’s sector-intelligence domain (lib/intelligence/ — feed-poller, relevance-scorer, RSS) — osiris’s feed-source list (sanctions, news APIs) is mildly interesting as a catalogue, but it’s a visualisation app, not a library, and its data sources are geo/military-OSINT, not UK SMB sector intelligence.

Verdict: REJECT. Mislabelled in the source notes; a one-maintainer, month-old consumer OSINT dashboard with no extractable component for KH. If a security-awareness add-on is still wanted, this is not it — that search needs to restart from scratch. (Checked 2026-06-09.)

3. MCPJam — mcpjam.com / MCPJam/inspector

Section titled “3. MCPJam — mcpjam.com / MCPJam/inspector”

What it actually is. MCPJam/inspector is a testing/debugging/eval platform for MCP servers, MCP apps, and ChatGPT apps: JSON-RPC + OAuth trace visibility, capability inspection (tools/resources/prompts/elicitation), multi-model LLM chat playground against your server, and an evals runner with CLI/SDK for CI. Runs as hosted app (app.mcpjam.com), desktop app, npx @mcpjam/inspector@latest, or Docker. (mcpjam.com itself 403’d WebFetch; verified via repo + docs.mcpjam.com.)

Maturity. 2,005 stars / 238 forks, created 2025-05-23, 3,868 commits, last push 2026-06-09 — very active. Licence is open-core: Apache-2.0 except /server/services and the evals route, which sit under a separate commercial licence (server/evals/LICENSE, “Copyright MCPJam Inc”). Backed by MCPJam Inc (runs YC-sponsored MCP hackathons; no public funding round found — checked 2026-06-09).

Fit/overlap. Dev-workflow only. KH already has 58 MCP tools, 4 MCP Apps, and a 3-layer eval harness (scripts/mcp-eval/: protocol-compliance 42 checks, response-quality 17, functional-correctness 37) — so MCPJam’s eval layer is largely redundant (and is the commercially-licensed part anyway). What KH lacks is exactly MCPJam’s free layer: interactive inspection/debugging — JSON-RPC traces, OAuth-flow debugging (KH’s remote MCP server auth path is a recurring pain point), and MCP-Apps rendering checks outside Claude Desktop. It’s the maintained successor-in-spirit to the bare @modelcontextprotocol/inspector.

Verdict: ADOPT-CANDIDATE (dev-workflow; local npx usage of the Apache-2.0 inspector core). Zero platform-data exposure when run locally against staging, immediate payoff for the ID-71 tool-consolidation work (58 → curated set needs fast interactive probing), and no overlap-conflict: KH’s own harness stays the CI source of truth while MCPJam covers the interactive gap. Avoid building on its evals module (commercial licence) — KH’s Layer 1/3/4 harness already covers that. (Checked 2026-06-09.)

What it actually is. Knowhere extracts, parses, and structures unstructured documents (PDF, Office, images, text) into “agent-ready” chunks, reconstructing document hierarchy and optionally building knowledge graphs for RAG. Python backend + workers, PostgreSQL/Redis, pluggable vector stores (Milvus/Qdrant/Chroma), VLM-based parsing (DeepSeek, Qwen-VL, OpenAI). Cloud API (knowhereto.ai) or Docker-Compose self-host.

Maturity. Apache-2.0, 1,128 stars / 110 forks, created 2026-04-30 and open-sourced 2026-05-07 — barely a month public, but shipping hard: 28 releases, latest 2026-06-04 (“ultra-long PDF support”), 1,475 commits, last push 2026-06-09. Backed by Ontos AI (commercial cloud API with free credits). Model lean is DeepSeek/Qwen-VL-first, which suggests a China-based team/cloud — fine for self-host, a residency question for their hosted API.

Fit/overlap. Platform (ingestion pipeline). Overlaps directly with KH’s working stack: cocoindex incremental pipeline + pdfplumber/trafilatura/pullmd. KH’s stack is deterministic-extraction-first; Knowhere’s differentiator is VLM-driven layout/hierarchy reconstruction for hard documents (scanned PDFs, complex tables, very long PDFs) — the exact category where pdfplumber degrades (relevant to bid/form ingestion, q_a_extractions). Self-hostability satisfies UK/EU residency, but it would add a second Python service + Redis + vector store alongside cocoindex, and its chunk/KG output would need mapping into KH’s canonical pipeline rather than replacing it.

Verdict: WATCH. Right problem, credible Apache-2.0 self-host story, but one month of public history is too little to take a pipeline dependency on, and KH’s current extractor mix isn’t the bottleneck today. Re-evaluate when (a) a concrete hard-PDF failure class shows up in ingestion QA, or (b) Knowhere reaches ~6 months of sustained releases. If trialled, self-host only; do not send SMB client documents to their cloud API. (Checked 2026-06-09.)

What it actually is. Rowboat is now an “open-source AI coworker, with memory”: a local-first Electron desktop app that connects Gmail/Google Calendar/meeting notes, builds a long-lived knowledge graph in an inspectable local Markdown vault, and drafts documents/preps meetings; BYO-model (Ollama or hosted), extensible via MCP tools. This is the company’s third product: customer-support agent → low-code multi-agent IDE (the “AI-powered multi-agent builder” most 2025 references describe, Show HN Apr 2025) → AI coworker (Show HN 2026). Same repo, repurposed.

Maturity. Apache-2.0, 14,940 stars / 1,530 forks (largely accumulated by the previous product), created 2025-01-13, last push 2026-06-09, 121 open issues. Y Combinator-backed. Active, funded — but two pivots in ~18 months is a stability signal.

Fit/overlap. Neither platform component nor dev-workflow tool — it’s an end-user desktop product that partially competes with KH’s value proposition (“structured personal/company knowledge accessible by AI”). Nothing is consumable as a library. Its design patterns are the only value: human-inspectable Markdown memory vault + KG over personal work data is a useful comparable for KH’s platform user-memory design ({11} below) and for MemPalace-style transparency.

Verdict: REJECT. Wrong shape (desktop app, not infrastructure), pivot-prone vendor, star count inherited from an abandoned product line. Note it as a comparable in the user-memory design doc, nothing more. (Checked 2026-06-09.)

What it actually is. Mirage is a unified virtual filesystem for AI agents: mount S3, Google Drive, Slack, GitHub, Redis etc. as one Unix-like tree so agents use cat/grep/cp across services instead of per-service APIs. Python (mirage-ai) + TypeScript (@struktoai/mirage-node/-browser) SDKs, CLI; integrations for OpenAI Agents SDK, Vercel AI SDK, LangChain, Pydantic AI.

Maturity. Apache-2.0, 3,112 stars / 218 forks, created 2026-05-06, first public release v0.0.1 on 2026-05-06, 287 commits, 84 open issues, last push 2026-06-09. Backed by strukto-ai (commercial company, strukto.ai). v0.0.1 + 1 month public = pre-production by its own versioning.

Fit/overlap. Potentially both, but only in the future tense. Dev-workflow: Claude Code already has native filesystem + MCP servers — Mirage adds little today. Platform: when KH ships in-platform agents, a uniform mount over Supabase Storage + client document sources could simplify tool surfaces (and is philosophically aligned with KH’s “reduce 58 tools’ cognitive overhead” note — a filesystem metaphor replaces N bespoke tools). Security model for multi-tenant SMB data behind a single mounted tree is the open question — RLS-equivalent enforcement at the VFS layer is unproven.

Verdict: WATCH. Genuinely interesting abstraction with real momentum, but v0.0.1-grade and KH has no in-platform agent runtime yet to plug it into. Re-check when KH scopes in-platform agents, or when Mirage hits a stable release with an auth/tenancy story. (Checked 2026-06-09.)

What it actually is. HTML Anything is an “agentic HTML editor”: your local coding agent (Claude Code, Cursor, Codex, etc.) converts Markdown/CSV/JSON into ship-ready single-file HTML across 75 skill templates × 9 surfaces (magazine, deck, poster, data report, “Hyperframes”…), with sandboxed iframe preview and one-click export to WeChat / X / Zhihu / PNG / HTML. Next.js 16 + React 19; from the team behind Open Design.

Maturity. Apache-2.0, 6,496 stars / 631 forks, created 2026-05-11 (<1 month), last push 2026-06-02 (a week quiet at check time), ~30 commits on main — star velocity far ahead of code depth. Self-described “early but real”.

Fit/overlap. Marginal. The nearest KH concern is deliverable generation (sales-proposal workspaces, product-guide workspaces, intelligence briefs) — but KH generates structured artefacts through its own template system (lib/templates/) tied to KB data and citations, not free-form HTML one-pagers. The export surfaces (WeChat/Zhihu/XHS) signal a Chinese-creator-economy target market, not UK SMB documents. As a dev-workflow toy for quick visual one-offs it’s harmless but adds nothing the existing agents can’t already do.

Verdict: REJECT. Wrong market, wrong artefact model (presentation-first single-file HTML vs KH’s data-grounded templated documents), and a month-old codebase whose stars outrun its substance. (Checked 2026-06-09.)

8. Claude for Small Business — claude.com/solutions/small-business

Section titled “8. Claude for Small Business — claude.com/solutions/small-business”

What it actually is. Anthropic’s SMB solution, launched 2026-05-13: a free one-click plugin inside Claude Cowork (desktop) bundling 15 prebuilt agentic workflows (payroll planning, month-end close, morning business brief, sales campaign execution…), 15 reusable skills, and connectors (QuickBooks, PayPal, HubSpot, Canva, DocuSign, Google Workspace, Microsoft 365, Slack). No extra product charge beyond the Claude licence; every workflow is owner-initiated with approval gates (“nothing sends, posts, or pays on its own”). No public GitHub repo is linked from the solution page; distribution is via the Claude plugin directory. (Checked 2026-06-09.)

Maturity. Anthropic first-party, weeks old but with a 10-city launch tour and full docs/workshops — as backed as it gets.

Fit/overlap. Both, as a pattern source — exactly as Liam’s note anticipates (sales-plugin reuse already audited for sales-proposals). It is simultaneously (a) the canonical example of what “curated workflow set + skills + connectors for an SMB” looks like — directly applicable to ID-71’s core problem (58 accreted MCP tools → outcome-first curated tooling; the supporting notes explicitly call for “start with the outcome a user wants and work backwards”), and (b) a channel/competitor shaping what KH’s SMB users will expect from Claude-native experiences. KH’s differentiation per the notes — structured, governed company knowledge feeding such workflows — is complementary: the SMB plugin has connectors to tools, not to a governed knowledge base; KH’s remote MCP server can be the knowledge-side counterpart.

Verdict: ADOPT-CANDIDATE (pattern reuse, not dependency). Concretely for {71.2}: mirror its structure — small named workflow set, owner-initiated approval gates, skills as the unit of reuse — when redesigning KH’s plugin/MCP surface; map each of the 15 workflows against KH’s domains to find which ones KH data can ground (briefs, proposals, procurement). Track it also as market signal: Anthropic is normalising the plugin+Cowork delivery model KH plans to ride. (Checked 2026-06-09.)

What it actually is. iii is a backend orchestration platform: a Rust engine where Workers (queues, agents, sandboxes…) register Functions behind stable identifiers and Triggers fire them, giving cross-service composition + observability “as if it were a single runtime”. SDKs for Node/Python/Rust/Go; console; workers catalogue (workers.iii.dev). Finding: the SPDX file identifies the supplier as Motia LLC — iii is the rebrand/successor of the Motia backend framework, carrying its accumulated stars.

Maturity. 17,783 stars / 1,176 forks, created 2025-01-02, 237 releases (0.19.0 on 2026-06-06), 1,764 commits, last push 2026-06-09 — very active. Licensing is split: engine Elastic License 2.0 (not OSI-approved; no managed-service offering, but internal use fine), SDKs/CLI/console Apache-2.0. GitHub API reports licence “None” because of the composite.

Fit/overlap. Platform infrastructure — and that’s the problem. KH’s backend is deliberately boring and already operational: Vercel (Next.js API routes), Supabase (DB/auth/RLS/queues-by-table), and the on-prem Python cocoindex pipeline (Coolify/IONOS). Adopting iii means inserting a new stateful Rust engine between all of them — a wholesale re-architecture with no current pain it solves; KH has no microservice-sprawl problem (it has the opposite: a one-developer team that benefits from fewer moving parts). Elastic-2.0 on the engine also adds licence diligence for any future managed/multi-tenant angle.

Verdict: REJECT. Impressive project, wrong stage and wrong shape for KH: pre-launch platform priorities are consolidation, not runtime replacement, and the Motia→iii rebrand plus Elastic-2.0 engine warrant caution about strategic churn. Nothing here is adoptable piecemeal — it’s all-or-nothing infrastructure. (Checked 2026-06-09.)

What it actually is. Watchmen is a skill-mining system: it continuously captures coding-session transcripts from Claude Code, Codex, pi.dev, and OpenCode, analyses recurring procedures with LLMs, and auto-generates reusable skill bundles and workspace briefs (CLAUDE.md/AGENTS.md) that travel across agents. Python 3.11 + uv, FastAPI “mission control” dashboard, local SQLite, scheduled via launchd/systemd.

Maturity. MIT, 223 stars / 19 forks — by far the smallest candidate — created 2026-05-10, latest release v0.6.7 (2026-05-22), 255 commits, last push 2026-06-09. Backed by FirstBatch (firstbatchxyz — the agent-tooling org behind Dria); no dedicated funding signal for Watchmen itself.

Fit/overlap. Dev-workflow only. Direct hit on Liam’s nominated use: KH’s workflow-evaluation setup (evaluator-efficiency-sweep skill, workflow-evaluator lane) measures inefficiency in archived sessions; Watchmen attacks the complementary half — turning recurring session patterns into skills automatically. KH already has a large hand-curated skill estate plus create-skill/update-skill hooks, so the risk is skill-sprawl in the opposite direction (auto-generated skills competing with curated ones). Data note: it ships transcripts to an LLM provider for analysis — acceptable for dev-workflow transcripts, but configure providers consciously; storage itself is local SQLite.

Verdict: WATCH (with a cheap pilot allowed). MIT + local-first + tiny blast radius makes a one-week trial against KH’s archived session corpus nearly free, and its output could feed the evaluator-efficiency-sweep’s “redundant dispatch” findings with concrete skill candidates. But 223 stars / one month of life is too immature to wire into the standing workflow; revisit after the ID-71 tooling consolidation lands, when “which skills should exist” is a sharper question. (Checked 2026-06-09.)

11. Memory: supermemoryai/supermemory + moorcheh-ai/memanto

Section titled “11. Memory: supermemoryai/supermemory + moorcheh-ai/memanto”

What it actually is. Supermemory is a memory/context engine for AI: fact extraction from conversations, temporal contradiction handling, automatic forgetting, ~50ms user profiles, hybrid RAG+memory search, connector sync (Drive/Gmail/Notion/GitHub), multimodal ingestion. Verification finding: the 26.3k-star MIT repo contains the web app, browser/Raycast extensions, MCP server, docs, and SDKs (apps/: web, mcp, extensions; packages/: sdk/hooks/ui) — the memory engine itself is not in the repo. Independent 2026 comparisons describe the engine as closed source with self-hosting only via enterprise agreement (Docker-based, in-VPC, negotiated). Cloudflare-stack (Workers/KV), VC-backed “research lab”; very active (last push 2026-06-09).

Fit/overlap. Platform user memory (and conceivably dev-workflow memory). KH’s ratified position matters here: the MemPalace wrapped pattern is deferred post-launch and the direct pattern is ratified — i.e. platform user memory is to be built directly on KH’s own Supabase substrate, where RLS, UK/EU residency, and the existing taxonomy/ontology grounding already live. Supermemory as a hosted API would route SMB client memory through a third-party US/global Cloudflare service — a residency and data-processing-agreement burden KH doesn’t need; the enterprise self-host path is disproportionate for KH’s stage.

Verdict: WATCH. Best-in-class product signal and the strongest design reference for the direct-pattern build (profile/fact schema, forgetting, temporal reconciliation — note KH already has lib/entities/temporal-reconciliation.ts pointing the same way). But “MIT, 26k stars” materially overstates what is adoptable: the open part is the shell, not the engine. Revisit post-launch when platform user memory is scoped; until then mine its docs/API shape, not its service.

What it actually is. MEMANTO (Moorcheh.ai) is an “active memory” agent layer — remember / recall / answer over typed semantic categories with an information-theoretic retrieval engine, backed by a peer-reviewed paper (arXiv:2604.22085). MIT Python client, local REST server (memanto serve), Docker support, integrations for Claude Code/Cursor/etc. Verification finding: retrieval runs on Moorcheh’s proprietary “no-indexing” semantic database — a Moorcheh API key is required even when self-hosting the wrapper. Sovereign in-VPC deployment of the full Moorcheh stack exists but is an enterprise sales motion (moorcheh.ai).

Maturity. 733 stars / 271 forks (an unusually high fork:star ratio — likely integration-template forking), created 2026-03-23, 18 releases (latest 2026-06-09), 105 open issues / 98 PRs — active but young, and the OSS part is a thin client over a closed cloud.

Fit/overlap & verdict: WATCH (lean REJECT for platform). For platform user memory it has the same disqualifier as supermemory but worse: the core capability is a proprietary third-party cloud dependency, vs KH’s ratified Supabase-direct pattern. For dev-workflow memory, MemPalace already covers the role. The durable value is the typed-memory-schema + information-theoretic-retrieval research — read the paper when designing KH’s direct-pattern memory taxonomy; don’t take the dependency. (Both checked 2026-06-09.)

12. Raindrop — raindrop.ai + raindrop-ai/workshop

Section titled “12. Raindrop — raindrop.ai + raindrop-ai/workshop”

What it actually is. Raindrop is “Sentry for AI agents”: hosted observability that captures agent traces (messages, tool calls, retries, errors), auto-detects silent failures (hallucinations, loops), pipes issues to Slack, and runs A/B experiments on fixes. Pricing $59/mo (Startup) → $399/mo (Pro) + per-event fees; self-hosting in beta for own-cloud deployment; edge PII redaction; Snowflake/BigQuery export at enterprise tier. Strongly backed: $15M seed led by Lightspeed, YC, Vercel/Figma Ventures and founder angels; customers include Vercel, Framer, Clay.

The open-source version is raindrop-ai/workshop: a local debugger + eval harness for coding agents — live token-by-token trace streaming, every tool call/decision visible, and a “self-healing eval loop” where the agent (Claude Code is a first-class integration) writes evals, finds failures, fixes, retries. MIT, TypeScript/Bun/Drizzle/Vite, 873 stars / 44 forks, created 2026-05-01, 16 releases (v0.1.15, June 2026), last push 2026-06-04. Same binary talks to Raindrop Cloud via separate MCP servers, so local use has no cloud dependency.

Fit/overlap. Two distinct fits. (a) Dev-workflow, now: Workshop slots directly into KH’s workflow-evaluator lane — KH’s evaluator-efficiency-sweep computes corpus-level metrics over archived sessions; Workshop adds live per-run trace inspection + agent-authored evals, with MIT licence and local-only data. It also complements (not duplicates) the MCP eval harness, which tests the server, while Workshop observes the agent. (b) Platform, later: in-platform agents serving SMB client data would need observability with UK/EU residency — Raindrop’s hosted product is US-cloud-default and self-host is beta/enterprise, so that decision is premature.

Verdict: ADOPT-CANDIDATE (Workshop, dev-workflow scope only). Low-risk, MIT, local, purpose-built for exactly the Claude Code-centric evaluation loop KH runs, from a well-funded team likely to keep maintaining it; the obvious caveats are youth (5 weeks public, 31 commits on main) and the strategic intent that Workshop funnels users to the paid cloud — keep usage local and avoid coupling KH’s eval artefacts to Raindrop-proprietary formats. Hosted Raindrop for future in-platform agents stays a separate, deferred decision (re-check when self-host exits beta or an EU region ships). (Checked 2026-06-09.)


  1. Hype-velocity cohort. Seven of the twelve candidates (osiris, knowhere, mirage, html-anything, watchmen, memanto, workshop) were created in March–May 2026. Star counts in this cohort measure launch marketing, not durability — every WATCH verdict above carries an implicit “re-check after ~6 months of sustained releases”.
  2. “Open source” needs verification per candidate. Three candidates’ headline licences overstate adoptability: supermemory (MIT shell, closed engine), memanto (MIT client, proprietary cloud core), MCPJam (Apache-2.0 core, commercial evals module), and iii splits Elastic-2.0/Apache-2.0. None of this was visible from the one-liners.
  3. Residency pattern. Every platform-side memory/observability candidate defaults to US/global cloud with self-host as an enterprise upsell. This consistently reinforces KH’s ratified direct-on-Supabase pattern for anything touching SMB client data.
  4. The two ADOPT-CANDIDATEs are both dev-workflow + zero-data-risk (MCPJam inspector local, Raindrop Workshop local) plus one pattern-source (Claude for Small Business). Nothing in this sweep justifies a platform-architecture change — which is itself a useful ID-71 result: the platform gaps (KG stage, user memory) already have in-house paths (ID-101, direct pattern).