Não tenho nada contra o Copilot Studio como ideia. Um estúdio low-code integrado ao Microsoft 365, com governança, conectores, DLP e boa parte da infraestrutura pronta resolve um problema real: colocar um agente interno no ar sem construir uma plataforma inteira antes.
O problema aparece depois da demo, na distância entre "conseguimos colocar um agente funcionando" e "conseguimos operar esse agente como software em produção". É nessa distância que, na minha experiência, os projetos começam a adoecer.
Isso não é uma crítica ao low-code, nem uma defesa de que todo agente deveria nascer do zero. É uma crítica ao momento em que uma ferramenta criada para simplificar a construção passa a ser usada para resolver problemas que exigem engenharia: observabilidade, testes, controle de custo, integração, versionamento e previsibilidade. É exatamente aí que as limitações aparecem.
A ferramenta muda debaixo de você
O primeiro problema parece pequeno até você passar algumas semanas trabalhando nele. O Copilot Studio muda o tempo todo. Menus trocam de lugar, experiências são substituídas, recursos aparecem em novos modelos de authoring e funcionalidades antigas continuam coexistindo com as novas. Isso é compreensível em uma plataforma em evolução, mas existe uma diferença entre uma ferramenta evoluir e uma ferramenta tornar o desenvolvimento imprevisível.
Somem-se a isso os relatos recorrentes de instabilidade. O próprio fórum da Microsoft tem discussões sobre a tela de Overview quebrando e sobre o Copilot Studio fechando ao acessar determinadas abas de ações do Power Automate. Parece inconveniente. Para quem desenvolve, não é: quando a ferramenta de desenvolvimento é instável, o custo não aparece na licença, aparece no tempo do desenvolvedor.
O ciclo é sempre parecido. Você abre uma configuração, a página demora, você atualiza, o estado não aparece. Publica, o comportamento muda, volta para conferir e a interface já é outra. Então começa a investigação: é o agente, o flow, o ambiente, o navegador, o conector ou a plataforma? Você parou de desenvolver e começou a fazer arqueologia.
Existe ainda um efeito colateral menos óbvio. Você escreve um procedimento interno com base na interface atual, e algumas semanas depois o botão mudou de lugar. O screenshot envelheceu, o tutorial não corresponde mais ao produto. Isso é trivial até você precisar treinar dez pessoas ou entregar documentação para um cliente. A velocidade de evolução da plataforma vira dívida operacional.
O custo de descobrir
Esse é um dos pontos que mais me incomodam, e quero ser preciso: não sou contra cobrar por consumo. Sou contra cobrar pelo processo de descoberta.
A Microsoft adotou Copilot Credits como unidade de consumo para as capacidades de agentes. O custo depende do que o agente efetivamente faz: modelo, grounding, ferramentas, ações, complexidade da tarefa. Razoável. O problema é que o custo não é apenas uma propriedade do uso final. Ele é consequência da arquitetura.
Você começa com um agente simples, percebe que precisa de grounding e adiciona uma fonte. Precisa de uma ação e adiciona Power Automate. A resposta não está boa, então aumenta o raciocínio. Precisa de outra ferramenta, adiciona mais contexto. O agente fica melhor e mais caro ao mesmo tempo, porque arquitetura e custo estão diretamente acoplados.
Só que arquitetura muda durante o desenvolvimento. Ninguém sabe qual será a arquitetura final de um agente antes de construir o agente, e portanto ninguém sabe quanto ele vai custar antes de experimentar. Experimentar é justamente a parte mais importante do trabalho.
O novo harness torna isso mais estranho ainda. A proposta é boa: o Copilot Studio passa a trabalhar com uma experiência mais orientada a planejamento, raciocínio e execução de ferramentas, o que aproxima a plataforma do que se espera de agentes modernos. Mas o desenvolvimento também entra na equação de consumo. Construir, testar, avaliar e iterar podem fazer parte da conta.
Isso quebra uma premissa básica do desenvolvimento de software. Em software tradicional, experimentar é barato: você escreve uma implementação, roda, descarta, refaz, cria dez versões e testa todas, e o custo principal é o seu tempo. Em agentes, parte desse ciclo passa a ter custo variável, e o incentivo se inverte: quanto mais você experimenta, mais você paga. David Wyatt descreve bem essa lógica de "prove o ROI antes de experimentar".
Para agentes isso é especialmente ruim, porque qualidade não aparece no primeiro prompt. Você precisa quebrar o agente, procurar casos extremos, testar ferramentas, testar grounding, testar instruções conflitantes, testar erro e testar tudo de novo depois de cada mudança. Se cada ciclo tem preço, o incentivo passa a ser reduzir ciclos, que é o oposto do que engenharia de agentes exige.
Integrar dói mais do que deveria
Aqui está uma das maiores contradições do produto. A promessa é construir agentes de negócio, mas agentes de negócio quase nunca vivem só de conversa. Eles consultam sistemas, criam registros, executam processos, chamam APIs, geram documentos. E é aí que entra o Power Automate.
Na teoria, a cadeia é Agente → Power Automate → Sistema externo. Na prática, é Agente → Agent Action → Power Automate → Connector → API → Sistema externo, e cada camada traz o próprio conjunto de limitações: timeout, autenticação, permissão, formato de entrada, formato de saída, tratamento de erro, observabilidade.
Quando algo falha, nem sempre fica claro onde. Foi o flow? O conector? A API? O timeout? Foi o modelo que decidiu não chamar a ferramenta? Foi a resposta que voltou em um formato inesperado?
Esse último caso é o perigoso. Uma exceção é fácil de identificar. Uma operação que simplesmente não aconteceu, não. O usuário pergunta se o pedido foi criado, o agente responde que sim, e a ação falhou. Isso não é um problema de UX, é um problema de confiabilidade.
O harness ainda não é uma ferramenta de engenharia
Harness virou uma palavra comum no ecossistema de agentes, e não é só uma interface. É a camada que coordena contexto, modelo, ferramentas, execução, estado, decisões, erro e observabilidade. É onde o agente realmente vive.
Era exatamente onde eu esperaria as ferramentas de engenharia mais fortes. Se o agente tomou uma decisão errada, quero saber por quê. Se escolheu a ferramenta errada, ou não chamou nenhuma, quero saber por quê. Se recebeu contexto incorreto, quero ver o que ele recebeu. Se uma chamada falhou, quero saber onde. Se o comportamento mudou entre versões, quero comparar. Se o custo subiu, quero identificar a causa.
O que existe hoje ainda parece uma ferramenta de configuração tentando virar plataforma de engenharia. Você vê o resultado, algumas etapas, algumas chamadas. Conforme a arquitetura cresce, falta a capacidade de explicar o comportamento do sistema. Você deixa de depurar e passa a tentar reproduzir.
Isso importa mais em agentes do que em software comum. Um agente não é prompt + LLM. É uma cadeia de orquestração, contexto, modelo, escolha de ferramenta, execução, resultado, nova decisão e resposta, em que cada etapa pode introduzir erro e boa parte do comportamento é probabilística. A observabilidade deveria ser melhor que a de software tradicional, não pior. Sem saber o que aconteceu, quando, com qual versão, com qual modelo, com qual ferramenta, com qual contexto, a que custo e com qual retorno, o desenvolvimento vira tentativa e erro. Tentativa e erro sem observabilidade é uma forma cara de desenvolver.
Multiagentes prometem mais do que a operação entrega
Multiagentes ficam bonitos em diagrama. Um supervisor chama o agente financeiro, o jurídico, o de RH, o comercial, o de dados, e visualmente parece sofisticado.
Em produção as perguntas são outras. Quem controla o contexto? O agente subordinado recebe todo o histórico? Quem decide o handoff? Quanto custa cada salto? O que acontece quando dois agentes discordam? Como reproduzir um erro específico, testar uma combinação específica, observar uma cadeia de seis agentes?
Criar cinco agentes é fácil. Operar cinco agentes é o problema. Quanto mais agentes, maior a superfície de comportamento não determinístico. Em algum momento surge uma pergunta desconfortável: se eu preciso construir minha própria camada de orquestração para controlar a orquestração do Copilot, que problema o orquestrador original está resolvendo?
O ALM fica desconfortável
Projeto de agente precisa de versionamento, CI/CD, teste automatizado, regressão, comparação entre versões, rollback e colaboração. O Copilot Studio tem mecanismos de ALM via Solutions, ambientes e pipelines, mas existe diferença entre ter mecanismos de ALM e ter uma experiência de desenvolvimento naturalmente orientada a ALM.
Quando duas pessoas mexem na mesma lógica, eu quero a segurança que tenho em código: branch, alteração, diff, review, merge, deploy. A experiência do Copilot Studio não chega nesse nível de naturalidade, então o time começa a construir processos paralelos. Exporta soluções, versiona arquivos, escreve scripts, mantém testes por fora, cria validação própria. Funciona, mas o low-code passou a exigir uma camada de engenharia ao redor dele. Quanto mais crítico o agente, mais essa camada cresce.
A escalada que ninguém percebe
Esse é o padrão que mais vejo. O projeto começa com "vamos criar um agente para consultar documentos internos", e funciona. Depois ele precisa consultar o ERP, abrir uma solicitação, gerar um documento, chamar uma API, conversar com outro agente. Depois precisa de interface própria, de logs, de testes, de controle de custo.
Nenhuma dessas decisões é absurda sozinha. O problema é o acumulado. O projeto vai se afastando do problema que o Copilot Studio resolve muito bem e ninguém percebe exatamente quando isso aconteceu. Não existe o momento em que alguém anuncia que a partir dali a ferramenta é a errada. A complexidade só se acumula. Essa é a doença.
Por que tantos problemas aparecem juntos
Depois de listar tudo isso, é fácil concluir que faltam interface melhor, sistema de créditos melhor e debugging melhor. Acho que existe uma pergunta mais interessante: por que esses problemas aparecem todos ao mesmo tempo?
Minha hipótese é que boa parte deles é consequência da estratégia da Microsoft para Copilot. A empresa tinha uma vantagem que ninguém mais tinha: já controlava a camada de interação de milhões de trabalhadores, entre Office, Teams, Windows, Edge, GitHub, Power Platform e Azure. Se Copilot estivesse em todos esses lugares, a adoção seria inevitável. É a mesma lógica de outras apostas históricas da Microsoft: distribuir primeiro, dominar a camada de interação e descobrir a monetização depois.
O efeito colateral foi uma quantidade enorme de produtos e arquiteturas diferentes surgindo, sendo reposicionados ou incorporados em um intervalo curto: Copilot no Office, Microsoft 365 Copilot, Copilot Studio, Agent Builder, Agent Mode, Agent Flows, Work IQ, MCP, Cowork. Wyatt argumenta que o lançamento inicial foi fragmentado, com equipes diferentes construindo experiências de Copilot de forma relativamente independente. O Copilot no Office ilustra bem: a arquitetura passou por experiências baseadas em Graph, depois agentes específicos por aplicação e depois um modelo mais orientado a ferramentas e contexto, com MCP e Work IQ.
O resultado final pode ser melhor. Mas existe um custo para quem constrói em cima da plataforma, porque cada pivot estratégico vira dívida técnica de quem começou o projeto antes dele. Você define a arquitetura, escolhe o modelo, define as ferramentas, integra Power Automate, documenta, treina o time, coloca em produção. Seis meses depois a arquitetura recomendada mudou, o harness funciona de outro jeito, a integração recomendada agora é MCP. Você não errou a decisão. A plataforma mudou enquanto você construía, e essa é uma dívida técnica particularmente ingrata porque não foi o desenvolvedor que a criou.
Vale contrastar com quem foi por outro caminho. A Anthropic começou pelo núcleo de capacidade e subiu na cadeia depois: modelo, API, um domínio específico onde poderia dominar (programação) e só então Claude Code, Cowork, Design e outras experiências.
A OpenAI apostou em transformar o ChatGPT na marca universal de IA, para todo mundo ao mesmo tempo, o que gerou adoção enorme e também mudanças de direção conforme o mercado amadureceu. Nenhuma dessas estratégias venceu de forma definitiva, o mercado ainda está mudando rápido demais. Mas as consequências para quem constrói em cima delas são visíveis.
O que isso explica sobre o Copilot Studio, para mim, é o seguinte: ele está tentando resolver problemas de engenharia enquanto a própria plataforma ainda muda de identidade. Daí as contradições. Quer ser low-code, mas os projetos exigem engenharia. Quer ser simples, mas acumula dezenas de abstrações. Quer democratizar agentes, mas começa a cobrar pelo processo de construção. Quer esconder a complexidade do modelo, e ela reaparece em créditos, grounding, ações, flows e orquestração.
O problema dos 95%
Wyatt usa uma expressão que descreve bem a sensação: o problema dos 95%. A funcionalidade chega, funciona, a interface está pronta, a documentação existe, parece terminada. Mas os últimos 5% impedem o uso real em produção, e é exatamente ali que ficam observabilidade, controle de custo, teste, versionamento, permissão, integração, tratamento de erro e previsibilidade.
Para uma demonstração, 95% pronto basta. Para uma empresa, 95% pronto costuma ser 0% pronto.
Isso conversa diretamente com a minha experiência. Nada está quebrado o suficiente para abandonar a plataforma, e algumas coisas não estão completas o suficiente para confiar cegamente nelas.
Some-se a monetização. A estratégia de colocar Copilot em todo lugar funcionou para gerar adoção, mas adoção subsidiada precisa virar receita em algum momento. Antes a mensagem era "use Copilot". Agora é "use Copilot, e vamos medir quanto cada ação custa". Do ponto de vista empresarial faz sentido. Do ponto de vista de quem desenvolve agentes, cria o problema que descrevi lá em cima: experimentação, teste, avaliação e iteração passam a ter preço, e o agente fica mais caro justamente quando fica mais sofisticado.
Onde o Copilot Studio é a escolha certa
A conclusão fácil seria "não use Copilot Studio". Não concordo. Ele tem um sweet spot muito claro, e dentro dele é excelente.
Eu usaria sem hesitar quando os dados estão predominantemente dentro do Microsoft 365, em SharePoint e Dataverse, com usuários internos, processos razoavelmente bem definidos, volume pequeno ou moderado, agentes com escopo claro, necessidade forte de governança Microsoft e uma organização que já investiu em Power Platform. Um agente interno que consulta políticas de RH, responde perguntas sobre documentos e abre uma solicitação é exatamente esse caso. Não existe razão para construir plataforma própria para isso.
O problema é confundir "consigo fazer isso no Copilot Studio" com "devo fazer isso no Copilot Studio". São perguntas diferentes.
Cinco perguntas antes de começar
Onde estão os dados? Se quase tudo está no Microsoft 365, o Copilot Studio ganha muitos pontos. Se estão espalhados entre APIs, ERPs, bancos e sistemas legados, o custo de integração cresce rápido.
Quanto custa uma execução? Não basta estimar número de usuários. É preciso entender interações, modelo, grounding, ferramentas, ações, raciocínio, chamadas externas e complexidade das tarefas. Esse custo precisa ser medido durante a POC, não estimado em planilha.
O projeto precisa de engenharia ou de configuração? Se precisa de teste de regressão, CI/CD, diff, code review, tracing, versionamento granular e integração customizada, isso entra na estimativa desde o início.
É realmente um agente ou é um chatbot com algumas ações? Um agente simples se beneficia muito do low-code. Um sistema autônomo com várias ferramentas, planejamento e múltiplos agentes exige controles que a plataforma ainda precisa acompanhar.
Estamos dentro do sweet spot? Provavelmente a mais importante. Toda plataforma tem um espaço onde é excelente, e o risco é o projeto crescer sem ninguém notar que saiu dele.
O que eu gostaria de ver
Na minha lista, cinco prioridades. Primeiro, estabilidade: menos iterações virando produto novo, e mais confiança de que a arquitetura que escolho hoje continuará válida daqui a dois anos. Segundo, custo previsível: prefiro pagar mais por uma licença previsível do que descobrir em produção que o custo depende de uma combinação de modelo, grounding, ferramentas e raciocínio. Empresa compra previsibilidade, não necessariamente preço baixo.
Terceiro, um harness que sirva como ferramenta de engenharia, com tracing, debugging, replay, teste, avaliação, comparação entre versões e explicabilidade de decisão. Um agente precisa ser observável como qualquer sistema crítico. Quarto, integração tratada como parte central do produto: o Power Automate não pode ser apenas a ponte para tudo que está fora do Copilot Studio, ainda mais quando o objetivo declarado é criar agentes capazes de executar trabalho real. Quinto, resolver o problema dos 95%. Uma feature que funciona bem em produção vale mais que dez previews.
Conclusão
O Copilot Studio não adoece projetos de agentes por ser uma ferramenta ruim. Ele adoece porque é muito fácil começar e relativamente difícil perceber quando você deveria parar de usá-lo como plataforma principal.
A primeira versão fica pronta rápido, a segunda também. A terceira precisa de integração, a quarta de observabilidade, a quinta de controle de custo, a sexta de testes, a sétima de interface própria. Quando você percebe, o projeto deixou de ser um agente low-code e virou um sistema distribuído de IA construído sobre uma ferramenta que ainda tenta esconder parte dessa complexidade.
Interface instável, consumo de créditos, dependência do Power Automate e harness imaturo são sintomas. O problema maior é construir software crítico sobre uma plataforma cuja arquitetura e cuja estratégia ainda estão mudando rápido.
A Microsoft tem uma vantagem enorme com Azure, Microsoft 365, Entra, SharePoint, Teams, Power Platform, Dataverse, Dynamics e agora Work IQ. Esse ecossistema pode ser uma das melhores fundações possíveis para agentes empresariais. Mas integração não é o mesmo que maturidade, e ter todos os componentes não garante que a experiência de engenharia entre eles seja boa. Um agente empresarial não precisa só de um modelo bom. Precisa de segurança, observabilidade, ALM, integração, previsibilidade de custo, teste, governança e estabilidade. Se a infraestrutura ao redor do modelo for ruim, o projeto continua ruim.
Por isso minha crítica não é "não use". É: saiba exatamente em que ponto você deixou de usar uma ferramenta low-code e começou a construir um sistema de IA crítico. É nesse ponto que a arquitetura precisa ser reavaliada, e é nesse ponto que a pergunta deixa de ser "consigo fazer?" e passa a ser "consigo operar isso por anos?".
Referências
- David Wyatt, What Went Wrong For Copilot, DEV Community: https://dev.to/wyattdave/what-went-wrong-for-copilot-19f2
- Microsoft, Introducing a new harness for Copilot Studio
- Microsoft Learn, Copilot Studio billing and licensing
- Microsoft Learn, View agent's billing consumption
- Microsoft Learn, Use Power Automate flows in Copilot Studio
- Microsoft Q&A, relatos de instabilidade no Copilot Studio
- Reddit, What is your experience with Copilot Studio? e New harness experience really bad in M365 Copilot
