Delphi, KAI e ExeWatchMCP: e se o seu assistente de IA lesse os erros dos seus clientes e os corrigisse?

Segunda de manhã você abre o projeto no Delphi ou no C++Builder, escreve ao KAI uma linha sobre o erro que o cliente XYZ teve, e o KAI vai ler tudo sozinho. Eu conto como chegar lá com o ExeWatchMCP, e por que para quem programa no RAD Studio isso muda o jeito de trabalhar.

TL;DR: O ExeWatch tem um servidor MCP, o ExeWatchMCP. Você o registra no KAI, o assistente de IA do RAD Studio, e o KAI lê sozinho os erros e as lentidões que seus clientes têm em produção. Você abre o projeto Delphi ou C++Builder, diz “corrija o erro do cliente XYZ” e ele parte do que aconteceu de verdade: logo abaixo tem uma sessão real. Funciona também com Claude Code, Codex e os outros agentes MCP, no fim do artigo.

Aqui está a revolução

Um cliente avisa que viu um erro. Você escreve uma linha ao KAI, e o KAI faz o resto: lê a produção, acha o ponto no código, corrige, compila. Tudo dentro da IDE, no mesmo chat.

É uma sessão real num projeto meu em Delphi 13 (RecommenderPro, um servidor REST). Os screenshots estão em inglês porque o KAI e a minha sessão estão em inglês. Não dei cliente nem versão, só esta frase: “A client told me they saw an error in this app this afternoon. Check ExeWatch.”

O KAI chama exewatch_guide, exewatch_apps e exewatch_groups (a primeira chamada a groups dá erro e o KAI a refaz), e me diz que nas últimas 24 horas há dois problemas distintos: uma licença inválida, quatro vezes, e uma falha na importação de um CSV, uma vez. Diz também o que não sabe: “I haven’t read any code yet”, e que para entender qual dos dois é o do cliente precisaria da hora local do cliente. Não chuta.

Respondo: “OK, check it and fix it!”

O KAI lê os logs da falha, procura no projeto, abre RPServices.BulkU.pas e acha a causa: o separador esperado é o ponto e vírgula e o arquivo recebido estava separado por vírgulas, então o parser via uma coluna só e dizia “1 value per row”, uma mensagem que não ajuda ninguém. Ele troca a mensagem, que agora nomeia a linha e o separador exigido, e compila com a IDE.

Da frase “um cliente viu um erro” ao código alterado e compilado: um chat, dentro da IDE, sem que eu tenha copiado um stack trace para um prompt. No erro de licença o KAI não mexeu no código: o log indica um arquivo de licença inválido, ou seja, é um problema de arquivo e de configuração. Ele notou também que o ExeWatch não tem stack trace para esses dois erros, porque o projeto não está compilado com o map file detalhado: explico mais abaixo.

O código não é mais o centro

Até hoje o código era o centro e a produção, um lugar que você visitava. O cliente ligava, você abria o dashboard, copiava o stack, colava no prompt do agente. O agente conhecia o código-fonte e mais nada: achava três pontos suspeitos, escolhia um, e se estivesse errado o crash continuava e você tinha mais uma alteração para revisar.

Agora o centro é o que acontece em produção, e o código se adapta. O agente lê o erro, a versão, quantas vezes aconteceu, em quais clientes, depois de quais ações, e só então abre o arquivo. O fluxo é este: o código vai para produção, o ExeWatch coleta o que acontece, o agente lê isso enquanto altera o código, a alteração volta para produção e o ExeWatch mostra se o erro sumiu. Você não faz mais alterações no escuro. É um game changer.

O que você pode pedir

Você escreve os pedidos como diria a um colega, em português ou em inglês. Por exemplo:

Customer XYZ got an error yesterday evening on version 2.3.
Look it up in ExeWatch, find the spot in the code and fix it.

Check in ExeWatch where this program is slow
when opening the customer records screen, explain why and optimize it.

No primeiro caso o KAI procura o erro, lê o stack trace, chega à unit e à linha, olha os breadcrumbs para entender o que o usuário estava fazendo e propõe a correção no seu código. No segundo ele parte dos timings reais, não da ideia dele sobre onde pode estar o gargalo. Muitas vezes são dois lugares diferentes.

Por que no RAD Studio é outra coisa

Dar a um agente a visibilidade do que acontece em produção é um superpoder. O bug fixing fica muito mais rápido, porque o agente parte do erro de verdade e não precisa procurá-lo, e você reage ao que acontece nos clientes numa conversa, não num ticket.

O KAI está onde você está, dentro da IDE, com o projeto aberto. Com o ExeWatchMCP, no mesmo lugar onde escreve o código você também pergunta o que aconteceu nos clientes, sem navegador, sem copiar e colar, sem trocar de ferramenta. Delphi e C++Builder com o KAI e com a produção diante dos olhos trabalham melhor, e é isso que quero mostrar à comunidade Embarcadero.

O que é o ExeWatchMCP

É um pacote Python, o ExeWatchMCP no PyPI: pip install ExeWatchMCP e você tem o servidor (exewatch-mcp) mais a linha de comando exewatch. MCP é o protocolo com o qual um agente de IA descobre e executa ferramentas externas; falei dele em Não apenas MCP. Um agente de IA real, incorporado na sua aplicação Delphi. e em MCP Server para Delphi: Conecte Suas Aplicações à IA com DMVCFramework. As ferramentas que o seu agente passa a ter são estas:

Como conectar ao KAI

A chave de API você cria no ExeWatch e ela é somente leitura. No RAD Studio vá em Tools > Options > Kai > Chat > MCP Servers > Custom, adicione um servidor e preencha quatro campos: o nome (exewatch-mcp), o tipo (Local), o comando de inicialização (exewatch-mcp) e uma variável de ambiente EXEWATCH_API_KEY com a sua chave. A chave fica ali, não no prompt.

Se a IDE não encontrar exewatch-mcp no PATH, escreva o caminho completo do comando, ou use python -m exewatch_cli mcp.

Uma coisa para quem trabalha em Delphi: o stack trace só chega se você compilar o programa com o map file detalhado e os stack frames ativados. Se você já usa madExcept ou EurekaLog, pode passar ao ExeWatch o stack trace deles com uma pequena unit de ligação: expliquei em Integrating ExeWatch into Delphi Projects That Already Use madExcept (em inglês), e o mesmo esquema vale para o EurekaLog.

O que ele pode fazer e o que não pode

• Somente leitura. A chave é somente leitura: o agente não escreve nada no ExeWatch.
• Chave com escopo. Ao criar a chave você escolhe o que ela pode ler: uma única aplicação, um grupo de aplicações ou todas. Um consultor externo recebe uma chave para o único app em que trabalha e não vê os outros.
• Planos PRO e BUSINESS. As chaves de API estão disponíveis nos planos PRO e BUSINESS, tanto na cloud quanto on-premises. Se o ExeWatch pedir upgrade quando você cria a chave, o seu plano não as inclui.
• O texto que chega da produção não é seu. Mensagens e stack traces são escritos pelo software dos clientes, e em teoria por qualquer um que consiga fazê-lo falar. Por isso cada resposta traz "untrusted_content": true, e o agente a trata como dado a ler, nunca como instrução a executar.
• Janelas de tempo. Sem filtros, uma query cobre até 90 dias (24 horas se você não disser nada). Filtrando por texto, tag, versão ou sessão o máximo é 7 dias, e o mesmo vale para os timings.
• A versão é um texto exato. 2.3 não encontra 2.3.0.145. Se não achar nada, o agente refaz sem filtro e lê a versão nos resultados.
• O código quem revisa é você. Como manda a boa prática, o agente propõe a alteração no código e você faz o code review, como em qualquer outra alteração.

Funciona também com Claude Code, Codex e os outros

O ExeWatchMCP é um servidor MCP padrão, então não está preso ao KAI. Com o Claude Code:

claude mcp add exewatch --env EXEWATCH_API_KEY=<your key> -- exewatch-mcp

Com o Codex é igual, com codex mcp add, ou uma entrada [mcp_servers.exewatch] em ~/.codex/config.toml. Qualquer outro agente ou assistente que fale MCP se configura do mesmo jeito. Quem escolhe é você.

Neste artigo falei de Delphi e C++Builder porque foi ali que o ExeWatch nasceu e onde a integração com o KAI faz mais sentido. Os SDKs do ExeWatch cobrem também .NET, Python e JavaScript, e o servidor é o mesmo.

Quer ver ao vivo?

Eu mostro ao vivo na ITDevCon, Roma, 19 e 20 de novembro de 2026: o KAI aberto num projeto Delphi, um erro de verdade vindo do ExeWatch, e o agente resolvendo na sua frente. Depois falarei disso em alguns webinars e em outras conferências, entre elas a Ekon. As datas eu coloco aqui conforme for confirmando.

Para entender o que o ExeWatch coleta hoje, leia ExeWatch 1.35: Nested Timing Traces para Delphi e .NET e ExeWatch: Proactive Software Monitoring from Passive Security to Observability (em inglês). O resto está em exewatch.com.

Perguntas frequentes

O que é o ExeWatchMCP? É o servidor MCP do ExeWatch. Permite que um agente de coding leia erros, stack traces, breadcrumbs, versões e timings das aplicações monitoradas, enquanto trabalha no seu código.

Com quais agentes funciona? Com o KAI, o assistente de IA do RAD Studio para Delphi e C++Builder, e com qualquer outro ambiente que suporte o Model Context Protocol, como Claude Code e Codex.

Como instalo? pip install ExeWatchMCP (Python 3.9 ou superior), depois você registra o exewatch-mcp no seu agente com a chave de API no ambiente.

O agente pode alterar os dados no ExeWatch? Não. A chave é somente leitura.

Preciso de um plano pago? Sim. As chaves de API estão disponíveis nos planos PRO e BUSINESS, cloud e on-premises.

Posso dar acesso a um consultor em um único app? Sim. A chave pode ser limitada a uma aplicação, a um grupo de aplicações ou a todas.

Funciona só com Delphi e KAI? Não, mas este artigo parte daí. O ExeWatch tem SDKs para Delphi, C++Builder, .NET, Python e JavaScript, e o servidor MCP é o mesmo para todos.

Onde vejo isso em ação? Na ITDevCon, em Roma, nos dias 19 e 20 de novembro de 2026.