agents-cli · teams · graph engineering

Multi-agent work is a graph.
Teams make the edges explicit.

agents teams turns a multi-step coding goal into a directed acyclic graph of agent processes: nodes are named teammates, edges are --after dependencies, and a supervisor drains the DAG wave by wave — locally or across a device pool. That is graph engineering applied to real CLIs (Claude, Codex, Grok, …), not a slide deck.

product agents teams edge --after name[,name] runtime start --watch as of 2026-08-10 source lib/teams/*
DAG
Topology
nodes = teammates · edges = --after
Waves
Scheduler
parallel ready set each tick
Devices
Placement
pin · pool · least-loaded
Disk
State machine
meta.json · restartable

01What “graph engineering” means here

In 2026 the industry name for designing multi-agent topology — not just one agent’s tool loop — is graph engineering.

Working definition Graph engineering designs the multi-agent system as an explicit graph: which nodes exist (agents, joins, human checkpoints), which transitions are allowed, and how work routes. Loop engineering designs how each node thinks. You need both. — TrueFoundry, “Graph Engineering for Multi-Agent Systems” (Jul 2026); explainx.ai synthesis (Jul 2026)

Linear chains (A then B then C) break under real product work: independent surfaces want parallelism; QA should wait on both backend and frontend; a planner can add nodes mid-flight. A DAG encodes that structure once — true parallelism for independent nodes, joins for multi-parent deps, no circular waits.

See also: DAG-First Agent Orchestration (Apr 2026); Microsoft Conductor (YAML deterministic multi-agent graphs, May 2026); LangGraph multi-agent workflows (nodes + edges + state).

LINEAR CHAIN auth ui qa ui waits on auth even if files are independent DAG (agents teams) auth ui qa wave 1: auth ∥ ui · wave 2: qa --after auth,ui Independent surfaces race · join waits for both
Same goal, better topology. Parallel independent work + multi-parent join is the default multi-agent pattern in production systems (2026).

02The edge: --after (and “before”)

In agents-cli the edge is declared on the dependent node: “start me only after these names finish.”

# Nodes
agents teams add feat claude "Implement /api/pricing" --name backend
agents teams add feat codex  "Build pricing UI"       --name frontend

# Edge: qa depends on both (multi-parent join)
agents teams add feat claude "Playwright suite" --name qa --after backend,frontend
ConceptIn graph theoryIn agents teams
NodeVertex / taskNamed teammate (--name)
EdgeA → B “B after A”add … --name B --after A
JoinMulti-inbound edges--after A,B,C (all must complete)
“Before”Inverse edge languageNot a flag — declare on the child with --after
CycleForbidden in a DAGRejected at add time (validateAddPreconditions)
Ready setZero indegree remainingstartReady(team) each wave
Why no --before flag Edges are stored on the dependent’s meta.json as after: string[]. Writing “B before A” from A’s side would be the same edge; one direction keeps the graph unambiguous and cycle checks simple. Name is required when using --after because deps are by name, not UUID.

03Wave scheduler — how the graph runs

The supervisor is a classic DAG dispatcher: poll disk, launch the ready set, wait, repeat until drained.

rescanFromDisk prefetchRemoteStatus startReady onWave wait loop until pending+running == 0 · or max-waves · or SIGINT · or budget breach STATE MACHINE (per teammate) PENDING RUNNING COMPLETED FAILED lib/teams/supervisor.ts · runSupervisor · default interval 8s
Continuous dispatch. Mid-flight teams add is picked up on the next rescan — the graph can grow while it runs (Factory planner pattern).
agents teams start pricing-page --watch
# --interval 8   seconds between waves (default)
# --max-waves 1000
# --json         one JSON object per wave

Wave N

  • Any teammate whose after[] are all terminal → launch
  • Independent ready nodes launch together
  • Distributed: one SSH prefetch per host, not per teammate

Drained ≠ all green

  • pending + running == 0 ends the loop
  • Check failed count — failures still drain
  • Optional live budget can stop the whole team

04Distributed teams — same graph, many machines

One orchestrator owns the DAG. Teammates can run on different fleet devices; placement is a separate axis from dependency.

orchestrator (teams start --watch) yosemite-s0 backend docs --device pin or pool pick yosemite-s1 frontend worktree on remote zion (laptop) qa --after … waits for deps fleet-wide
Two axes. --after is time/order. --device / --devices is where. The supervisor still sees one team graph.
Placement ruleBehavior
--device X on addPin — never second-guessed
Pool of oneWhole team on that device
Pool of many (unpinned)Best-viable: reachable, not overloaded, agent installed, under cap, least loaded
No pool / no pinLocal
No viable deviceFail loud — never silent fallback to local
agents teams create feat \
  --devices yosemite-s0,yosemite-s1 \
  --repo git@github.com:org/app.git \
  --enable-worktrees

agents teams add feat claude "API" --name backend  --device yosemite-s0 --worktree api
agents teams add feat claude "UI"  --name frontend --device yosemite-s1 --worktree ui
agents teams add feat claude "QA"  --name qa --after backend,frontend --worktree qa
agents teams start feat --watch

05Boundary contracts — the other half of the graph

Topology without ownership is a race. Parallel teammates need file boundaries; --after only orders time.

Rule from the agents-cli playbook If A must finish before B can start because they edit the same files, the split is wrong. Re-cut ownership so independent nodes truly are independent — then use --after only for real data dependencies (API ready → QA).
Anti-patternFix
Two edit-mode agents, shared checkout, no worktrees--enable-worktrees + unique --worktree names
Serializing independent work with --afterDrop the edge; run same wave
Cross-repo team with one --repoOne team per repo
Assuming shared memory between teammatesPass outcomes via PRs, files, or explicit messages (teams message)

Modes: plan (read-only) · edit · auto · skip. Pair plan-mode reviewers with edit-mode implementors on separate branches.

06Cookbook

# 1. Create + DAG + watch
agents teams create pricing -d "Ship /pricing end-to-end" --enable-worktrees
agents teams add pricing claude "Backend tiers API"     --name backend  --worktree backend
agents teams add pricing codex  "Frontend pricing page" --name frontend --worktree frontend
agents teams add pricing claude "E2E Playwright"        --name qa --after backend,frontend --worktree qa
agents teams start pricing --watch

# 2. Mid-flight graph growth (planner adds a node)
agents teams add pricing claude "Fix flake from QA log" --name bugfix --after qa --worktree bugfix
# supervisor rescans disk next wave and stages it

# 3. Steer / resume
agents teams message pricing qa "Skip visual snapshot for now"
agents teams resume  pricing backend "Review green — rebase-merge then release"

# 4. Observe
agents teams status pricing
agents sessions --teams          # teammate sessions tagged [team/…]
agents teams disband pricing

07Code map

FileRole
commands/teams.tsCLI: create / add / start / status / message / …
lib/teams/agents.tsTeammate process model · after[] · validateAddPreconditions · startReady
lib/teams/supervisor.tsrunSupervisor wave loop (shared with factory run)
lib/teams/scheduler.tsDevice placement cascade (pin / pool / least-loaded / fail-loud)
lib/teams/worktree.ts · remoteWorktree.tsIsolated branches for parallel edit
lib/teams/registry.tsTeam registry on disk
docs/teams.mdFull reference
One-liner for friends agents teams is graph engineering for coding agents: declare a DAG with named teammates and --after edges, isolate edit surfaces with worktrees, place nodes across devices with --device/--devices, and let start --watch drain ready waves until the graph is done. Not shared memory — explicit topology + disk state.
agents teams · graph engineering explainer · grounded in phnx-labs/agents-cli lib/teams/* · industry context 2026 (DAG-first orchestration, TrueFoundry graph engineering, LangGraph) · 2026-08-10 · sibling of agents-sessions-cross-device-index.html · ◐ theme