Sobre o cold start está dentro do esperado pra uma aplicação dessas. Uso AOT. E o evo uso somente pra receber e entregar informação. Toda a camada do agente está em outros locais da aplicação. A construção dos agentes toda via código, sem usar frameworks. Como não sou programador algumas nomenclaturas não domino. Não sei se ficou claro. Ah, e uso BAML para ter entradas estruturadas depois do evo.
AOT resolve bem esse problema. Interessante separar a camada de agente do serviço de entrega, faz sentido em termos de manutenção. Você disse que constrói os agentes via código sem framework, usa qual linguagem nessa camada?
Uso Typescript e toda a camada de tecnologia da CLoudflare pra isso. Aqui um artigo deles pra entender o caminho: https://blog.cloudflare.com/project-think/
Cloudflare Workers é uma aposta diferente: em vez de otimizar linguagem, você otimiza na layer de infraestrutura. TypeScript em V8 isolates na edge tem benchmarks impressionantes. O ponto que me preocuparia é lock-in no ecossistema deles e as limitações de tempo de CPU por request. Para quem já está no mundo Cloudflare faz sentido, mas como opção principal de backend ainda não vi muito uso fora de casos de edge logic específica. Você usa Workers para toda a lógica de negócio ou só para o que precisa estar na edge?
Abordagem muito boa essa de fugir de frameworks pesados tipo LangChain ou CrewAI. Quando a regra de negócio aperta em produção, loops abertos controlados pelo LLM começam a alucinar transição de estado e tool-calling.
Uma alternativa sólida para manter isso previsível é amarrar a orquestração do agente em uma FSM (Máquina de Estados Finitos) determinística: quem decide o próximo estado da aplicação é código estrito, e cada estado só expõe ao modelo as ferramentas estritamente permitidas naquele momento (Capability Gates).
Isso elimina alucinação de chamada de ferramenta fora de hora e garante que a esteira continue determinística, mesmo usando LLM para o processamento intermediário.