Concord
A planner splits a task into subgoals, workers run them from a shared blackboard, and a supervisor catches stalls, repeated work and off-task output, measured under injected faults.
- Client
- Own project · multi-agent infrastructure
- Role
- Design · build · evaluate
- Timeline
- 1 week
- Stack
- Claude · Python · Redis · OpenTelemetry
- Status
- Building
01 — The system
02 — Results
03 — The problem
When several agents split a task, things fail in ways a single agent never hits. A worker dies and the run hangs. Two subgoals ask for the same thing and the work is paid for twice. A specialist finishes with an answer about something else, and everything downstream builds on it. I wanted a runtime that notices these, and numbers that show when it does and when it doesn't.
04 — Decisions & tradeoffs
- All state lives in Redis. Every state change is an atomic Lua script that also appends to an event stream, so a new process can resume a run without redoing recorded work.
- The model proposes, the code decides. Plans and re-plans are checked for cycles, size and depth before they apply. The drift check asks a model five yes/no questions, and code turns the answers into a verdict.
- Bounded on purpose. An output is sent back at most once, re-plans are capped per run, and the supervisor halts a run that goes over its token budget.
- One run is one OpenTelemetry trace, so a lost attempt, the requeue and the retry all show up.
05 — What I measured, honestly
On 19 real research questions with Claude Sonnet 5.5, the team's answer was judged better 12 times to 6, at about 2.9× the token cost. That judge is a model, not a person. The supervisor did nothing on those healthy runs; its value shows under faults. Reworded duplicates are not caught yet (0/16), and how often the model reviewer is right is not measured yet.
06 — What's next
A real embedding model for paraphrased duplicates, measuring the drift reviewer against 100 labelled cases, and running the model re-planner against the real API.