AgendaGo: um SaaS de agendamentos com três agentes de IA em produção

O que é e em que estado está

O AgendaGo é um SaaS de agendamentos multinegócio: cada negócio configura sua agenda e seus clientes reservam. Está em produção em agendago.com.ar. Projetei e opero o sistema e, sobre ele, construí três agentes de IA com tool calling.

Este caso descreve a parte de engenharia de IA: como se limita o que um modelo pode fazer, como ele é avaliado e o que se mede em cada chamada.

O problema que resolve

Um negócio que vive de horários marcados tem tarefas que se repetem todos os dias. Cada agente do AgendaGo assume uma delas:

• Configurar o sistema: serviços, horários e regras. Quem faz isso é o assistente do painel, a pedido do dono.
• Atender e agendar por WhatsApp. Quem faz isso é o agente de WhatsApp, com o cliente final.
• Carregar o estoque a partir das notas fiscais e romaneios de fornecedores. Quem faz isso é a leitura com visão.

Arquitetura

O frontend é React com TypeScript, Vite, Tailwind e shadcn/ui. O backend vive no Supabase: PostgreSQL com RLS e Edge Functions. As integrações externas são a WhatsApp Cloud API e o MercadoPago.

A IA roda em Edge Functions e chama a OpenAI por HTTP direto, sem SDK, atrás de uma camada de abstração de provedor. A resposta viaja em streaming da Edge até o frontend, então o dono vê o texto enquanto ele é gerado.

Assistente do painel: propõe, e uma pessoa aprova

O assistente do painel tem 21 ferramentas: 11 de leitura, 2 de simulação ou explicação e 8 de proposta. As de proposta nunca escrevem. Elas criam uma proposta com o diff e sua consequência, que expira em 15 minutos, e um clique humano a aplica.

Aplicar a proposta não depende de o modelo se comportar bem: quem garante é o banco de dados. É uma função SECURITY DEFINER, só para o papel admin, com bloqueio de linha e uma etapa atômica que aplica e marca a proposta como aplicada.

• Três níveis de confirmação, derivados do risco de cada ação. As destrutivas exigem confirmação explícita e não podem ir em lote.
• Por turno: no máximo 4 rodadas de ferramentas do modelo e 700 tokens, mais um teto de gasto por turno.
• Um orçamento mensal por negócio, e as execuções podem ser canceladas.

Agente de WhatsApp: três barreiras antes de agendar

O agente de WhatsApp tem 9 ferramentas: disponibilidade, reserva, horários, endereço, serviços, cobertura, requisitos, nova pergunta e encaminhamento para uma pessoa.

Reservar tem três barreiras, e nenhuma depende do que o modelo diz:

• O horário precisa sair do motor de disponibilidade no mesmo turno.
• O cliente não pode já ter uma reserva naquele dia.
• Um trigger do banco bloqueia o overbooking como último fechamento.

Tudo o que sai para o cliente passa por uma única via de envio, que aplica a janela de 24 horas e os templates do WhatsApp. Um router determinístico responde cerca de 44% das mensagens sem chamar o modelo. O app passou pela revisão da Meta em 31 de agosto de 2026.

Visão: notas fiscais e romaneios de fornecedores

O modelo lê notas fiscais e romaneios de fornecedores para atualizar o estoque. Extrai fornecedor, número, data, total e itens, e o prompt manda usar null e nunca inventar um dado.

• Uma validação determinística limita itens e tamanhos e exige uma janela de datas.
• O cruzamento com o catálogo é feito por código determinístico, não pelo modelo.
• O que foi lido vai para uma área de preparação: o estoque só se move quando uma pessoa confirma.
• Um bloqueio por sha256 impede enviar o mesmo arquivo duas vezes. PDFs com camada de texto usam extração de texto em vez de visão.
• O texto dentro de um arquivo é tratado como dado, não como instrução: é a defesa contra prompt injection.

Avaliação e telemetria

Para o assistente do painel há um dataset de 100 frases com a ferramenta esperada para cada uma, além de checagens determinísticas no CI. Para o WhatsApp há um dataset de 52 cenários e 15 conversas, com categorias como saudação, preço, reserva, ambiguidade, adversarial e prompt injection. Cada cenário declara a rota esperada, os critérios e o comportamento que o agente deve evitar.

Os evals com modelo rodam contra o stack real, com um teto de gasto, e existe um script de juiz às cegas.

A tabela ai_usage_log guarda, por chamada: negócio, agente, usuário, modelo, versão do prompt, tokens de entrada, saída e cache, custo em dólares, latência, intenção, ferramentas usadas e resultado (ok, fallback, encaminhamento, erro, orçamento esgotado, guardrail ou modelo rejeitou). Não guarda texto de clientes. Se o insert falha, o turno é cortado; um teste exige que cada insert declare modelo e versão do prompt, e os prompts são versionados no repositório.

Confiabilidade e segurança

• Lista de ferramentas permitidas, filtrada por papel.
• O negócio vem do JWT, nunca do modelo. Os parâmetros proibidos (ids de negócio, tokens, flags de admin) são descartados.
• O texto de clientes e de arquivos é envolvido como dado.
• Um detector de entidades inventadas e a proveniência de cada afirmação.
• O texto de recusa é montado pelo código, não pelo modelo.
• Limite de taxa na borda e um único controle no banco para o orçamento mensal.
• RLS do Postgres habilitado em todo o esquema, e RPCs SECURITY DEFINER com search_path fixo.
• A suíte tem 522 arquivos de teste.

O que está em produção e o que não está

Tudo o que está descrito nesta página está em produção: os três agentes, os evals e a telemetria. O que continua em construção não é do AgendaGo: é o Nux, o assistente do Bonuxo, e a plataforma de agentes de IA para empresas, que está na fase 0, de arquitetura.