Skip to content

Why angelo, not a framework

Most multi-agent frameworks — LangGraph, CrewAI, AutoGen, and friends — ship a runtime: a Python process you host, an execution engine that owns the control loop, usually a state store, and often a server and a UI. You write your agents inside their abstractions and hand them the keys to run the show.

Angelo's coordinator ships none of that. It is a protocol plus a small MCP tool set, and it rides the subagent spawning your editor already has.

Where the agents actually run

The load-bearing idea: angelo does not run agents — your editor does.

Cursor and Claude Code can already spawn subagents (Cursor's Task tool; Claude Code's subagents). Those subagents are full agent sessions with tools, context, and a model — the exact thing a framework spends most of its code reimplementing. Angelo leans on them instead:

  • The coordinator designs a task DAG and asks for your approval.
  • For each ready task it takes a write lease and asks the host agent to spawn a subagent (the same primitive you'd use by hand).
  • The subagent does the work; the coordinator records the result, advances the wave, and appends fix cycles when a check fails.

So the "engine" is the editor's own agent loop. Angelo is the thin layer that turns a one-shot "spawn a subagent" button into a reviewable, resumable graph.

A coordinator wave: the engineer done, reviewer/critic/tester running in parallel, and memory waiting to record

The coordinator only tracks the graph: each node is a subagent the editor spawns. Here Wave 2's checkers run in parallel after the engineer, with the memory node waiting to record last.

What that buys you

Typical framework Angelo coordinator
Runtime A process/engine you host and keep alive None — it's MCP tools over stdio
Where agents run Inside the framework's executor The editor's native subagent spawner
State A database or in-memory store you manage Plain files in .memory/ + coordinator state, committed to git
Install footprint The framework + its transitive deps A pip package exposing MCP servers
Model access You wire up API keys and providers Whatever your editor already uses
Observability Framework-specific tracing The memory dashboard, reading the same files
Lock-in Agents written to the framework's API Agents are just prompts + personas in agents.yaml

The practical upshot: there is nothing extra to deploy, no second place for secrets, and no divergence between "the agent in my editor" and "the agent in the pipeline" — they are the same runtime.

Just enough orchestration

Being lightweight doesn't mean being naïve. The coordinator adds exactly the coordination a shared-workspace, multi-agent run needs, and no more:

  • Waves + a DAG. Tasks declare dependencies; the coordinator runs each unblocked wave, waits for all of it, then decides what's next.
  • Path-scoped write leases. Implementers with disjoint writes run in parallel; only overlapping scopes serialize. That is the entire concurrency model — no global lock, no scheduler.
  • Bounded, on-graph fixes. A failed review appends an [engineer, reviewer] cycle up to a rigor-set cap, then escalates to you. Corrections never happen off-graph, so the dashboard always reflects reality.
  • Resumability. Because the graph and its results are files, a run whose chat closed can be adopted and continued rather than restarted.

When you'd still want a heavier framework

Angelo is aimed at coding and research work driven from an editor, where the host already provides capable agents. If you need to run agents headless on a server with no editor in the loop, orchestrate long-lived autonomous services, or express control flow far richer than a DAG of waves, a full framework earns its weight. Angelo trades that generality for near-zero setup and complete transparency in the environment where you actually work.

Semantically related entries from the memory graph.