Sandcastle, Flue e agentes aplicados
Dia de comparar ferramentas de agentes, testar ideias de orquestração no iTOP e transformar isso em conteúdo e produto.
O dia girou em torno de uma pergunta prática: onde ferramentas como Sandcastle e Flue ajudam de verdade em projetos reais? Comparei os dois com foco menos em hype e mais em função. Sandcastle apareceu como uma forma de criar ambientes e loops de desenvolvimento mais isolados. Flue apareceu como uma forma de desenhar fluxos de agentes com etapas explícitas.
No iTOP, isso virou experimentação aplicada. Desenhei um fluxo para criação de eventos a partir de texto livre, com saída estruturada em JSON, perguntas para campos faltantes e uma regra importante: o agente não deve inventar data, horário ou local. Também apareceu um loop de desenvolvimento com etapas de análise, implementação, revisão, testes e QA.
Conteúdo para o site
No site, esse estudo virou o post comparando Sandcastle e Flue. A conclusão ficou simples: são ferramentas com propósitos diferentes. Uma conversa sobre sandbox, outra sobre fluxo. Esse tipo de diferença importa porque evita usar uma ferramenta nova como resposta genérica para qualquer problema.
Também surgiu uma ideia para um agente público do próprio site: uma interface de perguntas sobre o corpus público, usando posts, diários já sanitizados e llms-full.txt, sem tocar memórias privadas nem sessões locais. A linha de produto ficou clara: se o site fala sobre trabalho com IA, ele pode também expor uma forma limitada e segura de consultar esse material.
Produto e performance
No iTOP, a pauta continuou com performance mobile, peso de assets e pequenos pontos de confiança visual, como favicon. Em paralelo, o projeto de controladoria ganhou uma discussão mais concreta sobre OCR assíncrono: upload, extração, validação por agente, persistência em banco e atualização do frontend quando o job termina.
Foi um dia de separar ferramenta de aplicação. A ferramenta nova só ficou interessante quando encontrou um fluxo concreto para melhorar.