Em maio e junho de 2026, três projetos open-source independentes — KanBots (maio/2026, MIT), agtx (junho/2026, MIT) e agent-kanban (março/2026, MIT) — chegaram ao mesmo desenho, sem combinar: um kanban board onde cada AI agent roda em sua própria git worktree, recebe tasks via Model Context Protocol (MCP), e o humano acompanha o que está acontecendo em vez de conversar com cada agent. A interface não é mais chat. É um board com cards, e os cards são os agentes. Por que três projetos convergiram no mesmo formato em quatro meses, e o que isso significa pra quem está montando operação com IA em 2026.
Resposta direta
O padrão "AI-agent-driven kanban via MCP" funciona assim: o board vira um MCP server que expõe tools (create_task, assign, claim, complete, comment). Cada agent conectado lê o board via MCP, pega os cards atribuídos a ele, executa em worktree isolada, atualiza o status, e sobe o resultado de volta. O humano abre o board e vê o que cada agent está fazendo, sem ficar em call síncrona. KanBots, agtx e agent-kanban implementam isso de formas diferentes (desktop local, TUI com tmux, e self-hosted com identidade criptográfica), mas a forma é a mesma: board + worktree + MCP + parallel dispatch.
O que é e por que importa agora
MCP virou o padrão de fato pra conectar AI agents a ferramentas externas em 2026 — segundo a página oficial do Model Context Protocol, o protocolo ganhou servers da Anthropic, OpenAI, Cloudflare, Microsoft Semantic Kernel e Azure OpenAI, e o AAIF realizou o MCP Dev Summit North America em abril de 2026 com 1.200 participantes. O que faltava era a peça de orquestração: como um humano coordena 5-10 agents rodando em paralelo sem virar refém do chat.
Antes, o workflow era sempre o mesmo: humano abre Cursor, conversa com Claude Code, espera 8 minutos, abre outra janela, conversa com Codex, espera mais, e assim por diante. O resultado: 3 agents em paralelo = 24 janelas abertas, contexto perdido, nenhum log auditável de quem fez o quê.
KanBots, agtx e agent-kanban atacam exatamente esse ponto. Cada um à sua moda:
-
KanBots (leodavinci1/kanbots no GitHub) é desktop local-first. Você dropa uma pasta, o board lê o repo, cada card vira um agent CLI rodando em worktree separado (
kanbots/issue-N). Suporta Claude Code, Codex, Gemini, Cursor, Copilot e mais — 11 CLIs em paralelo segundo o site oficial. Tem modo autopilot onde os próprios agents se dividem tasks. -
agtx (fynnfluegge/agtx) é TUI + tmux. Cada task recebe worktree + tmux window próprio, e o agent roda em qualquer uma das fases do lifecycle (research, planning, running, review). Você pode configurar agentes diferentes por fase — Gemini pra research, Claude pra implementação, Codex pra review — e o sistema troca automaticamente. MCP server oficial exposto pra que outros tools possam se conectar.
-
agent-kanban (saltbo/agent-kanban) é o mais ambicioso conceitualmente: cada agent tem identidade criptográfica, role, e skills carregáveis. Agents não só recebem tasks — eles criam tasks, atribuem colegas, e se auto-organizam em times. É "mission control for your AI workforce" nas palavras do autor.
Por que isso importa agora: até meados de 2025, o padrão era "humano conversa com um agent por vez". Em 2026, o padrão virou "humano observa um board de agents". A diferença prática é a mesma que existe entre gerenciar uma pessoa por Slack e gerenciar 5 pessoas por kanban — Slack escala pra 3, kanban escala pra 30.
Como funciona (sem jargão)
O fluxo concreto, em 4 passos, no caso do KanBots (a versão mais didática dos três):
- Você abre o KanBots, dropa a pasta do projeto. O board lê o repo, mostra as issues/PRs abertas como cards em colunas (Backlog, In Progress, Review, Done).
- Em cada card, você escolhe qual agent CLI vai rodar (Claude Code, Codex, Gemini, etc.) e clica em dispatch. O KanBots cria uma worktree
kanbots/issue-Ne dispara o agent nela. - O agent trabalha em background. Você vê progresso em tempo real no card (tokens consumidos, diff, comandos rodados, output parcial).
- Quando termina, o agent commita, abre PR, e move o card pra Done. Você revisa a PR direto do board.
O detalhe que muda tudo: o agent lê o board via MCP, não via API custom. Isso significa que qualquer agent MCP-aware (Claude Code, Codex com plugin, Cursor com MCP) pode se conectar ao mesmo board. O board não é dono do agent — o board é dono do fluxo.
O post do Kanban Zone de junho de 2026 coloca assim: "This is pull. This is WIP control. This is the entire logic of a Kanban system, applied to autonomous AI agent management. The board isn't showing you what AI did — it's showing you what AI is doing, and letting you pull the work when you're ready for it." É a lógica de lean manufacturing, só que aplicada a software escrito por agent.
Comparativo rápido: antes vs agora
| Cenário | Modelo 2024-2025 (chat síncrono) | Modelo 2026 (kanban + MCP + worktree) |
|---|---|---|
| 3 agents em paralelo | 3 abas de Cursor abertas, contexto manual | 1 board com 3 cards em "In Progress", cada um em worktree |
| Acompanhar progresso | Ficar olhando output de cada agent | Abrir o board, ver status + diff + custo por card |
| Trocar de agent no meio | Cancelar, copiar contexto, abrir outro CLI | Mover o card pra outra coluna, próximo dispatch pega |
| Auditar quem fez o quê | Print screen dos chats, montar doc | Log nativo do board: agent, task, commit, PR, custo |
| Escalar pra 10 agents | Caos, impossível | Board aceita mais cards, worktrees isolam, MCP padroniza |
| WIP limit | Você mesmo se policia | Coluna "In Progress" tem limite visual, igual Trello/Jira |
| Custo de tokens | Você só descobre no fim do mês | Cada card mostra tokens consumidos em tempo real |
A regra subjacente: quando o trabalho é assíncrono e paralelo por natureza, a ferramenta de coordenação também precisa ser assíncrona e paralela. Chat síncrono é a ferramenta errada pra 5+ workers.
O que isso muda para o seu negócio
Três consequências práticas, ordenadas do mais imediato pro mais estrutural:
1. Equipe de dev ganha 2-3x de throughput sem contratar. O gargalo de 2025 era o humano, não o agent. Você tinha agent bom, mas o humano era o coordenador: abria terminal, esperava output, copiava pro próximo agent. Em 2026, o board faz a coordenação, e o humano vira reviewer. Times de 2-3 devs usando KanBots ou agtx reportam no GitHub conseguir rodar 8-10 agents em paralelo sem perder controle. Isso muda a conta: R$ 8-12k/mês de Claude API rodando contra 1 dev sênior em vez de 3 juniores.
2. Operação contínua (SRE, customer ops, monitoramento) vira viável em PME. O mesmo desenho serve pra agentes de SRE, de atendimento, de BI. Você monta um board com agents que rodam 24/7, e o humano consome os resultados quando faz sentido. Não é o agent te notificando a cada commit — é o board com WIP limits te forçando a olhar quando importa. Pra varejo brasileiro com 1-2 pessoas de TI, isso é a diferença entre "temos monitoramento" e "temos 5 agents monitorando e a gente olha o board uma vez por dia".
3. A stack de IA em produção fica auditável. O board é o log. Quem fez o quê, em qual branch, com qual agent, com qual custo, em quanto tempo. Pra empresas que precisam de compliance (saúde, financeiro, jurídico), isso destrava o uso de agent em produção: você consegue provar que o agent X fez a task Y com output Z e custo W, e o humano revisou e aprovou antes do merge. Sem isso, agent em produção é insustentável juridicamente.
Referência natural Agendai
Na Agendai a gente aplica esse padrão em duas frentes: (1) o pipeline de produção de conteúdo do blog usa kanban interno onde 1 agent pesquisador dispara paralelo com 1 agent validador e 1 agent de SEO, todos em worktrees separados, com merge automático depois de aprovação; (2) em projetos de cliente, mapeamos primeiro onde a operação da empresa tem trabalho paralelo hoje (atendimento, follow-up de lead, conciliação, monitoramento de pedido) e propomos o board como primeira peça — antes de automatizar task por task. O pacote típico de 2 semanas começa com desenho do board (colunas, WIP limits, quais agents em qual fase), passa por setup do MCP server e dos agents, e termina com governança (logs, custo por card, política de escalação). Primeira semana é de graça, sem fidelidade. Mais em agendai.cc.
Perguntas frequentes
O que é o Model Context Protocol (MCP) e por que importa pra kanban de agents? MCP é o protocolo aberto criado pela Anthropic em 2024 e adotado em 2025 por OpenAI, Cloudflare e outros, que padroniza como AI agents se conectam a ferramentas externas (banco, API, planilha, IDE). Quando o kanban expõe um MCP server, qualquer agent MCP-aware consegue ler e mover cards sem código custom. É o que destravou os três projetos do post: sem MCP, cada board teria que integrar individualmente com cada CLI de agent.
KanBots, agtx e agent-kanban são concorrentes? Não diretamente. KanBots é desktop local-first pra times de dev; agtx é TUI com tmux pra quem vive no terminal; agent-kanban é plataforma self-hosted com identidade de agent e auto-organização. Os três implementam o mesmo padrão (board + MCP + worktree) pra públicos diferentes. Tem até interoperabilidade: como todos expõem MCP, dá pra usar agent-kanban como board de controle e KanBots como runner local, por exemplo.
Quanto custa rodar kanban de agents em produção? Software é free nos três casos (MIT). Custo é de API de LLM (Claude Sonnet 4 fica na faixa de R$ 25-40 por milhão de tokens, Codex similar). Um time de 3 devs rodando 8 agents paralelos consome na faixa de 50-150 milhões de tokens/mês em operação real — R$ 1.500-6.000/mês dependendo do mix de modelo. Setup inicial: 3-5 dias de um dev sênior pra colocar board + MCP + primeiro agent rodando.
Quais os riscos de usar kanban de agents em paralelo?
Três riscos reais: (1) race condition — dois agents editando o mesmo arquivo em worktrees diferentes; mitigado por branch por card (kanbots/issue-N), mas exige revisão antes de merge; (2) custo descontrolado — agent em loop infinito gasta tokens sem ninguém ver; mitigado por WIP limit na coluna "In Progress" e timeout por card; (3) output ruim passa despercebido — humano revisa menos porque "tem muito card"; mitigado por gate obrigatório de teste + review antes de mover pra Done.
Esse padrão substitui o dev sênior? Não. Substitui o dev sênior fazendo trabalho braçal (setup de ambiente, integração trivial, refactor mecânico). O que continua humano: decisões de arquitetura, validação de modelo de domínio, design de API, trade-off de stack, e revisão final do que o agent produz. O board mostra onde está o gargalo humano — geralmente, é a review. Aí você ataca o gargalo, não o agent.