Microsoft leva o Copilot harness ao Foundry para criar agentes multi-modelo

O que é o Copilot harness

O modelo fornece a capacidade de raciocinar e gerar respostas. O harness coordena o restante do ciclo: quais instruções o agente recebe, que contexto e ferramentas pode usar, onde executa ações e quais limites se aplicam. Por isso, dois agentes baseados no mesmo modelo podem se comportar de forma diferente quando usam harnesses distintos.

A Microsoft descreve o Copilot harness como uma camada de orquestração com suporte a padrões como MCP e Agent Skills, além de plugins. A ideia é melhorar ou manter essa camada sem exigir que cada equipe construa seu próprio roteador de modelos, ambiente de execução e controles.

O que a Microsoft anunciou

Segundo o anúncio oficial, o harness já sustenta experiências como Copilot Code, Copilot Studio, o aplicativo GitHub Copilot, a CLI e o VS Code. A novidade é oferecê-lo também por meio do Microsoft Foundry Agent Service, como uma opção gerenciada para criar agentes que usam ferramentas e executam tarefas longas.

A Microsoft diz que o harness trabalha com mais de 20 modelos de fronteira e aceita trazer uma chave própria. Também descreve roteamento de modelos conforme a tarefa, em vez de exigir que a equipe escolha e mantenha manualmente um modelo para cada etapa. A empresa executa o loop do agente e o sandbox no Foundry; quem constrói fornece instruções, skills, ferramentas e a escolha do modelo.

Para quem prefere integrar a capacidade em uma aplicação, a Microsoft aponta o GitHub Copilot SDK. O SDK e o serviço gerenciado são caminhos diferentes: um permite integrar capacidades do Copilot em software; o outro hospeda agentes no Foundry.

O que muda para quem constrói agentes

O anúncio reforça que o valor de um agente não depende apenas do modelo. Contexto, ferramentas, isolamento, seleção de modelos e políticas de execução também influenciam o resultado. Uma equipe que hoje mantém cada parte por conta própria pode avaliar se faz sentido delegar esse trabalho a um serviço gerenciado — desde que ele atenda aos requisitos de dados, governança e custo do projeto.

Na prática, vale testar o harness com tarefas representativas do seu produto, não apenas com uma demonstração curta. Compare o resultado em etapas de trabalho reais, registre quando o agente chama ferramentas, examine os dados enviados e verifique como a solução lida com falhas e retomadas. Para planejar papéis e revisões entre agentes, veja nosso guia de workflows multiagente no BridgeCode. E compare essa discussão com um benchmark de agentes em tarefas de repositório real.

O que o anúncio ainda não demonstra

A publicação da Microsoft descreve a arquitetura e a disponibilidade, mas não oferece, nesse anúncio, uma comparação independente que prove que o harness terá melhor desempenho em qualquer projeto. A lista completa de modelos, a disponibilidade específica por região e os custos também precisam ser conferidos na configuração atual do Foundry. Termos como “mais rápido” ou “mais eficiente” devem ser avaliados com métricas do próprio workload, não inferidos apenas do anúncio.