Há 3 semanas, no primeiro Show GN, compartilhei que estava criando um firewall de 5 camadas; desde então, fiz uma correção no design + trouxe o que realmente coloquei em produção. Acabou passando batido com 1 ponto/1 comentário, mas houve progresso, então estou postando de novo.
▶ Correção de 5-tier → 4-tier (PUSH / QUEUE / SILENT / AUTO)
A camada "Call" foi removida e ficou em espera. Decidi isso com base nos dados durante o PoC.
▶ Loop do agente completo de ponta a ponta
Chega um e-mail pedindo reunião → classificação por tier → o Klorn verifica conflito na agenda → rascunho da resposta + evento de calendário → fica aguardando em PendingAction → usuário aprova com 1 clique → dispara. Todas as ações são assinadas com hash do payload antes do disparo, e sem correspondência de ActionReceipt a execução é impossível.
▶ A parte que mais demorou: teste de invariantes (menos de 100 linhas de código)
Um teste que quebra a build se uma ação como send_email for executada sem aprovação do usuário. Se alguém remover a checagem de aprovação → teste falha → build falha → deploy falha. Contornar isso simplesmente deixa de ser uma opção. É por isso que "o agente não envia por conta própria" deixa de ser frase de marketing e vira fato.
▶ Também corrigi um bug real de produção
A OpenRouter descontinuou o SKU de modelo :free, então todos os ciclos autônomos morriam com "404 No endpoints found". O failover antigo só tratava 402 / 403 / 429. Não cobria "modelo desapareceu". Coloquei uma cadeia de fallback multi-modelo, então mesmo que um SKU upstream morra, o agente não morre.
▶ Medindo retenção Day 14+7
Ativar 5 pessoas do ICP é o critério para passar no PoC. Feedback sincero, mesmo que em uma linha, é muito bem-vindo.
▶ Vídeo de 60 segundos: https://klorn.ai
▶ Código: https://github.com/k08200/klorn
Beta grátis + PRO aplicado automaticamente. Muito obrigado a quem deixou opinião no primeiro post.
3 comentários
Uma pergunta — para quem opera agent / SaaS, qual foi o failure mode que vocês viram com mais frequência quando o agent agiu sem a intenção do usuário?
Na minha experiência operando, por ordem de frequência:
:freemorre e o ciclo para sem nem fallbackQueria saber quais padrões vocês têm visto.
O caso 2 acontecia com frequência, e quando eu usava fallback como alternativa, o caso 1 passava a acontecer dependendo do prompt, e aí isso levava ao caso 3 kkk
Claro que isso não aconteceria se eu sempre usasse um modelo avançado, mas para um serviço voltado ao cliente, modelos no nível do Sonnet ou acima acabam sendo um peso no custo mesmo..
kkk, eu me identifico muito com essa sequência. Eu também me ferrei mais por causa do #2 e, quando derrubo para o free, já passei exatamente pelo mesmo de o prompt não encaixar e acabar dando #1.
Então, em algum momento eu desisti de confiar no modelo e, em vez disso, independentemente de o modelo ser barato ou caro, ou até ser descontinuado, bloqueei a possibilidade de ele decidir enviar e-mail, apagar coisa ou repassar para fora. Isso sempre sai só com aprovação humana. O que roda automático são apenas coisas reversíveis, como classificação, marcar como lido ou briefing.
Depois de configurar assim, mesmo se o modelo der drift, o pior cenário vira "uma sugestão estranha que eu vou ver e recusar", e não "uma resposta que já foi enviada". O #1 não se espalha até o #3.
No #2, eu pego esse 404 do SKU free checando o catálogo todo dia e desvio com uma cadeia de fallback, mas deixei fixo em um flash pago só o classificador. Usar tudo no nível do Sonnet também pesa para atendimento ao cliente para mim... então gasto só na classificação, deixo a geração de sugestões no free e faço o gate de aprovação absorver o risco.
No fim, acho que o ponto-chave foi não colocar custo e segurança no mesmo eixo. O modelo pode até ser barato, mas o gate não pode.