External/roboco
1
0
Fork 0
mirror of https://github.com/rennf93/roboco.git synced 2026-08-03 07:23:24 +02:00
Code Issues Packages Projects Releases Wiki Activity

[36f50c8e] Write factual framework-comparison research doc (#795) (#803)

Browse Source 
* [fff7b8e3] Write factual framework-comparison research doc (#778)

* [fff7b8e3] docs(backend): add factual LangGraph/CrewAI/AutoGPT vs RoboCo comparison

* [fff7b8e3] docs(backend): ground the per-agent workspace/branch section in build_branch_name and workspace.py

* [fff7b8e3] docs(backend): index framework-comparison-2026.md in backend docs README

---------




* [1a34207b] Fix lifecycle symbol citations in framework-comparison-2026.md (#797)



* [171e90b8] Correct BudgetPolicy budget-field citation in framework-comparison doc (#802)



---------

Co-authored-by: roboco-app[bot] <302741806+roboco-app[bot]@users.noreply.github.com>
Co-authored-by: Backend Developer 2 <be-dev-2@roboco.tech>
Co-authored-by: Backend Documenter <be-doc@roboco.tech>
This commit is contained in:
roboco-app[bot]
2026-08-02 04:57:58 +00:00
committed by GitHub
co-authored by roboco-app[bot] <302741806+roboco-app[bot]@users.noreply.github.com> Backend Developer 2 Backend Documenter
parent 8b18dc3e95
commit 92063a83a9
2 changed files with 47 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/backend/README.md
+1
View File
@@ -9,6 +9,7 @@ Documentation for the Backend Cell team.
## Contents
- `framework-comparison-2026.md` - Factual LangGraph / CrewAI / AutoGPT vs. RoboCo comparison mapping each framework's model to a real RoboCo mechanism (task lifecycle, role hierarchy, per-agent git isolation, PR-review gates, CEO-approval gate), with code citations
- `/api/` - API documentation
- `/qa/` - QA-related docs
- `/services/` - Internal service architecture & patterns
docs/backend/framework-comparison-2026.md
+46
View File
@@ -0,0 +1,46 @@
# Framework comparison: LangGraph / CrewAI / AutoGPT vs. RoboCo (2026)
**Source:** [aegisai.in — LangGraph vs CrewAI vs AutoGPT (2026)](https://aegisai.in/langgraph-vs-crewai-vs-autogpt-2026/)
That 2026 market comparison finds the open-source multi-agent framework landscape fragmented and build-it-yourself: LangGraph is the production-grade choice for complex state via a graph-based state machine, CrewAI is best for collaborative role-based crew simulations, and AutoGPT is dated but beginner-friendly with an autonomous-loop model. None of the three ship as a running product — each is a library or framework a buyer wires up themselves.
This document maps each framework's model to the closest mechanism RoboCo actually ships, citing real code paths in this repository rather than marketing language.
## LangGraph's graph-based state machine vs. RoboCo's task lifecycle
LangGraph models an agent workflow as an explicit graph of nodes and edges that a developer assembles and maintains themselves. RoboCo ships the equivalent state machine already built and enforced: `Status` in `roboco/foundation/policy/lifecycle.py` enumerates every task state (`backlog`, `pending`, `claimed`, `in_progress`, `blocked`, `paused`, `verifying`, `awaiting_qa`, `needs_revision`, `awaiting_documentation`, `awaiting_pr_review`, `awaiting_pm_review`, `awaiting_ceo_approval`, `completed`, `cancelled`), and `_STATUS_TRANSITIONS` (the same module) is a declarative table of `StatusTransition` entries — `(source, target, triggered_by_action, role_constraint)` — that the gateway's Choreographer enforces on every verb call. Role gating comes from the triggered action's `ActionSpec.allowed_roles` / `IntentSpec.allowed_roles`, inherited by a transition via `role_constraint=None` (set explicitly only when a transition's gate differs from the action's). A LangGraph user builds and debugs this graph from scratch per project; RoboCo's graph is canonical, versioned in one module, and already wired to role-based permissions, claim-locking, and audit logging (every transition emits a `task.<status>` row consumed by `MetricsService`, per `docs/backend/framework-comparison-2026.md`'s sibling docs under `docs/map/`). The buyer edits task content, not the state machine.
## CrewAI's role-based crews vs. RoboCo's agent role hierarchy
This is the closest structural adjacency of the three, and it is worth calling out explicitly: CrewAI's core abstraction is a "crew" of agents each assigned a role (researcher, writer, reviewer, …) that hand work to each other. RoboCo's org chart is the same shape at a glance — `be-pm` plans and delegates, `be-dev-1`/`be-dev-2` implement, `be-qa` reviews, `be-doc` documents, mirroring a CrewAI crew's role split (see the org tree in this repo's root `CLAUDE.md`: Main PM → cell PM → developers/QA/documenter/PR reviewer, repeated per team).
The difference is what a buyer actually receives. CrewAI is a Python library: you import it, define your own agents/tasks/crew, and run it inside infrastructure you build and operate — no persistent task store, no git integration, no review gates, no approval chain ship with the library. RoboCo ships all of that already running: `TaskService` (`roboco/services/task.py`) persists every task with acceptance criteria and a `branch_name` auto-set on claim; `WorkSessionService` (`roboco/services/work_session.py`) tracks the git session (branch, commits, PR number) per claim, enforced to at most one active session per task (migration 047's partial-unique index, referenced in this repo's own `CLAUDE.md`); and the role hierarchy above is not agent prompt text — it is enforced server-side by the `allowed_roles` sets on `ActionSpec` / `IntentSpec` in `roboco/foundation/policy/lifecycle.py`, inherited by transitions in `_STATUS_TRANSITIONS` where `role_constraint=None` (and driven through `_INTENT_VERBS`), so a developer role literally cannot call the PM's `delegate` or the QA's `pass_review` verb. CrewAI remains a library a buyer assembles themselves; RoboCo ships the full 25-agent organization as a running, governed product — not a kit.
Per-agent git isolation is likewise already built, not something a CrewAI buyer has to design. `build_branch_name` (`roboco/templates/git/branch.py`) generates every task's branch as `{type}/{team}/{root}--{sub}--{subsub}--{subsubsub}` (up to 4 ancestor levels, shorter hierarchies omitting the trailing segments), walking the task's ancestor chain so a leaf dev task's branch name encodes its whole delegation path back to the root. Each agent then works in its own isolated checkout: `WorkspaceService.get_workspace_path` (`roboco/services/workspace.py`) resolves an agent's clone to `{workspaces_root}/{project}/{team}/{agent}/`, and `get_worktree_path` (same module) gives each individual task its own `git worktree` under that clone (`{clone_root}/.worktrees/{task_short_id}`) so a coordinator PM holding several `in_progress` roots at once never clobbers one root's working tree by checking out another's branch.
## AutoGPT's autonomous loop vs. RoboCo's per-task agent execution loop
AutoGPT's model is a single agent looping autonomously toward a goal with no built-in checkpoint for human review — the loop runs until the agent decides it's done (or runs out of budget), a well-known reliability and predictability liability. RoboCo's per-task execution loop is bounded and gated at every step instead of open-ended: an agent claims one task via `i_will_work_on` (which requires a plan and a checklist before it starts, `roboco/services/gateway/`), works it through `in_progress` with commits and progress updates, and must pass through `verifying` → `awaiting_qa` before QA's `claim_review`/`pass_review`/`fail_review` verbs (`IntentSpec` entries in `roboco/foundation/policy/lifecycle.py`, lines ~1378-1410) ever let it proceed further. A tool-call budget (`BudgetPolicy.tool_call_warn_at`/ `tool_call_halt_at` in `roboco/foundation/policy/agent_loop.py`) and a same-window loop detector bound runaway tool use the way AutoGPT's undifferentiated loop does not. Where AutoGPT is one agent looping alone, RoboCo's loop is one agent working one bounded, reviewed unit of work at a time, handed off through a fixed pipeline of other agents and gates.
## PR review gates
RoboCo enforces two review gates AutoGPT/CrewAI/LangGraph have no equivalent of, because none of the three ship a delivery pipeline at all:
- **QA review.** `claim_review` → `pass_review`/`fail_review` (`IntentSpec`s in `roboco/foundation/policy/lifecycle.py`) gate every developer's PR before it can proceed to documentation and PM review; `fail_review` bounces the task to `needs_revision` with structured, per-file findings (`task_review_findings`, the revision-findings ledger described in this repo's `CLAUDE.md`).
- **In-path PR-review gate.** Beyond individual dev PRs, every *assembled* cell→root or root→master PR passes through its own `awaiting_pr_review` state before a PM can merge it: `submit_up`/`submit_root` open that PR, and a dedicated PR reviewer's `pr_pass`/`pr_fail` verbs (`StatusTransition(Status.AWAITING_PR_REVIEW, ...)` in `roboco/foundation/policy/lifecycle.py`) either advance it to `awaiting_pm_review` or bounce it back to `needs_revision` — a merge-level reject that catches integration issues a single dev's own QA pass would not.
## The CEO-approval gate on every merge to master
No merge to master happens without a human sign-off. `escalate_to_ceo` (`ActionSpec`/`IntentSpec` in `roboco/foundation/policy/lifecycle.py`) is the only transition into `awaiting_ceo_approval`, restricted to `{MAIN_PM, PRODUCT_OWNER, HEAD_MARKETING}` roles, and only from `AWAITING_PM_REVIEW` or `BLOCKED`. From there, only the `CEO` role may act: `ceo_approve` transitions to `completed` (merging the PR), `ceo_reject` transitions back to `needs_revision` with a structured blocker finding recorded against the task, and `ceo_reject_to_pool` returns it to `pending`. Every one of these is a role-checked `ActionSpec`/`StatusTransition` entry in the same canonical module every other consumer (the Choreographer, the MCP tool manifest, the RAG corpus, agent prompts, the panel UI) reads from — a single source of truth, not a convention documented in prose and hoped for. LangGraph, CrewAI, and AutoGPT have no analogous concept: any human approval step in those frameworks is something a buyer has to design and build into their own orchestration code.
## Summary
| Framework concept | RoboCo mechanism | Real code |
|---|---|---|
| LangGraph graph-based state machine | Task lifecycle state machine | `roboco/foundation/policy/lifecycle.py` (`Status`, `_STATUS_TRANSITIONS`) |
| CrewAI role-based crew orchestration | Agent role hierarchy (PM/dev/QA/doc/PR-reviewer per cell) | `roboco/foundation/policy/lifecycle.py` (`allowed_roles` per `ActionSpec`/`IntentSpec`), `roboco/services/task.py`, `roboco/services/work_session.py` |
| AutoGPT autonomous loop | Per-task, gated agent execution loop | `roboco/services/gateway/` (claim/plan/commit/submit verbs), `roboco/foundation/policy/agent_loop.py` (budget) |
| (none — no delivery pipeline in any of the three) | Dev QA gate + in-path PR-review gate | `roboco/foundation/policy/lifecycle.py` (`claim_review`/`pass_review`/`fail_review`, `pr_pass`/`pr_fail`) |
| (none — no human approval concept in any of the three) | CEO-approval gate on every merge to master | `roboco/foundation/policy/lifecycle.py` (`escalate_to_ceo`, `ceo_approve`, `ceo_reject`) |
All three frameworks are libraries a buyer assembles into their own infrastructure — including CrewAI, whose role-based crew model is structurally the closest to RoboCo's own hierarchy. RoboCo's differentiation is not a novel orchestration primitive; it is that the state machine, the role hierarchy, the review gates, and the human approval chain are already built, already enforced server-side, and already running as one governed product — not source code a buyer has to write, wire up, and operate themselves.