Software de gestão para agentes de IA: como saber se ele aguenta
CRM com IA costumava significar um CRM com IA embutida. Com agentes como Claude Code, Codex e Cursor, significa cada vez mais um software de gestão que o seu próprio agente consegue operar: clientes, pedidos, faturas e pagamentos. Isso levanta uma pergunta antes de qualquer outra: ele consegue fazer isso com segurança? Em julho de 2025, o agente de IA do serviço de desenvolvimento Replit apagou o banco de dados de produção de um usuário durante um code freeze explícito. Depois afirmou que a restauração era impossível, embora existisse um backup. A Replit reagiu separando automaticamente os bancos de desenvolvimento e de produção (heise online, 25 de jul. de 2025). A lição: uma instrução no prompt não é uma trava. Se um agente pode causar estrago depende do software que ele opera. Em software de gestão, um erro não fica no código, ele chega ao seu cliente. Os oito critérios abaixo valem para qualquer software que você entrega a um agente. No fim, você vê como o Time Momentum trata cada um.
1. Uma interface que o agente consegue ler
Um agente que clica por telas ou raspa HTML está adivinhando. Verifique se há uma linha de comando ou API que retorna JSON e expõe o próprio schema: quais comandos existem, quais campos são obrigatórios, quais valores são permitidos. Os erros também devem ser legíveis por máquina, com um código que diga ao agente se ele deve corrigir a chamada, esperar ou perguntar a você.
Verifique também a cobertura. O que só funciona na interface gráfica, o agente faz por desvio ou não faz.
2. Permissões separadas
O agente precisa de uma chave própria que você pode revogar a qualquer momento, não da sua senha. Melhor ainda se a chave for trocada por um token de curta duração em vez de viajar em cada requisição.
Algumas ações não pertencem às mãos de um agente: criar novas chaves, excluir a conta, trocar a senha. O software deve bloqueá-las no servidor para o acesso de agentes, não apenas desaconselhá-las na documentação.
3. Confirmação para tudo o que é irreversível
Uma fatura emitida não pode ser desfeita, só cancelada. O software deve marcar esses passos como destrutivos e executá-los apenas com confirmação explícita. Essa confirmação precisa estar na própria ferramenta; uma frase no prompt não protegeu o banco de dados na Replit.
4. Simulação (dry run)
Antes de o agente alterar algo importante, ele deve conseguir mostrar exatamente o que enviaria: método, endereço, corpo. Você então aprova o que viu, e não uma intenção descrita em palavras.
5. Idempotência
Agentes tentam de novo. Se a conexão cai, o agente repete, e sem proteção o lançamento de horas ou o pagamento vai parar duas vezes no sistema. Verifique se a criação de um registro aceita um ID próprio que permita ao servidor reconhecer uma repetição e se operações em lote dão certo por completo ou não acontecem. Onde um passo não pode ser repetido, o erro deve dizer isso.
6. Logs rastreáveis
Depois, você quer saber o que aconteceu. Isso significa: cada ação é um comando legível que você mesmo pode executar, as requisições podem ser registradas sob demanda sem expor a chave, e você vê qual chave estava ativa e quando. Uma chave por agente deixa isso inequívoco.
7. Desfazer
Erros acontecem. O que importa é como são corrigidos: editar ou excluir rascunhos, corrigir lançamentos, cancelar o que foi emitido, com registro em vez de uma sobrescrita silenciosa. O que já foi faturado deve ficar travado, para que uma correção em um lugar não altere uma fatura concluída.
8. Limites do plano
Quando o agente esbarra em um limite, como um recurso fora do seu plano ou requisições demais, o software deve dizer isso com clareza: com o motivo e se esperar resolve ou se você precisa decidir. Um agente que confunde um limite com um erro continua tentando ou procura um atalho.
Os oito critérios no Time Momentum
Seu agente opera o Time Momentum pela linha de comando tm.
- Quais comandos existem, quais são destrutivos?
tm --json - Quais campos uma fatura aceita?
tm schema invoices --json - Mostre a requisição antes de emitir
tm invoices finalize <invoice-id> --dry-run - Está certo, pode emitir
tm invoices finalize <invoice-id> --yes - Lance os 90 minutos de hoje de manhã
tm timers add --project-id <project-id> --started-at "today 09:00" --duration 1:30 --client-id <uuid> - Cancele a fatura
tm invoices cancel <invoice-id> --reason "Período de serviço errado" --yes - Qual chave foi usada por último?
tm api-keys list
O acesso de agentes faz parte do Pro.
| Critério | No Time Momentum |
|---|---|
| 1. Interface | Cada operação da API tem exatamente um comando tm, e um teste confere isso a cada alteração. Saída e erros em JSON, tm schema lista comandos e campos, e o código de saída diz ao agente se deve corrigir a chamada, perguntar a você, esperar ou tentar de novo. |
| 2. Permissões separadas | Uma chave de API por agente, criada no app web e revogável a qualquer momento. O tm a troca por um token válido por uma hora; revogar a chave encerra a sessão na hora. Criar chaves e excluir a conta são bloqueados no servidor para esse acesso. Uma chave de leitura alcança apenas rotas de leitura selecionadas e os timers. |
| 3. Confirmação | Emitir, cancelar, excluir e revogar são marcados como destrutivos. No terminal, o tm pergunta; um agente precisa de um --yes explícito, senão o tm para sem enviar nada. O servidor recusa uma fatura eletrônica com dados obrigatórios faltando, e ela continua como rascunho. |
| 4. Simulação | --dry-run mostra método, endereço e corpo da requisição sem enviá-la e sem a chave. |
| 5. Idempotência | Lançamentos de horas aceitam um ID próprio (--client-id), então repetições não criam duplicatas. Um pagamento conjunto de várias faturas dá certo por completo ou não acontece. Se a montagem de uma fatura falha depois que o rascunho já existe, o erro indica o rascunho com que continuar. |
| 6. Logs | Cada ação é um comando legível que você mesmo pode executar. --verbose registra cada requisição, nunca a chave ou o token. A lista de chaves mostra quando cada chave foi usada pela última vez. Não há um log de atividades separado por agente. |
| 7. Desfazer | Rascunhos podem ser editados e excluídos, pagamentos corrigidos ou removidos. Por padrão, uma fatura emitida só pode ser cancelada, com um documento de cancelamento próprio. O tempo em faturas emitidas e em relatórios de horas finalizados fica travado. |
| 8. Limites do plano | Um recurso Pro sem Pro retorna upgrade_required com o nome do recurso; requisições demais retornam rate_limited com um tempo de espera. O código de saída diz ao agente se deve perguntar a você ou esperar. |
O que nenhum software faz por você
Dê a cada agente uma chave própria com o mínimo de permissões necessário, uma chave de leitura onde ler basta. Permita o irreversível só quando você pedir e olhe a simulação antes de aprovar. O acesso de agentes ao Time Momentum faz parte do Pro.
Perguntas frequentes
O que é um CRM com IA?
Ou um CRM com recursos de IA embutidos, como rascunhos de e-mail ou lead scoring, ou um CRM que o seu próprio agente de IA consegue operar por uma API, um servidor MCP ou uma linha de comando. Este guia trata do segundo tipo.
Por que o agente da Replit apagou o banco de dados?
Segundo as reportagens, ele executou o comando de banco de dados npm run db:push durante um code freeze, sem permissão. Na época, preview, testes e produção compartilhavam o mesmo banco (heise online). A instrução de não alterar nada existia só na conversa, não no software.
Basta dizer ao agente para não apagar nada?
Não. Um prompt é um pedido, não uma trava. Só os limites que o servidor impõe protegem você: permissões ausentes, confirmação obrigatória, dados faturados travados.
E se meu agente errar algo no Time Momentum?
Você edita ou exclui rascunhos, corrige pagamentos e cancela uma fatura emitida com um documento de cancelamento próprio. O tempo faturado continua travado o tempo todo.
Deixe seu agente faturar com segurança
- 30 dias de Pro
- Sem cartão de crédito
- Depois, continue no Free