Neon + Cloud Run faz sentido para esse perfil: sem infra pra gerenciar, custo controlável, escala com o uso. O ponto que vale monitorar conforme cresce é a latência de cold start quando o tráfego fica muito espaçado, o Neon pode demorar pra acordar depois de inatividade longa.
Sobre Go com agentes: faz sentido. O ecossistema mais enxuto diminui a ambiguidade, o agente tem menos caminhos conflitantes. Você usa mais pra boilerplate ou pra lógica de negócio também?
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?