Datadog defende serverless como primeira opção de execução para agentes de IA

O argumento da Datadog parte de um dado de uso: em mais de 35.000 sessões de coding agents em produção, a sessão mediana passou só 20% do tempo executando chamadas a LLM ou a ferramentas. No resto, o agente ficou parado entre etapas, com o sandbox ainda alocado. Em computação sempre ligada, esse tempo ocioso é cobrado do mesmo jeito.

A proposta é montar um perfil de execução antes de decidir onde rodar. Ele registra padrão de chegada, taxa de pico, duração de rajada, tempo ativo de computação por execução, tempo total decorrido, memória, CPU e requisitos como acelerador ou conexão persistente. A razão entre tempo ativo e tempo total é o primeiro sinal: razão baixa favorece execução sob demanda, razão alta com chegadas constantes pode tornar workers dedicados mais baratos. Para execuções longas, a empresa sugere workflows serverless duráveis (AWS Step Functions, Google Cloud Workflows, Azure Durable Functions, AWS Lambda durable functions), com o orquestrador guardando o estado e o framework de agente (LangChain, Vercel AI SDK) cuidando só das chamadas de modelo e ferramenta em cada etapa. Cada etapa deve ser idempotente, para que um retry não envie e-mail duplicado nem cobre duas vezes.

Para quem opera plataforma, a leitura é que o custo de agentes deve ser medido por custo por execução bem-sucedida, não por preço de invocação. No exemplo da Datadog, US$ 12 em 100 execuções, com 80 concluídas, dá US$ 0,15 por execução útil, e não US$ 0,12. Também vale ver o texto como posição de um fornecedor de observabilidade: ele recomenda medir com APM, Agent Observability e Serverless Monitoring, e mover para capacidade quente só as etapas em que a latência de partida pesa de fato.