diff --git a/docs/n8n-agendamento-runbook.md b/docs/n8n-agendamento-runbook.md
index 5656edb..7060ad8 100644
--- a/docs/n8n-agendamento-runbook.md
+++ b/docs/n8n-agendamento-runbook.md
@@ -9,7 +9,12 @@
 > nativo do n8n). A seção 14 cobre os outros três providers — **Klingo**,
 > **SysLife** e **ClinicAll** — todos construídos com o mesmo padrão de
 > MCP Server nativo, mas ainda sem clínica real pra testar (ver cada
-> subseção pras specs/planos completos e pendências específicas).
+> subseção pras specs/planos completos e pendências específicas). As
+> seções 15-17 cobrem features transversais do Z-PRO (config de IA via
+> Google Docs, memória via Postgres, MCP de mensageria standalone). As
+> seções 18-20 cobrem a feature de **confirmação de agenda via
+> WhatsApp**, replicada nos três providers adicionais (Klingo,
+> ClinicAll, SysLife) — ver o resumo comparativo na seção 21.
 
 ## 1. Node MCP: qual usar e como instalar
 
@@ -880,3 +885,39 @@ preencher o `baseUrl` real (IP:9000) e provisionar banco Postgres +
 credencial pro cliente. Com isso, os 4 providers (Z-PRO em produção
 real, Klingo, ClinicAll, SysLife estruturalmente prontos) têm o mesmo
 padrão de confirmação de agenda implementado.
+
+## 21. Resumo — Confirmação de Agenda via WhatsApp nos 4 providers
+
+Visão consolidada das seções 18-20 (Z-PRO usa a mensageria própria da
+clínica exemplo, sem MCP de confirmação dedicado — a confirmação lá
+seria uma extensão futura do AI Agent já em produção, não construída
+nesta rodada).
+
+| | **Klingo** | **ClinicAll** | **SysLife** |
+| --- | --- | --- | --- |
+| API/recurso | Klingo Telefonia (separada da de agendamento) | `TCalendarController`/`TDomainController` (mesma do agendamento) | `AgendaWSApp` (mesma API do agendamento) |
+| Endpoint de confirmação | `POST /confirmar` | `POST /AgendamentoFlags` | `POST /AgendaWSApp` |
+| Valor de confirmação | `status`: `"C"`/`"S"`/`"N"` (3 estados) | `estadoAgenda`+`situacaoAgenda`: strings longas exatas (tabela de domínio) | `Resposta`: `"1"`/`"2"` (2 estados, mais simples) |
+| Busca de pendente | `GET /lista_ultimo_por_cpf` (CPF) | `GET /agendamentoSemPaciente` (CPF **+** data de nascimento) | `GET /AgendaWSApp` (telefone) |
+| Autenticação | `X-APP-TOKEN` por clínica (token real confirmado, sem clínica de teste) | Não documentada (`authentication: none`, mesma pendência do MVP de agendamento) | **Já resolvida** — Basic Auth fixo, credencial reaproveitada do MVP de agendamento |
+| Tools no MCP Server | 6 | 5 | 3 |
+| Workflow servidor | `tSw2LGlOYVg9antR` | `lHU5H0cZP4BJ6dWp` | `xq8CyqyewtENpIMW` |
+| Lembrete proativo (exemplo, inativo) | `IvLzmASwa9LGaMxf` | `liBLpRUmbcnWk05V` | `LpRRZxTsM0Vc9PsV` |
+| AI Agent de exemplo (inativo) | `F5jEliFFE3K9cW14` | `ylc3Jcz239ra6XZK` | `wBjXOZSEj5TopzfB` |
+
+**Padrão idêntico nos três**: `MCP Server Trigger` + N sub-workflows
+(`Execute Workflow Trigger` → `Config` → montagem de request → `HTTP
+Request` com `neverError`+`fullResponse` → `Classificar resultado`
+com taxonomia genérica por status HTTP); workflow proativo de lembrete
+via cron 8h chamando o MCP de Mensageria ZPRO (`enviar_texto`); workflow
+de exemplo de AI Agent reativo (webhook Z-PRO/GChat → `AI Agent` com
+`Postgres Chat Memory` → tools via `MCP Client Tool`) — os dois últimos
+sempre criados **inativos de propósito**, já que nenhum dos três tem
+clínica real disponível pra testar.
+
+**Pendência comum aos três**: nenhum foi testado com chamada HTTP real.
+Falta, por provider, quando houver clínica real: preencher `baseUrl`,
+resolver autenticação (só pendente no Klingo — sem clínica de teste — e
+no ClinicAll — sem mecanismo documentado; o SysLife já está resolvido),
+provisionar banco Postgres + credencial, e então ativar os workflows de
+lembrete e de AI Agent de exemplo.