Kanban for AI Agents: Multi-Agent Workflows That Actually Ship Code

One AI agent can do a lot. But when you need three things done in parallel — research, coding, testing — a single agent becomes a bottleneck. The solution: a kanban board where the orchestrator agent decomposes work into tasks, and specialist agents pick them up and execute.

The Architecture

The system has two roles:

• Orchestrator: Decomposes the goal into tasks, manages the kanban board, reviews completed work
• Workers: Execute individual tasks with isolated contexts and toolsets

Communication happens through delegate_task — the orchestrator spawns subagents, each with its own conversation, terminal session, and toolset. The subagent works independently and returns a summary. The orchestrator never sees intermediate tool outputs — only the final result.

Profile Isolation

This is critical and easy to get wrong. Each worker runs with its own agent profile, which means its own configuration, model selection, and tool access. Without isolation, workers can interfere with each other — one worker's terminal session might conflict with another's, or they might write to the same files simultaneously.

Profile isolation gives each worker:

• A separate terminal session (separate working directory and state)
• A restricted toolset (only the tools it needs)
• Its own conversation context (no contamination between workers)

The Fallback Chain Problem

When you're running multiple agents in parallel, provider reliability matters. If all your workers use the same LLM provider and it goes down, everything stops. I use a fallback chain: primary provider, then backup, then backup to the backup.

The chain looks like:

fallback_chain:
  - openrouter/glm-5.1      # primary
  - anthropic/claude-sonnet   # backup
  - openai/gpt-4o            # backup^2

Each worker can independently fall through the chain. This means even if one provider is having issues, the overall workflow continues.

delegate_task vs. Spawning

There are two ways to create subagents:

• delegate_task: Managed subagents with automatic summarization. Good for parallel execution of defined tasks.
• Spawning a full process: An entirely separate agent process with its own gateway connection. Used for long-running autonomous agents.

For kanban workflows, delegate_task is almost always the right choice. It's synchronous (the orchestrator waits for results), scoped (limited tool access), and clean (only the summary returns). Spawning is for agents that need to run independently for hours or days.

The Two-Stage Review

Workers return summaries, not verified facts. A subagent that claims "file uploaded successfully" might be wrong. For operations with side effects (HTTP POST, file writes, deployments), I use a two-stage review:

1. Worker executes the task and returns a summary with verifiable handles (URLs, file paths, HTTP status codes)
2. Orchestrator verifies by fetching the URL, stating the file, or reading back the content

This catches the "I did it" vs "I actually did it" gap that AI agents are prone to.

Practical Example

Here's a real workflow — deploying a blog with parallel content creation:

1. Orchestrator: "Create 8 blog posts and an index page"
2. Worker A: Writes posts 1-4 (parallel)
3. Worker B: Writes posts 5-8 (parallel)
4. Orchestrator: Reviews all 8 posts, creates index page
5. Orchestrator: Deploys to S3 + invalidates CloudFront cache

Total time: ~60% of what a single agent would take, because the content creation is parallelized.

Lessons

• Profile isolation is not optional. Without it, parallel workers will conflict on shared resources.
• Diversity your providers. A fallback chain with provider diversity means one outage doesn't kill your workflow.
• Trust but verify. Subagent summaries are self-reports. For anything that matters, verify the result yourself.
• delegate_task for scoped work, spawning for autonomous work. Different tools for different problems.