Spotify Ads: a fronteira de um agente também precisa de um responsável

Em apresentação publicada pela InfoQ, Pratik Rasam descreve a arquitetura do Ads AI do Spotify, que transforma instruções de anunciantes em conteúdo e recomendações de campanha.[12] O relato envolve produção, mas o agente específico de recomendação de audiência ainda está em piloto.[12] Essa distinção importa antes de tratar tudo o que aparece no desenho como funcionalidade plenamente implantada.

O que muda para quem desenvolve

A base usa Google ADK Java, Vertex AI e serviços gRPC, com a regra de um agente, um pacote e um responsável.[12] Os pacotes incluem configuração de monitoramento e alertas; a visibilidade no Bazel impede dependências não autorizadas entre agentes em tempo de compilação.[12]

Minha análise é que a decomposição só tem valor quando cria fronteiras verificáveis. Distribuir um prompt grande por vários arquivos não resolve quem mantém a capacidade, quais dados ela pode ler e qual erro deve acionar uma equipe. A fronteira organizacional precisa aparecer no código e na operação.

O Spotify separa interpretação de intenção, consulta a dados oficiais e aplicação de regras determinísticas.[12] Um exemplo relatado mostra um pedido para mulheres de 21 anos ou mais convertido numa faixa de 21 a 99, incompatível com os intervalos aceitos pela plataforma.[12] Outro confundiu pais de adolescentes com os próprios adolescentes.[12] São problemas de contrato e significado, não apenas de formatação.

Como aplicar

Para uma automação de campanhas, mantenha catálogos e faixas permitidas em ferramentas ou código. Proponho que o agente selecione identificadores existentes e declare ambiguidades, em vez de inventar valores operacionais. Valide os identificadores novamente antes de qualquer ação.

Monte testes para pedidos parecidos, mas semanticamente diferentes. Inclua adultos responsáveis por adolescentes, adolescentes como público e termos geográficos ambíguos. Compare a trajetória de ferramentas e a decisão final, não somente se a resposta parece bem escrita.

Defina um responsável por cada capacidade e um contrato de erro estruturado. Um retorno deve indicar dado ausente, escolha ambígua ou indisponibilidade, com um caminho de recuperação limitado. A etapa seguinte não deveria precisar adivinhar o significado de uma falha genérica.

Instrumente duração, ferramentas, validações e moderação. O Spotify usa rastros padronizados e combina verificação da trajetória, regras determinísticas e avaliação limitada de tom e coerência.[12] Minha recomendação é transformar falhas recorrentes em testes baratos sempre que o critério puder ser expresso em código.

Cuidados e limites

Execução paralela reduz espera para tarefas independentes, mas aumenta consumo e exige cuidado com o estado compartilhado, conforme a apresentação.[12] Não paralelize uma etapa que depende do resultado ainda não produzido por outra.

A equipe optou por avaliações sob demanda e noturnas, sem chamadas de LLM em todo merge como bloqueio de CI.[12] Isso é uma decisão de custo daquele contexto, não dispensa universal de critérios de liberação. O ponto aproveitável é exigir evidência da trajetória e regras claras. Mais agentes não substituem domínio, responsabilidade ou teste de uma decisão que pode sair errada em JSON perfeitamente válido.

Fonte

[12] Fonte: InfoQ, apresentação de Pratik Rasam