Molecule AI Research Lead 1811719286 chore(eco-watch): 2026-04-17 daily survey — dimos, Cloudflare Workers AI

Two new LOW-tier entries:
- dimos (dimensionalOS/dimos, 2.9k⭐, v0.0.11, MIT) — agentic OS for
  robotics; MCP as primary agent interface; module/blueprint architecture
  with typed stream passing; spatio-temporal RAG memory; hardware:
  Unitree/AgileX/DJI/MAVLink. Watch for A2A support.
- Cloudflare Workers AI (Agents Week 2026) — unified inference layer:
  70+ models, 14+ providers, auto-failover, streaming resilience, 330
  global PoPs. Part of Cloudflare full-stack agent platform (+ Durable
  Objects + Artifacts + Agents SDK + AI Search). Separate from previously
  tracked Cloudflare Artifacts entry. Escalate to MEDIUM if Agents SDK
  integrates all four primitives into one-click multi-agent deployment.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-04-17 02:55:34 +00:00

173 KiB

Raw Blame History

Ecosystem Watch

Projects adjacent to molecule-monorepo that are worth tracking — for design ideas to borrow, terminology collisions to be aware of, and to stay honest about where our differentiation actually is.

How to use this doc

Skim quarterly. The agent-infra space moves fast; expect entries to be stale within ~3 months. When a project on this list ships something we should react to, add a line under "Signals to react to" for that entry and a short plan.
Add entries liberally. Easier to prune than to miss.
One entry per project. Keep each under ~200 words — link out, don't duplicate.

Template

### <Project> — `org/repo`

**Pitch:** one sentence in their words.

**Shape:** what it actually is (language, deployment target, one-vs-many-agents, etc.)

**Overlap with us:** where our designs touch.

**Differentiation:** why we're not the same product.

**Worth borrowing:** specific ideas we should study.

**Terminology collisions:** shared words that mean different things.

**Signals to react to:** what they might ship that would change our roadmap.

**Last reviewed:** YYYY-MM-DD · **Stars / activity:** <quick stat>

Competitor Snapshot

Machine-readable index for PMM cron diffing. One YAML entry per competitor — the cron diffs this block to detect version bumps, threat escalations, and new notable_changes, then updates docs/marketing/competitors.md.

Maintenance rule: whenever you update a narrative entry below, also bump the corresponding date, version, and notable_changes fields here.

Fields: name · slug · date (last reviewed) · version · stars · threat_level (high / medium / low) · notable_changes (≤ 2 sentences) · source_url

# competitor-snapshot
# Generated: 2026-04-17 | Maintainer: Research Lead
# PMM cron reads this block, diffs vs. previous commit, updates docs/marketing/competitors.md.
# Update date + version + notable_changes whenever a competitor ships something significant.

snapshots:

  # ── HIGH THREAT ────────────────────────────────────────────────────────────────────
  # Direct substitutes or major market-erosion risk for Molecule AI.

  - name: Paperclip
    slug: paperclip
    date: "2026-04-17"
    version: "v2026.416.0"
    stars: "54.8k"
    threat_level: high
    notable_changes: >
      v2026.416.0 (Apr 16 2026) ships assistant-ui chat threads for agent
      transcripts, execution policies for multi-stage approvals, and blocker
      dependencies with auto wake-on-resolve — mirrors our PM→Dev→Eng
      delegation model with "zero-human companies" framing; 54.8k ⭐ in 6 weeks.      
    source_url: https://github.com/paperclipai/paperclip/releases

  - name: OpenAI Agents SDK
    slug: openai-agents-sdk
    date: "2026-04-17"
    version: "v0.14.1"
    stars: "14k"
    threat_level: high
    notable_changes: >
      v0.14.1 (Apr 15 2026) patches tracing export on top of v0.14.0's
      SandboxAgent beta — persistent isolated workspaces, snapshot/resume,
      and sandbox memory directly competing with our workspace lifecycle model.      
    source_url: https://github.com/openai/openai-agents-python/releases

  - name: CrewAI
    slug: crewai
    date: "2026-04-17"
    version: "v1.14.1"
    stars: "48k"
    threat_level: high
    notable_changes: >
      Deep-dive 2026-04-17: Crew Studio is a real node-and-edge drag-and-drop
      canvas (workflow design paradigm, not governance — no org hierarchy, no
      auth audit trail). AMP Factory self-hosted confirmed: on-prem/private VPC,
      K8s, FedRAMP High certified. A2A spec v0.3.0 first-class (client+server,
      matches Molecule AI a2a-sdk==0.3.25) — zero-shim interop confirmed;
      CrewAI agents recruitable as Molecule AI workers today. v1.0.0 migration
      (Mar 2026 spec) not yet adopted by either side — shared upgrade clock.
      ICP unchanged: moat is governance-layer canvas (#582), not visual canvas
      alone. File FedRAMP gap as enterprise procurement tracking issue.      
    source_url: https://github.com/crewAIInc/crewAI/releases

  - name: Google ADK
    slug: google-adk
    date: "2026-04-17"
    version: "v1.30.0"
    stars: "19k"
    threat_level: high
    notable_changes: >
      v1.30.0 (Apr 13 2026) adds Auth Provider support to the agent registry,
      Parameter Manager integration, and Gemma 4 model support; v2.0.0a3
      pre-release introduces a graph-based execution engine.      
    source_url: https://github.com/google/adk-python/releases

  - name: Microsoft Agent Framework
    slug: microsoft-agent-framework
    date: "2026-04-17"
    version: "python-1.0.1"
    stars: "9.5k"
    threat_level: high
    notable_changes: >
      python-1.0.1 (Apr 10 2026) ships FileCheckpointStorage security hardening;
      v1.0 GA is the official AutoGen successor with SOC 2/HIPAA compliance,
      .NET + Python support, and a Process Framework GA planned for Q2 2026.      
    source_url: https://github.com/microsoft/agent-framework/releases

  # ── MEDIUM THREAT ──────────────────────────────────────────────────────────────────
  # Significant overlap in adjacent space; no direct substitution risk today.

  - name: Dify
    slug: dify
    date: "2026-04-17"
    version: "v1.13.3"
    stars: "60k"
    threat_level: medium
    notable_changes: >
      Latest stable is v1.13.3 (Mar 27 2026); v1.14.0 RC adds Human Input
      node (HITL); raised $30M Pre-A (Mar 2026, $180M valuation) with
      280 enterprise deployments — no-code positioning targets business users,
      not our developer audience.      
    source_url: https://github.com/langgenius/dify/releases

  - name: LangGraph
    slug: langgraph
    date: "2026-04-17"
    version: "v1.1.6"
    stars: "29k"
    threat_level: medium
    notable_changes: >
      langgraph-cli v0.4.22 (Apr 16 2026) adds deploy source tracking;
      core v1.1.6 (Apr 10 2026) ships LangGraph 2.0 declarative guardrail nodes;
      LangGraph Cloud hosted execution competes with our scheduler.      
    source_url: https://github.com/langchain-ai/langgraph/releases

  - name: VoltAgent
    slug: voltagent
    date: "2026-04-17"
    version: "server-elysia@2.0.7"
    stars: "8.2k"
    threat_level: medium
    notable_changes: >
      @voltagent/server-elysia v2.0.7 (Apr 11 2026) fixes A2A agent card
      endpoints to advertise correct absolute URLs; VoltOps Console is the
      closest Canvas analogue in the TypeScript ecosystem.      
    source_url: https://github.com/VoltAgent/voltagent/releases

  - name: n8n
    slug: n8n
    date: "2026-04-17"
    version: "v2.17.2"
    stars: "50k"
    threat_level: medium
    notable_changes: >
      v2.17.2 (Apr 16 2026) improves AI Gateway credentials endpoint;
      n8n 2.0 (Dec 2025) added enterprise-grade AI Agent nodes, RBAC, SSO,
      and 400+ channel integrations — direct overlap with our workspace_channels.      
    source_url: https://github.com/n8n-io/n8n/releases

  - name: Claude Code Routines
    slug: claude-code-routines
    date: "2026-04-17"
    version: "cloud-feature"
    stars: "n/a"
    threat_level: medium
    notable_changes: >
      Launched Apr 14 2026 (research preview): Anthropic-hosted cron + GitHub-
      event-triggered Claude Code sessions running on Anthropic cloud; competes
      with our workspace_schedules; single-model, no org canvas.      
    source_url: https://code.claude.com/docs/en/routines

  - name: Scion
    slug: scion
    date: "2026-04-17"
    version: "active"
    stars: "early"
    threat_level: medium
    notable_changes: >
      Launched Apr 8 2026 — GCP experimental container-per-agent harness for
      Claude Code/Gemini CLI with parallel isolated workspaces and markdown
      workflow definitions; escalation risk to HIGH if productized by Google.      
    source_url: https://github.com/GoogleCloudPlatform/scion

  - name: Multica
    slug: multica
    date: "2026-04-17"
    version: "active-36-releases"
    stars: "12.8k"
    threat_level: medium
    notable_changes: >
      Positioned as open-source Claude Managed Agents alternative (Apr 2026);
      local daemon + central backend with pgvector semantic skill compounding;
      +1,503 stars/day at launch — no A2A or org canvas but similar architecture.      
    source_url: https://github.com/multica-ai/multica/releases

  - name: Cline
    slug: cline
    date: "2026-04-17"
    version: "active"
    stars: "44k"
    threat_level: medium
    notable_changes: >
      VS Code Claude Code extension with 44k ⭐ and MCP support; primary user
      overlap with our Claude Code workspace — developers who outgrow Cline's
      single-session model are our conversion path.      
    source_url: https://github.com/cline/cline/releases

  - name: ClawRun
    slug: clawrun
    date: "2026-04-17"
    version: "active-45-releases"
    stars: "84"
    threat_level: medium
    notable_changes: >
      Closest architectural match tracked — sandbox/heartbeat/snapshot-resume/
      channels/cost-tracking feature parity with us; 84 ⭐ but 45 releases
      shows active shipping; adding A2A would make this a direct lightweight
      competitor.      
    source_url: https://github.com/clawrun-sh/clawrun/releases

  - name: Gemini CLI
    slug: gemini-cli
    date: "2026-04-17"
    version: "v0.38.1"
    stars: "101k"
    threat_level: medium
    notable_changes: >
      v0.38.1 (Apr 15 2026) is a cherry-pick stability patch; 1M-token context
      + MCP support; runtime candidate for our workspace adapter — elevated to
      MEDIUM because it forms a full agent stack with Google ADK + adk-web.      
    source_url: https://github.com/google-gemini/gemini-cli/releases

  # ── LOW THREAT ─────────────────────────────────────────────────────────────────────
  # Tools, infra layers, single-agent tools, or products we use — not substitutes.

  - name: Hermes Agent
    slug: hermes-agent
    date: "2026-04-17"
    version: "v0.10.0"
    stars: "61k"
    threat_level: low
    notable_changes: >
      v0.10.0 (Apr 16 2026) launches Tool Gateway giving paid Portal subscribers
      built-in web search, image generation, TTS, and browser automation; no
      multi-agent or org hierarchy — personal AI shape, not platform competitor.      
    source_url: https://github.com/NousResearch/hermes-agent/releases

  - name: gstack
    slug: gstack
    date: "2026-04-17"
    version: "active"
    stars: "70k"
    threat_level: low
    notable_changes: >
      Viral Claude Code skills bundle with 70k ⭐; sequential single-session
      persona-switching — no persistent infra, Docker isolation, or A2A protocol;
      differentiation holds unless multi-session execution is added.      
    source_url: https://github.com/garrytan/gstack

  - name: Flowise
    slug: flowise
    date: "2026-04-17"
    version: "flowise@3.1.2"
    stars: "30k"
    threat_level: low
    notable_changes: >
      v3.1.2 (Apr 14 2026) delivers security hardening (CORS abuse, credential
      leaks, unauthorized access); acquired by Workday (Aug 2025) — repositioned
      for HR/finance enterprise, narrowing its developer-team market.      
    source_url: https://github.com/FlowiseAI/Flowise/releases

  - name: OpenHands
    slug: openhands
    date: "2026-04-17"
    version: "v1.6.0"
    stars: "47k"
    threat_level: low
    notable_changes: >
      v1.6.0 (Mar 30 2026) adds hook support and /clear command preserving
      sandbox runtime; jumped to v1.x series (was v0.39.0); SWE-Bench top
      open-source rank — single-agent software engineer, not a platform.      
    source_url: https://github.com/All-Hands-AI/OpenHands/releases

  - name: Temporal
    slug: temporal
    date: "2026-04-17"
    version: "v1.30.4"
    stars: "13k"
    threat_level: low
    notable_changes: >
      v1.30.4 (Apr 10 2026) patches CVE-2026-5724 MEDIUM authorization
      vulnerability; $300M Series D (Feb 2026, $5B valuation); we integrate
      Temporal as infra via workspace-template/builtin_tools/temporal_workflow.py.      
    source_url: https://github.com/temporalio/temporal/releases

  - name: Chrome DevTools MCP
    slug: chrome-devtools-mcp
    date: "2026-04-17"
    version: "active"
    stars: "35.5k"
    threat_level: low
    notable_changes: >
      Official ChromeDevTools org MCP server with 23 browser-control tools;
      replaces our bespoke Puppeteer CDP plugin — we adopt it as of issue #540.      
    source_url: https://github.com/ChromeDevTools/chrome-devtools-mcp

  - name: Composio
    slug: composio
    date: "2026-04-17"
    version: "active"
    stars: "18k"
    threat_level: low
    notable_changes: >
      250+ tool integrations with managed auth; potential skill-pack dependency
      for workspace channel integrations rather than a competing platform.      
    source_url: https://github.com/composio-dev/composio/releases

  - name: AgentScope
    slug: agentscope
    date: "2026-04-17"
    version: "v1.0.18"
    stars: "23.8k"
    threat_level: low
    notable_changes: >
      v1.0.18 (Mar 26 2026) from Alibaba/ModelScope with MsgHub typed routing
      and OpenTelemetry; MCP integration; no deployment layer — framework only.      
    source_url: https://github.com/modelscope/agentscope/releases

  - name: Skills CLI
    slug: skills-cli
    date: "2026-04-17"
    version: "active"
    stars: "14.2k"
    threat_level: low
    notable_changes: >
      Vercel-backed canonical agentskills.io install CLI covering 45+ agents
      including our Claude Code workspace; aligning plugins/ manifest to the
      agentskills.io spec gives us free distribution through this channel.      
    source_url: https://github.com/vercel-labs/skills

  - name: Archon
    slug: archon
    date: "2026-04-17"
    version: "v0.3.6"
    stars: "18.1k"
    threat_level: low
    notable_changes: >
      v0.3.6 active; YAML-DAG coding workflow with mixed AI/deterministic nodes
      and human approval gates; reference design for our workspace delivery
      pipelines — no multi-agent coordination.      
    source_url: https://github.com/coleam00/Archon/releases

  - name: Tencent AI-Infra-Guard
    slug: tencent-ai-infra-guard
    date: "2026-04-17"
    version: "v4.1.3"
    stars: "3.5k"
    threat_level: low
    notable_changes: >
      v4.1.3 (Apr 9 2026); red team platform scanning MCP server and skills
      surfaces — use as security compliance checklist for our MCP server and
      plugin registry hardening; not a runtime competitor.      
    source_url: https://github.com/Tencent/AI-Infra-Guard/releases

  - name: Holaboss
    slug: holaboss
    date: "2026-04-17"
    version: "active"
    stars: "1.7k"
    threat_level: low
    notable_changes: >
      Desktop "AI employee" with filesystem-as-memory and compaction boundaries;
      single-agent, no A2A — primary concern is terminology collisions
      (workspace / MEMORY.md / SKILL.md / agentskills.io).      
    source_url: https://github.com/holaboss-ai/holaboss-ai

  - name: claude-mem
    slug: claude-mem
    date: "2026-04-17"
    version: "active"
    stars: "56k"
    threat_level: low
    notable_changes: >
      SQLite FTS5 + Chroma hybrid cross-session memory with lifecycle hooks;
      56k ⭐ signals strong demand for the gap we need to close in agent_memories
      — adopt PostToolUse + SessionEnd observation pipeline.      
    source_url: https://github.com/thedotmack/claude-mem

  - name: Plannotator
    slug: plannotator
    date: "2026-04-17"
    version: "v0.17.10"
    stars: "4.3k"
    threat_level: low
    notable_changes: >
      v0.17.10 (Apr 13 2026); HITL plan annotation UX with structured feedback
      types (delete/insert/replace/comment); reference design for improving our
      approvals API response schema.      
    source_url: https://github.com/backnotprop/plannotator/releases

  - name: open-multi-agent
    slug: open-multi-agent
    date: "2026-04-17"
    version: "v1.1.0"
    stars: "5.7k"
    threat_level: low
    notable_changes: >
      v1.1.0 (Apr 1 2026); TypeScript multi-agent with runtime goal-to-DAG
      decomposition in 3 deps; ephemeral per-run — no persistent identity,
      no canvas, no scheduling.      
    source_url: https://github.com/JackChen-me/open-multi-agent/releases

  - name: Open Agents (Vercel)
    slug: open-agents-vercel
    date: "2026-04-17"
    version: "active"
    stars: "2.2k"
    threat_level: low
    notable_changes: >
      +1,020 stars in one day (Apr 15 2026); Vercel Labs reference app for
      background coding agents with snapshot-based VM resumption; no multi-
      agent coordination — reference template, not a platform.      
    source_url: https://github.com/vercel-labs/open-agents

  - name: GenericAgent
    slug: generic-agent
    date: "2026-04-17"
    version: "v1.0"
    stars: "2.1k"
    threat_level: low
    notable_changes: >
      v1.0 (Jan 16 2026); self-evolving skill tree with four-tier memory
      hierarchy (L0 rules → L4 session archives); single-agent, no A2A —
      memory taxonomy worth borrowing for agent_memories scopes.      
    source_url: https://github.com/lsdefine/GenericAgent/releases

  - name: OpenSRE
    slug: opensre
    date: "2026-04-17"
    version: "active"
    stars: "900"
    threat_level: low
    notable_changes: >
      AI SRE toolkit with 40+ observability integrations (Grafana/Datadog/
      K8s/AWS/GCP/PagerDuty); potential DevOps workspace skill-pack source
      rather than a competing platform.      
    source_url: https://github.com/Tracer-Cloud/opensre

  - name: AMD GAIA
    slug: amd-gaia
    date: "2026-04-17"
    version: "v0.17.2"
    stars: "1.2k"
    threat_level: low
    notable_changes: >
      v0.17.2 (Apr 10 2026); AMD-backed local agent framework hardware-locked
      to Ryzen AI 300+ NPU; MCP support; not general-purpose.      
    source_url: https://github.com/amd/gaia/releases

  - name: Cognee
    slug: cognee
    date: "2026-04-17"
    version: "v1.0.1.dev1"
    stars: "15.8k"
    threat_level: low
    notable_changes: >
      Hybrid graph+vector knowledge engine for agent memory; claude-code plugin
      + Hermes Agent native integration; cross-agent knowledge sharing with
      tenant isolation; reference design for closing our agent_memories gap.      
    source_url: https://github.com/topoteretes/cognee/releases

  - name: Archestra
    slug: archestra
    date: "2026-04-17"
    version: "platform-v1.2.15"
    stars: "3.6k"
    threat_level: low
    notable_changes: >
      Enterprise MCP registry + dual-LLM security gateway (Apr 16 2026);
      centralized MCP server governance, Kubernetes-native, AGPL-3.0;
      reference design for our plugin registry governance story.      
    source_url: https://github.com/archestra-ai/archestra/releases

  - name: GitHub MCP Server
    slug: github-mcp-server
    date: "2026-04-17"
    version: "v1.0.0"
    stars: "28.9k"
    threat_level: low
    notable_changes: >
      v1.0.0 GA (Apr 16 2026); 60+ tools across 20+ toolsets (repos, issues,
      PRs, Actions, security, code scanning); GitHub-hosted or local Docker;
      adopt as workspace plugin source for GitHub-native agent orgs.      
    source_url: https://github.com/github/github-mcp-server/releases

  - name: Skillshare
    slug: skillshare
    date: "2026-04-17"
    version: "v0.19.2"
    stars: "1.5k"
    threat_level: low
    notable_changes: >
      v0.19.2 (Apr 14 2026); Go binary syncing SKILL.md + agent configs across
      50+ AI tools (Claude Code, Codex, OpenClaw, Cursor) via symlinks; reference
      design for cross-tool skill distribution; direct overlap with our plugins/.      
    source_url: https://github.com/runkids/skillshare/releases

  - name: Compound Engineering Plugin
    slug: compound-engineering-plugin
    date: "2026-04-17"
    version: "v2.66.1"
    stars: "14.5k"
    threat_level: low
    notable_changes: >
      v2.66.1 (Apr 16 2026); TypeScript CLI distributes one plugin to 12 AI
      runtimes simultaneously (Claude Code, Cursor, Codex, OpenClaw, Gemini,
      Kiro, Windsurf, etc.); competing multi-runtime distribution mechanism
      vs. our agentskills.io plugin portability strategy; 103 stars gained today.      
    source_url: https://github.com/EveryInc/compound-engineering-plugin/releases

  - name: EDDI
    slug: eddi
    date: "2026-04-17"
    version: "v6.0.1"
    stars: "296"
    threat_level: low
    notable_changes: >
      Show HN Apr 17 2026; config-driven multi-agent orchestration (Java/Quarkus)
      with A2A, cron scheduling, Ed25519 cryptographic agent identity,
      GDPR/HIPAA posture, HMAC-SHA256 immutable audit ledger, 12 LLM providers +
      MCP; reference design for compliance-guardrails audit trail posture.      
    source_url: https://github.com/labsai/EDDI/releases

  - name: Cloudflare Artifacts
    slug: cloudflare-artifacts
    date: "2026-04-17"
    version: "beta"
    stars: "N/A"
    threat_level: low
    notable_changes: >
      Apr 16 2026 private beta; Git-compatible versioned workspace storage
      for agents (programmatic repo create/fork/clone/diff, ~100KB Zig+WASM
      Git engine) on Cloudflare Durable Objects; ArtifactFS driver open-sourced;
      infrastructure watch — escalate to MEDIUM if Cloudflare Agents SDK
      integrates Artifacts as a managed workspace-persistence layer.      
    source_url: https://blog.cloudflare.com/artifacts-git-for-agents-beta/

  - name: dimos
    slug: dimos
    date: "2026-04-17"
    version: "v0.0.11"
    stars: "2.9k"
    threat_level: low
    notable_changes: >
      GitHub trending Apr 17 2026 (+137 today); agentic OS for robotics
      (humanoids, quadrupeds, drones, robotic arms) via natural language;
      MCP as primary agent interface; module/blueprint architecture with
      typed stream passing; spatial+temporal memory (SLAM + spatio-temporal
      RAG); hardware: Unitree, AgileX, DJI, MAVLink. Python/MIT. Watch for
      A2A support — would make robot workspaces first-class Molecule AI peers.      
    source_url: https://github.com/dimensionalOS/dimos

  - name: Cloudflare Workers AI
    slug: cloudflare-workers-ai
    date: "2026-04-17"
    version: "Agents Week 2026"
    stars: "N/A"
    threat_level: low
    notable_changes: >
      Agents Week Apr 2026; unified inference layer for agents: 70+ models,
      14+ providers (OpenAI, Anthropic, Google), auto-failover, streaming
      resilience, 330 global PoPs. Complements Cloudflare Durable Objects
      (agent state), Artifacts (versioned storage), and Agents SDK (multi-step
      orchestration). Cloudflare assembling full-stack agent platform.
      Escalate to MEDIUM if Agents SDK integrates all four primitives into
      one-click multi-agent deployment.      
    source_url: https://blog.cloudflare.com/ai-platform/

Entries

Holaboss — `holaboss-ai/holaboss-ai`

Pitch: "AI workspace desktop for business — build, run, and package AI workspaces and workspace templates with a desktop app and portable runtime."

Shape: Electron desktop app + TypeScript runtime. Single active agent per workspace. MIT-licensed OSS core with a hosted Holaboss backend for some features (proposal ideation). macOS supported; Windows/Linux in progress.

Overlap with us: both call the unit of packaging a "workspace"; both ship a skills/<id>/SKILL.md convention; both have a plugin/app marketplace; both treat long-lived context as important.

Differentiation: Holaboss is the "AI employee" shape — one agent holding one role for months, with heroic effort spent on token-cost discipline (compaction boundaries, prompt_cache_profile, stable vs volatile prompt sections). We're the "AI company" shape — many agents collaborating via A2A, visual org chart, multiple runtimes. No A2A, no multi-agent coordination on their side.

Worth borrowing:

Filesystem-as-memory: memory/workspace/<id>/knowledge/{facts,procedures,blockers,reference}/ + scoped preference/ and identity/ namespaces. Clean model for durable memory that beats our current DB-only approach for inspectability.
Compaction boundary artifact (summary + restoration order + preserved turn ids + request snapshot fingerprint) — if we ever add long-horizon single-agent mode, this is the reference design.
Section-based prompt assembly with per-section cache fingerprints. Could reduce our Claude Code prompt cost.
workspace.yaml rejects inline prompt bodies — forces prompts into AGENTS.md. We should do the same in config.yaml to keep runtime plans machine-readable.

Terminology collisions:

"workspace" — theirs is a directory + agent state; ours is a Docker container running one agent in a team.
"MEMORY.md" — theirs is the structured memory-service root; ours is the native file Claude Code / DeepAgents read.
"skills/SKILL.md" — same filesystem convention, both inject into system prompt. Fully compatible in spirit.

Signals to react to:

If they add A2A between workspaces → direct competitor; revisit differentiation.
If they publish the compaction-boundary format as a spec → adopt.

Last reviewed: 2026-04-12 · Stars / activity: ~1.7k ⭐, pushed today

Hermes Agent — `NousResearch/hermes-agent`

Pitch: "The self-improving AI agent built by Nous Research — creates skills from experience, improves them during use, searches its own past conversations, and builds a model of who you are across sessions."

Shape: Python-first agent framework with a TUI + multi-messenger gateway (Telegram / Discord / Slack / WhatsApp / Signal / Email). Single user, single continuous agent with a closed learning loop. Six execution backends (local, Docker, SSH, Daytona, Singularity, Modal — last two are serverless w/ hibernation). MIT, ~61k⭐ and climbing fast.

Overlap with us:

"Skills" with filesystem convention — compatible with the agentskills.io open standard they back.
Subagent spawning for parallel work.
Scheduled automations (natural-language cron).
Model-agnostic (Nous Portal, OpenRouter, GLM, Kimi, MiniMax, OpenAI, …).

Differentiation: Hermes is the "personal AI across every messenger" shape — one agent that knows you deeply and runs anywhere. We're the "team of agents behind a canvas" shape — many roles collaborating on shared work. Hermes has no visual canvas, no org hierarchy, no A2A between workspaces.

Worth borrowing:

Closed learning loop: autonomous skill creation after complex tasks, skills self-improve during use, agent-curated memory with periodic nudges to persist knowledge. This is a much stronger memory discipline than ours; the "nudge to persist" pattern in particular is cheap to implement.
FTS5 + LLM-summarization for cross-session recall — cheap, no vector-store overhead, works great for the "did I tell you about X" case.
Honcho dialectic user modeling (plastic-labs/honcho) for building a model of the user across sessions. Worth evaluating as a memory backend for Molecule AI's PM workspace specifically (the one role where knowing the CEO well matters most).
Daytona / Modal serverless backends with hibernation — a great fit for our DevOps workspaces that only wake for scheduled audits. Could drop our idle compute cost meaningfully.
hermes claw migrate command — gracefully import users from OpenClaw (the predecessor). Good pattern if we ever deprecate a runtime adapter.

Terminology collisions:

"skills" — same direction as ours post-refactor (file-based, installable, runtime-agnostic). Their agentskills.io spec is worth reading before we finalize our plugin manifest schema.
Topic tags on the repo include openclaw, clawdbot, moltbot, claude-code, codex — Nous Research has a whole agent family. Our workspace-template/adapters/openclaw/ adapter predates Hermes's rebrand; check whether it still points to a live project.

Signals to react to:

If agentskills.io spec picks up mass adoption → align our plugin manifest so the same skill repo installs on Hermes AND Molecule AI.
If Hermes ships multi-agent / A2A → direct overlap with our core thesis.
If Atropos RL trajectory generation becomes the standard for training tool-calling models → our workspace activity logs should adopt the trajectory schema so users can export training data.

Last reviewed: 2026-04-12 · Stars / activity: ~61k ⭐, pushed today

gstack — `garrytan/gstack`

Pitch: "Use Garry Tan's exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA." Claude Code skills bundle, MIT, ~70k⭐ and going viral on X.

Shape: A single directory of Markdown slash-command definitions installed at ~/.claude/skills/gstack/, invoked inside one Claude Code session: /office-hours, /plan-ceo-review, /review, /qa, /ship, /land-and-deploy, /cso (security), /retro, etc. No services, no containers, no DB — just prompts and scripts that the Claude Code CLI executes in whatever repo the user has open.

Overlap with us:

Same role metaphor as molecule-dev. Both cast AI work as a cast of roles (CEO, Eng Manager, Designer, Security, QA). The naming overlap is nearly 1:1 with our org template.
Claude Code-native, Markdown-driven config, "skills" as the unit.
Team-mode auto-updates shared repos — same instinct as our org templates.

Differentiation: gstack is sequential, single-session, single-repo. One Claude Code session runs each slash command in turn; the "team" is a persona switch, not separate processes. We're parallel, multi-session, hierarchical: real containers, A2A between siblings, a visual canvas, real-time WebSocket updates, schedules, org bundles. gstack has no multi-agent coordination, no A2A, no canvas, no workspace persistence beyond git — it's a brilliant prompt library, not an orchestration platform.

Worth borrowing:

/retro command: generates a weekly retrospective from git history ("140,751 lines added, 362 commits, ~115k net LOC in one week"). Would be a natural addition to our PM agent's toolbox — commit_memory + git log synthesis. Cheap win.
/autoplan and /freeze / /guard / /unfreeze for architectural guardrails during a risky change. Maps cleanly onto our approval flow — could turn into a /freeze hook that sets a workspace-level policy flag preventing certain tool calls during a migration.
Role-prompt library. gstack has spent a lot of effort on the CEO / Designer / Eng Manager personas. Even without adopting their runtime, we could lift the prompt text into our molecule-dev system-prompt.md files with attribution. Their CSO (OWASP + STRIDE audit) and Designer (AI-slop detection) personas are both stronger than ours today.
Team-mode auto-update (throttled once/hour, network-failure-safe, silent) — good pattern for keeping plugins in sync across an org without requiring manual /plugins/install calls.

Terminology collisions:

"Skills" — gstack ships everything as Claude Code skills (filesystem convention ~/.claude/skills/<name>/). Same filesystem shape as ours AND Hermes AND Holaboss. Four projects, one spec shape — should formalize with agentskills.io.
"Ship / Release" — their /ship is a local PR-and-merge flow; nothing to do with our A2A lifecycle.
Mentions "OpenClaw" (247k ⭐ claim) as inspiration — tracks with the Hermes entry's note that the OpenClaw name is alive in multiple ecosystems.

Signals to react to:

If gstack adds multi-session / parallel execution (spawning multiple Claude Code workers and routing between them) → direct competitor with a 70k⭐ head start. Revisit our differentiation messaging.
If their /plan-ceo-review prompt or /qa browser flow becomes an informal standard → copy it into molecule-dev's system prompts.
If Garry Tan posts a video deploying gstack on a new use case → high-signal about what "everyone" will ask us to support next week.

Last reviewed: 2026-04-12 · Stars / activity: ~70k ⭐, pushed yesterday

Composio — `composio-dev/composio`

Pitch: "The integration layer for AI agents — 250+ tools across Slack, GitHub, Telegram, Linear, Discord, and more, with managed auth."

Shape: Python + TypeScript SDK. Pure integration library — no agent runtime, no visual canvas. Plugs into any LLM framework (LangChain, LangGraph, AutoGen, CrewAI, Claude, OpenAI Agents). Managed auth so agents can act on user-connected accounts. MIT-adjacent, ~18k ⭐.

Overlap with us: Both provide agent-accessible Slack, Telegram, and Discord channels. Both handle OAuth / credential management for workspace integrations. Channels feature in platform/internal/handlers/channels.go does a subset of what Composio does for the messaging platforms.

Differentiation: Composio is a tool library, not a runtime or org hierarchy. No canvas, no A2A between agents, no org structure. They're "the 250 tools agents can call"; we're "the company that runs the agents." Composio could be a dependency inside a Molecule AI workspace skill — not a competitor for the platform layer.

Worth borrowing:

Trigger model: inbound webhook → fire agent → respond in same channel. Our channels feature handles outbound well but inbound triggers are still manually configured. Composio's trigger schema is worth adopting.
"Connected accounts" pattern: per-workspace OAuth token stored per integration, reused across runs. Our workspace_channels JSONB config is close; formalize as a named model.
Auth sandbox: test mode that mocks API calls — useful for our POST /workspaces/:id/channels/:id/test endpoint.

Terminology collisions:

"actions" = their tool calls; we use "skills."
"triggers" = their inbound webhooks; we use channels + schedules.

Signals to react to:

If they add persistent agent identity across trigger runs → direct overlap with our workspace model.
If they add A2A between agent sessions or multi-agent orchestration → threat to our integration story.
If agentskills.io adopts Composio trigger schema → we should too.

Last reviewed: 2026-04-13 · Stars / activity: ~18k ⭐, active

n8n — `n8n-io/n8n`

Pitch: "Fair-code workflow automation with 400+ integrations — build AI pipelines visually, self-host or cloud."

Shape: Node.js, self-hosted or n8n cloud. Visual workflow builder (nodes

edges, not unlike React Flow). 400+ connectors: Slack, Telegram, Discord, WhatsApp, Email, GitHub, Linear, Notion, … plus dedicated AI nodes (LLM chains, agent nodes, vector stores, tool use). Fair-code license (source-available, free for internal use). ~50k ⭐, pushed daily.

Overlap with us:

Visual graph metaphor for orchestrating work (their nodes ≈ our canvas workspaces).
Connects AI agents to Slack / Telegram / Discord / WhatsApp — identical surface to our workspace_channels feature.
Scheduled automations (cron triggers) → same as workspace_schedules.
Self-hostable, Docker Compose first-class.

Differentiation: n8n is trigger→step→step→output (stateless sequential workflow per run). No persistent agent identity, no shared memory across runs, no org hierarchy, no A2A between agents. Each execution is isolated. We're "agents that remember, collaborate, and hold roles"; they're "workflows that transform data." The UX audiences barely overlap: n8n users are ops/no-code builders; Molecule AI users are developers building agent companies.

Worth borrowing:

Channel trigger UX: select platform → OAuth → pick chat → done in three clicks. Our channel setup requires more manual config; this flow is the right target for POST /workspaces/:id/channels.
"Test workflow" dry-run: one-click test execution with live output. Maps well onto our POST /workspaces/:id/channels/:id/test — we should fire a real test message and show the round-trip result inline.
Sticky notes on canvas: freeform annotation nodes for documentation. Cheap win for our canvas — could be a "comment node" workspace type.
Execution log with step-level timing: n8n shows each node's in/out data and ms. Our activity_logs captures A2A traffic but not intra-agent step timing. Worth adding to the trace view.

Terminology collisions:

"workflow" — their atomic unit; for us "workflow" is informal. No hard collision but our marketing copy should avoid it to stay distinct.
"nodes" — their workflow steps; our canvas nodes are workspaces. Different enough to not cause user confusion, but worth noting in docs.

Signals to react to:

If n8n ships persistent agent nodes (memory between runs) → direct substitute for simple Molecule AI use cases. They've been adding AI nodes fast (AI Agent node shipped 2024-Q3).
If they add multi-agent coordination with shared state → revisit our differentiation messaging.
If a major Slack/Discord bot tutorial uses n8n instead of a custom agent → indicates channel-first UX is the market expectation we need to match.

Last reviewed: 2026-04-13 · Stars / activity: ~50k ⭐, pushed daily

Pydantic AI — `pydantic/pydantic-ai`

Pitch: "AI Agent Framework, the Pydantic way."

Shape: Python SDK (MIT), ~16.3k ⭐, last release v1.8.0 on April 10, 2026 — actively maintained at high velocity. Single and multi-agent, with typed dependency injection (RunContext[DepsType]), structured/validated outputs (Agent[Deps, OutputType]), composable capability bundles (tools + hooks + instructions + model settings), built-in streaming, and human-in-the-loop tool approvals. Supports A2A and MCP natively as first-class integrations. Model-agnostic: OpenAI, Anthropic, Gemini, Mistral, Cohere, DeepSeek, Bedrock, Vertex, Ollama, OpenRouter, and more. Observability via Pydantic Logfire.

Overlap with us: A2A support means Pydantic AI agents can speak directly to Molecule AI workspaces over our native protocol — they're potential consumers of Molecule AI's registry, not just a parallel ecosystem. MCP integration mirrors our workspace tool model. The composable capability bundles are the same instinct as our plugin/skills system. Logfire's agent tracing is a polished alternative to our GET /workspaces/:id/traces + Langfuse stack.

Differentiation: Pydantic AI is a library for building agents in Python — no visual canvas, no Docker workspace isolation, no registry/discovery, no scheduling, no WebSocket org chart, no channels. It's the in-process layer; we're the operational platform layer. The two are naturally complementary: a Molecule AI workspace running Pydantic AI agents is a valid architecture, not a contradiction.

Worth borrowing:

Typed dependency injection via RunContext — passing strongly-typed deps (DB connection, API client, user object) into every tool and instruction without global state. Our config.yaml passes env vars; this pattern is safer and more testable.
Agent[Deps, OutputType] generic typing — structured, schema-validated agent outputs. Our A2A responses are freeform text; adopting structured output schemas at the A2A layer would enable typed inter-workspace contracts.
Composable capability bundles — reusable packages of tools + hooks + instructions. Our plugins install files; this is the right next evolution (code bundles, not just Markdown).

Terminology collisions:

"capabilities" — their term for composable tool+instruction bundles; we use "plugins" or "skills."
"RunContext" — their typed dependency carrier; not a shared term, but will appear in codebases mixing Pydantic AI + Molecule AI adapters.
"tools" — same word, same meaning. No collision, but documentation should be explicit about Pydantic AI tools vs. MCP tools vs. Molecule AI skills.

Signals to react to:

If Pydantic AI ships a workspace/session persistence layer → fills the one gap between it and Molecule AI's value; revisit our Python-SDK adapter story.
If pydantic-deepagents (vstorm-co/pydantic-deepagents) gains traction — "Claude Code–style deep agents on Pydantic AI" — it would become a direct competitor to our Claude Code runtime adapter.
If Logfire's agent tracing becomes the de facto standard → align our trace schema so Logfire can ingest Molecule AI workspace traces natively.

Last reviewed: 2026-04-13 · Stars / activity: ~16.3k ⭐, v1.8.0 released April 10, 2026

Rivet — `Ironclad/rivet`

Pitch: "The open-source visual AI programming environment and TypeScript library."

Shape: Electron desktop app + TypeScript library (MIT), ~4.5k ⭐. Visual node-based editor where AI workflows are built by connecting nodes in a graph: LLM call nodes, tool nodes, subgraph nodes, conditional branches. Runs locally; exports workflows as .rivet-project files that can be embedded in applications via the @ironclad/rivet-node npm package. Built and open-sourced by Ironclad (a Series D contract intelligence company). Model-agnostic. Plugin marketplace for custom node types.

Overlap with us: The canvas is the obvious overlap — both products present AI agent work as a visual graph. Rivet's subgraph nesting (complex workflows broken into reusable components) maps to our parent/child workspace hierarchy. The plugin marketplace for custom nodes mirrors our plugins/ registry. Rivet workflows can call external APIs, making them potential consumers of Molecule AI's /workspaces/:id/a2a endpoint — a Rivet node that delegates to a Molecule AI agent is a plausible integration.

Differentiation: Rivet is a workflow authoring tool, not an agent runtime. A .rivet-project file describes a static graph; there's no persistent agent identity, no memory across runs, no org hierarchy, no real-time WebSocket canvas, no scheduling, no Docker container management. The Rivet editor is for building workflows; Molecule AI is for running a live org of agents. The /channels angle is absent from Rivet — it has no concept of an agent receiving or sending messages via Telegram, Slack, or other social platforms. Rivet's audience is developers prototyping single pipelines; ours is teams deploying multi-agent organizations.

Worth borrowing:

Nested subgraph UX — Rivet's handling of "graph within graph" as a first-class reusable node is the cleanest visual pattern for our parent/child workspace hierarchy. Our current Canvas flattens deeply nested teams into chips; Rivet's subgraph expand/collapse is the reference UX to study.
Node-level debug inspector — clicking any node in a completed run shows its exact inputs, outputs, and latency. Our Canvas chat shows A2A messages but not intra-workspace step-level data. This is the natural evolution of our trace view.
.rivet-project portability — workflow-as-file, embeddable in any TypeScript app via npm. Suggests we should support a "workspace bundle export" that can run outside Molecule AI, not just be imported back into it.

Terminology collisions:

"graph" — their graph is a workflow definition (static); ours is the live org chart (dynamic, stateful). Different semantics, same word.
"node" — their nodes are workflow steps; our canvas nodes are workspaces. No runtime collision but documentation must be unambiguous.
"plugin" — both have plugin systems; theirs extends the node palette, ours extends the workspace runtime.

Signals to react to:

If Rivet adds persistent agent state between runs → closes the gap with Molecule AI for simple use cases; revisit our "quick start" story for non-enterprise users.
If Rivet adds a "deploy workflow as agent endpoint" feature → their visual builder becomes a Molecule AI workspace creator; consider a Rivet → Molecule AI import adapter.
If .rivet-project format becomes a de facto workflow interchange standard → support importing Rivet projects as Molecule AI workspace configs.

Last reviewed: 2026-04-13 · Stars / activity: ~4.5k ⭐, actively maintained

Letta — `letta-ai/letta`

Pitch: "The platform for building stateful agents: AI with advanced memory that can learn and self-improve over time."

Shape: Python + TypeScript SDK (Apache-2.0), ~22k ⭐, v0.16.7 released March 31, 2026. Formerly MemGPT (the research project that pioneered OS-inspired virtual context management for LLMs). Letta's defining feature is a multi-block memory architecture: each agent holds named, editable in-context memory segments ("core memory") such as human, persona, and archival blocks, which the agent can read and write via tool calls. Memories persist across sessions in a Letta Server (self-hosted or Letta Cloud). Agents are accessed via a REST API. The ADE (Agent Development Environment) is a graphical interface for creating, testing, and monitoring agents in real-time. Multi-agent support via subagents and shared memory. Model-agnostic (OpenAI, Anthropic, local LLMs via Ollama).

Overlap with us: Letta's named memory blocks (human, persona, archival) are a structured evolution of the same problem our agent_memories table and MEMORY.md file solve — persistent, durable knowledge for a long-lived agent. The ADE's graphical agent-monitoring interface overlaps with our Canvas; both offer a UI to inspect and interact with running agents. Letta Server exposes a REST API that accepts messages at agent endpoints — structurally similar to our A2A proxy (POST /workspaces/:id/a2a). Multi-agent subagent support maps to our parent/child workspace hierarchy. Letta's initial_prompt equivalent (agent system prompt + memory bootstrap) mirrors our initial_prompt in config.yaml.

Differentiation: Letta is focused on the single-agent memory problem, not the multi-agent org problem. No Docker container isolation per agent, no workspace registry, no real-time WebSocket org chart, no scheduling, no channels to Slack/Telegram/Discord. The ADE shows individual agents; it does not visualize an org hierarchy or inter-agent A2A traffic. Letta's multi-agent support is hierarchical subagent spawning within a single Letta Server context — not independently deployable, independently schedulable workspaces. We're "a company of agents"; Letta is "an agent with a very good memory."

Worth borrowing:

Named, agent-editable memory blocks — the human / persona / archival distinction is the clearest taxonomy we've seen for agent memory. Our agent_memories namespace is flat; adopting explicit named blocks (at minimum: self, user, task-context, long-term-knowledge) would make memory more inspectable and auditable in the Canvas.
Memory self-editing as a tool call — Letta agents call core_memory_replace(label, old, new) and archival_memory_insert(content) as first-class tool actions, making memory updates part of the visible tool-call trace. Our commit_memory MCP tool is close; making it show up in activity_logs as a named tool call (not a silent background action) would match this pattern.
ADE real-time message inspector — the ADE shows each tool call, memory read/write, and reasoning step inline in a timeline. This is more granular than our Canvas chat tab; it's the reference design for a "step-through debug mode" in our trace view.

Terminology collisions:

"archival memory" — Letta: a searchable long-term store the agent queries via tool calls. Ours: not a defined term. Our agent_memories table is functionally similar but not surfaced to agents as a named primitive.
"persona" — Letta: a named memory block containing the agent's self-description. Ours: the role: field in config.yaml plus the system prompt. Same intent, different packaging.
"agent" — Letta: a long-lived server-side object with persistent memory, accessed via REST. Ours: a Docker container running one of six runtimes. Same word, substantially different operational model.

Signals to react to:

If Letta ships a multi-agent canvas that visualizes org hierarchies (not just individual agent inspection) → direct overlap with our Canvas; they have strong memory credibility that could attract our target buyer.
If Letta formalizes a memory-block schema as an open spec (building on their MemGPT research lineage) → evaluate adopting it as Molecule AI's agent_memories schema to gain interoperability with the Letta ecosystem.
If Letta Cloud adds Slack/Telegram/Discord inbound triggers → they gain channels capability; currently absent, but a REST API means it's one webhook away.
Watch v0.x → v1.0 trajectory: v0.16.7 suggests pre-1.0 API stability; a 1.0 GA announcement would signal enterprise readiness and an accelerated sales motion.

Last reviewed: 2026-04-13 · Stars / activity: ~22k ⭐, v0.16.7 March 31, 2026

Trigger.dev — `triggerdotdev/trigger.dev`

Pitch: "Build and deploy fully-managed AI agents and workflows."

Shape: TypeScript (Apache-2.0), ~14.5k ⭐, v4.4.3 released March 10, 2026. Started as a developer-friendly alternative to cron + background jobs; v4 repositions it squarely as durable execution infrastructure for AI agents. Tasks are TypeScript functions decorated with task() — they run in a managed cloud with: automatic retry with exponential backoff, checkpoint/resume (task state saved to storage, resumed after crash or timeout), queue and concurrency control, and cron scheduling up to one-year duration. Human-in-the-loop via waitForApproval(). MCP server available (trigger-dev MCP) so AI assistants (Claude Code, Cursor, etc.) can trigger tasks, check run status, and deploy from chat. Warm starts execute in 100–300ms. Fully self-hostable.

Overlap with us: Trigger.dev's schedules.task() cron system overlaps directly with our workspace_schedules table and POST /workspaces/:id/schedules API — both schedule recurring prompts/tasks on a cron expression. The checkpoint/resume model (waitForApproval, wait.for()) is a precise parallel to our workspace pause / resume lifecycle. Human-in-the-loop approval gates match our POST /workspaces/:id/approvals. The MCP server enabling AI agents to trigger tasks maps to the same use case as our MCP server's delegate_task tool. Both platforms treat long-running, fault-tolerant execution as a core design constraint.

Differentiation: Trigger.dev has no agent identity — tasks are stateless TypeScript functions, not persistent agents with memory, roles, or system prompts. No visual canvas, no org hierarchy, no A2A protocol, no workspace registry. It is execution infrastructure, not an agent platform. The right mental model: Trigger.dev is to Molecule AI what Temporal is to Molecule AI — a lower-level durable execution substrate that Molecule AI's workspaces could use as a backend for their scheduled tasks, rather than a replacement for Molecule AI itself. Their /channels story is inbound-only (HTTP triggers, webhooks, cron) with no native Slack/Telegram messaging surface.

Worth borrowing:

Idempotency keys on task invocation — trigger("send-report", payload, { idempotencyKey: runId }) ensures a task is only ever executed once for a given key, even if triggered multiple times. Our delegation system has no equivalent guard; duplicate delegations from container-restart races are a known issue (see delegationRetryDelay in delegation.go). Adding idempotency keys to POST /workspaces/:id/delegate would fix the duplicate-execution class of bugs.
waitForApproval() inline in task code — instead of a separate approvals table and polling loop, the task itself calls await wait.for({ event: "approval" }) and suspends. Our approval flow requires a separate API round-trip and the agent to re-check; Trigger.dev's inline suspension is the right long-term model.
Warm-start pool for sub-300ms agent starts — Trigger.dev pre-warms TypeScript runtimes to achieve 100–300ms cold start. Our Docker workspace startup is measured in seconds. Worth evaluating their warm-pool approach for our claude-code and langgraph adapters.

Terminology collisions:

"task" — Trigger.dev: a decorated TypeScript function, the atomic unit of execution. Ours: informal (used in delegation context and current_task heartbeat field). Their definition is more precise; consider whether our heartbeat current_task field should be renamed to avoid collision with Trigger.dev vocabulary in integrations.
"schedule" — same word, same meaning. Trigger.dev's cron schedule API and ours (workspace_schedules) are functionally identical at the surface. Our docs should distinguish "Molecule AI schedules" from "Trigger.dev schedules" clearly when positioning integrations.
"run" — Trigger.dev: a single execution of a task with full lifecycle tracking. Ours: informal. No hard collision.

Signals to react to:

If Trigger.dev ships native agent identity (persistent state, memory across runs, named agents) → crosses from infrastructure into platform territory; reevaluate positioning.
If the trigger-dev MCP becomes a de facto standard for AI-tool-triggered background work → add a Trigger.dev adapter to our workspace runtime so Molecule AI agents can fire Trigger.dev tasks as a tool call (complementary, not competitive).
If Trigger.dev ships a Slack/Discord trigger adapter → they gain a channels surface; currently absent. Watch their integration roadmap.
Their TypeScript-first stack and MCP server target the same developer audience as our Canvas + mcp-server. Co-marketing opportunity: "run your Molecule AI agent on a schedule via Trigger.dev" is a cleaner story than our current in-house cron for some user segments.

Last reviewed: 2026-04-13 · Stars / activity: ~14.5k ⭐, v4.4.3 March 10, 2026

Mem0 — `mem0ai/mem0`

Pitch: "The memory layer for AI agents — add persistent, adaptive memory to any LLM application."

Shape: Python/TypeScript SDK (Apache 2.0), ~25k ⭐. Runs as an embedded library or managed cloud service. Extracts structured memory objects from conversations (facts, preferences, relationships), stores them with embeddings, and retrieves relevant memories on each new interaction. Supports multiple vector backends (Qdrant, Pinecone, Chroma, Postgres pgvector). REST API available.

Overlap with us: Molecule AI ships agent_memories + /workspaces/:id/memories for per-agent memory. Mem0 targets exactly this use case and is the incumbent OSS solution for add-on agent memory. Any team evaluating Molecule AI will compare our memory primitives to Mem0's.

Differentiation: Mem0 is a memory service, not an agent platform. It has no workspace lifecycle, no org hierarchy, no A2A protocol, no canvas, no scheduling. Molecule AI memory is scoped per-workspace and stored in Postgres as raw key-value pairs; Mem0 extracts and semantically indexes facts across interactions using vector search. The extraction step is the critical gap — we store what agents explicitly save, Mem0 learns what matters automatically.

Worth borrowing:

Structured extraction — Mem0 auto-extracts facts ("project uses zinc-900 palette") from conversation text. Adding extraction to our memory writes would improve recall quality for long-running agents without agents needing to explicitly call commit_memory.
pgvector backend — supports Postgres pgvector; we could add semantic memory search to our existing DB with no new infrastructure.

Terminology collisions:

"memory" — same word, different semantics. Mem0 memories are extracted semantic facts; our memories are programmatically set key-value pairs.

Signals to react to:

If Mem0 ships multi-agent scoped memories (shared across an org) → directly competes with our team memory model.
If Mem0 becomes default memory backend for LangGraph or CrewAI → assess whether our adapters should delegate to Mem0 under the hood.

Last reviewed: 2026-04-13 · Stars / activity: ~25k ⭐, actively maintained

AG2 — `ag2ai/ag2`

Pitch: "A programming framework for agentic AI — the continuation of AutoGen by the original team."

Shape: Python library (Apache 2.0), ~40k ⭐ (combined AutoGen lineage). Community fork maintained by the original AutoGen core contributors after Microsoft redirected microsoft/autogen toward a new architecture. Preserves the classic AutoGen API: AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager. Actively ships new features (tool calling, code execution, nested chats). pip install ag2 is now the recommended path for the classic AutoGen experience.

Overlap with us: Molecule AI ships an autogen runtime adapter targeting microsoft/autogen. AG2 is API-compatible for most use cases but is the fork with active community investment — our adapter should be validated against AG2 and the migration path assessed.

Differentiation: AG2 is a conversation orchestration framework, not an agent platform. Agents are ephemeral Python objects per-conversation; no persistent workspace identity, no canvas, no Docker management, no org hierarchy, no A2A, no scheduling. Molecule AI workspaces are long-lived; AG2 sessions are not.

Worth borrowing:

GroupChat speaker selection — AG2's GroupChatManager supports round-robin, auto (LLM-selected), and custom speaker strategies. More sophisticated than our linear PM → Lead → Engineer delegation; study for future dynamic routing.
Hardened code execution sandbox — AG2's Docker-isolated code execution container is the reference design for any Molecule AI feature where engineer agents run arbitrary code.

Terminology collisions:

"agent" — their agents are ephemeral Python objects; ours are long-lived Docker workspaces.
"GroupChat" — their multi-agent coordination primitive; analogous to our PM + team hierarchy but stateless.

Signals to react to:

If the microsoft/autogen ↔ AG2 split resolves → update our adapter target accordingly; don't maintain two paths.
If AG2 ships persistent agent state → direct competitor to our Claude Code and LangGraph adapters.

Last reviewed: 2026-04-13 · Stars / activity: ~40k ⭐ (primary community repo for AutoGen lineage)

Super Dev — `shangyankeji/super-dev`

Pitch: "Engineering workflow layer for AI coding tools — specs, review, quality gates, and traceability for commercial-grade AI-assisted delivery."

Shape: Python 3.10+ CLI (MIT), ~217 ⭐, v2.3.7. Not an agent runtime — a governance overlay that injects structured workflow into existing AI coding hosts (Claude Code, Cursor, Cline, Codex). Users invoke via /super-dev inside their host tool. Delivers an 8-phase pipeline (research → PRD → architecture → UI/UX → spec → implementation → quality → delivery) with 11 domain-expert context injections per phase (PRODUCT, PM, ARCHITECT, UI, UX, SECURITY, CODE, DBA, QA, DEVOPS, RCA), YAML-driven validation rules, knowledge-file auto-injection, and DORA-4 delivery metrics. Primary audience: Chinese-market developers; bilingual README. 63 forks as of April 2026.

Overlap with us: Both use a PM role, a "skills" directory convention, CLAUDE.md injection, and quality gates. Molecule AI users who run Claude Code workspaces may already use super-dev inside that workspace — orthogonal layers, not competitors.

Differentiation: Super-dev engineers a solo developer's AI coding session; Molecule AI engineers a team of persistent AI agents collaborating via A2A. Super-dev has no agent identity, no workspace lifecycle, no Docker runtime, no multi-agent coordination. Molecule AI has no per-phase expert Playbooks or spec-traceability. Complementary shapes.

Worth borrowing:

Expert-Playbook injection — 11 domain experts with 350-line Playbooks auto-injected per pipeline phase. Our org-template system-prompts are the equivalent, but super-dev's staged injection (only relevant experts per phase) is more surgical than our always-on prompts.
Staged pipeline formalism — explicit phase names (research → spec → quality) with mandatory confirmation gates. Formalizing this in Molecule AI's PM org-template would make agent hand-offs auditable.
Spec-Code traceability — super-dev spec trace links implementation files back to spec docs. Worth adding as a workflow convention even without tooling.
YAML validation rules with multi-level severity — 14 built-in rules + custom rules. Adapt for Molecule AI's own QA step.

Terminology collisions:

"memory" — super-dev has 4 typed memory categories (user / feedback / project / reference) with dream consolidation; ours are key-value pairs programmatically set by agents.
"skills" — super-dev's super-dev-skill/ is a host-injection convention; our skills/ are composable agent behaviours loaded at workspace boot.
"PM" — their PM is an expert context fragment; ours is a live orchestrating agent.
"pipeline" — their 8-phase delivery sequence vs our runtime adapter selection + delegation chains.

Signals to react to:

If super-dev ships multi-agent coordination (shared workspace state, agent hand-offs beyond single-host) → overlap increases materially; assess positioning.
If super-dev adds a Molecule AI workspace adapter (they already handle Claude Code, Cursor, Cline) → co-marketing / integration opportunity; our Claude Code adapter runs inside their pipeline.
If the "11 expert Playbook" pattern gets wide adoption → formalize equivalent staged-injection in our PM + Dev Lead system prompts.

Last reviewed: 2026-04-13 · Stars / activity: ~217 ⭐, 63 forks, v2.3.7 pushed Apr 13 2026

Sierra — `sierra.ai` (commercial, no public repo)

Pitch: "AI agents for customer service — production-grade conversational AI that handles complex customer issues end-to-end without human escalation."

Shape: Enterprise SaaS (YC-backed, ~$4B valuation, 2024). Sierra builds custom AI agents for specific companies (Sonos, Weight Watchers, OluKai) rather than a general-purpose platform. Each deployment is a brand-trained agent that handles returns, account management, troubleshooting, and purchasing through multi-turn natural-language conversation. No self-serve tier; sold via enterprise contract. Backed by Bret Taylor and Clay Bavor (ex-Google). No public SDK or API.

Overlap with us: Both are "agents with persistent state and human-readable conversation history." Sierra's agent architecture (multi-turn session, tool calls to CRMs/ERPs, escalation triggers) is the same shape as a Molecule AI workspace with A2A access to backend tools. Sierra targets the customer-service vertical; Molecule AI targets engineering teams. Same underlying pattern, radically different buyer.

Differentiation: Sierra is a fully managed, vertically specialized offering — customers buy a branded agent, not a platform. Molecule AI sells the platform and lets teams compose their own agents. Sierra has no org hierarchy, no multi-agent orchestration within a session, no developer API. Molecule AI has no trained vertical-specific knowledge, no out-of-box CRM/ERP connectors, no customer service SLA guarantees. Sierra's moat is vertical depth + enterprise trust; ours is composability + developer control.

Worth borrowing:

Agent personality/brand layer — Sierra's agents adopt a company's tone, policies, and vocabulary as a first-class config layer. Our SOUL.md convention in the OpenClaw adapter is the nearest equivalent; worth generalising as a platform concept (a "persona" config block in org.yaml that injects brand voice into every system-prompt).
Escalation to human — Sierra has a defined handoff protocol when confidence drops or the issue requires a human. Our approvals table covers the "pause for review" pattern; a formal escalation tool (create a ticket, notify a human via channel) is missing.

Terminology collisions:

"agent" — Sierra: a deployed brand-trained assistant. Ours: a Docker workspace with a role. Conceptually adjacent, not interchangeable.
"session" — Sierra: one customer conversation. Ours: not a first-class concept.

Signals to react to:

If Sierra opens a developer API or self-serve tier → they enter our addressable market for teams that want a customer-facing agent alongside their internal engineering agents.
If Sierra raises another round or announces a platform play → they may be building the platform we're building, just starting from the customer service vertical rather than engineering.
Enterprise buyers comparing us to Sierra → emphasize Molecule AI's programmability and multi-agent composition vs Sierra's closed vertical depth.

Last reviewed: 2026-04-13 · Stars / activity: commercial SaaS, ~$4B valuation, no public repo

ERNIE / Baidu LLM line — `qianfan.baidubce.com`

Pitch: Baidu's family of large language models — ERNIE 4.5, ERNIE Speed, ERNIE Lite — available via the Qianfan platform with OpenAI-compatible endpoints. Primary model provider for the Chinese-market hackathon ecosystem and the cheapest LLM option for Molecule AI sub-agents given available free credits.

Shape: Cloud API (Baidu Cloud). ERNIE models span capability tiers: ERNIE 4.5 (flagship, strong reasoning), ERNIE Speed (fast, cost-efficient), ERNIE Lite (cheapest, for low-stakes tasks). Accessed via https://qianfan.baidubce.com/v2 with OpenAI-compat JSON format. Auth: QIANFAN_API_KEY (standard) or AISTUDIO_API_KEY (via Google AI Studio compat layer at https://generativelanguage.googleapis.com/v1beta/openai). Not a competitor; it's infrastructure.

Overlap with us: Molecule AI now has AISTUDIO_API_KEY and QIANFAN_API_KEY as recognised adapter keys (openclaw adapter fix, SHA d779e16). The MeDo hackathon integration targets the Baidu Cloud ecosystem, making ERNIE models the natural default for hackathon workspaces. ERNIE Speed / ERNIE Lite are cost candidates for Research Lead and Market Analyst sub-agents where we don't need Opus-class reasoning.

Differentiation: ERNIE is a model line, not a platform. No agents, no orchestration, no workflow. Molecule AI is the platform; ERNIE is one of many possible backends. The entry here is about when to route to ERNIE rather than Anthropic or OpenAI.

Worth borrowing:

Tiered model routing by task complexity — ERNIE's Speed/Lite/4.5 tiers make explicit the "pick the cheapest model that can do the job" principle. Molecule AI's PM could route shallow research tasks (keyword search, web fetch) to ERNIE Lite and deep reasoning tasks (code review, architecture analysis) to Claude Opus. A model_policy field in org.yaml per-workspace would encode this without hard-coding model IDs.
Qianfan model hub metadata — the Qianfan API surfaces context window, pricing, and availability per model in a machine-readable format. Worth scraping for a Molecule AI model registry that shows operators the cost/capability tradeoff at provisioning time.

Terminology collisions:

"knowledge base" — Baidu Qianfan's knowledge base feature (RAG pipeline) vs our agent_memories table. Overlapping concept; their offering is more mature on retrieval.

Signals to react to:

If QIANFAN_API_KEY free credit expires → swap hackathon sub-agents back to AISTUDIO_API_KEY + Gemini Flash.
If ERNIE 4.5 closes the gap with Claude Sonnet on English-language reasoning → evaluate as a cost-saving default for non-PM workspaces.
If Baidu opens ERNIE function-calling / tool-use parity with GPT-4o → ERNIE becomes viable for the Backend Engineer and QA Engineer workspaces, which require reliable structured output.

Last reviewed: 2026-04-13 · Stars / activity: commercial API (Baidu Cloud), ERNIE 4.5 released Q1 2026

MeDo — `moda.baidu.com` (commercial, no public repo)

Pitch: Baidu's no-code AI application builder — scaffold and publish AI-powered apps through a visual editor with pre-built LLM integrations.

Shape: SaaS platform (Baidu Cloud, Chinese-market primary). Users compose apps from prompt nodes, data connectors, and UI blocks via a drag-and-drop canvas. Published apps get a hosted endpoint. REST API for programmatic create/update/publish. No OSS repo; requires Baidu Cloud account. Hackathon track: MeDo SEEAI May 2026.

Overlap with us: Both expose a canvas (theirs visual, ours org-chart + agent config). Both have an app-publish lifecycle. Our Canvas + workspace provisioner covers roughly the same surface for technical teams; MeDo targets non-developers. Molecule AI is integrating MeDo via the new medo.py builtin tool to enter the May 2026 hackathon.

Differentiation: MeDo is a no-code builder for end-user AI apps; Molecule AI is a developer platform for multi-agent engineering workflows. MeDo has no A2A, no workspace Docker runtime, no persistent agent memory. Molecule AI has no no-code UI builder. The integration is complementary: Molecule AI agents can create and publish MeDo apps programmatically as a delivery step.

Worth borrowing:

Visual prompt-node composition — their drag-and-drop prompt pipeline could inspire a simpler Canvas view for non-technical stakeholders who want to inspect an agent's workflow without reading system-prompt.md.

Terminology collisions:

"app" — a published MeDo application vs a Molecule AI workspace; different lifecycles.
"canvas" — their visual editor surface vs our org-chart canvas.

Signals to react to:

If MeDo opens a REST API to third-party agent platforms → expand medo.py from stub to full integration; file a Hermes-style adapter PR.
If the MeDo hackathon win generates user interest → prioritise MeDo as a first-class delivery target alongside GitHub and Slack.

Last reviewed: 2026-04-13 · Stars / activity: commercial SaaS (Baidu Cloud), active hackathon track May 2026

Inngest — `inngest/inngest`

Pitch: "The durable execution engine for AI agents and background functions — write reliable step functions that survive failures, retries, and deploys."

Shape: Go + TypeScript SDK (Apache 2.0), ~5.2k ⭐. Cloud-hosted or self-hosted. Developers define "functions" as async step graphs; Inngest handles scheduling, retries, concurrency limits, rate limits, and failure recovery. HTTP-native — functions live in your existing web server and Inngest calls them. Comparable to Temporal but lighter: no gRPC, no workflow history replay, just durable HTTP step execution.

Overlap with us: Molecule AI ships an in-house cron scheduler and a Temporal adapter for durable background work. Inngest is a third option in the same space: schedule-driven agent tasks, retry-on-failure, fan-out. Any Molecule AI feature that today uses CronCreate or temporal_workflow could instead use Inngest's step functions.

Differentiation: Inngest is infrastructure-as-a-service for function scheduling; Molecule AI is an agent platform. Inngest has no concept of persistent agent identity, workspace lifecycle, org hierarchy, or A2A. Our Temporal adapter is the direct equivalent for complex multi-step workflows; Inngest targets simpler event-triggered functions with less operational overhead than Temporal.

Worth borrowing:

HTTP-native step graph model — Inngest steps live in a plain web route. Adopting this pattern for Molecule AI's skill execution would remove the need for the workspace's internal runner process for short tasks.
Built-in rate limiting per function — our current delegation tool has no per-workspace rate limit; Inngest's concurrency + rate-limit primitives are the reference design.

Terminology collisions:

"function" — Inngest functions are durable async step graphs; ours are Python tool functions decorated with @tool.
"event" — Inngest events trigger functions; our event_queue in A2A is different.

Signals to react to:

If Inngest ships native agent-state primitives (memory, long-running sessions) → direct overlap with our workspace model; re-evaluate our Temporal dependency.
If Inngest becomes the dominant alternative to Temporal in AI stacks → add an inngest adapter alongside temporal_workflow.py.

Last reviewed: 2026-04-13 · Stars / activity: ~5.2k ⭐, v0.x actively developed

Arize Phoenix — `Arize-ai/phoenix`

Pitch: "AI observability and evaluation platform — trace, evaluate, and troubleshoot LLM applications and agents in production."

Shape: Python + TypeScript (Apache-2.0), ~5k ⭐, v8.x. Self-hostable or Phoenix Cloud. Ships an OpenTelemetry-compatible tracing SDK (pip install arize-phoenix-otel) that auto-instruments LangChain, LangGraph, LlamaIndex, OpenAI, Anthropic, and more. Every LLM call, tool use, retrieval, and agent step is captured as an OpenTelemetry span and displayed in a trace waterfall UI. Built-in evaluation framework (hallucination, Q&A accuracy, toxicity) runs over captured traces.

Overlap with us: Our GET /workspaces/:id/traces endpoint and Langfuse integration solve the same problem — making agent behaviour inspectable after the fact. Phoenix's span-level trace waterfall (LLM call → tool call → next LLM call) is more granular than our per-A2A-message activity_logs. Any team evaluating Molecule AI will compare our trace depth to Phoenix's.

Differentiation: Phoenix is a pure observability layer — no agent runtime, no org hierarchy, no A2A, no workspace lifecycle. Molecule AI is the platform that runs agents; Phoenix can be wired in as the backend for our trace data. They're complementary by design: an OpenTelemetry exporter in each Molecule AI workspace adapter could ship spans to a Phoenix instance with zero code change.

Worth borrowing: Span-level trace waterfall — tool calls, LLM inputs/outputs, and latency shown as a nested tree per agent run. Our current trace view shows A2A messages; this granularity is the natural next step. Evaluation datasets from traces — capturing production traces as an eval dataset is a clean pattern for improving agent quality without manual labeling.

Terminology collisions: "traces" — same word, same meaning. Molecule AI's GET /workspaces/:id/traces → Langfuse; Phoenix offers an alternative or complementary backend.

Signals to react to: If Phoenix becomes the de facto OTel backend for LangGraph + CrewAI workspaces → add an OTEL_EXPORTER_OTLP_ENDPOINT env var to our workspace containers and document Phoenix as the recommended trace backend. If Phoenix ships agent evaluation pipelines that score multi-turn A2A conversations → directly useful for Molecule AI's QA Engineer workspace.

Last reviewed: 2026-04-13 · Stars / activity: ~5k ⭐, v8.x, actively maintained

SWE-agent — `SWE-agent/SWE-agent`

Pitch: "SWE-agent turns LLMs into software engineers that can fix real bugs and implement features in GitHub repos."

Shape: Python framework (MIT), ~16k ⭐, v1.0.6 released March 2026. A research project from Princeton NLP. An LLM is given a SWE-agent Computer Interface (ACI) — a curated set of bash tools and file-viewing commands purpose-built for code navigation — and autonomously works through GitHub issues end-to-end. No persistent agent identity; each run is ephemeral. Benchmarked heavily on SWE-bench: scored ~12% (GPT-4 turbo) up to ~53% with Claude 3.7 Sonnet. The ACI (not the LLM) is the key innovation — existing tools like bash/grep/vim are replaced by search-and-edit primitives that reduce LLM confusion in large codebases.

Overlap with us: SWE-agent's ACI is the reference design for what our Backend Engineer, Frontend Engineer, and QA Engineer workspaces should have as their tool surface. Our workspaces currently rely on Claude Code's built-in tooling (Read, Edit, Bash, Grep, Glob) plus MCP skills; SWE-agent's research shows that custom ACI primitives improve coding benchmark scores meaningfully. Both platforms run LLMs inside Docker containers to execute code safely.

Differentiation: SWE-agent is a single-run task solver — give it an issue, get a patch. No persistent state, no org hierarchy, no scheduling, no multi-agent coordination, no canvas. It's a benchmark runner and research artifact, not an operational platform. Molecule AI workspaces remember context across sessions, hold roles, coordinate with siblings, and run on schedules. SWE-agent is what you'd want our Backend Engineer workspace to invoke for a focused one-shot task, not what replaces the workspace.

Worth borrowing:

Agent Computer Interface primitives — open, scroll, search_file, find_file, edit with line ranges are strictly better than raw bash for LLM coding agents. Our workspaces could expose these as platform-installed skills to reduce token waste on naive bash usage.
Thought/action/observation trace format — SWE-agent logs a structured trace of every reasoning step. Worth adopting as the schema for our GET /workspaces/:id/traces endpoint instead of raw activity log text.
Cost/performance tradeoff tracking — SWE-bench results per model at different temperatures are published with cost estimates. This is the data we need for our model_policy routing strategy (cheap model for low-stakes tasks, expensive for SWE-bench-class tasks).

Terminology collisions:

"agent" — SWE-agent: a one-shot issue-solving process. Ours: a long-lived Docker workspace.
"environment" — SWE-agent: a sandboxed Docker container with the repo. Ours: the workspace_dir bind-mount. Same concept, different lifecycle.
"trajectory" — SWE-agent: one full (thought+action+observation)* run. We should use this term for our trace schema going forward.

Signals to react to:

If SWE-agent adds persistent memory between runs → crosses from benchmark tool to agent platform; reassess positioning.
If SWE-bench scores with Claude cross 70% → the underlying ACI + model combo is good enough for production unattended use; evaluate as a Molecule AI runtime adapter for one-shot engineering tasks.
If the ACI spec gets published as a standard tool surface → adopt it in our platform-installed skill set so Molecule AI coding agents benchmark cleanly on SWE-bench.

Last reviewed: 2026-04-13 · Stars / activity: ~16k ⭐, v1.0.6 March 2026

Devin — `cognition.ai` (commercial, no public repo)

Pitch: "The first AI software engineer — Devin works alongside your team to tackle complex engineering tasks end-to-end."

Shape: Commercial SaaS (Cognition AI, ~$2B valuation). Devin is a fully autonomous AI software engineer: given a task (natural language, GitHub issue, or Slack message), it opens a browser and a terminal in a sandboxed environment, writes and runs code, debugs failures, opens PRs, and iterates until done — all without human intervention. Persistent session per task; Devin can pick up where it left off. Teams access via Slack bot or web UI. Enterprise-tier pricing, no self-serve API.

Overlap with us: Devin's session model — a long-lived, role-holding agent with persistent state that can be assigned tasks asynchronously and delivers results via Slack — is the same shape as a Molecule AI Backend Engineer workspace. Both use Docker containers, both accept A2A-style message delegation, both hold a role across sessions. Cognition has productized exactly the "one AI teammate" use case that our per-workspace org model targets.

Differentiation: Devin is a single fully-managed AI engineer, not a platform for building multi-agent teams. No org hierarchy, no canvas, no registry, no A2A protocol between multiple Devins. Molecule AI lets teams deploy many specialized workspaces that coordinate — a PM delegates to a Dev Lead who delegates to a Backend Engineer. Devin is one very capable engineer; Molecule AI is the company those engineers work in. Devin's moat is vertical depth and polish (browser, full IDE, PR workflow out of the box); ours is composability and multi-agent coordination.

Worth borrowing:

Slack-native task assignment — Devin accepts tasks from Slack with zero friction: @Devin fix the auth bug in PR #123. Our Telegram channel integration is close, but formal Slack-bot task routing (task accepted, progress updates, done notification) should match this UX. Map to workspace_channels + approvals flow.
Session replay / audit trail — Devin records every browser action, terminal command, and file edit in a viewable replay. Our GET /workspaces/:id/traces and activity_logs give the data; a UI replay view would close the gap for customers who need to audit AI work.
Task acceptance confirmation before execution — Devin sends a plan and waits for explicit human approval before starting expensive work. This maps cleanly onto our approvals table: add a "plan approval" step before any long-running delegation.

Terminology collisions:

"session" — Cognition: a self-contained task execution run with persistent context. Ours: not a first-class concept (workspace is the persistent unit). No hard collision; avoid using "session" in our Devin-comparison docs.
"teammate" — Devin's primary marketing metaphor. We use "agent" or "workspace." If Devin's framing wins the market, consider adopting "AI teammate" in our onboarding copy.

Signals to react to:

If Cognition opens a public API for Devin → evaluate as a Molecule AI adapter (devin runtime). Teams could provision a Devin workspace alongside Claude Code workspaces for tasks that benefit from browser access.
If Devin adds multi-agent orchestration (multiple Devins coordinating on a project) → direct competitor to our multi-workspace org model; expect significant marketing push.
If SWE-bench scores plateau and Cognition shifts positioning toward "AI company" (not just "AI engineer") → direct brand conflict; double down on our team-of-agents narrative.

Last reviewed: 2026-04-13 · Stars / activity: commercial SaaS, ~$2B valuation, no public repo

Cline — `cline/cline`

Pitch: "AI coding assistant that lives in VS Code and can autonomously edit files, run commands, and browse the web."

Shape: VS Code extension (Apache-2.0), ~44k ⭐, pushed daily. Wraps any LLM (Claude, GPT-4o, Gemini, DeepSeek, local via Ollama) with a system-level tool belt: read/write files, run shell commands, call browser MCP. Single active session per VS Code window. Marketplace install, no containers, no persistent agent identity between sessions.

Overlap with us: Cline's Claude-backed coding session is the same core loop as a Molecule AI Claude Code workspace — both wrap Claude with file+shell tools and stream results. super-dev explicitly runs inside Cline. Developers who discover Cline as a quick "AI pair programmer" are exactly our target user for the Claude Code runtime.

Differentiation: Cline is a VS Code-local tool, not a multi-agent platform. No persistent identity between sessions, no org hierarchy, no A2A between agents, no WebSocket canvas, no scheduling. "Done" for Cline means a code change lands in the editor; "done" for Molecule AI means a team of agents deployed a feature through a review pipeline. Complementary shapes — a Cline user who needs parallelism is a Molecule AI convert.

Worth borrowing: Auto-approval modes (read-only → write → execute tiers) with per-command diff review — more granular than our single approvals gate. The "cost meter" (running token spend shown in UI) is a cheap trust-building feature for our Canvas.

Terminology collisions: "task" — their in-session coding task vs our current_task heartbeat field. "tools" — same word, both mean structured LLM tool calls.

Signals to react to: If Cline adds multi-session agent persistence or cross-window agent communication → direct threat to our Claude Code runtime story. If Cline's MCP support becomes the de facto way developers wire tools → align our workspace tool model to the same MCP surface.

Last reviewed: 2026-04-13 · Stars / activity: ~44k ⭐, pushed daily

OpenHands — `All-Hands-AI/OpenHands`

Pitch: "Open-source AI software engineer — let AI be your co-developer: browse the web, write code, run commands, and collaborate on tasks."

Shape: Python + TypeScript (MIT), ~47k ⭐, v0.39.0. Web-hosted UI (or local Docker) where an AI agent operates inside a sandboxed runtime (browser, shell, files) to complete multi-step engineering tasks. Supports Claude, GPT-4o, Gemini, DeepSeek. SWE-Bench top-ranked open-source system. Community of ~3k contributors.

Overlap with us: OpenHands is the closest open-source parallel to a Molecule AI Claude Code workspace — both run an AI agent with shell+file access inside a container. The sandbox model (Docker-isolated execution, browser use, file I/O) is identical to our workspace-template runtime layer. Molecule AI users building a "solo engineer" workspace are building what OpenHands ships out of the box.

Differentiation: OpenHands is single-agent, single-task — no org hierarchy, no A2A between agents, no visual canvas, no scheduling, no persistent identity across sessions. A single "project" is one sandboxed run. Molecule AI is a persistent, multi-agent company with A2A, schedules, and a visual org chart. OpenHands is the reference implementation for the solo-agent shape; Molecule AI is the platform for the team shape.

Worth borrowing: CodeAct action space — agent emits Python code instead of JSON tool schemas; code is executed directly in the sandbox. More expressive than JSON tool calls and simpler to extend. If our workspace agents need arbitrary tool composition, CodeAct is worth evaluating as an alternative to our MCP tool list.

Terminology collisions: "workspace" — theirs is a sandboxed task run; ours is a long-lived Docker container with an agent role. "agent" — same word, different persistence model.

Signals to react to: If OpenHands ships multi-agent coordination (agents spawning sub-agents with shared memory) → direct overlap with our team model. If their SWE-Bench rank approaches GPT-4o with an open model → cost-effective backend for our DevOps / QA workspaces.

Last reviewed: 2026-04-13 · Stars / activity: ~47k ⭐, v0.39.0, very active

Scion — `GoogleCloudPlatform/scion`

Pitch: "An experimental agent hypervisor — each agent runs in its own isolated container with dedicated credentials, config, and git worktree; orchestrates Claude Code, Gemini CLI, Codex, and OpenCode concurrently."

Shape: Go + YAML (Apache-2.0). Container-per-agent isolation via Docker, Podman, Apple Containers, or Kubernetes. Named runtime profiles. Introduces an agents.md capability-declaration convention. Not a framework — a harness supervisor.

Overlap with us: Container-per-agent mirrors our Docker workspace model. Multi-harness concurrency maps to multi-workspace A2A topology. Explicitly manages Claude Code — direct contact with our user base.

Differentiation: No persistent agent memory, no visual canvas, no A2A between agents, no channels. It is the container orchestration layer beneath agents; we are the agent identity and collaboration layer above.

Worth borrowing: agents.md capability spec — a standard file per workspace declaring what the agent can do. Adopt in workspace-template/ for Scion interoperability.

Terminology collisions: "profile" — Scion: named runtime config; ours: undefined. "harness" — both mean "the process managing agent execution."

Signals to react to: If Scion adds A2A or a memory layer → direct overlap. If agents.md gains wide adoption → align workspace-template/ to the spec.

Last reviewed: 2026-04-15 · Stars / activity: GCP repo, 230 HN pts at launch, April 8, 2026

claude-mem — `thedotmack/claude-mem`

Pitch: "Automatically captures everything Claude does during coding sessions — persistent cross-session memory with search, timeline, and observation retrieval as MCP tools."

Shape: TypeScript (AGPL-3.0), ~56k ⭐, +2,997 stars in one day. Five lifecycle hooks (SessionStart, UserPromptSubmit, PostToolUse, Stop, SessionEnd) intercept agent actions, compress observations via Claude SDK, store in SQLite FTS5 + Chroma hybrid. Three MCP tools exposed: search, timeline, get_observations. Web viewer at localhost:37777. ⚠️ ragtime/ retrieval subdirectory is PolyForm Noncommercial — reimplementation required for commercial SaaS use.

Overlap with us: Directly addresses our known cross-session memory gap. Lifecycle hooks are structurally compatible with our harness entry points.

Differentiation: A memory add-on for a single Claude Code session; no A2A, no org hierarchy, no scheduling, no channels.

Worth borrowing: PostToolUse + SessionEnd → compressed observation pipeline, compatible with our harness lifecycle. Progressive-disclosure retrieval (summaries first, full content on demand) caps token overhead at SessionStart.

Terminology collisions: "observations" — their captured agent actions; not a first-class term in our platform.

Signals to react to: If PolyForm NC removed from ragtime/ → evaluate direct integration. If hook schema is formalized → adopt as standard workspace lifecycle spec.

Last reviewed: 2026-04-15 · Stars / activity: ~56k ⭐, +2,997 today

Multica — `multica-ai/multica`

Pitch: "Turn coding agents into real teammates — assign tasks, track progress, compound skills."

Shape: TypeScript + Go (Next.js 16 / Chi router / PostgreSQL 17 + pgvector), ~12.8k ⭐, +1,503 today. Local agent daemons execute Claude Code / Codex / OpenCode in isolation; state syncs to a central backend. Solved tasks are semantically indexed via pgvector and surfaced to future agents team-wide — the "skill-compounding" model. 36 releases, 1.6k forks, actively shipped.

Overlap with us: Skill-compounding maps to our plugin/skills registry but adds automatic semantic indexing. Local-daemon + central-backend mirrors Docker workspaces + Canvas backend. Cross-agent task assignment and scheduling are first-class features.

Differentiation: No visual org-chart canvas, no A2A protocol, no persistent agent identity across restarts, no channel integrations. Central backend is a coordination hub, not peer-to-peer. Closer to a task manager for agents than an agent company platform.

Worth borrowing: pgvector semantic indexing of solved tasks — each completed workspace run contributes to a searchable skill pool, evolving our plugin registry from file-based discovery to semantic retrieval.

Terminology collisions: "skills" — their skills are solved-task embeddings; ours are installed behaviour bundles.

Signals to react to: If Multica adds A2A or persistent agent identity → direct competitor. Star velocity (+1,503/day) warrants weekly tracking.

Last reviewed: 2026-04-15 · Stars / activity: ~12.8k ⭐, +1,503 today, 36 releases

Skills CLI — `vercel-labs/skills`

Pitch: "The CLI for the open agent skills ecosystem — discover, install, and share reusable skills across 45+ coding agents."

Shape: TypeScript (MIT), ~14.2k ⭐, +153 today. npx skills package manager backed by Vercel. Skills are SKILL.md directories following the agentskills.io open spec. Targets Claude Code, Codex, Gemini CLI, Cursor, Cline, OpenCode, Hermes, Holaboss, and 37+ others from a single repository.

Overlap with us: Three existing entries (Hermes, gstack, Holaboss) flag "if agentskills.io picks up mass adoption → align our plugin manifest." This is that moment: Vercel ships the canonical install CLI with 14k stars and 45-agent coverage.

Differentiation: Skills CLI is a package manager, not an agent runtime. No canvas, A2A, or scheduling. It installs behavior bundles into whatever agent the developer uses; Molecule AI is the runtime those bundles run inside.

Worth borrowing: Align our plugins/ manifest to the agentskills.io SKILL.md spec so any npx skills-installable skill also installs cleanly into a Molecule AI workspace. Dual compatibility = free distribution channel.

Terminology collisions: "skills" — same word, same filesystem convention; full spec alignment is the goal, not a collision to manage.

Signals to react to: If npx skills becomes the de facto install path industry-wide → our plugins/install should natively consume the same manifest format. If agentskills.io publishes a versioned schema → adopt it immediately in plugins/.

Last reviewed: 2026-04-15 · Stars / activity: ~14.2k ⭐, +153 today, Vercel-backed

Archon — `coleam00/Archon`

Pitch: "The first open-source harness builder for AI coding — make AI coding deterministic and repeatable."

Shape: TypeScript (MIT), ~18.1k ⭐, +396 today. Defines AI coding workflows as YAML DAGs: planning → implementation → validation → review → PR. Each run is git-worktree-isolated. Nodes are either AI-powered (Claude Code generation) or deterministic (bash, test runners). Human approval gates at any phase. Delivery to Slack, Telegram, Discord, GitHub, or web UI. "What Dockerfiles did for infra, Archon does for AI coding."

Overlap with us: Wraps Claude Code in a structured pipeline — the same pattern as our Dev Lead delegating to a Claude Code workspace. Approval gates map to our approvals table. Git-worktree isolation mirrors our workspace-template/ worktree pattern.

Differentiation: No persistent agent identity, no org hierarchy, no A2A, no canvas, no multi-session scheduling. Archon defines a single delivery run; Molecule AI is the persistent company those runs operate inside.

Worth borrowing: YAML-DAG workflow definition (planning → implementation → validation → PR) with mixed AI/deterministic nodes — natural extension of workspace-template/ for repeatable, auditable delivery pipelines.

Terminology collisions: "workflow" — their YAML DAG vs our informal usage. "harness" — Archon, Scion, and our Claude Code runner all claim the word; Molecule AI docs should clarify its own use.

Signals to react to: If Archon adds multi-workspace coordination → direct competitor to our orchestration layer. If their YAML workflow schema gains wide adoption → add an Archon import adapter to workspace-template/.

Last reviewed: 2026-04-15 · Stars / activity: ~18.1k ⭐, +396 today, v0.3.6

Claude Code Routines — `anthropic.com` (commercial, no public repo)

Pitch: "Schedule Claude Code agents to run automatically on timers and GitHub events — agentic workflows in the cloud without manual intervention."

Shape: Anthropic-hosted cloud feature. Users define routines that fire a Claude Code session on cron timers or GitHub events (push, PR, issue). Runs serverlessly inside Anthropic infrastructure. No self-hosting, no public API. HN item 47768133: 611 pts, 355 comments at launch today — significant community concern about vendor lock-in.

Overlap with us: Direct overlap with workspace_schedules + cron-triggered workspace execution. Anthropic now competes in the scheduled agentic execution space with a first-party hosted offering.

Differentiation: No persistent agent memory, no org hierarchy, no A2A between agents, no visual canvas, no multi-model support, Anthropic-only lock-in. HN consensus: "trivially reproducible with cron + API." Our differentiators: multi-agent coordination, persistent identity, model-agnosticism, self-hostability.

Worth borrowing: GitHub event triggers (push/PR/issue → fire agent) as first-class schedule trigger types. Our workspace_schedules is cron-only; this gap is now competitively visible.

Terminology collisions: "routine" — Anthropic: a scheduled agent session; near-synonym with our workspace_schedule rows.

Signals to react to: If Routines adds A2A between routines → direct platform competition from Anthropic with massive distribution advantage. If lock-in backlash grows → double down on "self-hostable, model-agnostic" narrative as the open alternative.

Last reviewed: 2026-04-15 · Stars / activity: Anthropic cloud feature, 611 HN pts today (item 47768133)

Microsoft Agent Framework — `microsoft/agent-framework`

Pitch: "A framework for building, orchestrating and deploying AI agents and multi-agent workflows with support for Python and .NET."

Shape: Python + C#/.NET (MIT), ~9.5k ⭐, April 2026 active releases. Graph-based workflow engine with streaming, checkpointing, and human-in-the-loop approval gates. Supports Azure OpenAI, Microsoft Foundry, and OpenAI. Ships a DevUI for interactive debugging, OpenTelemetry observability, and "AF Labs" (experimental RL-based features). Ships a migration guide from AutoGen — this is the official Microsoft successor to microsoft/autogen.

Overlap with us: Our workspace-template adapters target AutoGen/AG2; this is the official Microsoft path forward, making our adapter coverage incomplete. HITL approval gates and graph-based multi-agent routing mirror our approvals table + delegation chain.

Differentiation: Orchestration SDK only — no persistent agent memory, no org-chart canvas, no A2A between independently deployed agents, no scheduling, no channel integrations.

Worth borrowing: DevUI interactive debugging panel (inspect agent state mid-run without a full canvas). AF Labs RL routing — agents improve delegation decisions from past run outcomes; worth evaluating for our PM workspace's delegate_task routing.

Terminology collisions: "middleware" — their processing pipeline hook; undefined in our platform. "graph" — their workflow DAG vs our live org chart (same word, different semantics).

Signals to react to: If AF 1.0 achieves enterprise adoption → update our autogen adapter to target microsoft/agent-framework. If AF Labs RL ships stable → evaluate for dynamic PM routing based on workspace performance history.

Last reviewed: 2026-04-15 · Stars / activity: ~9.5k ⭐, April 2026 .NET release, official AutoGen successor

Open Agents — `vercel-labs/open-agents`

Pitch: "An open-source reference app for building and running background coding agents on Vercel — fork it, adapt it, ship your own cloud coding agent."

Shape: TypeScript (MIT), ~2.2k ⭐, +1,020 today. Three-layer architecture: web UI → agent workflow (Vercel Workflow SDK for durable execution) → isolated sandbox VM. Key design principle: agent runs outside the sandbox VM and interacts with it through tools — not co-located. Snapshot-based VM resumption, auto-commit/push/PR, session sharing via read-only links, voice input. From Vercel Labs — same team as the Skills CLI entry above.

Overlap with us: Vercel Workflow SDK gives checkpoint-and-resume durability — the same gap our workspace restart-context solves ad hoc. Agent-outside-sandbox mirrors our Docker workspace + adapter separation. Auto-PR creation is a first-class feature we implement manually.

Differentiation: Single coding agent, no org hierarchy, no A2A, no scheduling, no persistent memory across sessions, no channels. A reference template, not an operational platform.

Worth borrowing: Snapshot-based sandbox resumption — preserves VM state across agent restarts without re-cloning the repo. More efficient than our current Docker restart + git clone approach for long-running workspace tasks.

Terminology collisions: "workflow" — Vercel's durable execution primitive; our informal delegation chain term.

Signals to react to: If Vercel Workflow SDK becomes a standard durable-execution backend → evaluate as a drop-in for workspace_schedules on Vercel-hosted deployments. If open-agents adds multi-agent coordination → direct competitor reference app with Vercel distribution.

Last reviewed: 2026-04-15 · Stars / activity: ~2.2k ⭐, +1,020 today, Vercel Labs

Gemini CLI — `google-gemini/gemini-cli`

Pitch: "An open-source AI agent that brings the power of Gemini directly into your terminal."

Shape: TypeScript (Apache 2.0), ~101k ⭐, v0.38.1 released April 15, 2026. Single-agent interactive CLI with a 1M-token context window (Gemini models). Tool surface: file read/write, shell execution, web fetch, Google Search grounding. MCP support via ~/.gemini/settings.json — any MCP server can extend its tool set. ReAct loop architecture. No persistent agent identity between sessions. Ships from Google's own org (google-gemini).

Overlap with us: Direct structural parallel to our Claude Code runtime adapter — both are agentic CLIs wrapping a frontier model with file+shell tools. Developers choosing between Claude Code and Gemini CLI for their workspace runtime will hit our adapter story immediately. MCP support means the same skills installed for a Claude Code workspace can target a Gemini CLI workspace with zero changes.

Differentiation: No persistent memory, no org hierarchy, no A2A, no scheduling, no canvas. A session ends when the terminal closes. Molecule AI's Claude Code adapter sits on top of Claude Code; Gemini CLI would need a parallel adapter. We're the platform; Gemini CLI is the runtime candidate.

Worth borrowing: Google Search grounding as a first-class tool — grounded web results with citations surfaced inline. Our Research Lead workspace uses raw WebSearch; grounding would reduce hallucinated citations. Consider exposing a google_search_grounded tool in our claude-code skill pack.

Terminology collisions: "agent" — their single-session CLI process; our long-lived Docker workspace.

Signals to react to: If Gemini CLI adds persistent memory between sessions → it closes the gap with our Claude Code adapter; push adoption of the gemini-cli runtime adapter. If gemini-cli MCP adoption exceeds claude-code MCP adoption → re-weight our adapter documentation priority. If Google ships a multi-agent layer on top of Gemini CLI → direct platform threat with massive distribution.

Last reviewed: 2026-04-16 · Stars / activity: ~101k ⭐, v0.38.1 April 15, 2026, Google-maintained

open-multi-agent — `JackChen-me/open-multi-agent`

Pitch: "TypeScript multi-agent framework — one runTeam() call from goal to result. Auto task decomposition, parallel execution. 3 dependencies, deploys anywhere Node.js runs."

Shape: TypeScript (MIT), ~5.7k ⭐, v1.1.0 released April 1, 2026. Coordinator-based architecture: one coordinator agent decomposes a natural-language goal into a dependency DAG of tasks, assigns each to a specialist agent, and fans results back. Shared message bus + memory pool across the agent pool. Three runtime deps (@anthropic-ai/sdk, openai, zod). MCP servers connected via connectMCPTools(). Supports Claude, GPT, Gemini, Grok, Ollama, and any OpenAI-compatible endpoint per-agent.

Overlap with us: Coordinator-DAG decomposition mirrors our PM → Dev Lead → Engineer delegation chain, but automated at runtime from a single goal string — where we rely on system-prompt-encoded delegation rules. The shared message bus maps to our A2A event queue. MCP-native means workspace skills install into open-multi-agent teams as easily as ours. The per-agent model selection (cheap model for shallow tasks, expensive for deep) is the same model_policy we've been deferring.

Differentiation: No persistent agent identity across runs, no visual canvas, no scheduling, no Docker isolation, no channels. Teams are ephemeral in-process objects. Molecule AI is an operational platform for long-lived agents; open-multi-agent is a library for one-shot goal execution.

Worth borrowing: Runtime goal-to-DAG decomposition — instead of hard-coding delegation trees in system prompts, the PM workspace could call a decomposition step that generates a task graph from the user's goal. Cheap to prototype: wrap runTeam() logic as a PM skill.

Terminology collisions: "coordinator" — their orchestrating agent; our PM workspace plays the same role but with a persistent identity. "team" — their ephemeral agent pool; our org-chart canvas of live workspaces.

Signals to react to: If open-multi-agent adds persistent agent state → library becomes a platform; assess as a dependency or competitor for our TypeScript SDK. If runTeam() pattern becomes idiomatic in the Node.js agent ecosystem → expose a compatible API surface in our SDK for parity.

Last reviewed: 2026-04-16 · Stars / activity: ~5.7k ⭐, v1.1.0 April 1, 2026, MIT

AgentScope — `modelscope/agentscope`

Pitch: "Build and run agents you can see, understand and trust."

Shape: Python (Apache 2.0), ~23.8k ⭐, v1.0.18 released March 26, 2026. Alibaba/ModelScope. Multi-agent: MsgHub typed message routing, ReAct agents, sequential and concurrent pipelines. MCP client integration. OpenTelemetry observability built-in. Voice agent support. RL-based agent tuning (experimental).

Overlap with us: MCP support means AgentScope agents can call tools exposed by our MCP server — potential consumer of our registry. Pipeline orchestration (sequential / concurrent) is structurally the same as our PM → Dev Lead → Engineer delegation chain. OpenTelemetry instrumentation parallels our GET /workspaces/:id/traces + Langfuse stack.

Differentiation: Code-first Python SDK — no visual canvas, no Docker workspace lifecycle, no org-chart hierarchy, no scheduling, no channels, no A2A between independently deployed agents. It's a framework for building agent logic in-process; we're the platform that deploys and coordinates agents as long-lived services.

Worth borrowing: MsgHub typed routing (messages carry sender/receiver type metadata, enabling selective fan-out) — more expressive than our flat A2A event queue. RL trajectory logging for agent tuning — if our activity_logs adopt the same schema, workspace runs become training data.

Terminology collisions: "pipeline" — their orchestration primitive; we use "delegation chain" informally. "service agent" — their long-running agent variant; close to our workspace concept.

Signals to react to: If AgentScope ships a deployment layer (Docker/Kubernetes-managed agent lifecycle) → direct overlap with our workspace model. If their RL tuning reaches stable → evaluate for PM routing improvement.

Last reviewed: 2026-04-16 · Stars / activity: ~23.8k ⭐, v1.0.18 March 26, 2026, Alibaba/ModelScope

Plannotator — `backnotprop/plannotator`

Pitch: "Annotate and review coding agent plans and code diffs visually — share with your team, send feedback to agents with one click."

Shape: TypeScript (Apache 2.0 + MIT dual), ~4.3k ⭐, v0.17.10 April 13, 2026. CLI install → opens browser UI for plan annotation. Supports Claude Code, Gemini CLI, Codex, OpenCode, Copilot CLI. Annotation primitives: delete, insert, replace, comment. Structured feedback returned to agent. Shareable plan links (URL-encoded or encrypted, 7-day expiry).

Overlap with us: Direct overlap with hitl.py (shipped PR #346) and the approvals table. Both implement "pause agent → human reviews → structured feedback → resume." Plannotator specifically targets the plan approval moment — exactly what requires_approval in hitl.py gates. The annotation type model (delete/insert/replace/comment) is more expressive than our current resume_task(message: str) free-text feedback.

Differentiation: A review UX tool, not an agent platform. No agent runtime, no memory, no scheduling, no A2A, no org hierarchy. Molecule AI runs the agents; Plannotator is what the review UI could look like.

Worth borrowing: Structured annotation types as HITL feedback schema — replace message: str in resume_task with {action: "approve"|"reject"|"modify", annotations: [{type: "delete"|"insert"|"replace"|"comment", ...}]}. Shareable approval links with expiry — our approve/deny URLs are static; time-bounded links improve security.

Terminology collisions: "plan" — their agent's proposed action list; we use this informally in system prompts.

Signals to react to: If Plannotator adds MCP integration → agents could self-request plan review via tool call; evaluate as a native HITL trigger in our platform.

Last reviewed: 2026-04-16 · Stars / activity: ~4.3k ⭐, v0.17.10 April 13, 2026

GenericAgent — `lsdefine/GenericAgent`

Pitch: "Self-evolving agent: grows a skill tree from a 3.3K-line seed, achieving full system control with 6x less token consumption."

Shape: Python (MIT), ~2.1k ⭐, v1.0 released January 16, 2026. Single-agent, system-level: browser automation, terminal, filesystem, keyboard/mouse, screen vision, mobile/ADB. Nine atomic tools. Self-evolving skill tree: each solved task is crystallised into a reusable skill stored in a four-tier memory hierarchy (L0 rules → L1 indices → L2 facts → L3 task-skills → L4 session archives). Subsequent similar tasks skip exploration and replay the stored skill directly. No MCP. No multi-agent.

Overlap with us: The four-tier memory taxonomy (rules / indices / facts / skills / archives) is structurally more expressive than our flat agent_memories key-value table. Skill crystallisation — automatically converting a solved task into a reusable procedure — is the same instinct as our plugins/ registry but applied at runtime rather than install-time.

Differentiation: Single agent, no org hierarchy, no A2A, no canvas, no channels. The skill tree grows from one user's usage; our plugins are shared org-wide. GenericAgent targets "personal OS agent"; we're "AI company for engineering teams."

Worth borrowing: Four-tier memory taxonomy as a named model for agent_memories — add explicit labels (rules / facts / skills / archives) to our memory scopes to improve inspectability and retrieval quality.

Terminology collisions: "skills" — theirs are crystallised task executions (runtime-generated procedures); ours are installed behaviour bundles (developer-authored Markdown). Same word, different origin.

Signals to react to: If skill crystallisation gets formalised as a standard (e.g., aligns with agentskills.io schema) → evaluate automatic skill generation from workspace task history.

Last reviewed: 2026-04-17 · Stars / activity: ~2.1k ⭐, v1.0 January 16, 2026, active

OpenSRE — `Tracer-Cloud/opensre`

Pitch: "Build your own AI SRE agents — the open source toolkit for the AI era."

Shape: Python (Apache 2.0), ~900 ⭐, active 2026. Framework + toolkit for AI-powered Site Reliability Engineering. Agents autonomously investigate incidents: fetch alert context, correlate logs/metrics/traces, identify root cause, suggest remediation, optionally execute fixes. 40+ pre-built integrations: LLM providers (OpenAI, Anthropic, Gemini, local), observability (Grafana, Datadog, Honeycomb, CloudWatch), infrastructure (K8s, AWS EKS/EC2/Lambda, GCP, Azure), databases, PagerDuty, Slack. MCP support including GitHub MCP. Incident summaries delivered directly to Slack/PagerDuty channels.

Overlap with us: Our DevOps workspace (org-templates/molecule-dev/devops/) handles infrastructure monitoring and deployment tasks — the same surface OpenSRE's agents cover. MCP integration means OpenSRE tools could be consumed by a Molecule AI DevOps workspace as a skill pack. Slack/PagerDuty delivery mirrors our workspace_channels feature.

Differentiation: OpenSRE is a specialised SRE toolkit, not a general agent platform. No visual canvas, no org hierarchy, no A2A between agents, no scheduling, no memory across sessions.

Worth borrowing: 40+ production-tested DevOps integrations as a reference skill pack — rather than building infra tool integrations from scratch, evaluate wrapping OpenSRE's adapters as Molecule AI DevOps workspace skills.

Terminology collisions: "agent" — their incident-response runner; our long-lived Docker workspace.

Signals to react to: If OpenSRE ships a workspace/session persistence layer → closes the gap with our DevOps adapter; reassess. If their 40+ integration catalogue becomes the de facto DevOps tool standard → make them a first-class skill pack dependency for DevOps workspaces.

Last reviewed: 2026-04-17 · Stars / activity: ~900 ⭐, Apache 2.0, actively maintained

AMD GAIA — `amd/gaia`

Pitch: "Build AI agents for your PC — an open-source framework for agents that run 100% locally on AMD Ryzen AI hardware with no cloud dependency."

Shape: Python + C++ (MIT), ~1.2k ⭐, v0.17.2 April 10, 2026. AMD-backed. Requires AMD Ryzen AI 300+ hardware (NPU-accelerated); no NVIDIA/CPU-only path documented. High-level API: subclass Agent, decorate tools with @tool, define system prompt. MCP client support — connects to any MCP server for external tool access. Built-in RAG (50+ file formats), vision (Qwen3-VL), voice (Whisper ASR + Kokoro TTS). pip install amd-gaia.

Overlap with us: MCP support means GAIA agents can consume the same tool servers our workspaces use. The @tool decorator registration pattern is structurally identical to our @app.workflow_task. "No cloud dependency" is a shared positioning — we're both self-hostable, privacy-first alternatives to managed cloud agents. GAIA targets the developer's laptop; Molecule AI targets the team's server.

Differentiation: Hardware-locked to AMD Ryzen AI — not general-purpose. No A2A, no org hierarchy, no canvas, no scheduling, no channels. Single-agent. Molecule AI runs anywhere Docker runs.

Worth borrowing: Clean @tool decorator pattern for agent tool registration — simpler than our MCP-tool-as-config approach; worth evaluating for the workspace adapter layer. RAG + vision + voice as first-class built-ins show what a complete local agent surface looks like.

Terminology collisions: "agent" — their in-process Python object; our Docker workspace. "tool" — same concept, same decorator pattern.

Signals to react to: If GAIA adds NVIDIA/CPU-only support → becomes a general local-agent framework with serious AMD backing; evaluate as a runtime adapter. If MCP server protocol via GAIA gains adoption → alignment already exists via our MCP server (#313).

Last reviewed: 2026-04-18 · Stars / activity: ~1.2k ⭐, v0.17.2 April 10, 2026, AMD-maintained

ClawRun — `clawrun-sh/clawrun`

Pitch: "Deploy and manage AI agents in seconds — one config to launch secure, sandboxed agents across any cloud."

Shape: TypeScript (Apache 2.0), ~84 ⭐, 45 releases, active 2026. Hosting and lifecycle layer for open-source agents: deploys into secure Vercel Sandboxes (more providers planned), manages startup, heartbeat keep-alive, snapshot/resume, and wake-on-message. Channels: Telegram, Discord, Slack, WhatsApp. Web dashboard + CLI. Cost tracking and budget enforcement per channel. Pluggable agent/provider/channel architecture.

Overlap with us: This is the closest architectural match we've tracked. Feature-for-feature: sandbox → our Docker workspace, heartbeat → our active_tasks + last_heartbeat, snapshot/resume → our workspace pause/resume, channels → our workspace_channels, cost tracking → our usage logging, pluggable architecture → our adapter + plugin system. ClawRun is building the same platform from a different starting point (agent hosting → adding channels) vs our approach (multi-agent org → adding deployment).

Differentiation: No visual canvas, no org hierarchy, no A2A between agents, no memory, no scheduling, no multi-agent coordination. 84 stars signals early stage — but 45 releases shows active shipping. Our differentiator: agent identity + memory + A2A coordination vs ClawRun's pure hosting focus.

Worth borrowing: Per-channel budget enforcement — our workspace_channels has no cost cap; adding a budget_limit field per channel would prevent runaway messaging costs. Wake-on-message lifecycle — agents sleep when idle and wake only when a message arrives; more cost-efficient than our always-on containers for low-traffic workspaces.

Terminology collisions: "sandbox" — their Vercel Sandbox container; our Docker workspace container. "channel" — same word, same concept.

Signals to react to: If ClawRun adds A2A or multi-agent coordination → becomes a direct lightweight competitor with Apache 2.0 and a simpler onboarding story. If their sandbox provider list expands (AWS/GCP/Azure) → pricing pressure on our Docker-first deployment model.

Last reviewed: 2026-04-18 · Stars / activity: ~84 ⭐, 45 releases, Apache 2.0, actively shipped

Paperclip — `paperclipai/paperclip`

Pitch: "Open-source orchestration for zero-human companies."

Shape: Python (MIT), ~54.8k ⭐, launched March 4, 2026. Hierarchical multi-agent system in which a CEO agent receives a top-level company goal, spawns Manager agents for functional areas (engineering, marketing, operations, finance), and Managers spawn Worker agents for atomic tasks. Authority and delegation flow bidirectionally through the org: workers can escalate, managers can override. Humans serve as the board with veto authority. Per-agent budget constraints and a full audit trail of every delegation decision.

Overlap with us: The CEO/manager/worker hierarchy is structurally identical to our PM → Dev Lead → Engineer delegation chain. Their "zero-human companies" is the same thesis as our "AI company" framing — and they reached 54.8k ⭐ in six weeks. Budget constraints and audit-trail export are features we've deferred; Paperclip ships both. Their bidirectional escalation (worker → manager) maps cleanly to our approvals table but is more automatic.

Differentiation: Paperclip is a framework — agents are in-process Python objects, ephemeral per run. No Docker workspace isolation, no persistent agent memory, no visual canvas, no A2A protocol, no scheduling, no channel integrations. We're the operational platform; Paperclip defines the org chart in code for one-shot execution.

Worth borrowing:

Per-agent budget constraints — token/cost ceilings per layer. Add a budget_limit field per workspace in org.yaml; enforce at the A2A delegation layer.
Audit trail schema — Paperclip logs every CEO → manager → worker delegation with decision rationale. Adopt this as the standard format for our activity_logs.
Bidirectional authority — worker escalation to manager without breaking the PM's delegation model; maps to a requires_approval flag on delegation responses.

Terminology collisions:

"CEO agent" — their top-level orchestrator; our PM workspace plays the same role.
"zero-human company" vs our "AI company" — identical positioning, watch for brand collision in marketing copy.

Signals to react to:

If Paperclip adds persistent agent memory → closes the primary gap; reassess differentiation urgently (54.8k ⭐ head start matters).
If they ship a visual org chart → direct Canvas competitor.
Paperclip is the highest-star agent-orchestration OSS project we've tracked; watch weekly.

Last reviewed: 2026-04-16 · Stars / activity: ~54.8k ⭐, launched March 4 2026, very active

Google ADK — `google/adk-python`

Pitch: "An open-source, code-first Python toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control."

Shape: Python (Apache-2.0), ~19k ⭐, v1.29.0 released April 9, 2026. Google's official multi-agent SDK — the framework companion to Gemini CLI (already tracked). Optimised for Gemini models but model-agnostic. Ships a web DevUI (google/adk-web, ~920⭐) for real-time agent debugging, a built-in evaluation framework, and pre-built tool integrations. Deployed via pip install google-adk. Actively maintained inside Google's own org.

Overlap with us: Google now has a full agent stack: Gemini CLI (interactive terminal agent) + ADK (framework for building agents) + adk-web (DevUI). Any team evaluating Molecule AI will weigh ADK + Gemini CLI as a build-your-own path. The adk-web DevUI overlaps with our Canvas's agent-inspection surface. ADK's evaluation framework is the same gap our GET /workspaces/:id/traces + Langfuse stack addresses.

Differentiation: ADK is a framework, not a platform. No persistent workspace lifecycle, no Docker container management, no visual org chart, no A2A between independently deployed agents, no scheduling, no channel integrations. It generates the agent logic; Molecule AI runs the agents as long-lived services. The two are potentially complementary: a Molecule AI workspace running ADK agents is a natural pairing.

Worth borrowing:

Built-in evaluation framework — structured agent eval runs tied to traces. Map to our GET /workspaces/:id/traces endpoint; add a companion eval-run API.
adk-web DevUI patterns — event tracking, execution-flow tracing, artifact management in a browser UI. Reference design for our Canvas trace view.
google-adk runtime adapter — add alongside our existing langgraph / autogen / openclaw adapters so Molecule AI workspaces can run ADK agent logic natively.

Terminology collisions:

"agent" — their in-process Python object; our long-lived Docker workspace.
"tool" — same concept; ADK tools and our MCP tools are structurally identical.
"runner" — ADK's execution context; distinct from our workspace container runtime.

Signals to react to:

If ADK ships persistent agent state and memory between runs → closes the primary gap with our platform; update positioning.
If ADK + Gemini CLI becomes a hosted Vertex AI managed service → Google enters platform territory with massive distribution; accelerate our model-agnostic story.
ADK is the official successor for teams currently using LangGraph with Gemini → our langgraph adapter should note ADK as an alternative path.

Last reviewed: 2026-04-16 · Stars / activity: ~19k ⭐, v1.29.0 April 9, 2026, Google-maintained

Chrome DevTools MCP — `ChromeDevTools/chrome-devtools-mcp`

Pitch: "Chrome DevTools for coding agents — MCP server enabling agents to control and inspect live Chrome browsers."

Shape: TypeScript (Apache-2.0), ~35.5k ⭐. Official ChromeDevTools org repo — the same team that maintains Chrome's built-in devtools. An MCP server exposing 23 tools across six categories: input automation (click, type, scroll), navigation (goto, back, reload), emulation (viewport, device mode), performance analysis (traces and Lighthouse insights), network analysis (HAR, request/response inspection), and debugging (source-mapped stack traces, console, screenshots). Compatible with 29 MCP clients including Claude Code, Gemini CLI, Cursor, and Copilot. Uses Puppeteer under the hood with CDP.

Overlap with us: Our browser-automation plugin connects to Chrome CDP at host.docker.internal:9223 using raw Puppeteer. Chrome DevTools MCP provides the same capabilities — and much more — as a standard MCP server any workspace agent can call without custom Puppeteer code. The 23-tool surface covers everything our current CDP integration does plus performance tracing, network HAR capture, and source-mapped stack traces we don't currently expose. Official ChromeDevTools org backing makes this the likely de facto standard for browser tool use in agents.

Differentiation: A pure MCP server — no agent runtime, no memory, no scheduling, no org hierarchy. Molecule AI is the platform that runs agents that call this MCP server. Complementary by design.

Worth borrowing:

Replace custom CDP integration — update plugins/browser-automation/ to install chrome-devtools-mcp as the standard MCP server rather than maintaining bespoke Puppeteer scripts. Agents get performance tracing, HAR capture, and source-mapped debugging for free.
23-tool surface as reference design — our current browser plugin exposes ~5 tools; this is the full coverage target.
Source-mapped stack traces — currently absent from our browser-automation debug output; immediately useful for our QA Engineer workspace.

Terminology collisions:

"DevTools" — their MCP server name; our plugin is "browser-automation." No user collision but align naming in skill docs.

Signals to react to:

If ChromeDevTools org publishes a versioned MCP manifest → treat as the browser-tool standard and pin a version in our plugin manifest.
If Anthropic or OpenAI reference this as the recommended browser MCP → accelerate the plugins/browser-automation migration.
Official org backing + 35.5k ⭐ means this is already the de facto standard.

Last reviewed: 2026-04-16 · Stars / activity: ~35.5k ⭐, ChromeDevTools org, Apache-2.0

LangGraph — `langchain-ai/langgraph`

Pitch: "Build resilient language agents as graphs — stateful, multi-actor applications with fine-grained control over agent flow."

Shape: Python + JavaScript/TypeScript library (MIT), ~29k ⭐, v1.1.6 released April 10 2026. Part of the LangChain ecosystem. Agents are modelled as directed graphs: nodes are callables (LLM calls, tool calls, conditional branches), edges are routing rules, and a persistent state schema carries data between nodes. Checkpointing (memory persistence across turns) is built in via a pluggable Checkpointer interface (in-memory, SQLite, Postgres, Redis). Multi-agent compositions via subgraph nodes. LangGraph Cloud offers hosted execution backed by LangSmith observability. LangGraph 2.0 GA shipped February 2026, adding declarative guardrail nodes (content filtering, rate limiting, audit logging as config).

Overlap with us: Molecule AI ships a langgraph runtime adapter (molecule-ai-workspace-template-langgraph) — this is us on top of LangGraph. Their graph model (nodes, edges, state) is structurally analogous to our workspace hierarchy (workspaces, A2A calls, shared context). Their Checkpointer is the lower-level equivalent of our agent_memories table. LangGraph Cloud's hosted execution competes directly with our scheduler + workspace lifecycle.

Differentiation: LangGraph is a framework for building the logic of one agent or pipeline; Molecule AI is a platform for deploying and coordinating long-lived agents as an org. LangGraph has no concept of Docker workspace isolation, org-chart hierarchy, inter-agent A2A protocol, channel integrations, visual canvas, or cron scheduling. Our langgraph adapter runs on top of LangGraph — they're layered, not competing, for most use cases. The gap is LangGraph Cloud vs our hosted platform.

Worth borrowing:

Declarative guardrail nodes (v2.0) — content filtering and audit logging as first-class graph nodes rather than custom code. Map to our approvals table: add declarative gate types (content-filter, rate-limit) in workspace config.
Subgraph composition — composing multi-agent pipelines by nesting graphs. Our workspace parent/child hierarchy is the operational equivalent; study for dynamic sub-workspace spawning UX.
Checkpointer interface — the pluggable backend design (SQLite → Postgres → Redis hot path) is the right abstraction for our agent_memories persistence layer.

Terminology collisions:

"state" — LangGraph: the typed dict carried between graph nodes; ours: workspace status (online/offline/degraded). No user confusion but docs should disambiguate.
"node" — LangGraph: a callable in the agent graph; our canvas: a workspace tile. Same word, very different level of abstraction.
"graph" — LangGraph: the directed workflow graph; our canvas: the live org chart. Marketing copy should distinguish "workflow graph" (LangGraph) vs "org chart" (us).

Signals to react to:

If LangGraph Cloud adds persistent agent identity (long-lived named agents beyond per-session checkpoints) → direct hosted-platform competition; accelerate our LangGraph adapter differentiation.
If LangGraph 2.0 guardrail nodes become the standard compliance primitive for AI pipelines → expose an equivalent gate type in workspace-template/ adapters.
If LangSmith + LangGraph Cloud bundle as an all-in-one enterprise platform → we need to position our model-agnostic, self-hostable story more aggressively against LangChain lock-in.

Last reviewed: 2026-04-16 · Stars / activity: ~29k ⭐, v1.1.6 April 10 2026, very active

CrewAI — `crewAIInc/crewAI`

Pitch: "Framework for orchestrating role-playing, autonomous AI agents — by fostering collaborative intelligence, CrewAI empowers agents to work together seamlessly, tackling complex tasks."

Shape: Python library (MIT), ~48k ⭐, v1.14.2 released April 8 2026. Agents are defined by role, goal, and backstory fields and assembled into a Crew with Process.sequential (fixed order) or Process.hierarchical (manager agent delegates) execution. Flow (event-driven stateful pipelines, shipped 2024-Q4) enables complex conditional branching beyond linear crew execution. Model-agnostic: OpenAI, Anthropic, Gemini, Mistral, Bedrock, Ollama, and any LiteLLM-compatible endpoint. Tools are Python callables or MCP integrations. CrewAI Enterprise is the commercial SaaS offering.

Overlap with us: Molecule AI ships a crewai runtime adapter (molecule-ai-workspace-template-crewai) — our workspaces run CrewAI crews. The Crew role model (role + goal + backstory) is our system-prompt-encoded persona convention made explicit and typed. Process.hierarchical with a manager agent mirrors our PM → Dev Lead → Engineer delegation chain. Flow's event-driven branching is analogous to our workspace_schedules trigger model.

Differentiation: CrewAI is an in-process Python framework; Molecule AI is the operational platform. CrewAI agents are ephemeral per crew run — no Docker isolation, no persistent identity across restarts, no org-chart canvas, no A2A between independently deployed agents, no cron scheduling, no channel integrations. A Molecule AI CrewAI workspace persists across sessions, holds a role in a larger org, and coordinates via our A2A protocol — capabilities CrewAI alone does not provide.

Worth borrowing:

Typed role schema — {role, goal, backstory} as first-class typed fields (not free-text system prompt). Our config.yaml role: is a single string; adopting a richer {role, goal, backstory} triplet would improve agent persona consistency across restarts and be CrewAI-compatible.
Flow event-driven pipelines — conditional state-machine branching triggered by events. Applicable to our workspace_schedules — replace cron-only triggers with an event graph: "when PR merged → trigger QA workspace → on pass → trigger deploy."
Tool decorator pattern — @tool with docstring-as-schema is simpler than our MCP tool config approach for workspace-local tools.

Terminology collisions:

"crew" — their multi-agent team; our team is a set of workspaces in an org hierarchy. Marketing copy should use "workspace org" not "crew" to stay distinct.
"agent" — their ephemeral in-process Python object; our long-lived Docker workspace.
"task" — their atomic unit of work assigned to an agent; our current_task heartbeat field. Same word, different scope.

A2A interop (confirmed 2026-04-17): CrewAI implements A2A spec v0.3.0 (client + server), matching Molecule AI's a2a-sdk[http-server]==0.3.25. Zero-shim interop confirmed today — a Molecule AI org can delegate to a CrewAI A2A endpoint, and CrewAI agents can be registered as worker nodes in a Molecule AI hierarchy without any protocol shim. The shared upgrade clock: A2A spec v1.0.0 (March 12 2026) has breaking wire-format changes (extendedAgentCard → AgentCapabilities, OAuth flow restructure). Neither side has migrated yet. Schedule a coordinated v1.0.0 migration before either platform upgrades unilaterally.

Signals to react to:

If CrewAI ships persistent agent state between crew runs → closes primary gap with our workspace model; ~48k ⭐ means it would land with significant reach.
If CrewAI Enterprise adds visual org-chart canvas → direct platform competitor (Crew Studio is workflow-only, not governance org-chart — our Canvas moat intact today).
If the 2026 State of Agentic AI survey (65% of orgs using agents) accelerates CrewAI Enterprise sales → their enterprise positioning competes directly with ours; update ICP messaging.
If either side upgrades to A2A v1.0.0 before the other → breaking interop; watch crewAIInc/crewAI CHANGELOG for protocol_version bump.

Last reviewed: 2026-04-17 (A2A interop confirmed) · Stars / activity: ~48k ⭐, v1.14.2 April 8 2026, very active

Temporal — `temporalio/temporal`

Pitch: "The durable execution platform — write code that runs reliably even in the face of failures, timeouts, and restarts."

Shape: Go server + SDKs for Go, Java, TypeScript, Python, .NET, PHP (MIT), ~13k ⭐ server repo. Workflow logic is deterministic code that Temporal replays from event history after failures — no explicit retry/checkpoint code. Activities are the fallible steps; Signals allow external input mid-workflow; Queries expose read-only workflow state. Temporal Cloud is the managed SaaS; self-hosted runs on K8s or Docker. Raised $300M Series D at $5B valuation February 2026, with AI driving demand for durable execution. v1.30.4 released April 10 2026.

Overlap with us: Molecule AI already integrates Temporal via workspace-template/builtin_tools/temporal_workflow.py. The infra/scripts/setup.sh starts a local Temporal server (:7233 gRPC + :8233 Web UI). Any Molecule AI workspace that needs bulletproof long-running or retryable work delegates to Temporal. Temporal's Worker Versioning (GA March 2026) solves the same code-deploy-during-live- workflow problem our restart-context message handles ad hoc.

Differentiation: Temporal is infrastructure — a durable execution engine with no concept of agent identity, LLM calls, memory, org hierarchy, canvas, channels, or A2A. It is the substrate beneath agents that need guaranteed execution; we are the platform that decides when to call Temporal vs handle work in the workspace itself. We are Temporal consumers, not competitors. The distinction for users: use Temporal when you need workflow history replay and multi-step retry guarantees; use Molecule AI scheduling for lighter cron-triggered agent prompts.

Worth borrowing:

Worker Versioning (GA March 2026) — pin live workflows to a specific code version so deploys don't corrupt in-flight runs. Analogous problem to our workspace restart-context; worth evaluating as the underlying mechanism for zero-downtime workspace deploys.
Workflow Update operation — synchronous request/response pattern for live workflows (e.g., human approves mid-workflow). Cleaner than our current approvals polling; evaluate for HITL in long Temporal-backed workspace tasks.
Upgrade-on-Continue-as-New (Public Preview March 2026) — pinned workflows can opt into a newer code version at a clean continuation boundary. Pattern applicable to our workspace versioning strategy.

Terminology collisions:

"workflow" — Temporal: a deterministic, replay-safe code function; ours: informal delegation chain term. In our docs, "Temporal workflow" should always be qualified to avoid confusion with "workflow" in general product copy.
"worker" — Temporal: a process that polls the server and executes workflow/activity code; ours: not a first-class term (workspaces fill this role).
"activity" — Temporal: a fallible, retryable step in a workflow; ours: activity_logs table (A2A traffic logs). Different concepts sharing a word.

Signals to react to:

If Temporal Cloud adds native LLM-aware primitives (e.g., LLM call as a first-class activity with token tracking, model fallback, prompt versioning) → Temporal becomes an agent platform, not just an infra layer; reassess our temporal_workflow.py integration depth.
If the $300M Series D accelerates enterprise sales motion → more enterprises will arrive with Temporal already deployed; strengthen our Temporal integration story as a first-class enterprise deployment pattern.
If Upgrade-on-Continue-as-New becomes stable → adopt for workspace blue/green deploy pattern (no workspace downtime during code updates).

Last reviewed: 2026-04-16 · Stars / activity: ~13k ⭐ (server); $5B valuation, $300M Series D Feb 2026; v1.30.4 April 10 2026

Dify — `langgenius/dify`

Pitch: "Production-ready platform for agentic workflow development — the leading open-source LLM app development platform."

Shape: Python backend + React frontend (MIT), ~60k ⭐, v1.14.0 released February 2026. Visual drag-drop workflow canvas where LLM calls, RAG retrievers, code executors, HTTP nodes, and agent loops are wired as a graph. Ships a full app deployment stack: API server, web UI widget, and Slack/Telegram/WhatsApp channel integrations. RAG pipeline with knowledge base management (file upload → chunk → embed → retrieve). Supports 50+ LLM providers. Dify Cloud is the managed SaaS; self-hosted via Docker Compose. Raised $30M Pre-A round led by HSG, March 2026.

Overlap with us: Both have a visual canvas for connecting AI work. Both support channel integrations (Slack / Telegram / WhatsApp). Both run LLM-backed agents and expose a REST API for external trigger. Dify's Human Input node (v1.14.0) is the same pattern as our approvals table — pause workflow, wait for human input, resume. Their knowledge base (RAG) is the equivalent of what our Research Lead workspace does via tool calls to external retrieval services. Dify Cloud competes with our SaaS control plane for teams that want a hosted no-code LLM app platform.

Differentiation: Dify targets no-code and low-code builders — the UX is workflow configuration, not code. No persistent agent identity across workflow runs, no multi-agent org hierarchy (agents in Dify are single workflow nodes, not first-class citizens), no A2A protocol between independently deployed agents, no Docker container isolation per agent. Molecule AI targets developers who write config.yaml and system prompts; Dify targets product managers and ops teams who want to deploy LLM apps without engineering. The ~60k ⭐ signal shows massive no-code demand that our current product does not address.

Worth borrowing:

Human Input node — native human-in-the-loop as a workflow node type, not a separate approvals API. Map to our approvals table: expose a "wait for human" node in a future visual workspace config editor.
Summary Index (v1.14.0) — AI-generated summaries per document chunk in the RAG knowledge base significantly improve retrieval precision. Applicable to our Research Lead workspace's document retrieval; evaluate for our MCP memory backend.
Knowledge base management UI — file upload → chunk → embed → retrieval test in a single interface. Reference design for our future agent_memories admin UI.
Channel trigger UX — same as n8n: three-click channel connect. Our channel setup is more manual; Dify is a second data point that this is the target UX.

Terminology collisions:

"workflow" — Dify: the visual graph of LLM+tool nodes that defines an app; ours: informal delegation chain. In competitive positioning copy, distinguish "no-code workflow builder" (Dify) vs "multi-agent org" (us).
"agent" — Dify: a single ReAct loop node inside a workflow; ours: a long-lived Docker workspace with an assigned role. Different scope and persistence model.
"knowledge base" — Dify: an indexed file collection for RAG; ours: not a first-class term (workspace agents manage their own retrieval).

Signals to react to:

If Dify ships persistent agent identity (agents that remember state across workflow runs, not just within one) → closes the primary product gap; ~60k ⭐ + no-code accessibility is a formidable combination.
If Dify adds multi-agent coordination (agents that spawn and coordinate sub-agents as org peers, not just nested workflow nodes) → direct overlap with our multi- workspace hierarchy.
If the $30M Pre-A closes more enterprise deals → Dify moves up-market; watch for enterprise canvas and RBAC features that would narrow our enterprise differentiation.

Last reviewed: 2026-04-16 · Stars / activity: ~60k ⭐, v1.14.0 Feb 2026; $30M Pre-A Mar 2026

Flowise — `FlowiseAI/Flowise`

Pitch: "Build AI Agents, Visually — drag-drop UI to build LLM flows and agent pipelines using LangChain and LlamaIndex components."

Shape: Node.js + React (MIT repo; post-Workday acquisition terms TBD), ~30k ⭐, flowise@3.1.0 released March 16 2026. Drag-drop visual node editor where LangChain chains, LlamaIndex query engines, vector stores, tools, and agents are wired as a flow graph. Each flow is exported as a JSON config; the Flowise server exposes a REST API and a chat widget embed. Agentflow (shipped 2024) adds multi-agent composition: a Supervisor agent routes tasks to Worker agents within a single Flowise flow. Acquired by Workday (announced August 2025) — Flowise is now part of Workday's AI platform, bringing agent-building capability to Workday customers. Security: three chained CVEs (CVE-2025-59528, CVE-2025-8943, CVE-2025-26319) enabling unauthenticated RCE via Custom MCP Node were patched in v3.0.6 (exploit confirmed April 7 2026).

Overlap with us: Both are drag-drop visual builders for AI agent workflows. Both support LangChain components under the hood. Flowise's Agentflow (Supervisor + Worker agents) mirrors our PM → engineer hierarchy, but within a single visual flow rather than independently deployed Docker workspaces. Flowise's REST API per flow is structurally similar to our POST /workspaces/:id/a2a endpoint — both let external systems trigger an agent and get a response. Channel integrations overlap with our workspace_channels.

Differentiation: Flowise is a no-code single-server app builder — agents are stateless flow executions, not long-lived Docker workspaces with persistent memory, schedules, and org identity. Post-Workday acquisition, Flowise targets Workday enterprise customers (HR, finance, ops) rather than developer-first teams building AI companies. No persistent agent memory between flow runs, no A2A protocol between independently deployed agents, no cron scheduling, no org-chart canvas. The Workday acquisition actually narrows Flowise's addressable market to Workday-centric enterprises — which opens space for Molecule AI as the developer-first alternative.

Worth borrowing:

Agentflow Supervisor/Worker pattern — the Supervisor agent dynamically routes tasks to Workers based on their capabilities, with results aggregated back. More flexible than our static PM → Lead delegation; study for dynamic routing in the PM workspace's delegate_task.
Flow-as-JSON export/import — each Flowise flow is a portable JSON blob that can be versioned, shared, and re-imported. Our workspace config.yaml is close; adding a full workflow export (config + memory schema + skill list) as a bundle would enable the same portability.
Chat widget embed — single-line script tag embeds a Flowise agent as a chat widget on any webpage. Our workspace_channels is closer to outbound messaging; a widget embed for inbound is a UX gap worth closing for developer adoption.

Terminology collisions:

"flow" — Flowise: a visual JSON graph of LangChain nodes; ours: not a first-class term. Avoid "flow" in our visual canvas docs to prevent confusion with Flowise- trained users.
"node" — Flowise: a LangChain component tile in the flow canvas; our canvas: a workspace tile. Same word, same visual metaphor, different semantics.
"supervisor" / "worker" — Flowise Agentflow roles; our PM / engineer hierarchy is the same concept with different names. Our marketing should own "PM + engineer" framing to stay distinct.

Signals to react to:

If Workday opens Flowise APIs to non-Workday enterprise customers → Flowise re-enters the general market with Workday distribution; update competitive messaging.
If the CVE chain (RCE via Custom MCP Node) causes enterprise churn → opportunity to position Molecule AI's Docker-isolated workspaces as the security-first alternative for self-hosted agent deployments.
If Flowise ships persistent agent memory or cross-flow A2A → closes primary gap; monitor quarterly given Workday engineering resources.

Last reviewed: 2026-04-16 · Stars / activity: ~30k ⭐, flowise@3.1.0 March 16 2026; acquired by Workday Aug 2025

Candidates to add (backlog)

Short-list of projects to write up next time someone has an hour:

AutoGen (microsoft/autogen) — Microsoft's original repo; now superseded by Microsoft Agent Framework (tracked above) and AG2 community fork (tracked above). Entry should clarify which adapter target is canonical.
DeepAgents (langchain-ai/deepagents) — we adapt it; particularly their sub-agent feature that collides with our "skills" word.
OpenClaw — check if this is still live post-Hermes rebrand; our adapter may need renaming.
Moltiverse / Moltbook (molti-verse.com) — "social network for AI agents." Not a competitor; orthogonal ecosystem but worth tracking in case we want agent-to-agent discovery beyond a single org.

OpenAI Agents SDK — Sandbox Agents — `openai/openai-agents-python`

Pitch: "A lightweight, powerful framework for multi-agent workflows — now with persistent isolated sandbox workspaces, snapshot/resume, and sandbox memory."

Shape: Python (MIT), ~14k ⭐ (110 stars today), v0.14.0 released April 15, 2026. New beta surface: SandboxAgent backed by a Manifest (file tree, Git repo, mounts) and a SandboxRunConfig that targets a pluggable execution backend. Local: UnixLocalSandboxClient; containerised: DockerSandboxClient; hosted via optional extras for Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel. Sandbox memory lets future runs inherit lessons from prior runs with progressive disclosure and configurable isolation boundaries. Existing SDK primitives (Agents, Handoffs, Guardrails, Tracing) are unchanged.

Overlap with us: SandboxAgent + hosted backends directly competes with our workspace lifecycle model — a persistent isolated execution environment, snapshot and resume, durable memory. The multi-backend strategy (Docker, Modal, Vercel, E2B) mirrors our Docker workspace + cloud-provider abstraction goal. Sandbox memory is the same cross-session memory gap we address via agent_memories.

Differentiation: Still a framework, not a platform — no visual canvas, no org-chart hierarchy, no A2A between independently deployed sandboxes (handoffs are in-process), no cron scheduling, no channel integrations. OpenAI-provider-optimised in practice. Our differentiators: multi-agent org hierarchy with A2A, model-agnostic, self-hostable, persistent agent identity beyond a single SDK process.

Worth borrowing: SandboxRunConfig backend abstraction — decouple workspace execution from provider (Docker / Modal / Vercel) using a single config object. Directly applicable to our workspace provisioner. Sandbox memory progressive disclosure (summaries first, full context on demand) matches the retrieval strategy in claude-mem; adopt for agent_memories query API.

Terminology collisions: "sandbox" — theirs: an isolated execution backend; ours: not a first-class term (we use "workspace" / "container"). "memory" — same word, same intent; our agent_memories and their sandbox memory are functionally equivalent.

Signals to react to: If OpenAI adds inter-sandbox A2A (sandboxes delegating to each other across process boundaries) → direct platform feature parity; accelerate our A2A documentation and SDK ergonomics. If hosted backends gain TypeScript support (announced as roadmap) → Vercel + TS stack competes for our TypeScript-native users.

Last reviewed: 2026-04-16 · Stars / activity: ~14k ⭐, v0.14.0 April 15, 2026, OpenAI-maintained

Tencent AI-Infra-Guard — `Tencent/AI-Infra-Guard`

Pitch: "A full-stack AI Red Teaming platform securing AI ecosystems via Agent Scan, Skills Scan, MCP scan, AI Infra scan, and LLM jailbreak evaluation."

Shape: Python + Go (Apache-2.0), ~3.5k ⭐, v4.1.3 released April 9, 2026. Tencent Zhuque Lab. Six scanning surfaces: ClawScan (open-source code security), Agent Scan (runtime agent behaviour audit), Skills Scan (verifying installed agent skills), MCP Server scan (tool-surface vulnerability detection), AI infrastructure CVE matching (1000+ CVEs across 57+ AI components including crewai, kubeai, lobehub), and LLM jailbreak evaluation. Ships a web UI, REST API, Docker deployment, and integration with ClawHub agent marketplace.

Overlap with us: Our plugin/skills registry and MCP server are exactly the surfaces AI-Infra-Guard scans. The Skills Scan module validates installed agent skill packs — the same artefacts our plugins/ directory ships. MCP Server scan targets the same @molecule-ai/mcp-server surface our platform exposes. If enterprise customers adopt AI-Infra-Guard for compliance audits, our plugin manifests and MCP tool definitions need to be compatible with its scanner.

Differentiation: A security tooling product, not an agent framework or platform. No agent runtime, no orchestration, no canvas, no memory. Molecule AI builds and runs agents; AI-Infra-Guard audits them and their supply chain.

Worth borrowing: MCP Server scan vulnerability categories — use as a checklist for hardening our own MCP server (@molecule-ai/mcp-server) before an enterprise security review. Skills Scan concept — add a plugin validate sub-command to molecli that runs the same checks locally before installing a plugin.

Terminology collisions: "agent scan" — their runtime audit process; not a term we use. "skills scan" — their validation of installed skill packs; same artefact, different word ("plugin audit" in our vocabulary).

Signals to react to: If AI-Infra-Guard publishes a formal MCP tool-surface security spec → treat as a compliance baseline for our MCP server hardening. If Tencent integrates this into enterprise procurement checklists → our plugin and MCP docs need an explicit security posture section to pass audits.

Last reviewed: 2026-04-16 · Stars / activity: ~3.5k ⭐, v4.1.3 April 9, 2026, Tencent Zhuque Lab

VoltAgent — `VoltAgent/voltagent`

Pitch: "The open-source TypeScript AI agent framework with a built-in observability and deployment console — build agents once, run and monitor them everywhere."

Shape: TypeScript (MIT), ~8.2k ⭐, 668 releases, latest April 11, 2026. Two-layer design: @voltagent/core framework (typed agent definitions, tool registry, multi-agent supervisor/sub-agent coordination, memory, RAG, voice, guardrails) + VoltOps Console (hosted or self-hosted web UI for observability, deployment automation, and agent lifecycle management). MCP client support connects any MCP server as a tool source. Provider-agnostic: OpenAI, Anthropic, Google, Ollama, and any OpenAI-compatible endpoint. Ships @voltagent/server-elysia for Bun-native HTTP serving of agents.

Overlap with us: VoltOps Console is the closest analogue to our Canvas we've tracked in the TypeScript ecosystem — both provide a web UI for managing and monitoring long-lived agents. The supervisor/sub-agent coordination model mirrors our PM → engineer delegation. MCP support means workspace skills install into VoltAgent as easily as ours. @voltagent/server-elysia pattern (agent as an HTTP server) is analogous to our A2A endpoint per workspace.

Differentiation: No Docker workspace isolation, no persistent agent identity across server restarts, no A2A protocol between independently deployed agents, no cron scheduling, no channel integrations. VoltOps Console focuses on observability and deployment automation; our Canvas is the live visual org chart with drag-drop topology control. Molecule AI targets multi-agent companies; VoltAgent targets individual TypeScript developers building production agents.

Worth borrowing: VoltOps observability schema — trace views, agent state inspection, and deployment automation as a single UI surface. Reference design for merging our Canvas agent-inspection panel with Langfuse traces into a unified observability tab. @voltagent/core typed agent definition API (role, memory, tools, guardrails as typed config) — cleaner than our YAML-then-system-prompt pipeline; evaluate for a future typed workspace config schema.

Terminology collisions: "console" — VoltOps Console: their monitoring + deploy UI; our molecli: a TUI dashboard. Both are "consoles" for watching agents. "supervisor" — their orchestrating agent tier; our PM workspace plays the same role.

Signals to react to: If VoltOps Console adds visual org-chart topology (not just list view) → direct Canvas competitor in the TypeScript ecosystem. If @voltagent/core multi-agent API becomes idiomatic for TS agent developers → consider shipping an official Molecule AI VoltAgent runtime adapter alongside our langgraph/crewai adapters.

Last reviewed: 2026-04-16 · Stars / activity: ~8.2k ⭐, 668 releases, latest April 11, 2026

Cognee — `topoteretes/cognee`

Pitch: "Knowledge Engine for AI Agent Memory in 6 lines of code — hybrid graph + vector search, runs locally, multimodal."

Shape: Python library (Apache 2.0), ~15.8k ⭐, v1.0.1.dev1 April 15, 2026. Six-stage ingest pipeline (cognify): classify → permissions → chunk → LLM entity/relationship extraction → LLM summarise → embed into vector + commit graph edges. 14 retrieval modes from top-k cosine up to GRAPH_COMPLETION (vector → graph traversal → structured context). Default backends are file-local, zero-config: LanceDB (vectors), KuzuDB (graph), SQLite (metadata). Production upgrade path: Postgres + pgvector or Neo4j via pip extras. Enterprise tier adds cross-agent knowledge sharing with tenant isolation and OTEL tracing.

Overlap with us: Directly addresses the same gap our agent_memories table targets — persistent, queryable agent knowledge across sessions. Ships a claude-code-plugin for session memory injection (same use case as claude-mem's 56k⭐ demand signal). Native integration with Hermes Agent. The hybrid graph+vector approach (knowledge graph for relationships, vector for semantic recall) is materially more sophisticated than our current key-value agent_memories model.

Differentiation: Pure memory library — no workspace lifecycle, no agent orchestration, no A2A, no canvas. Intended to be embedded into any agent framework, including Molecule AI workspaces, not to replace them.

Integration path (TR eval 2026-04-17): Augment, not replace the existing key-value agent_memories path.

cognify fires 2–5 LLM calls per ingest — must be async/batched (on session flush), not inline per-turn.
cognee_search (GRAPH_COMPLETION) latency ~200–500 ms — acceptable for explicit semantic queries, not per-turn default.
Existing key-value path stays as primary per-turn read (10–50 ms).
MVP deployment: pip install cognee + LLM_API_KEY (already supplied as ANTHROPIC_API_KEY) + /configs/cognee/ volume mount. Zero new containers.
Build estimate for molecule-cognee plugin: ~3 days (async ingest wrapper + search skill + plugin.yaml/rules/CI). Recommended sequence: after #573 (mcp-connector) and #574 (code-sandbox) land.

Worth borrowing: The four-operation memory API (remember / recall / forget / improve) is a clean contract worth adopting in our agent_memories API surface. The tenant-isolated cross-agent knowledge graph model (agents share a knowledge base scoped to their org) maps well to our workspace hierarchy.

Terminology collisions: "cognify" — their ingest verb; we'd call this "index" or "ingest". "prune" — their delete; we use DELETE /workspaces/:id/memories/:id.

Signals to react to: If Cognee ships a first-class MCP server → immediately relevant as a drop-in memory backend for any MCP-capable workspace. If 56k⭐ claude-mem users migrate to Cognee for graph-based recall → validates gap and urgency.

Last reviewed: 2026-04-17 (TR integration eval) · Stars / activity: ~15.8k ⭐, v1.0.1.dev1, April 15, 2026

Archestra — `archestra-ai/archestra`

Pitch: "End the MCP chaos — a self-hosted enterprise platform for governing, securing, and monitoring your organization's MCP servers."

Shape: TypeScript (AGPL-3.0), ~3.6k ⭐, platform v1.2.15 April 16, 2026. Kubernetes-native. Two main surfaces: (1) MCP Registry — private, shared MCP server catalog for teams; OAuth + API key management; governance controls on which teams can access which tools. (2) Security Gateway — dual-LLM architecture where a security sub-agent intercepts tool responses to block prompt injection and data exfiltration before results reach the primary agent. Also: per-team cost monitoring, ChatGPT-style chat UI with private prompt registry, Terraform provider + Helm chart.

Overlap with us: Our plugins/ registry and per-workspace plugin install system serve a similar "shared tools across an agent org" purpose. Archestra's MCP governance story (who can call which tools, cost per team, audit trail) is a more formal version of what our POST /workspaces/:id/plugins API provides informally. The dual-LLM security gateway pattern is novel and directly applicable to our A2A proxy hardening.

Differentiation: Archestra governs MCP servers, not agent workspaces — it has no multi-agent orchestration, no workspace lifecycle, no A2A protocol, no canvas. It's an MCP-specific control plane, not an agent orchestration platform. Could complement Molecule AI rather than replace it.

Worth borrowing: Dual-LLM security gateway pattern — intercept tool responses with a fast security model before they reach the primary agent. Apply to our A2A proxy (a2a_proxy.go) for tool-response sanitisation. Per-team MCP cost attribution model — maps naturally to our workspace tier billing.

Terminology collisions: "orchestrator" — Archestra means "MCP server lifecycle manager"; we mean "multi-agent coordinator". Both use the word for very different things.

Signals to react to: If Archestra adds agent-to-agent coordination on top of its MCP gateway → overlap with our platform increases significantly. If enterprise procurement teams start requiring an MCP governance audit trail → our plugin install API needs a formal audit log surface (issue backlog candidate).

Last reviewed: 2026-04-17 · Stars / activity: ~3.6k ⭐, platform v1.2.15, April 16, 2026

GitHub MCP Server — `github/github-mcp-server`

Pitch: "GitHub's official MCP Server — connect AI agents and assistants directly to your GitHub repositories, issues, PRs, and workflows."

Shape: Go (MIT), ~28.9k ⭐, v1.0.0 April 16, 2026. 60+ tools across 20+ toolsets: repos, issues, PRs, Actions/CI-CD, code security (scanning, Dependabot, secret protection), discussions, gists, git ops, notifications, orgs, projects, labels, users, stargazers. Deployment: GitHub-hosted at api.githubcopilot.com/mcp/ or local via Docker/compiled binary. Supports dynamic toolset discovery (beta) so hosts can enumerate and enable tools on demand rather than loading all 60+ upfront.

Overlap with us: Chrome DevTools MCP (#540) is already tracked as a tool we adopt into workspaces — GitHub MCP Server is the same pattern for GitHub operations. Any Molecule AI workspace doing code review, PR management, issue triage, or CI monitoring would naturally adopt this. Our Technical Researcher, Dev Lead, and Triage Operator workspace types are obvious candidates.

Differentiation: Tool provider only — no agent orchestration, no workspace model, no A2A. Designed to be consumed by MCP hosts (Claude Code, Copilot, Cursor etc.), not to compete with orchestration platforms.

Worth borrowing: Dynamic toolset discovery (enumerate tools per context, not a monolithic 60-tool blast) — reference design for our workspace plugin available endpoint (GET /workspaces/:id/plugins/available). Apply the same filtering logic for runtime-aware tool exposure.

Terminology collisions: None significant.

Signals to react to: If GitHub ships an agent-native event webhook model (not just REST polling) → evaluate as a channel adapter alongside our Telegram/Slack integrations. If GitHub exposes repo-scoped A2A agent cards → direct interop opportunity with our registry.

Last reviewed: 2026-04-17 · Stars / activity: ~28.9k ⭐, v1.0.0 GA, April 16, 2026

Skillshare — `runkids/skillshare`

Pitch: "Sync skills across all AI CLI tools with one command — Claude Code, Codex, OpenClaw, Cursor, and 50+ more."

Shape: Go binary (MIT), ~1.5k ⭐, v0.19.2 April 14, 2026. Manages a ~/.config/skillshare/ source-of-truth directory containing SKILL.md files, agent configs, rules, commands, and prompts. Syncs to 50+ AI tool targets via symlinks (macOS/Linux) or NTFS junctions (Windows). Three modes: global (~/.config/skillshare/), project (.skillshare/ per repo, committable), and installable repos (skillshare install <git-repo>). Ships a web dashboard UI (skillshare ui). Built-in security auditing: scans installed skills for prompt injection and exfiltration patterns.

Overlap with us: Directly overlaps with our plugins/ distribution model and SKILL.md format — Skillshare treats SKILL.md files as the unit of distribution across tools, the same way our plugin system does. The skillshare install <git-repo> command is equivalent to our POST /workspaces/:id/plugins with a github:// source. The project mode (.skillshare/ committed to a repo) maps to our org-template skill defaults in org.yaml.

Differentiation: Single-user local syncing, not a server-side multi-agent registry. No workspace lifecycle, no per-agent identity, no A2A, no canvas. Designed for individual developer ergonomics across tools, not for governing a fleet of persistent agents.

Worth borrowing: The prompt-injection/exfiltration scanner built into skillshare sync — we have no equivalent gate in our plugin install path today. Consider adding a static analysis step to POST /workspaces/:id/plugins that scans SKILL.md and rules files for injection patterns before activating. The install <git-repo> one-command install UX is cleaner than our current {"source":"github://org/repo"} JSON body — worth documenting as a molecli shorthand.

Terminology collisions: "skills" — Skillshare uses this for SKILL.md files that inject instructions into AI tools; we use "skills" for the same concept in our plugin system. Exact collision — no disambiguation needed since we use the same word intentionally.

Signals to react to: If Skillshare adds a server-side shared registry (teams publish skills to a central endpoint) → direct overlap with our plugin registry governance gap that Archestra's MCP registry addresses. If it reaches 10k⭐ → signals the SKILL.md format is becoming a community standard; we should ensure full compatibility.

Last reviewed: 2026-04-17 · Stars / activity: ~1.5k ⭐, v0.19.2, April 14, 2026

Compound Engineering Plugin — `EveryInc/compound-engineering-plugin`

Pitch: "One plugin, 12 runtimes — a CLI that converts a single engineering workflow plugin (brainstorm → plan → work → review) into the correct format for Claude Code, Cursor, Codex, OpenClaw, Gemini CLI, Kiro, Windsurf, Factory Droid, Pi, GitHub Copilot, Qwen, and more simultaneously."

Shape: TypeScript (MIT), ~14.5k ⭐, v2.66.1 April 16, 2026. 97 total releases — high-cadence active project. Source format: .claude-plugin/ (Claude Code format) is the canonical input — all other runtimes are generated from it. bunx @every-env/compound-plugin install <name> --to <target> transpiles to target-specific output via one .ts file per runtime in src/targets/. Current 11 targets: codex, copilot, droid, gemini, kiro, openclaw, opencode, pi, qwen, windsurf + Claude Code source. 12th slot likely Cursor (in-progress).

Molecule AI is not on the list. Adding us requires: (1) src/targets/molecule-ai.ts — one .ts file handling tool-name mapping and output path generation; (2) one-line export in index.ts. Estimated effort: 2–4 hours (upstream PR to EveryInc/compound-engineering-plugin). Since our .claude-plugin/ format already matches their source format exactly, this is zero-cost compatibility.

Overlap with us: Distribution-layer overlap with our agentskills.io multi-runtime adapter pattern. Compound uses a CLI transpiler (authors run one command); we embed per-runtime adapters/<runtime>.py files inside each plugin (authors maintain adapters). Compound is strictly more ergonomic for authors. The two mechanisms are complementary layers, not in conflict — but if Compound becomes the community standard, absent Molecule AI support means silent bypass of our registry.

Differentiation: Distribution/packaging tool only. No A2A, no workspace lifecycle, no cron, no canvas. Not an orchestration competitor.

Worth borrowing: The compound install <repo> one-command UX. Consider a molecli plugin install <github-url> shorthand. Also: their per-runtime .ts target file pattern is cleaner than our adapters/<runtime>.py per-plugin approach — evaluate adopting it for the plugin SDK.

Action (time-sensitive): Open upstream PR to add molecule-ai.ts target to EveryInc/compound-engineering-plugin before the Cursor slot lands — being 12th (not 13th) matters for perception. This is a ~2-4h Dev Lead task; file as external contribution issue when GH_TOKEN rotates.

Signals to react to: If Compound adds a server-side plugin registry → direct threat to our plugins/ registry as canonical source. If molecule-ai.ts PR is rejected → reassess whether to maintain a Compound-compatible fork.

Last reviewed: 2026-04-17 (CI deep-dive) · Stars / activity: ~14.5k ⭐, v2.66.1, April 16, 2026

EDDI — `labsai/EDDI`

Pitch: "Config-driven multi-agent orchestration middleware — intelligent routing between users, agents, and business systems where agent logic lives in JSON, not code."

Shape: Java 25 + Quarkus (Apache 2.0), ~296 ⭐, v6.0.1, 44 releases. Ships as Docker Compose + Kubernetes manifests. First HN exposure April 17, 2026 (Show HN, early traction). Five enterprise-grade capabilities: Ed25519 cryptographic agent identity per agent, HMAC-SHA256 immutable audit ledger, GDPR/HIPAA-compliant infrastructure, secrets vault with envelope encryption, group conversations with 5 configurable discussion styles.

Overlap with us: Hits five of six Molecule AI orchestration criteria — A2A, cron scheduling, persistent agent identity, self-hostable, model-agnostic (12 LLM providers + MCP). Only gap: no visual canvas. The immutable HMAC audit ledger and GDPR/HIPAA posture directly target the regulated-vertical ICP we sharpened in the #572/#582 market research.

Differentiation: Config-only (JSON) — no graph UI, no org-chart canvas, no Docker workspace isolation per agent. Java stack limits the overlap community; 296 stars = low current traction. Not a near-term competitive threat.

Worth borrowing: The HMAC-SHA256 immutable audit ledger design — every agent action is cryptographically chained so no event can be silently deleted. Relevant to the compliance-guardrails plugin spec (staged issue C) and enterprise procurement posture. Also: Ed25519 per-agent signing as a stronger identity mechanism than our current bearer token model.

Signals to react to: If EDDI gains traction (>5k⭐) or ships a visual canvas → reassess threat level. If the HMAC audit ledger pattern gets cited by enterprise compliance auditors as a requirement → accelerate compliance-guardrails plugin and add cryptographic chaining to activity_logs.

Last reviewed: 2026-04-17 (Show HN) · Stars / activity: ~296 ⭐, v6.0.1, Java/Quarkus

Cloudflare Artifacts — `blog.cloudflare.com/artifacts-git-for-agents-beta`

Pitch: "Git for agents — programmatic versioned storage built for agentic workflows: create repos, fork, clone, diff, and branch from code, with Durable Objects durability and ~100KB Zig+WASM Git engine."

Shape: Cloudflare proprietary service (ArtifactFS driver open-sourced), private beta April 16, 2026 — public beta targeted early May 2026. Pricing: $0.15/1k ops (10k/month free), $0.50/GB-month (1 GB free). Not a framework — an infrastructure primitive.

Overlap with us: Not an orchestration platform and does not compete with Molecule AI directly today. Relevant as a new workspace-persistence primitive: any competitor (Paperclip, Scion, VoltAgent) could wire Cloudflare Artifacts into their agent workspace layer to get Git-semantics workspace snapshots cheaper than our current Docker volume + CLAUDE.md prose approach. The fork/clone/diff semantics are a more principled snapshot model than our current snapshot_id pattern.

Differentiation: Storage primitive only — no agent identity, no A2A, no scheduling, no canvas. Requires Cloudflare Workers; not self-hostable on arbitrary infra.

Worth borrowing: The fork() → work → diff() → merge() lifecycle as a model for workspace snapshot/resume — cleaner than our current lossy prose injection into CLAUDE.md (#583). If ArtifactFS driver becomes usable standalone (non-Cloudflare backend), consider as a replacement for Docker volume snapshots.

Signals to react to: If Cloudflare Agents SDK integrates Artifacts as a built-in workspace-persistence layer → escalate to MEDIUM; Cloudflare would then offer a managed Docker+Git workspace alternative to Molecule AI. If snapshot_id semantics become standard across the ecosystem → accelerate #583.

Last reviewed: 2026-04-17 (private beta announcement) · Stars / activity: infrastructure service, ArtifactFS driver OSS

dimos — `dimensionalOS/dimos`

Pitch: "Agentic OS for physical space — control humanoids, quadrupeds, drones, and robotic arms via natural language. Python SDK, MCP-native, zero ROS dependency."

Shape: Python (MIT), ~2.9k ⭐, v0.0.11, March 2026. Module-based architecture: components expose typed input/output streams; autoconnect() wires them by name+type into a "blueprint." Multiple transports: LCM, shared memory, DDS, ROS 2. Spatial memory via SLAM; temporal memory via spatio-temporal RAG (object permanence across sessions). Hardware support: Unitree Go2/B1/G1, AgileX Piper, Xarm, DJI Mavic, MAVLink drones. MCP is the primary agent-control interface — robots are addressed as MCP tool endpoints.

Overlap with us: Any MCP-capable Molecule AI workspace could issue commands to dimos-managed hardware via the standard MCP tool surface. Spatio-temporal RAG for memory is adjacent to our agent_memories approach.

Differentiation: Hardware/robotics domain only — no workspace lifecycle, no A2A, no canvas, no SaaS orchestration. Not a software agent competitor; 278 open issues suggests pre-stability.

Worth borrowing: The autoconnect() blueprint wiring (match streams by name+type, not hardcoded edges) is a clean low-ceremony graph composition pattern — applicable to our workflow plugin composition system.

Terminology collisions: "blueprint" = their module-wiring config; we'd call this a workflow or pipeline.

Signals to react to: If dimos ships A2A support → robot-controlling workspaces become first-class Molecule AI peers. If spatio-temporal RAG pattern gains traction in non-hardware agents → revisit agent_memories retrieval architecture.

Last reviewed: 2026-04-17 (GitHub trending) · Stars / activity: ~2.9k ⭐, v0.0.11, March 2026

Cloudflare Workers AI — `cloudflare.com/ai-platform`

Pitch: "One API to access any AI model from any provider — built to be fast and reliable. Unified inference layer for agent-native apps with auto-failover and streaming resilience across 330 global PoPs."

Shape: Cloudflare proprietary platform (infrastructure service, some OSS components). Part of Cloudflare "Agents Week" 2026. 70+ models across 14+ providers (OpenAI, Anthropic, Google, etc.). Key capabilities for agents: automatic multi-provider failover, streaming response buffering independent of agent lifetime (reconnect without reprocessing), unified billing + monitoring across all model calls, custom model bring-your-own via Replicate Cog. Part of a broader Cloudflare agent stack: Durable Objects (state), Artifacts (versioned storage, tracked separately), Agents SDK (multi-step orchestration), AI Search (hybrid RAG for agents).

Overlap with us: Cloudflare is assembling a complete managed agent platform: inference + state + storage + orchestration + search. Collectively a competing infrastructure story to Molecule AI's self-hosted model. Neither product has canvas, visual org hierarchy, A2A, or governance tooling.

Differentiation: Pure infrastructure primitives — no agent identity model, no workspace lifecycle, no compliance/governance. Requires Cloudflare Workers (not self-hostable on arbitrary infra). Each piece is standalone; the "platform" is integration, not a packaged product. No pricing announced for full stack.

Worth borrowing: Streaming resilience pattern — buffer streaming LLM responses independently of agent process lifetime, allow graceful reconnection. Apply to our A2A response streaming. Multi-provider failover model — reference design for our model-agnostic workspace layer (runtime: field).

Terminology collisions: "Workers" = Cloudflare serverless compute; we call these "workspaces". "Bindings" = their service-to-service connector; we use A2A protocol for agent-to-agent calls.

Signals to react to: If Cloudflare Agents SDK integrates all four primitives (Workers AI + Durable Objects + Artifacts + AI Search) into a one-click multi-agent deployment → escalate to MEDIUM; would offer a competing managed workspace alternative at Cloudflare global scale. Watch for per-agent billing or workspace lifecycle management announcements.

Last reviewed: 2026-04-17 (Agents Week 2026, HN 248pts) · Stars / activity: infrastructure service, no public GitHub repo

173 KiB Raw Blame History Unescape Escape

Ecosystem Watch

How to use this doc

Template

Competitor Snapshot

Entries

Holaboss — holaboss-ai/holaboss-ai

Hermes Agent — NousResearch/hermes-agent

gstack — garrytan/gstack

Composio — composio-dev/composio

n8n — n8n-io/n8n

Pydantic AI — pydantic/pydantic-ai

Rivet — Ironclad/rivet

Letta — letta-ai/letta

Trigger.dev — triggerdotdev/trigger.dev

Mem0 — mem0ai/mem0

AG2 — ag2ai/ag2

Last reviewed: 2026-04-13 · Stars / activity: ~40k ⭐ (primary community repo for AutoGen lineage)

Super Dev — shangyankeji/super-dev

Last reviewed: 2026-04-13 · Stars / activity: ~217 ⭐, 63 forks, v2.3.7 pushed Apr 13 2026

Sierra — sierra.ai (commercial, no public repo)

ERNIE / Baidu LLM line — qianfan.baidubce.com

MeDo — moda.baidu.com (commercial, no public repo)

Inngest — inngest/inngest

Arize Phoenix — Arize-ai/phoenix

SWE-agent — SWE-agent/SWE-agent

Devin — cognition.ai (commercial, no public repo)

Cline — cline/cline

OpenHands — All-Hands-AI/OpenHands

Scion — GoogleCloudPlatform/scion

claude-mem — thedotmack/claude-mem

Multica — multica-ai/multica

Skills CLI — vercel-labs/skills

Archon — coleam00/Archon

Claude Code Routines — anthropic.com (commercial, no public repo)

Microsoft Agent Framework — microsoft/agent-framework

Open Agents — vercel-labs/open-agents

Gemini CLI — google-gemini/gemini-cli

open-multi-agent — JackChen-me/open-multi-agent

AgentScope — modelscope/agentscope

Plannotator — backnotprop/plannotator

GenericAgent — lsdefine/GenericAgent

OpenSRE — Tracer-Cloud/opensre

AMD GAIA — amd/gaia

ClawRun — clawrun-sh/clawrun

Paperclip — paperclipai/paperclip

Google ADK — google/adk-python

Chrome DevTools MCP — ChromeDevTools/chrome-devtools-mcp

LangGraph — langchain-ai/langgraph

CrewAI — crewAIInc/crewAI

Temporal — temporalio/temporal

Dify — langgenius/dify

Flowise — FlowiseAI/Flowise

Candidates to add (backlog)

OpenAI Agents SDK — Sandbox Agents — openai/openai-agents-python

Tencent AI-Infra-Guard — Tencent/AI-Infra-Guard

VoltAgent — VoltAgent/voltagent

Cognee — topoteretes/cognee

Archestra — archestra-ai/archestra

GitHub MCP Server — github/github-mcp-server

Skillshare — runkids/skillshare

Compound Engineering Plugin — EveryInc/compound-engineering-plugin

EDDI — labsai/EDDI

Cloudflare Artifacts — blog.cloudflare.com/artifacts-git-for-agents-beta

dimos — dimensionalOS/dimos

Cloudflare Workers AI — cloudflare.com/ai-platform

173 KiB

Raw Blame History

Holaboss — `holaboss-ai/holaboss-ai`

Hermes Agent — `NousResearch/hermes-agent`

gstack — `garrytan/gstack`

Composio — `composio-dev/composio`

n8n — `n8n-io/n8n`

Pydantic AI — `pydantic/pydantic-ai`

Rivet — `Ironclad/rivet`

Letta — `letta-ai/letta`

Trigger.dev — `triggerdotdev/trigger.dev`

Mem0 — `mem0ai/mem0`

AG2 — `ag2ai/ag2`

Super Dev — `shangyankeji/super-dev`

Sierra — `sierra.ai` (commercial, no public repo)

ERNIE / Baidu LLM line — `qianfan.baidubce.com`

MeDo — `moda.baidu.com` (commercial, no public repo)

Inngest — `inngest/inngest`

Arize Phoenix — `Arize-ai/phoenix`

SWE-agent — `SWE-agent/SWE-agent`

Devin — `cognition.ai` (commercial, no public repo)

Cline — `cline/cline`

OpenHands — `All-Hands-AI/OpenHands`

Scion — `GoogleCloudPlatform/scion`

claude-mem — `thedotmack/claude-mem`

Multica — `multica-ai/multica`

Skills CLI — `vercel-labs/skills`

Archon — `coleam00/Archon`

Claude Code Routines — `anthropic.com` (commercial, no public repo)

Microsoft Agent Framework — `microsoft/agent-framework`

Open Agents — `vercel-labs/open-agents`

Gemini CLI — `google-gemini/gemini-cli`

open-multi-agent — `JackChen-me/open-multi-agent`

AgentScope — `modelscope/agentscope`

Plannotator — `backnotprop/plannotator`

GenericAgent — `lsdefine/GenericAgent`

OpenSRE — `Tracer-Cloud/opensre`

AMD GAIA — `amd/gaia`

ClawRun — `clawrun-sh/clawrun`

Paperclip — `paperclipai/paperclip`

Google ADK — `google/adk-python`

Chrome DevTools MCP — `ChromeDevTools/chrome-devtools-mcp`

LangGraph — `langchain-ai/langgraph`

CrewAI — `crewAIInc/crewAI`

Temporal — `temporalio/temporal`

Dify — `langgenius/dify`

Flowise — `FlowiseAI/Flowise`

OpenAI Agents SDK — Sandbox Agents — `openai/openai-agents-python`

Tencent AI-Infra-Guard — `Tencent/AI-Infra-Guard`

VoltAgent — `VoltAgent/voltagent`

Cognee — `topoteretes/cognee`

Archestra — `archestra-ai/archestra`

GitHub MCP Server — `github/github-mcp-server`

Skillshare — `runkids/skillshare`

Compound Engineering Plugin — `EveryInc/compound-engineering-plugin`

EDDI — `labsai/EDDI`

Cloudflare Artifacts — `blog.cloudflare.com/artifacts-git-for-agents-beta`

dimos — `dimensionalOS/dimos`

Cloudflare Workers AI — `cloudflare.com/ai-platform`