A plataforma de agentes da DoorDash começa por identidade, custo e experiência

A DoorDash apresentou a evolução de sua plataforma GenAI, de uma interface comum para modelos até um Agent Gateway com autenticação, autorização por ferramenta, limites de uso e observabilidade.[11] No cenário relatado, a plataforma reúne mais de 50 servidores MCP e cerca de 300 mil chamadas de ferramentas por dia.[11] O interesse técnico está nos controles que acompanham a expansão, não na quantidade de conectores.

O que muda para quem desenvolve

A equipe tratou engenheiros de produto como clientes e adotou uma experiência centrada em APIs e SDKs, em vez de exigir conhecimento de infraestrutura de machine learning.[11] O relato também separa duas decisões de identidade: o servidor define quais ferramentas o usuário pode acessar, e o usuário escolhe quais agentes podem usar um subconjunto dessas permissões.[11]

Minha leitura é que uma plataforma de agentes precisa modelar delegação, não apenas autenticação. Saber quem iniciou uma tarefa não basta para determinar tudo que o agente pode executar. Uma automação de serviço deve ter um contrato de capacidades próprio, revisável e proporcional à função.

O gateway descrito é stateless; sessões e histórico continuam sob responsabilidade das equipes, e execução durável e retomada após falhas ainda estão em investigação.[11] Centralizar chamadas, portanto, não equivale a centralizar todo o ciclo de vida do trabalho.

Como aplicar

Escolha um fluxo completo de usuário antes de construir uma plataforma genérica. Defina a entrada, o resultado aceito, as ferramentas necessárias e quem responde pelo custo. Acrescente rastreamento que permita explicar uma chamada sem expor conteúdo sensível além do necessário.

Proponho testar o mesmo pedido com três identidades: pessoa, agente delegado por ela e agente de serviço. Use recursos sintéticos e uma ferramenta permitida apenas à pessoa. Verifique se a delegação limitada impede que os outros dois herdem esse acesso automaticamente.

Para avaliação, comece com poucas medidas: resultado correto, duração e custo atribuível. Registre também a intervenção humana exigida. Só depois acrescente interfaces e avaliadores mais sofisticados. O relato da DoorDash recomenda iniciar pelo tracing acessível e por duas ou três métricas relevantes de produto.[11]

Cuidados e limites

Em alguns casos próprios, a empresa relata redução de custo de aproximadamente 20 vezes ao adotar modelos de pesos abertos.[11] Isso não prova que hospedar modelos será mais barato para qualquer equipe.

Os guardrails apresentados são opt-in, e as equipes de produto permanecem responsáveis pelas políticas; A2A ainda estava em desenvolvimento.[11] Não transforme componentes descritos como incompletos ou opcionais em garantias universais.

Um gateway pode se tornar dependência central e exigir operação adicional. Para uma equipe pequena, a decisão sensata pode ser padronizar identidade e rastreamento num fluxo existente antes de criar outra camada. O objetivo é tornar a execução governável, não reproduzir a escala organizacional da DoorDash.

Fonte

[11] Fonte: InfoQ, apresentação de Swaroop Chitlur e Siddharth Kodwani