bkinnightskytw
/
agent-orchestrator
mirror of https://github.com/ComposioHQ/agent-orchestrator.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
agent-orchestrator/artifacts/competitive-research.md

433 lines
18 KiB
Markdown
Raw Blame History

# Competitive Research — Agent Orchestration Tools
_Compiled: 2026-02-13_
## Overview
Research into 16+ projects that orchestrate AI coding agents. The goal: understand abstractions, architectures, and gaps to build the best, most extensible agent orchestrator.
---
## Tier 1: Direct Competitors (Multi-Agent Orchestrators)
### Gas Town (Steve Yegge)
- **GitHub**: https://github.com/steveyegge/gastown
- **Stack**: Go 1.23+ (~189K LOC), SQLite3, Git 2.25+, tmux 3.0+
- **Stars**: Growing rapidly (released Jan 2026)
**Architecture — MEOW Stack (Molecular Expression of Work):**
| Layer | What | How |
| ----------------------------- | ------------------------ | ------------------------------------------------------------------------------ |
| **Beads** | Atomic work units | JSONL files tracked in Git. IDs like `gt-abc12`. Universal data/control plane. |
| **Epics** | Hierarchical collections | Organize beads into tree structures for parallel/sequential execution |
| **Molecules** | Workflow graphs | Sequenced beads with dependencies, gates, loops |
| **Protomolecules & Formulas** | Reusable templates | TOML format workflow definitions |
**Agent Roles (7 roles, 2 scopes):**
| Role | Scope | Purpose |
| ------------ | ----- | --------------------------------------------------------- |
| **Mayor** | Town | Chief AI coordinator with full workspace context |
| **Deacon** | Town | Health daemon running patrol loops |
| **Dogs** | Town | Maintenance helpers |
| **Crew** | Rig | Named, persistent agents for sustained design/review work |
| **Polecats** | Rig | Ephemeral "cattle" workers spawned for specific tasks |
| **Refinery** | Rig | Merge queue manager handling conflicts |
| **Witness** | Rig | Supervises polecats, unblocks stuck work |
**Other Abstractions:**
- **Town** — Workspace directory (`~/gt/`) housing all projects
- **Rigs** — Project containers wrapping git repositories
- **Hooks** — Git worktree-based persistent storage surviving crashes
- **Convoys** — Work-tracking bundles grouping multiple beads for an agent
- **GUPP** — Agents must execute work on their hooks; scheduling persists across restarts
**Runtime Backends:** claude, gemini, codex, cursor, auggie, amp (per-rig config)
**Communication/Isolation:**
- Git worktrees for filesystem isolation per agent
- Beads/Hooks for coordination (external state, not shared context windows)
- GUPP: deterministic handoffs through version control, not LLM-judged phase gates
**Strengths:** Most architecturally ambitious. Crash recovery via git-backed Beads. Role-based agent hierarchy. Multi-agent support.
**Weaknesses:** ~$100/hr token burn, auto-merged failing tests, agents causing unexpected deletions. Go-only ecosystem. No web dashboard. Optimized for autonomous, not human-in-the-loop.
---
### Par (Coplane)
- **GitHub**: https://github.com/coplane/par
- **Stack**: Python 3.12+
- **Closest to our current approach**
**Key Abstractions:**
- **Sessions**: Single-repo isolated branches via git worktrees + tmux sessions
- **Workspaces**: Multi-repo synchronized development contexts
- **Control Center**: Unified tmux session with windows for each context
- **Labels**: Globally unique, human-readable names
**Features:**
- `par start my-feature` — creates worktree + branch + tmux session
- `par send <label> "<command>"` — execute commands in specific sessions remotely
- `par send all "<command>"` — broadcast to all sessions
- `par control-center` — unified navigation
- `.par.yaml` — automatic worktree initialization (copy .env, install deps, etc.)
- IDE integration via auto-generated `.code-workspace` files
**Strengths:** Simple, clean CLI. Very similar spirit to our system. Global-first access.
**Weaknesses:** Single runtime (tmux only). No web dashboard. No plugin system. No PR/CI tracking. No agent abstraction.
---
### CAO — CLI Agent Orchestrator (AWS Labs)
- **GitHub**: https://github.com/awslabs/cli-agent-orchestrator
- **Stack**: Python, tmux, HTTP server (localhost:9889)
**Key Abstractions:**
- **Supervisor + Workers**: Hierarchical model with three coordination patterns:
- **Handoff**: Synchronous task transfer
- **Assign**: Asynchronous spawning with callback
- **Send Message**: Direct communication to agent inboxes
- **Session Isolation**: Agents in separate tmux windows with unique `CAO_TERMINAL_ID`
- **Flows**: Cron-based scheduled agent execution
**Supported Agents:** Amazon Q CLI (default), Kiro CLI, Codex CLI, Claude Code
**Strengths:** Clean supervisor/worker hierarchy. AWS backing.
**Weaknesses:** AWS-centric. Limited ecosystem.
---
### ccswarm (nwiizo)
- **GitHub**: https://github.com/nwiizo/ccswarm
- **Stack**: Rust (2024 edition), ratatui TUI, Tokio async, OpenTelemetry
**Key Abstractions:**
- **ProactiveMaster**: Orchestration core with zero shared state (message-passing channels)
- **Specialized Agent Pools**: Frontend, Backend, DevOps, QA
- **Multi-Provider Layer**: Claude Code, Aider, OpenAI Codex, custom tools
- **Session-Persistent Manager**: Claims 93% token reduction
**Isolation:** Git worktrees per agent. Native PTY sessions (no tmux dependency).
**Strengths:** Rust performance. No tmux dependency. Good provider abstraction.
**Weaknesses:** Partially implemented (orchestrator loop WIP as of v0.4.0).
---
### agent-team (nekocode)
- **GitHub**: https://github.com/nekocode/agent-team
- **Stack**: Rust 92.8%, npm distribution
**Key Abstractions:**
- **Agent Client Protocol (ACP)**: Standardized interface across all agents
- **Process Isolation**: Each agent in its own process with UDS socket
- **Remote Access**: Interact with any agent from any terminal
**Supported Agents:** 20+: Gemini, Copilot, Claude, Goose, Cline, Blackbox, OpenHands, Qwen, Kimi, and more.
**Strengths:** Broadest agent support. Clean protocol.
**Weaknesses:** Thin orchestration. No lifecycle management. No PR/CI tracking.
---
### claude-flow (ruvnet)
- **GitHub**: https://github.com/ruvnet/claude-flow
- **Stack**: TypeScript, Node.js 20+, WebAssembly, SQLite, PostgreSQL
- **Claims**: 100K+ monthly active users, 84.8% SWE-Bench solve rate
**Key Abstractions:**
- **Swarm Topologies**: mesh, hierarchical, ring, star configurations
- **Queen-Led Hierarchies**: Strategic Queens (planning), Tactical Queens (execution), Adaptive Queens (optimization)
- **8 Worker Types**: researcher, coder, analyst, tester, architect, reviewer, optimizer, documenter
- **60+ Specialized Agents** across 8 categories
- **31+ MCP Tools** across 7 categories
- **Shared Memory**: LRU cache with SQLite persistence (WAL mode)
- **ReasoningBank**: Pattern storage with trajectory learning
- **Consensus Mechanisms**: Raft, Byzantine, Gossip, Weighted, Majority
**Extension System:**
- 17 integration hooks (pre-task, post-task, etc.)
- Custom workers (12 context-triggered background services)
- Plugin SDK with IPFS marketplace distribution
- Native MCP integration
**Strengths:** TypeScript. Feature-rich. MCP native.
**Weaknesses:** Claude-only. Overcomplicated. Questionable claims.
---
## Tier 2: Adjacent Tools (Single-Agent or Cloud-First)
### OpenHands (formerly OpenDevin)
- **GitHub**: https://github.com/OpenHands/OpenHands (67.8K stars)
- **Stack**: Python 75.5%, TypeScript/React 22.3%, Docker, Kubernetes
**Key Abstractions:**
- **Software Agent SDK**: Composable Python library
- **Runtime/Sandbox**: Docker-based sandboxed execution environments
- **Event Stream Architecture**: Event-driven communication between backend and frontend
- **ACI (Agent Computer Interface)**: Standardized tools for agent-computer interaction
**Runtime Backends:** Docker (default), Kubernetes, E2B (cloud)
**Deployment Options:** Local CLI, Desktop GUI, Cloud hosting, Enterprise K8s
**Strengths:** Most mature cloud story. Event-sourced architecture (enables replay/audit). 67K stars.
**Weaknesses:** Heavy (Docker required). Not optimized for human-in-the-loop. Single-task runs, not parallel session management.
---
### SWE-agent + SWE-ReX (Princeton NLP)
- **GitHub**: https://github.com/SWE-agent/SWE-agent + https://github.com/SWE-agent/SWE-ReX
- **Stack**: Python 94.6%
**Key Abstractions:**
- **SWEEnv**: Environment manager (thin wrapper around SWE-ReX)
- **Agent**: Configured via single YAML file
- **ACI (Agent-Computer Interface)**: Custom tools installed in container
- **Deployment**: Abstraction over execution targets
**Runtime Backends (SWE-ReX):**
- Local Docker containers
- Modal (serverless compute)
- AWS Fargate (container orchestration)
- AWS EC2 (remote machines)
- Daytona (WIP)
Agent code remains the same regardless of deployment target.
**Strengths:** Cleanest deployment abstraction. Research-backed. Massively parallel (30+ instances).
**Weaknesses:** Research-focused, not production orchestrator.
---
### Goose (Block/Square)
- **GitHub**: https://github.com/block/goose
- **Stack**: Rust 58.9%, TypeScript 33.0%, Go (temporal scheduler)
**Key Abstractions:**
- **Crate architecture**: goose (core), goose-cli, goose-server, goose-mcp, mcp-client, mcp-core
- **Sessions**: Stateful autonomous execution environments
- **Recipes**: Task automation workflows
- **Extensions**: MCP-based capability providers (1,700+ available)
- **Custom Distributions**: Preconfigured providers, extensions, and branding
**Strengths:** Rust core. MCP-native. 1,700+ extensions. Professional engineering.
**Weaknesses:** Single-agent tool. No multi-agent orchestration.
---
### Cline
- **GitHub**: https://github.com/cline/cline
- **Stack**: TypeScript, Node.js, esbuild
**Key Abstractions:**
- **Sequential Decision Loop**: Analysis → Planning → Execution → Monitoring → Iteration
- **Checkpoint System**: Workspace snapshots at each step for compare/restore
- **Context Attachments**: @file, @folder, @url, @problems
**Strengths:** Great human-in-the-loop UX. Checkpoint/restore. Multi-provider.
**Weaknesses:** VS Code only. Single-agent.
---
### Multi-Agent Coding System (Danau5tin)
- **GitHub**: https://github.com/Danau5tin/multi-agent-coding-system
- **Stack**: Python, LiteLLM/OpenRouter, Docker
- **Reached #13 on Stanford's TerminalBench**
**Key Abstractions:**
- **Orchestrator Agent**: Strategic coordinator; never touches code
- **Explorer Agent**: Read-only investigation specialist
- **Coder Agent**: Implementation specialist with write access
- **Context Store**: Persistent knowledge layer across interactions
- **Knowledge Artifacts**: Discrete, reusable context items
**Communication:** XML tags with YAML parameters for task creation/delegation.
**Key Innovation:** "Front-loading precision" — over-providing context vs. rapid iteration.
**Strengths:** Clean role separation. Context Store innovation.
**Weaknesses:** Small project. Not production-ready.
---
### CCPM (Automaze)
- **GitHub**: https://github.com/automazeio/ccpm
- **Stack**: Python, GitHub REST API, Claude Code
**Key Abstractions:**
- **5-Phase Workflow**: Brainstorm → Document → Plan → Decompose → Execute
- **GitHub Issues as Database**: Issues store specs, comments provide audit trail
- **Epic Worktrees**: Each epic spawns a dedicated worktree
- **Parallel Agent Execution**: Tasks marked `parallel: true` run concurrently
---
### AI-Agents-Orchestrator (hoangsonww)
- **GitHub**: https://github.com/hoangsonww/AI-Agents-Orchestrator
- **Stack**: Python (Flask + Socket.IO), Vue 3 + Vite, Docker/Kubernetes
**Key Abstractions:**
- **Workflow Presets**: Default (Codex→Gemini→Claude), Quick, Thorough, Review-Only, Document
- **AI Adapters**: Standardized interfaces per agent tool
- **Session Manager**: Context across workflow steps
- **Vue Dashboard**: Real-time Socket.IO with Monaco editor
---
### wshobson/agents
- **GitHub**: https://github.com/wshobson/agents
- **Stack**: Claude Code plugin ecosystem
**Key Abstractions:**
- **Plugins**: 73 plugins, 112 agents, 146 skills, 79 tools
- **Progressive Disclosure Skills**: 3-tier knowledge
- **16 Workflow Orchestrators**: review, debug, feature, fullstack, research, security, migration
- **4-Tier Model Strategy**: Opus (critical) → Inherit → Sonnet → Haiku
- **Conductor Plugin**: Context → Spec & Plan → Implement
---
## Runtime Backend Research
### Cloud Sandbox Platforms
| Platform | Startup Time | Isolation | API Style | Cost |
| ------------------- | ------------ | -------------------- | -------------------- | ----------- |
| **Docker (local)** | ~1-5s | Container namespace | Docker CLI/API | Free |
| **E2B** | ~200-400ms | Firecracker microVMs | Python/JS SDK | Pay-per-use |
| **Daytona** | ~27-90ms | OCI containers | Python/TS SDK + REST | Open source |
| **Modal Sandboxes** | Sub-second | gVisor containers | Python SDK | $0.03/hr |
| **Fly.io Machines** | ~200ms-1s | Firecracker microVMs | REST API | $0.02/hr |
### Agent-Sandbox Connection Patterns (per LangChain)
**Pattern 1: Agent IN Sandbox**
- Agent runs inside the container/VM
- Communicates outward via HTTP/WebSocket
- Pro: Direct filesystem access, mirrors local dev
- Con: API keys inside sandbox
**Pattern 2: Sandbox AS Tool**
- Agent runs on orchestrator/server
- Calls sandbox via SDK/API for code execution
- Pro: API keys secure, parallel execution
- Con: Network latency per call
### Communication Protocols
| Protocol | Use Case | Used By |
| -------------------- | ----------------------- | -------------------------------- |
| **REST API** | Request/response | OpenHands, Fly.io, Daytona |
| **WebSocket** | Bidirectional streaming | OpenHands, Claude Agent SDK |
| **stdio/subprocess** | Child process | Claude Agent SDK, Codex CLI, MCP |
| **tmux send-keys** | Terminal injection | Our orchestrator, Par, CAO |
| **SSE** | Server → client push | MCP remote transport |
### Heartbeat / Health Detection
| Pattern | Description | Used By |
| ------------------------ | ------------------------------------ | --------------------------- |
| **WebSocket ping/pong** | Periodic heartbeats | OpenHands |
| **Process polling** | Check PID alive | Claude Agent SDK |
| **tmux capture-pane** | Scrape terminal output | Our `claude-session-status` |
| **File-based signaling** | Status to shared filesystem | Our metadata files |
| **HTTP health endpoint** | `/health` or `/status` | OpenHands server |
| **JSONL mtime** | Check session file modification time | Our `claude-status` |
---
## Key Findings & Gaps
### What Everyone Does
1. **Git worktrees** = standard isolation primitive
2. **tmux** = dominant session manager for local
3. **External state > context windows** (Beads, Context Store, GitHub Issues)
4. **MCP** = emerging extension protocol
### What Nobody Does Well (Our Opportunity)
1. **Multiple runtime backends** (tmux + Docker + cloud) with same interface
2. **Multiple agent support** with proper abstraction
3. **Human-in-the-loop optimization** (our core differentiator — everyone else optimizes for autonomous)
4. **Works out of the box** with zero setup
5. **Truly extensible plugin architecture** for all concerns
6. **Beautiful web dashboard** with real-time PR/CI/review tracking
7. **Full PR lifecycle management** (CI checks, review comments, merge readiness, auto-reactions)
### Best Ideas to Steal
- **Gas Town**: Git-backed state (Beads), role-based agents, crash recovery
- **OpenHands**: Event-sourced architecture, Docker/K8s runtime abstraction
- **SWE-ReX**: Clean deployment backend interface (`swe-rex[modal]`, `swe-rex[fargate]`)
- **Par**: Simple `.par.yaml` config, global labels, broadcast to all
- **Goose**: MCP-based extensions, Rust crate architecture
- **Cline**: Checkpoint/restore system
- **Multi-Agent Coder**: Context Store, front-loading precision
- **agent-team**: Agent Client Protocol for 20+ agents
---
## Sources
- [Gas Town](https://github.com/steveyegge/gastown)
- [Gas Town Architecture Analysis](https://reading.torqsoftware.com/notes/software/ai-ml/agentic-coding/2026-01-15-gas-town-multi-agent-orchestration-framework/)
- [Gas Town: Two Kinds of Multi-Agent](https://paddo.dev/blog/gastown-two-kinds-of-multi-agent/)
- [Par](https://github.com/coplane/par)
- [CAO](https://github.com/awslabs/cli-agent-orchestrator)
- [ccswarm](https://github.com/nwiizo/ccswarm)
- [agent-team](https://github.com/nekocode/agent-team)
- [claude-flow](https://github.com/ruvnet/claude-flow)
- [OpenHands](https://github.com/OpenHands/OpenHands)
- [SWE-agent](https://github.com/SWE-agent/SWE-agent)
- [SWE-ReX](https://github.com/SWE-agent/SWE-ReX)
- [Goose](https://github.com/block/goose)
- [Cline](https://github.com/cline/cline)
- [Multi-Agent Coding System](https://github.com/Danau5tin/multi-agent-coding-system)
- [CCPM](https://github.com/automazeio/ccpm)
- [AI-Agents-Orchestrator](https://github.com/hoangsonww/AI-Agents-Orchestrator)
- [wshobson/agents](https://github.com/wshobson/agents)
- [LangChain: Two Agent-Sandbox Patterns](https://blog.langchain.com/the-two-patterns-by-which-agents-connect-sandboxes/)
- [Modal: Top Code Sandbox Products](https://modal.com/blog/top-code-agent-sandbox-products)
- [Rise of Coding Agent Orchestrators](https://www.aviator.co/blog/the-rise-of-coding-agent-orchestrators/)
- [E2B](https://e2b.dev/)
- [Daytona](https://www.daytona.io/)
- [Fly.io AI](https://fly.io/ai)
Reference in New Issue View Git Blame Copy Permalink