Microsoft Copilot Harness chega ao Foundry, mudando a decisão entre desenvolver ou comprar

A Microsoft disponibilizou seu Microsoft Copilot harness por meio do Foundry em 28 de outubro, estendendo aos desenvolvedores uma base interna de execução enquanto mantém o controle sobre sua operação. Um harness é o software que envolve um modelo de IA e organiza instruções, contexto, ferramentas e execução. O anúncio muda o que as empresas podem comprar em vez de desenvolver, sem eliminar sua responsabilidade pelo trabalho resultante.

A escolha central é manter internamente essa infraestrutura de execução ou adotar a abordagem gerenciada da Microsoft. Um agente, software que usa modelos e ferramentas para realizar uma tarefa, precisa de mais do que acesso a um modelo capaz. Alguém precisa decidir como ele prossegue, lida com falhas e permanece dentro dos limites do negócio.

A Anthropic já oferece uma abordagem gerenciada concorrente, dando aos compradores uma referência útil além da família de produtos da Microsoft. A proposta distinta da Microsoft enfatiza o acesso a diferentes famílias de modelos por meio de uma infraestrutura compartilhada. Para equipes de desenvolvimento, isso levanta uma questão prática: quais responsabilidades se tornam mais fáceis de delegar e quais ainda exigem julgamento específico da aplicação?

Microsoft Copilot Harness entra em prévia pública no Foundry

A Microsoft está transformando uma base compartilhada de produtos em um componente gerenciado para aplicações de clientes.

Segundo o anúncio do harness multimodal da Microsoft, a equipe de engenharia do GitHub desenvolveu o harness antes de a Microsoft adotá-lo em experiências do Copilot. A empresa cita Copilot Code, Copilot Studio, o aplicativo GitHub Copilot, a interface de linha de comando e o VS Code entre seus usuários.

O Foundry Agent Service, plataforma da Microsoft para criar e operar agentes, agora oferece o harness em prévia pública. Esse status importa porque o anúncio combina uma tecnologia interna já estabelecida com um serviço gerenciado recém-disponibilizado. A experiência dentro dos produtos da Microsoft não comprova automaticamente a prontidão para as cargas de trabalho de todos os clientes externos.

A Microsoft descreve uma divisão de responsabilidades na qual opera a infraestrutura de execução, enquanto os clientes fornecem instruções e conexões específicas de suas aplicações. Esse arranjo torna o lançamento relevante além dos assistentes de programação. Uma empresa que desenvolve um assistente de pesquisa ou agente operacional pode considerar comprar uma infraestrutura que antes era tratada como trabalho interno de engenharia.

O anúncio também descreve um kit de desenvolvimento de software para download, um pacote usado por desenvolvedores para integrar a tecnologia às aplicações. Essa opção não deve ser confundida com a experiência gerenciada do Foundry. Escolher um método de distribuição e escolher quem opera um serviço são decisões relacionadas, mas respondem a perguntas diferentes.

Para um comprador empresarial, a mudança imediata é uma opção adicional de implementação. Uma equipe que avalia um agente não precisa mais presumir que oferecer suporte a diferentes modelos exige manter seu próprio sistema de execução adjacente. A Microsoft está se oferecendo para manter essa base compartilhada em nome do cliente.

Essa oferta merece uma leitura precisa. Comprar um harness gerenciado não comprova que um fluxo de trabalho específico produz respostas corretas ou ações apropriadas. Isso muda quem fornece parte da infraestrutura. O comprador ainda precisa de evidências de que a aplicação completa atende aos seus próprios requisitos.

Considere uma aplicação hipotética de pesquisa que compara anúncios de fornecedores e prepara um briefing interno. Um resultado útil inclui fontes precisas, datas claras e um tratamento explícito de informações conflitantes. Um sistema de execução funcional sustenta esse trabalho, mas não pode definir esses requisitos editoriais para a organização.

Portanto, o lançamento muda o ponto de partida das discussões arquiteturais. Em vez de perguntar apenas qual modelo deve responder a uma solicitação, as equipes podem perguntar quais partes da execução de agentes merecem engenharia personalizada. Essa é uma questão mais consequente do que saber se outro modelo aparece em um menu de seleção.

A pressão recai sobre equipes que mantêm sua própria infraestrutura de execução

A oferta da Microsoft submete projetos internos de infraestrutura a um escrutínio maior, especialmente quando reproduzem capacidades sem criar uma vantagem de negócio.

A pressão mais forte recai sobre equipes de aplicações que já mantêm a infraestrutura adjacente dos agentes. Seus gestores agora têm uma alternativa externa para examinar. Continuar uma implementação personalizada passa a ser uma decisão que exige justificativa, em vez de um pré-requisito automático para lançar um agente.

Essa justificativa ainda pode ser convincente. Uma empresa pode exigir comportamentos de execução incomuns, integrações especializadas ou controle direto sobre como o trabalho avança. A distinção relevante é se esses requisitos afetam materialmente a aplicação. A propriedade personalizada faz mais sentido quando a organização consegue identificar o que esse controle proporciona.

Comprar infraestrutura introduz uma obrigação diferente: entender os limites do provedor. Uma equipe de desenvolvimento não pode avaliar um serviço gerenciado apenas pelas capacidades mostradas em uma demonstração. Ela precisa identificar onde a plataforma termina e onde começam seu próprio software, procedimentos e supervisão.

O anúncio da Microsoft sobre execução gerenciada de agentes descreve skills, ferramentas conectadas, execução de arquivos e código e delegação limitada. Skills são procedimentos reutilizáveis empacotados com instruções e recursos de apoio. Ferramentas dão aos agentes acesso a informações ou ações externas. Essas capacidades descrevem uma base de aplicação mais ampla do que a geração de texto isoladamente.

O mesmo anúncio apresenta a perspectiva de um cliente inicial. Chris Evans, diretor de tecnologia da Confluence Technologies, afirma que a empresa tinha uma solução funcionando em menos de uma semana. É um relato útil de implementação, embora não estabeleça um cronograma típico de implantação nem um resultado operacional de longo prazo.

Para compradores, a distinção importante está entre alcançar um estado inicial funcional e manter um serviço confiável. Um protótipo interno pode tolerar premissas que uma aplicação operacional não pode. Uma base gerenciada pode encurtar parte do trabalho de engenharia, deixando sem solução revisões de integração, critérios de aceitação e decisões de responsabilidade.

Uma comparação financeira útil deve, portanto, examinar o fluxo de trabalho completo, em vez de uma única resposta de modelo. Considerações relevantes incluem manutenção de engenharia, investigação de falhas, revisão humana e mudanças em sistemas conectados. Não há um cálculo universal decorrente do lançamento, porque essas responsabilidades diferem entre organizações.

A pressão também alcança fornecedores de infraestrutura cujos produtos cercam os modelos. A distribuição da Microsoft dá aos clientes mais um motivo para questionar de quais componentes separados precisam. Isso não estabelece que produtos independentes se tornem desnecessários. Eleva o padrão para explicar o controle, a visibilidade ou a especialização adicionais que oferecem.

Para trabalhadores do conhecimento, as implicações aparecem de outra forma. Eles vivenciam se um agente conclui uma entrega utilizável, preserva as evidências corretas e escala a incerteza adequadamente. Uma mudança arquitetural importa para eles quando reduz trabalho incompleto ou torna erros mais fáceis de identificar e corrigir.

É por isso que a discussão entre desenvolver ou comprar deve envolver proprietários de produto, além de engenheiros. A organização precisa definir um resultado satisfatório antes de decidir qual arranjo de infraestrutura o entrega. Caso contrário, uma implantação tecnicamente bem-sucedida pode deixar o problema real de negócio em grande parte intacto.

Escolha de modelo e controle de runtime são decisões distintas

O acesso a diferentes modelos não dá aos clientes controle ilimitado sobre como o serviço gerenciado executa seu trabalho.

A FAQ sobre disponibilidade do harness da Microsoft estabelece limites para a prévia. O suporte a modelos próprios não está disponível. Os clientes selecionam o harness ao criar um novo agente de prompt e não podem alterá-lo posteriormente. A disponibilidade também pode variar por região, cliente, ferramentas, rede e cotas.

Essas restrições esclarecem o significado do suporte multimodal. Um cliente pode avaliar opções compatíveis dentro dos limites do serviço. Isso é diferente de presumir que qualquer modelo, conexão ou arranjo de implantação funcionará simplesmente porque a estratégia mais ampla enfatiza a escolha.

A distinção importa durante a aquisição. A presença de um modelo em outra parte do portfólio de um fornecedor não responde se ele é compatível com uma experiência gerenciada específica. Os compradores precisam avaliar a combinação que pretendem usar, incluindo o local de implantação relevante e os sistemas conectados.

Também há uma distinção entre mudar um modelo e preservar o comportamento de uma aplicação. Mesmo que uma interface permaneça consistente, um modelo diferente pode produzir decisões ou resultados distintos. Proprietários de aplicações devem tratar uma mudança de modelo como algo a ser avaliado frente aos requisitos de negócio, e não como uma substituição administrativa.

Considere um assistente hipotético de compras que analisa uma proposta de fornecedor. Uma tarefa envolve extrair datas de entrega. Outra envolve interpretar uma cláusula de cancelamento ambígua. A organização pode preferir características diferentes de modelos para essas atividades, mas ainda precisa de uma definição consistente de evidência aceitável e escalonamento.

Uma base compartilhada de execução pode tornar essa comparação mais fácil de organizar. Ela não estabelece que as mesmas instruções funcionem igualmente bem em todos os modelos compatíveis. O resultado útil é uma oportunidade controlada de comparar resultados, com registros claros do que mudou e por quê.

A arquitetura de agentes gerenciados da Anthropic oferece uma comparação competitiva relevante. Seu relato de engenharia de abril de 2026 descreve a separação entre o modelo e o harness dos ambientes de execução e registros duráveis de sessão. O objetivo declarado é permitir que as implementações evoluam por trás de interfaces estáveis.

Essa comparação mostra por que a competição do setor vai além da seleção de modelos. Os provedores também competem sobre quais responsabilidades de execução conseguem absorver, preservando uma interface na qual os clientes podem confiar. A ênfase da Microsoft em múltiplas famílias de modelos aborda uma dimensão dessa decisão mais ampla de compra.

Nenhuma das descrições arquiteturais estabelece um vencedor universal. Uma empresa que escolhe entre abordagens gerenciadas precisa comparar seu fluxo de trabalho real, integrações exigidas e restrições operacionais. Um serviço que se adapta bem a uma aplicação pode impor premissas inadequadas a outra.

A troca mais profunda diz respeito a onde reside a flexibilidade. Uma equipe pode manter opções entre modelos compatíveis enquanto aceita o projeto de execução do provedor. Alternativamente, pode preservar maior controle sobre a execução e assumir a responsabilidade por mantê-la. São formas distintas de flexibilidade, com consequências diferentes para a engenharia.

Para o harness Microsoft Copilot, a interpretação prática mais sólida é, portanto, a de escolha limitada. Os clientes obtêm uma rota adicional gerenciada para o desenvolvimento de agentes. Devem avaliar essa rota com base em suas capacidades documentadas, em vez de tratar a marca mais ampla como uma promessa de compatibilidade universal.

Os Ganhos nas Avaliações da Microsoft Exigem Interpretação Cuidadosa

Os resultados internos da Microsoft justificam avaliações adicionais, mas não estabelecem ganhos equivalentes para todas as aplicações do Foundry.

Em seus resultados de avaliação de agentes, a Microsoft compara o harness Copilot ao harness Standard no Copilot Studio. A empresa relata melhorias nas taxas de aprovação de 10,8 pontos percentuais com um modelo da OpenAI e de 22,1 pontos percentuais com um modelo da Anthropic.

A Microsoft também relata tentativas contínuas após chamadas de ferramentas com falha em 84–91% dos casos avaliados, em comparação com menos de 7% usando o harness Standard. Suas notas complementares distinguem explicitamente o uso contínuo de ferramentas e novas tentativas bem-sucedidas da conclusão bem-sucedida da tarefa como um todo. São conclusões relatadas pela empresa, sem validação independente estabelecida aqui.

Essa ressalva é fundamental para interpretar o anúncio. Persistência descreve o comportamento depois que algo dá errado. Conclusão descreve se o resultado solicitado foi alcançado. Um sistema pode continuar trabalhando e ainda assim interpretar mal a tarefa, usar evidências inadequadas ou produzir um resultado inaceitável.

A diferença se torna concreta em um fluxo de trabalho hipotético de atendimento ao cliente. Um agente pode repetir com sucesso o acesso a um registro de caso, mas ainda recomendar a solução errada. Medir a recuperação após a falha de conexão ajuda a explicar o comportamento de execução. Isso não determina se o cliente recebeu uma resposta precisa.

Da mesma forma, uma taxa de aprovação mais alta em avaliações depende do que a avaliação solicita. Compradores precisam entender as tarefas relevantes, os critérios de aceitação e as configurações antes de transferir um resultado para seu próprio ambiente. Uma melhoria em pontos percentuais só é informativa em relação ao teste que ela mede.

Isso não diminui a importância do sistema de execução ao redor. A comparação relatada pela Microsoft é consistente com o argumento de que a capacidade do modelo, por si só, não determina os resultados dos agentes. Ela dá aos clientes um motivo para testar escolhas de execução junto com escolhas de modelo, mantendo explícitas a atribuição e as limitações.

A Microsoft também descreve uma aplicação interna de suporte que superou uma taxa de resolução totalmente autônoma de 35% em agosto de 2026. A empresa define essa medida como a resolução de casos sem intervenção humana. Trata-se de uma implantação concreta relatada, mas sua adequação como comparação depende dos casos e das condições operacionais.

Para uma empresa que avalia uma aplicação semelhante, a autonomia deve ser considerada junto com a correção e as consequências. Um caso resolvido sem intervenção pode ser uma evidência útil quando a resolução é precisa e apropriada. A ausência de intervenção, por si só, não pode estabelecer que o resultado atendeu ao padrão da organização.

A avaliação também deve considerar o trabalho transferido aos revisores. Se um agente produz mais material, mas exige correções substanciais, o volume de saída pode representar de forma enganosa sua contribuição prática. A questão empresarial diz respeito ao trabalho concluído e aceitável, além do esforço necessário para obtê-lo.

A mesma lógica se aplica a falhas que permanecem invisíveis até mais tarde. Um briefing bem elaborado com uma afirmação não fundamentada pode parecer bem-sucedido na entrega. Uma avaliação que verifica evidências e atribuição revelaria um resultado diferente. Os critérios de aceitação devem refletir como o resultado será efetivamente usado.

Por enquanto, os números da Microsoft são evidências úteis sobre seus próprios ambientes testados. Eles justificam investigação, sem substituir testes específicos de cada cliente. Compradores devem resistir a transformar uma comparação de fornecedor em uma previsão para cargas de trabalho que não fizeram parte da avaliação relatada.

A Execução Gerenciada Ainda Mantém a Responsabilidade Empresarial com o Cliente

Delegar infraestrutura não transfere a responsabilidade de decidir o que um agente pode fazer.

O limite mais claro diz respeito a ações consequentes. Um agente que prepara uma recomendação e outro que compromete a organização com essa recomendação exigem controles diferentes. Um serviço de execução gerenciada pode apoiar qualquer um dos dois modelos, mas a organização deve decidir onde a autoridade começa e termina.

A Fashable oferece uma perspectiva de cliente no material de lançamento da Microsoft. O diretor-executivo Orlando Ribas Fernandes descreve oportunidades envolvendo fluxos de trabalho de sourcing, enquanto mantém decisões comercialmente vinculantes sob controle humano. Trata-se de um limite operacional pretendido, e não de evidência de que toda capacidade proposta já tenha gerado um resultado mensurado.

O exemplo ilustra por que a responsabilização não pode ser inferida a partir da automação. Um assistente de sourcing pode comparar especificações, identificar informações ausentes ou preparar material de negociação. Autorizar uma compra introduz uma responsabilidade diferente. A distinção deve permanecer visível mesmo quando essas atividades aparecem em uma única conversa.

O trabalho de longa duração introduz outro limite: lembrar o que aconteceu versus saber o que continua válido. Um agente pode reter um resultado anterior sem saber que as circunstâncias mudaram. Os responsáveis pela aplicação precisam determinar quando informações anteriores exigem nova verificação e quais decisões dependem de evidências atuais.

A pesquisa sobre agentes de longa duração da Anthropic descreve falhas envolvendo trabalho incompleto e declarações prematuras de conclusão ao longo de sessões. Sua abordagem proposta utiliza registros explícitos de progresso e trabalho incremental. A lição mais ampla é que a execução contínua exige um relato confiável das obrigações não concluídas.

Para empresas, essa lição sugere tratar a conclusão como uma condição de negócio. Uma tarefa está finalizada quando seus critérios de aceitação são atendidos, incluindo qualquer revisão ou confirmação necessária. Uma mensagem final confiante não pode substituir evidências de que essas condições foram cumpridas.

Reiniciar um trabalho interrompido cria uma preocupação relacionada. Imagine um agente hipotético que prepara um relatório e o envia a outro sistema. Se o envio for bem-sucedido, mas a confirmação se perder, repetir a ação pode criar registros duplicados. A aplicação precisa de uma forma de distinguir uma ação inacabada de uma não confirmada.

A Microsoft anunciou separadamente a disponibilidade geral de resiliência de longa duração para agentes hospedados, nos quais os clientes trazem sua própria lógica de execução. Sua documentação atribui ao código da aplicação a responsabilidade pelo progresso salvo e pela prevenção de duplicações. Esse recurso separado não deve ser tratado como uma garantia abrangente para a nova prévia do harness.

A qualidade da informação cria uma responsabilidade adicional. Um agente conectado a orientações desatualizadas pode executar suas instruções de forma consistente e ainda produzir trabalho inadequado. Equipes que consideram uma base de conhecimento pesquisável devem tratar a organização e a manutenção das fontes como parte da aplicação.

Essa relação torna a gestão do conhecimento relevante para o lançamento sem implicar uma integração específica. A infraestrutura determina como o trabalho avança; as evidências disponíveis limitam o que o agente pode concluir de forma razoável. Melhorar uma não elimina as fragilidades da outra.

As organizações devem, portanto, atribuir responsabilidades em todo o fluxo de trabalho. Alguém precisa ser responsável pelo material-fonte, pelas permissões, pelos critérios de aceitação e pelas correções quando os resultados falham. A execução gerenciada pode alterar a carga de engenharia, mas não elimina essas decisões organizacionais.

O caso de adoção mais convincente identifica tanto o trabalho que o provedor absorve quanto as obrigações que o cliente mantém. Essa clareza facilita avaliar se o serviço reduz a complexidade no conjunto. Ela também impede que um protótipo bem-sucedido se transforme em uma aplicação pela qual ninguém é plenamente responsável.

Três Sinais Mostrarão se a Abordagem Gerenciada Funciona

As próximas evidências úteis dizem respeito à maturidade do serviço, aos resultados comparativos e às operações dos clientes, e não a alegações adicionais de lançamento.

O primeiro sinal é como a Microsoft desenvolverá a prévia do Foundry nos próximos meses. Compradores devem acompanhar disponibilidade mais clara, configurações compatíveis, opções de migração e orientações para produção. Um suporte documentado mais amplo fortaleceria o argumento para adotar uma base gerenciada comum em mais aplicações.

A expansão mais significativa atenderia a um requisito que atualmente impede uma implantação real. Outra configuração compatível importa quando permite que uma organização opere dentro de suas restrições técnicas e empresariais. Uma lista maior de recursos, por si só, diz menos sobre se uma aplicação específica se torna viável.

Se as restrições da prévia continuarem significativas para o ambiente pretendido de um cliente, o argumento para adoção imediata enfraquece para esse cliente. Esse é um julgamento específico da carga de trabalho. Uma limitação pode ser irrelevante para um protótipo de pesquisa e decisiva para uma aplicação conectada a sistemas operacionais sensíveis.

O segundo sinal é uma evidência comparativa que separe mudanças de modelo de mudanças de execução. As avaliações devem deixar claro qual componente mudou e como o sucesso foi medido. Isso ajudaria compradores a determinar se o benefício relatado vem do harness, do modelo ou da interação entre ambos.

Avaliações independentes aumentariam a confiança, especialmente quando divulgarem categorias de falha e requisitos de revisão. Uma comparação focada em trabalho concluído fortaleceria o argumento da Microsoft mais diretamente do que uma focada apenas em atividade. Resultados que mostrem dependência substancial de configuração restringiriam o quão amplamente a alegação deve ser aplicada.

Os desenvolvimentos competitivos importam dentro dessa mesma comparação. Mudanças na oferta gerenciada da Anthropic, ou na abordagem de execução de outro provedor, podem alterar as alternativas disponíveis. Compradores devem comparar serviços com base em um requisito estável da aplicação, para que um mercado em transformação não transforme a avaliação em uma busca interminável por recursos.

O terceiro sinal são os relatos dos clientes além da velocidade inicial de implantação. Relatos úteis descreveriam operação contínua, resultados aceitáveis, esforço de correção e as responsabilidades mantidas pelo cliente. Evidências de menor manutenção junto com resultados confiáveis fortaleceriam o argumento para adquirir a camada de execução compartilhada.

Relatos de trabalho personalizado extensivo exigiriam uma leitura mais cuidadosa. A personalização pode refletir especialização empresarial valiosa ou lacunas no serviço gerenciado. Entender qual explicação se aplica importa mais do que simplesmente contar quanto código um cliente escreveu.

Esses sinais também oferecem uma forma prática de revisitar uma decisão anterior. Uma equipe pode razoavelmente construir seu próprio sistema de execução hoje e adotar um serviço gerenciado mais tarde. Outra pode começar com infraestrutura gerenciada e mantê-la apenas enquanto o arranjo continuar atendendo aos seus requisitos.

Avalie o harness do Microsoft Copilot em relação a um fluxo de trabalho que sua organização já conhece bem. Defina um resultado aceitável, identifique quais ações exigem aprovação e registre onde a correção humana continua necessária. Compare a opção gerenciada com sua abordagem atual usando as mesmas evidências e os mesmos critérios de conclusão. Inclua a qualidade das fontes, o comportamento de recuperação e o esforço necessário para investigar erros. Mantenha a decisão vinculada às responsabilidades que sua equipe realmente pode delegar e reavalie-a à medida que evoluírem o suporte documentado e as evidências dos clientes. O lançamento da Microsoft cria uma alternativa concreta à manutenção interna de toda a base de execução. O próximo passo útil é estabelecer quais partes do seu próprio fluxo de trabalho essa alternativa melhora e quais evidências mudariam sua decisão