Um relato em primeira pessoa publicado no blog da Databricks descreve a substituição de parte de uma fila interna de revisão de segurança por um sistema multiagente construído inteiramente na própria plataforma da empresa, argumentando que a automação anterior "simplesmente havia atingido seus limites" e ainda consumia tempo de revisores especialistas em casos previsíveis. O post, intitulado "How I built agent-based security reviews on Databricks," descreve um sistema funcional construído em menos de duas horas, contra o que o autor diz que levaria semanas conectando serviços separados.
A arquitetura é um conjunto de sete agentes focados, em vez de um único revisor de propósito geral: um agente de admissão (intake) que conduz a porta de entrada conversacional, um agente de avaliação de risco que atribui um nível (tier) e assume por padrão um nível mais alto quando as evidências estão incompletas, um agente de requisitos que mapeia solicitações para padrões, agentes de revisão especializados para casos como modelagem de ameaças de extensões de navegador e avaliação de fornecedores terceiros, um agente de validação que constrói checklists por item, um agente de fluxo de trabalho (workflow) que trata lembretes e escalonamentos, e um agente de aprendizado que compara periodicamente as edições dos revisores com a saída dos agentes para revelar melhorias de prompts e padrões. O autor escreve que isso foi deliberado: "Evitei deliberadamente construir um único agente com ampla autoridade para atuar como revisor de segurança." Cada agente, segundo o post, tem uma responsabilidade limitada, de modo que seu comportamento "permanece inspecionável e testável, e uma mudança em um não afeta silenciosamente outro."
A stack nomeia quatro componentes da Databricks que realizam funções distintas. O Unity Catalog atua como sistema de registro, mantendo padrões, dados de solicitações, evidências, saídas de modelos e decisões como tabelas governadas sob um único modelo de permissão e linhagem. Modelos de fundação hospedados pela Databricks fornecem a camada de raciocínio, com uma divisão em níveis por tarefa: Claude Haiku para classificação leve, Claude Sonnet para "a maior parte do trabalho de revisão," e Claude Opus "reservado para o raciocínio mais pesado." O Lakeflow Jobs orquestra os fluxos de trabalho dos agentes baseados em notebooks em computação serverless. Dois Databricks Apps separados tratam das interfaces voltadas para humanos: um app de admissão conversacional que transforma solicitações em linguagem simples em tickets estruturados, e um painel executivo que lê as mesmas tabelas do Unity Catalog para reportar volume, mix de risco, taxa de automação e tempo economizado.
Quanto à realidade operacional, o post é escasso em métricas concretas além da comparação de duas horas contra semanas na construção. Afirma que solicitações rotineiras elegíveis "que antes esperavam na fila por dias agora podem ser concluídas em minutos," mas não apresenta um número específico de tempo de ciclo, uma porcentagem de taxa de automação, ou um volume de solicitações — os números subjacentes do painel são descritos apenas como existentes e são mostrados no post com, nas palavras do autor, "alguns dos dados exclusivamente internos redigidos." Leitores que avaliam isso como um padrão a ser adotado recebem uma arquitetura, não um benchmark.
A troca que o autor explicita é de escopo, não de precisão: a automação fica confinada a "classes de solicitação predefinidas" — categorias bem compreendidas e de menor risco, como uma integração interna rotineira em um padrão aprovado de single sign-on que não lida com dados sensíveis — e tudo o mais é encaminhado por padrão a um humano. O sistema trata uma alegação sem suporte como uma lacuna, não como uma aprovação: "uma afirmação sem evidência é tratada como informação ausente," e quando a evidência está ausente ou contraditória, os agentes publicam um pedido de esclarecimento ou repassam o caso a um revisor "com as questões em aberto anexadas," em vez de inferir aprovação. As correções dos revisores realimentam prompts e padrões, mas explicitamente não permitem que os agentes alterem o comportamento em produção por conta própria — uma escolha de governança que troca autonomia por auditabilidade.
O que o post deixa sem resposta para quem tenta replicá-lo é exatamente a parte que uma equipe de plataforma precisaria orçar: nenhum número de custo para inferência de modelo nos três níveis de Claude, seja qual for o volume em que essa fila opera, nenhuma taxa de erro ou de escalonamento falso, e nenhum detalhe sobre como os limiares de níveis de risco foram validados antes de serem confiados a conclusões automatizadas. O relato é um padrão de design e uma filosofia de governança — agentes limitados, exigências de evidência, escalonamento conservador por padrão — não um estudo de caso de custo ou precisão.
A lição para equipes que constroem ferramentas internas semelhantes: copie a lógica de limites antes da arquitetura — decida primeiro quais classes de solicitação são elegíveis para conclusão automatizada e o que conta como evidência aceitável, depois conecte os agentes, em vez de construir um revisor geral e torcer para que seu julgamento de risco se sustente.