O agente é o produto? Atualização de outubro do Copilot Studio sugere que o produto é o processo todo

Quando uma empresa aprova um agente de IA, o que exatamente ela está aprovando?

A resposta usual trata o agente como a unidade. Ele recebe uma revisão de design, um conjunto de avaliação, uma aprovação de segurança e um release. A mais recente atualização do Copilot Studio, publicada em 7 de outubro por Jason Moore, vice-presidente de produto, pressiona essa suposição, porque o que ela ajuda os times a construir não é mais um agente. É um processo com um agente dentro.

Três tipos de lógica em um só lugar

A ideia central da atualização é que os makers podem “criar apps, workflows e agentes em um só lugar”. O próprio exemplo da Microsoft é onboarding de funcionários: um app dá a gerentes e funcionários uma interface estruturada, workflows executam as etapas repetíveis do onboarding, e um agente responde a perguntas. Nas palavras do post, os times podem reunir “a interface que as pessoas usam, workflows determinísticos com os quais o negócio pode contar, e agentes que raciocinam, se adaptam e agem”.

As peças chegam em diferentes maturidades:

• Apps, gerados a partir de uma descrição e refinados em conversa com acesso ao código, estão em preview pública.
• Copilot Managed Runtime, que analisamos quando foi anunciado como a parte difícil de operar apps criados com IA, ainda está em preview pública. Agora ele cobre apps do Copilot Studio, Copilot Cowork e Copilot Code, com hospedagem operada pela Microsoft, identidade, acesso a dados governado, gerenciamento de ciclo de vida e versionamento com Git.
• Hooks para agentes, por meio do harness do GitHub Copilot, estão em preview. Eles executam lógica determinística em pontos do ciclo de vida de um agente, como início de sessão, chamadas de ferramenta e erros. A formulação da Microsoft é precisa: “Enquanto um workflow define a lógica a executar, um hook determina quando essa lógica roda.”
• A integração com Foundry IQ, para bases de conhecimento reutilizadas entre agentes com rede privada, está em disponibilidade geral (GA).
• O Review panel, que mostra bloqueadores e avisos, incluindo avisos de avaliação, antes da publicação, está em disponibilidade geral (GA).

Onde a visão do agente como produto quebra

Se a solução é um app, um conjunto de workflows e um agente, muitas falhas não vão morar dentro de nenhum deles. Elas vão morar nas junções. Um agente passa o ID de funcionário errado para um workflow. Um workflow retorna um erro e o agente diz ao usuário que teve sucesso. Um app mostra o rascunho do agente como se fosse o registro aprovado.

Uma avaliação que olha apenas a conversa do agente perde todos os três. É por isso que a linha mais consequente da atualização é curta: as avaliações no Copilot Studio “estão se expandindo além das conversas de agentes para a automação”.

Os novos graders mapeiam para essas junções. Task Completion verifica se o resultado pretendido foi alcançado, não se a resposta soou certa. Tool Accuracy verifica se o agente escolheu as ferramentas esperadas e passou as entradas esperadas, que é exatamente onde um agente faz o handoff para um workflow determinístico. Verificações de Safety e latência ficam ao lado deles, e uma biblioteca de graders personalizados pode ser reutilizada entre agentes. A Microsoft não informa um status de lançamento para cada um desses recursos de avaliação, então verifique no seu tenant antes de planejar em cima deles.

Determinístico onde o negócio depende disso

A atualização também confirma uma regra de design que tiramos do sistema de contas a pagar da Snowflake: mantenha as partes determinísticas determinísticas. Hooks são uma forma de impor isso de dentro da execução de um agente. Uma verificação a cada chamada de ferramenta pode validar parâmetros contra a política antes de um workflow executar. Um hook em erros pode enviar uma falha para um caminho definido em vez de deixar o agente improvisar uma explicação. Ambas são escolhas de design que os times vão fazer, não padrões que a Microsoft fornece.

Um detalhe a mais merece atenção: um novo papel de Evaluation Viewer permite que revisores e outros stakeholders vejam os resultados de avaliação. Isso coloca a evidência diante da pessoa que é dona do processo de negócio, não apenas da pessoa que construiu o agente. Como argumentamos sobre observabilidade de agentes além do uptime, um sistema que retorna um código de sucesso ainda pode estar errado, e as pessoas mais bem posicionadas para perceber são as que sabem como é o certo.

A mudança prática está no que é aprovado. Os casos de teste devem começar onde uma pessoa começa, no app, e terminar onde o registro de negócio muda, no sistema em que o workflow escreve. A precisão de ferramenta deve ser avaliada em cada workflow que o agente pode chamar. E compromissos de produção devem se apoiar nas partes que estão em disponibilidade geral hoje, não nos previews ao redor delas. O agente é um componente. O que a empresa aprova, e o que um auditor vai eventualmente amostrar, é o processo.