Why I Stopped Predefining Agent Roles — and Built a Runtime That Grows Its Own Team

何勇军 — Mon, 12 Oct 2026 10:19:03 +0000

Most multi-agent frameworks ask you to design the team before you know the task.

You define roles (researcher, writer, reviewer), wire up a workflow or a graph, and then
feed tasks into that fixed shape. CrewAI calls them Crews. AutoGen calls them conversable
agents. LangGraph makes you draw the graph by hand. All three assume you can predict, in
advance, what kind of team a task will need.

That assumption breaks down fast once tasks get long, ambiguous, or multi-stage — a feature
that needs design, then implementation, then tests, where you don't know at the start how
many workers it'll take or how the work should split.

So I built AICU-Graph, an open-source
multi-agent orchestration runtime that doesn't predefine the team at all. You give it a
goal. A Manager plans the work and spawns Worker nodes at runtime. As the task evolves,
the organization reorganizes — more nodes, different division of labor, new collaboration
edges — without you hand-authoring a workflow graph upfront.

The core difference

	CrewAI / AutoGen / LangGraph	AICU-Graph
Roles	Defined upfront	Created as needed
Topology	Fixed graph / fixed conversation pattern	Built and reshaped at runtime
Who decides structure	You, the developer	The Manager, based on the live task
Execution	Agent abstractions call an LLM API	Each node runs a real coding CLI

That last row matters as much as the first three. Every node in AICU-Graph is driven by an
actual CLI tool — Claude Code, Codex CLI, Gemini CLI, and others — not a thin LLM-call
wrapper. Workers don't just reason about code, they run in a real terminal session with
real tool access, the same way a human developer would.

What this looks like in practice

A goal comes in. The Manager breaks it down and creates the Worker nodes it currently
thinks it needs. Workers execute independently on their piece of the problem. When a
Worker's output changes what the task actually requires — new dependency discovered,
scope turns out bigger than expected — the Manager can adjust: spawn more nodes, change
how work is divided, or change who collaborates with whom. The organization is a living
structure, not a static diagram you drew before starting.

I ran this on a real task and watched it grow into a 60-node Manager/Worker session,
entirely from a single goal, with no pre-authored workflow. Here's a ~3-minute walkthrough:

https://github.com/user-attachments/assets/ed0c9594-8b8f-49b8-9082-0755e13ab0bc

Full-length version: https://youtu.be/Zw-mO_qeR20

Why this is worth trying if you use Claude Code or Codex CLI

If you're already driving Claude Code or Codex CLI for coding tasks, AICU-Graph sits one
level up: instead of running one CLI session yourself, you give it a goal and it coordinates
multiple CLI sessions as Manager and Workers, each with their own context and job, while
you watch the graph, events, and node logs in a web workbench.

It's a research and engineering prototype — functional, not polished. The CLIs and models
you can use depend on your local installs, accounts, and quotas. The current open
problem I'd most want feedback on: as the role pool for Workers grows into the hundreds,
how do you pick the right small set of roles to cover a task — retrieval, ranking, coverage
checks? That's a stub in the current build and genuinely unsolved.

Try it


bash
git clone https://github.com/heyongjun666/AICU-Graph.git
cd AICU-Graph
# install deps, install a CLI (Claude Code / Codex / Gemini), then:
python3 main.py

DEV Community: 何勇军

Why I Stopped Predefining Agent Roles — and Built a Runtime That Grows Its Own Team

The core difference

What this looks like in practice

Why this is worth trying if you use Claude Code or Codex CLI

Try it