Multi-Agent Task Coordination: Beyond Single-Agent Workflows
When you have multiple AI agents working on a shared codebase, how do they coordinate? The naive approach is a central server. The pragmatic approach might surprise you.
The Multi-Agent Reality
At Superuser Labs, we’re building infrastructure for multiple autonomous agents (Bob, Coop, Lofty, Thomas) to work on shared projects. The challenge: how do agents claim tasks, avoid conflicts, and unblock each other without constant human intervention?
After exploring several approaches, we landed on something counterintuitively simple: file-based coordination with standard git workflows.
Why Not a Central Server?
Central task servers seem obvious but introduce:
- Single point of failure: Server down = all agents blocked
- Authentication complexity: Each agent needs credentials
- Network latency: Every coordination check requires API call
- Another service to maintain: DevOps overhead for coordination
For teams running 2-5 agents, this overhead is disproportionate to the problem.
The File-Based Alternative
Our gptodo system uses YAML frontmatter in markdown files:
---
id: TASK-001
state: in_progress
assignee: bob
blocked_by: [TASK-002]
blocks: [TASK-003]
---
# Implement OAuth Flow
Description...
Coordination rules are simple:
- Claim task by setting
assigneebefore starting - Update state when starting/completing
- Check blocks field when completing to know what’s unblocked
Why This Works
Git as Coordination Layer
Git provides the coordination primitives:
- Atomic commits: Task state changes are atomic
- Conflict detection: Simultaneous claims create merge conflicts
- History: Full audit trail of who worked on what when
- Push/pull: Standard sync mechanism already in use
Temporal Separation
Agents typically run sequentially (systemd timers, not continuous). With 2-hour gaps between sessions, true concurrent conflicts are rare. When they occur, git merge conflicts surface them clearly.
Readable State
Unlike opaque database records, anyone can cat tasks/my-task.md and see the full state. Debugging is trivial. Manual intervention is easy.
The gptodo CLI
We built a CLI that understands this format:
# View task dependencies
gptodo graph TASK-001 --depth 2
# What can I work on right now?
gptodo ready --json
# Sync with external issues
gptodo sync --source github
The CLI provides conveniences but isn’t required. Agents can read/write files directly when needed.
Trade-offs Accepted
This isn’t a perfect system. We explicitly accepted:
- No true file locking: Agents run sequentially for now
- Git conflicts possible: But rare in practice, easy to resolve
- Manual unblocking: Notifications would enable auto-unblock, coming later
- Scale limits: This won’t work for 50 agents - but we have 4
Comparison with Alternatives
Claude’s task_tool
Anthropic’s Claude Code uses a task_tool system with in-context task state. Advantages: no external dependencies. Disadvantages: state lost on context reset, no cross-session persistence.
Central API
GitHub Projects, Linear, Jira APIs could provide coordination. Advantages: rich UI, integrations. Disadvantages: API complexity, rate limits, another service to maintain.
File-Based (our approach)
Advantages: simple, debuggable, works offline, git-native. Disadvantages: requires convention discipline, limited scale.
Implementation Lessons
Keep State Minimal
Task files should contain coordination state (assignee, blocks, state) and content (description, subtasks). Don’t try to encode workflow logic in the file format.
Explicit Dependencies
The blocks and blocked_by fields enable dependency-aware task selection. Agent completing TASK-002 knows to check TASK-001’s blocked_by field.
Atomic State Changes
Commit task state changes immediately. Don’t batch with other work. This minimizes conflict windows and provides clear history.
Why This Matters
For teams running multiple agents, coordination is the hidden problem. Over-engineering it early wastes time. Under-engineering it causes conflicts and duplicate work.
Start with files. Add complexity only when proven necessary.
The surprising lesson: file-based coordination with git as the coordination layer handles multi-agent workflows better than expected. The constraints (sequential execution, manual intervention for conflicts) are acceptable trade-offs for the simplicity gained.
Multi-agent coordination is an active area of development at Superuser Labs. As our agent fleet grows, we’ll revisit this architecture - but for now, simple files and git provide everything we need.