Competitive Landscape

Last updated: 2026-03-21

This document tracks Gru's competitive positioning over time. Each section captures a point-in-time snapshot so we can see how the landscape evolves.

March 2026 Update

Added: 2026-03-21

Five new projects researched and added: Symphony (OpenAI), Barnum, Cook, Paperclip, and GitHub Spec-Kit. The space has exploded — OpenAI and GitHub have both entered, and community projects are attracting massive attention (Paperclip: 31k stars in 3 weeks).

Market Overview (March 2026)

The market has expanded beyond just "agent orchestrators" into several distinct categories:

1. Agent Orchestrators: Tools that run multiple AI agents in parallel (Conductor, Emdash, Symphony, Gru)
2. Task Executors: Tools that enhance individual agent task quality (Cook, Barnum)
3. Specification Tools: Tools that generate specs/prompts for agents (Spec-Kit)
4. Business Orchestrators: Platforms that coordinate agents toward business goals (Paperclip)
5. Remote Control Layers: Mobile/remote interfaces for existing agents (Happy)
6. IDE-Integrated Agents: Extensions and built-in coding assistants (Copilot, Cursor - not covered here)

New Entries (March 2026)

Symphony by OpenAI

GitHub: https://github.com/openai/symphony Status: Engineering preview, 13.7k stars License: Apache 2.0

What It Does

Long-running automation service that polls Linear for issues, creates isolated workspaces, and runs OpenAI Codex agents to autonomously implement work. Teams define agent behavior via WORKFLOW.md files (YAML front matter + Markdown prompt) checked into their repo.

Architecture

• Language: Elixir/OTP (reference implementation); spec-first design encourages reimplementation in any language
• Components: Workflow Loader, Issue Tracker Client (Linear), Orchestrator (poll loop), Workspace Manager, Agent Runner
• Dashboard: Optional Phoenix LiveView web UI + JSON API
• Concurrency: Configurable max concurrent agents (default 10), retry with exponential backoff

Business Model

• Free, open source (Apache 2.0)
• Drives OpenAI Codex adoption/revenue

Platform Support

• Any platform with Elixir/Erlang runtime
• SSH remote workers for distributed execution

Strengths

• ✅ Spec-first design (portable across languages)
• ✅ WORKFLOW.md — repo-owned prompt + config pattern
• ✅ Built-in web dashboard (LiveView)
• ✅ SSH remote workers for distributed execution
• ✅ Strong community momentum (13.7k stars)
• ✅ OpenAI brand backing

Weaknesses

• ❌ Linear-only (no GitHub Issues, Jira)
• ❌ Codex-only agent support
• ❌ No GitHub-native workflow (doesn't use labels/PRs as state)
• ❌ Explicitly "prototype software intended for evaluation only"
• ❌ Elixir runtime requirement (niche language)
• ❌ No built-in PR lifecycle (agent handles all writes)

Overlap with Gru

🔴 HIGH - Closest architectural match among new competitors:

• Both: Autonomous polling daemon, per-issue workspace isolation, stuck detection, retry/backoff
• Different: Symphony requires Linear + Codex; Gru uses GitHub as state store + supports multiple backends
• Gru advantage: Full PR lifecycle (review response, CI fix, merge), single binary, GitHub-native
• Symphony advantage: Spec-first portability, web dashboard, SSH remote workers

Barnum

GitHub: https://github.com/barnum-circus/barnum Status: Early stage, 2 contributors License: MIT

What It Does

Task queue orchestrator for AI agents using type-safe state machines. Workflows are defined as JSON configs with explicit states and transitions. Uses "progressive disclosure" — each agent step receives only the context it needs.

Architecture

• Language: Rust monorepo
• Components: Barnum CLI (orchestrator), Task Queue Library (state machines), Troupe (daemon managing agent pools)
• Protocol: File-based dispatch between orchestrator and agent workers

Business Model

• Free, open source (MIT)

Platform Support

• Cross-platform (Rust binary), also distributed via npm/pnpm

Strengths

• ✅ Type-safe Rust with schema validation
• ✅ Progressive disclosure limits agent context per step
• ✅ Persistent worker pools (no cold-start costs)
• ✅ Explicit state transition logging and auditability

Weaknesses

• ❌ Very early (2 contributors, brand new)
• ❌ Generic orchestration — no built-in GitHub/PR/issue awareness
• ❌ Steeper learning curve (state machines + JSON config)
• ❌ File-based protocol may limit scaling

Overlap with Gru

🟡 MODERATE - Different philosophy, some shared goals:

• Both: Rust, multi-agent parallelism, workspace isolation
• Different: Barnum is domain-agnostic workflow engine; Gru is opinionated GitHub lifecycle manager
• Barnum could theoretically serve as an orchestration layer under Gru, but has no built-in git/GitHub/PR understanding

Cook

Website: https://rjcorwin.github.io/cook/ GitHub: https://github.com/rjcorwin/cook Status: Early stage (293 stars), no license file License: None specified (legally ambiguous)

What It Does

CLI for orchestrating Claude Code, Codex, and OpenCode using composable operators. Chain iteration, parallelization, and quality gates: cook "Add dark mode" review v3 "cleanest result" races 3 implementations with review loops, then picks the best.

Core Operators

• Loop: xN (repeat), review (critique-and-refine), ralph (task-list progression)
• Composition: vN (race N approaches), vs (compare strategies)
• Resolvers: pick, merge, compare

Architecture

• Language: TypeScript/Node.js
• Isolation: Git worktrees for parallel branches
• Install: npm global or as a Claude Code skill

Business Model

• Free, open source (but no license file)

Platform Support

• macOS, Linux, Windows via Node.js

Strengths

• ✅ Elegant composable operator syntax
• ✅ Multi-agent support (Claude, Codex, OpenCode)
• ✅ Parallel racing for quality (vN operator)
• ✅ Built-in review loops
• ✅ Can embed as a Claude Code skill

Weaknesses

• ❌ No issue/project management or PR lifecycle
• ❌ Stateless — no daemon mode, registry, or tracking
• ❌ No license file (legally risky)
• ❌ Very new (3 weeks old)
• ❌ Requires human to initiate each task

Overlap with Gru

🟢 LOW - Complementary, not competitive:

• Cook is a "task executor with quality multipliers" (racing, review loops)
• Gru is an "autonomous project worker" (full issue-to-merge lifecycle)
• Cook's racing/review operators could be interesting to integrate into Gru's agent execution layer

Paperclip

GitHub: https://github.com/paperclipai/paperclip Status: Early stage (31k stars in 3 weeks), MIT license

What It Does

Orchestration platform for coordinating multiple AI agents to run autonomous businesses. Models companies with org charts, budgets, goals, governance, and agent coordination. Tagline: "If OpenClaw is an employee, Paperclip is the company."

Architecture

• Language: TypeScript (96.7%)
• Backend: Node.js server with embedded or external PostgreSQL
• Frontend: React UI dashboard
• Agent support: OpenClaw, Claude Code, Codex, Cursor, Bash, HTTP agents

Key Features

• Hierarchical goal alignment (goals cascade through tasks)
• Per-agent monthly budgets with automatic throttling
• Multi-company data isolation
• Governance (approval gates, config versioning, rollback)
• Built-in ticket system with full audit logs

Business Model

• Free, open source (MIT)
• ClipMart (coming soon) — marketplace for pre-built company templates

Platform Support

• Linux/macOS/Windows via Node.js + Docker
• Mobile-responsive web UI

Strengths

• ✅ Explosive community growth (31k stars in 3 weeks)
• ✅ Agent-agnostic (BYO agent)
• ✅ Cost tracking with per-agent budget enforcement
• ✅ Governance and audit capabilities
• ✅ Simple onboarding (npx paperclipai onboard --yes)

Weaknesses

• ❌ No GitHub-native workflow (own ticket system, no PR lifecycle)
• ❌ Overkill for single-agent or small coding setups
• ❌ Requires PostgreSQL
• ❌ Not a code review tool (explicitly stated)
• ❌ Very early (3 weeks old, 917 open issues)

Overlap with Gru

🟢 LOW - Different abstraction levels:

• Paperclip is a "company orchestrator" for business goals across many agent types
• Gru is a "coding agent orchestrator" for GitHub issue lifecycle
• Paperclip could theoretically use Gru as one of its agents
• Paperclip's cost tracking/budgets are a feature Gru lacks

GitHub Spec-Kit

GitHub: https://github.com/github/spec-kit Status: Shipped, backed by GitHub License: MIT

What It Does

"Spec-Driven Development" toolkit that guides developers through a structured workflow: Constitution → Specify → Plan → Tasks → Implement. Specifications become executable — they generate working implementations via AI coding agents.

Architecture

• Language: Python (installed via uv)
• Interface: CLI with slash commands (/speckit.specify, /speckit.plan, etc.)
• Template System: 3-tier hierarchy (Core → Extensions → Presets → Project overrides) in .specify/ directories
• Agent Support: 25+ agents (Claude Code, Copilot, Cursor, Gemini, Windsurf, Codex, etc.)

Business Model

• Free, open source (MIT, Copyright GitHub, Inc.)

Platform Support

• Cross-platform (Linux, macOS, Windows)
• Enterprise/air-gapped deployment via wheel bundles

Strengths

• ✅ Agent-agnostic (25+ supported agents)
• ✅ Backed by GitHub (credibility, ecosystem integration path)
• ✅ Strong specification methodology
• ✅ Highly customizable (presets, extensions, overrides)
• ✅ Enterprise-ready (air-gapped install, proxy support)

Weaknesses

• ❌ Not an orchestrator — requires human to drive each step
• ❌ No PR lifecycle management
• ❌ No issue-to-task pipeline or autonomous claiming
• ❌ No daemon/polling mode
• ❌ Stateless — no persistent tracking

Overlap with Gru

🟢 LOW - Different layer entirely:

• Spec-Kit answers "how do I write a good spec for an AI agent?"
• Gru answers "how do I autonomously manage AI agents working on GitHub issues?"
• Potentially complementary: Spec-Kit could generate specs that Gru's Minions implement
• Risk: If GitHub extends Spec-Kit into full autonomous execution via GitHub Actions

Competitive Positioning Matrix (March 2026)

December 2025 Analysis

Original analysis from 2025-12-13. Covered: Conductor, Emdash, Happy.

Direct Competitors (Dec 2025)

Conductor by Melty Labs

Website: https://conductor.build/ GitHub: https://github.com/ryanmac/code-conductor Status: Shipped, Y Combinator backed

What It Does

Run multiple Claude Code agents in parallel with GitHub-native orchestration. Each agent works in isolated git worktrees to avoid merge conflicts.

Business Model

• Free - No separate pricing
• Uses your existing Claude subscription (Pro, Max, or API)
• Likely VC-funded with future enterprise/cloud monetization

Platform Support

• Mac only (requires Apple Silicon)
• Desktop application

Open Source Status

• GitHub repository is public but has no LICENSE file
• Technically source-available but not legally open source
• Cannot be legally forked/modified/distributed without permission

Strengths

• ✅ First mover advantage in this niche
• ✅ Y Combinator backing (resources, credibility)
• ✅ Polished desktop app UX
• ✅ Free to use
• ✅ Already has production users

Weaknesses

• ❌ Mac-only (excludes Linux/Windows users)
• ❌ Unclear licensing (no LICENSE file)
• ❌ Appears to be one-shot execution (PR created, agent done)
• ❌ Desktop app only (no headless/server deployment)
• ❌ Requires Apple Silicon (excludes Intel Macs)

Overlap with Gru

🔴 HIGH - This is our closest competitor. Both tools:

• Orchestrate multiple AI agents on GitHub issues
• Use git worktrees for isolation
• Aim for autonomous claim → implement → PR workflow
• Support parallel execution

Emdash by General Action

Website: https://www.emdash.sh/ GitHub: https://github.com/generalaction/emdash Status: Shipped, open source

What It Does

Coding agent orchestration layer that supports 15+ AI CLI tools (Claude Code, Qwen Code, Amp, Codex, etc.) with parallel execution in git worktrees.

Business Model

• Open source (appears to be MIT/Apache based on GitHub)
• Free to use
• Monetization model unclear

Platform Support

• Cross-platform (Windows, Mac, Linux)
• Packaged as desktop app (.exe, .dmg, .AppImage, .deb)

Provider Support

• Multi-provider - 15+ different AI CLIs supported
• Provider-agnostic architecture
• Users can choose models per task

Strengths

• ✅ Multi-provider support (not locked to Claude)
• ✅ Cross-platform
• ✅ Appears to be truly open source
• ✅ Good diff review UI
• ✅ Linear, GitHub, Jira integration

Weaknesses

• ❌ Desktop app packaging complexity
• ❌ Task-based model (not persistent agents)
• ❌ More complex setup (supports many providers)

Overlap with Gru

🟡 MODERATE - Similar orchestration goals but different architecture philosophy:

• Both: Git worktrees, parallel execution, GitHub integration
• Different: Emdash is multi-provider, Gru focuses on Claude with persistent agents

Adjacent Tools (Dec 2025)

Happy

Website: https://happy.engineering/ Status: Shipped, open source (npm install -g happy-coder)

What It Does

Mobile client for remotely controlling Claude Code instances running on your computers. Not an orchestrator itself, but a remote control layer.

Business Model

• Free and open source
• No monetization

Platform Support

• Mobile app (iOS/Android)
• Controls Claude Code on any machine (Mac, Linux, Windows)

Strengths

• ✅ Mobile-first design
• ✅ End-to-end encryption
• ✅ Multiple concurrent sessions
• ✅ Remote workflow ("fire off tasks while away from desk")

Weaknesses

• ❌ Not an orchestrator (requires manual task assignment)
• ❌ No GitHub issue queue management
• ❌ No autonomous claiming/execution

Overlap with Gru

🟢 LOW - Complementary, not competitive. Happy is a UI layer; Gru is an orchestrator. Could potentially use Happy to monitor Gru Labs remotely.

Competitive Positioning Matrix (Dec 2025)

Gru's Strategic Advantages (Dec 2025)

1. 🎯 Persistent Minions (Killer Feature)

What it means: Gru's agents stay alive after creating a PR to handle:

• Review comment responses
• Failed CI check fixes
• Feedback iterations
• Multiple review rounds

Why it matters: Competitors treat agents as one-shot tasks. Gru treats them as autonomous collaborators for the full PR lifecycle.

Marketing message: "Autonomous collaborators, not just code generators"

2. ✅ Cross-Platform

What it means: Gru works on Mac, Linux, Windows—anywhere Rust compiles.

Why it matters:

• Conductor is Mac-only (excludes ~70% of developers)
• Emdash requires desktop environment
• Gru can run headless on servers ($5/month VPS vs. $2000 Mac)

User stories:

• "Run Gru Labs on cheap Linux VPS"
• "Works on your company's Windows laptop"
• "Deploy in Docker containers"

3. ✅ Clear Open Source License

What it means: MIT or Apache 2.0 license (assuming we choose this).

Why it matters:

• Conductor has no LICENSE file (legally murky)
• Enterprises need clear licensing for compliance
• Developers can fork, modify, contribute freely

Marketing message: "Fully open source with clear MIT licensing—no gray areas"

4. ✅ GitHub as Database

What it means: No separate database—issues are queue, labels are state, PRs are results.

Why it matters:

• Simpler architecture (no PostgreSQL/Redis to maintain)
• Inspectable state (everything visible in GitHub)
• Rebuild state from GitHub on restart
• No vendor lock-in

User benefit: "Your orchestration state is just GitHub—no black box database"

5. ✅ Lab + Tower Architecture

What it means: Labs run autonomously; Tower is optional stateless UI relay.

Why it matters:

• Labs work offline (local-first principle)
• Tower can crash without affecting Labs
• Multiple Labs can coordinate via GitHub
• Remote access without VPN (Labs dial out to Tower)

Unique capability: "Multi-Lab coordination across machines/teams"

6. ✅ Single Binary

What it means: gru lab, gru tower, gru fix all from one executable.

Why it matters:

• Simple installation (cargo install gru or download binary)
• No desktop app packaging complexity
• Works in CI/CD, scripts, automation
• Easy to update

Developer benefit: "One command to install, no app store required"

Competitive Threats (Updated March 2026)

1. 🔴 Conductor Has First-Mover Advantage (Dec 2025)

• Already shipped and has users
• Y Combinator visibility and resources
• Refined UX from user feedback
• Production-tested

Mitigation:

• Move fast to Phase 2 (autonomous orchestration)
• Emphasize cross-platform and open source
• Target Linux/Windows users Conductor can't serve

2. 🟡 Emdash Has Multi-Provider Support (Dec 2025)

• Users may want choice in AI models
• Cost optimization (cheaper models for simple tasks)
• Avoid vendor lock-in to Anthropic

Mitigation:

• Phase 3+ roadmap includes multi-provider support
• Focus on doing Claude really well first
• Plugin architecture for future extensibility

3. 🔴 Symphony Has OpenAI Backing (Mar 2026)

• OpenAI brand and distribution (13.7k stars immediately)
• Spec-first approach encourages ecosystem of implementations
• WORKFLOW.md pattern is elegant and could become a standard
• SSH remote workers enable distributed execution

Mitigation:

• Symphony is Linear-only and Codex-only; Gru is GitHub-native with multiple backends
• Symphony delegates PR lifecycle to agent; Gru manages it end-to-end
• Symphony requires Elixir runtime; Gru is a single binary
• Adopt good ideas: consider WORKFLOW.md-style repo-owned config

4. 🟡 All Tools Are Free (Dec 2025)

• No pricing moat or defensibility
• Competition is purely on features/UX
• Hard to out-spend VC/corporate-backed competitors (YC, OpenAI, GitHub)

Mitigation:

• Open source creates community moat
• Cross-platform serves wider market
• Persistent Minions = unique feature
• Future: Hosted Tower convenience (optional paid tier)

5. 🟡 Paperclip Has Explosive Community Growth (Mar 2026)

• 31k stars in 3 weeks signals massive interest in agent orchestration
• Agent-agnostic model attracts broader audience
• Cost tracking/budgets address a real gap in Gru

Mitigation:

• Paperclip targets business orchestration, not coding agent lifecycle
• No GitHub-native workflow or PR lifecycle
• Gru could adopt cost tracking as a feature

Market Insights (Dec 2025)

Validated Demand

✅ The market exists: Conductor and Emdash prove developers want GitHub agent orchestration.

✅ Users will adopt: Production usage of competitors shows willingness to trust AI agents.

✅ Free model works: All competitors are free, using existing Claude/AI subscriptions.

User Needs (Confirmed)

1. Parallel execution: Tackle backlog with multiple agents simultaneously
2. Merge conflict avoidance: Git worktree isolation is table stakes
3. GitHub-native: Developers want orchestration integrated with existing workflow
4. Simple setup: Must be easy to install and configure
5. Visibility: Need to see what agents are doing (dashboard, logs, diffs)

Unmet Needs (Gru's Opportunity)

1. Post-PR handling: No competitor does PR review response well
2. Cross-platform: Conductor is Mac-only, Emdash requires desktop
3. Server deployment: Run agents on cheap VPS, not expensive Mac
4. Multi-Lab: Coordinate agents across machines/teams
5. Clear licensing: Enterprises need MIT/Apache, not "no license"

Strategic Recommendations (Dec 2025)

Phase 1-2: Catch Up

Goal: Match Conductor's core orchestration by Q1 2025

Priorities:

1. Issue claiming via labels (gru:todo)
2. Git worktree management
3. Parallel Minion execution
4. PR creation workflow
5. Basic status dashboard

Messaging: Focus on cross-platform and open source

Phase 2-3: Differentiate

Goal: Ship features competitors don't have

Priorities:

1. Persistent Minions (respond to reviews, fix CI)
2. Tower UI (web-based, mobile-responsive)
3. Multi-Lab (coordinate across machines)

Messaging: "Full PR lifecycle, not just code generation"

Phase 3+: Expand

Goal: Build moats through ecosystem

Priorities:

1. Multi-provider support (match Emdash)
2. Plugin architecture
3. Hosted Tower convenience tier ($10-20/month optional)
4. Enterprise features (SSO, audit, multi-org)

Messaging: "Open platform for autonomous development"

Positioning Statement (Dec 2025)

For developers who manage large GitHub backlogs, Gru is an autonomous agent orchestrator that handles the full PR lifecycle from issue claim to merge, unlike Conductor (Mac-only, one-shot PRs) or Emdash (desktop app, task-based), Gru runs anywhere (Linux VPS, Windows, Mac), is fully open source, and its persistent Minions handle reviews, CI failures, and iterations—making them true autonomous collaborators.

Opportunities to Learn From Competitors (Updated March 2026)

From Conductor

• ✅ UX patterns for agent orchestration
• ✅ GitHub-native workflow design
• ✅ Messaging around "self-managing agents"
• ❓ How they handle edge cases (duplicate claims, stuck agents)

From Emdash

• ✅ Multi-provider plugin architecture
• ✅ Side-by-side diff UI patterns
• ✅ Task assignment UX
• ✅ Support for external trackers (Linear, Jira)

From Symphony

• ✅ WORKFLOW.md as repo-owned prompt + runtime config (versioned with code)
• ✅ Spec-first design (portable, encourages ecosystem)
• ✅ Phoenix LiveView dashboard patterns
• ✅ SSH remote workers for distributed execution

From Cook

• ✅ Composable operator syntax for chaining agent behaviors
• ✅ Racing (vN) multiple implementations for quality
• ✅ Built-in review loops as first-class workflow concept

From Barnum

• ✅ Progressive disclosure (limit context per agent step)
• ✅ Type-safe state machine workflow definitions
• ✅ Persistent worker pools to avoid cold-start costs

From Paperclip

• ✅ Per-agent cost tracking and budget enforcement
• ✅ Goal alignment (agents see "what" and "why")
• ✅ Governance patterns (approval gates, rollback)
• ✅ Audit logging for agent actions

From Spec-Kit

• ✅ Specification-driven development methodology
• ✅ Template hierarchy (core → extensions → presets → project overrides)
• ✅ Enterprise deployment patterns (air-gapped, proxy support)

From Happy

• ✅ Mobile-responsive thinking for Tower UI
• ✅ Multiple concurrent session management
• ✅ Real-time monitoring UX
• ✅ "Remote workflow" messaging

Questions to Investigate (Dec 2025)

1. Conductor's PR lifecycle: Do they handle review responses? CI failures? How?
2. Emdash architecture: How does their multi-provider plugin system work?
3. User feedback: What do users love/hate about these tools? (Check Discord, GitHub issues)
4. Enterprise adoption: Are companies using these in production? What blockers exist?
5. Collaboration potential: Would Melty Labs or General Action be open to coordination?

Conclusion

December 2025 Assessment

Gru is NOT redundant. It occupies a unique position with:

• Cross-platform support (not Mac-only)
• Persistent agent model (full PR lifecycle)
• GitHub-as-database architecture (no separate state)
• Clear open source licensing (MIT/Apache)
• Lab + Tower split (local-first with optional remote UI)

The opportunity is real: Conductor and Emdash validate market demand for GitHub agent orchestration.

Gru's path to win:

1. Ship Phase 2 quickly (match competitors' core features)
2. Emphasize cross-platform and open source (serve wider market)
3. Nail persistent Minions (unique differentiator)
4. Build community moat (open source, clear license, extensible)

Competition is healthy: Validates the problem, raises awareness, improves the category. Gru's principles (local-first, one binary, GitHub as state) position us well for the long term.

March 2026 Assessment

The landscape has grown significantly. OpenAI entered with Symphony, GitHub shipped Spec-Kit, and community projects like Paperclip (31k stars in 3 weeks) show explosive interest in agent orchestration. The field has expanded from 3 tools to 8.

Gru's position has strengthened:

• Full PR lifecycle — Still the only tool that manages claim → implement → PR → review response → CI fix → merge autonomously. Every other tool either stops at PR creation (Conductor, Cook) or delegates lifecycle management to the agent (Symphony).
• GitHub-native — No external tracker dependency. Symphony requires Linear; Paperclip requires Postgres. Gru uses GitHub as both code host and state store.
• Single binary — No runtime dependencies. Competitors require Elixir (Symphony), Node.js (Cook, Paperclip), or Python (Spec-Kit).
• Cross-platform — Conductor is still Mac-only.
• Clear open source licensing — MIT/Apache. Conductor and Cook still have no license file.

New competitive dynamics:

• Symphony is architecturally the closest new competitor (autonomous poll-loop, workspace isolation, stuck detection). But it's Linear-only, Codex-only, and Elixir-only.
• Paperclip validates massive interest in agent orchestration but operates at a different abstraction level (business orchestration vs coding lifecycle).
• Cook and Barnum are complementary tools, not direct competitors.
• Spec-Kit is a specification layer, not an orchestrator — but watch for GitHub extending it.

Ideas worth adopting from competitors:

1. WORKFLOW.md-style repo-owned config (from Symphony)
2. Cost tracking and per-agent budgets (from Paperclip)
3. Web dashboard for observability (from Symphony, Paperclip)
4. Racing/review operators for quality (from Cook)