Olá pessoALL, semana passada eu estava numa reunião com um cliente de varejo, uns 600 funcionários, quando a diretora de RH fez a pergunta mais direta que eu ouvi no mês:

"Rafael, a gente quer um assistente que responda dúvidas de política interna, férias, benefícios e reembolso. Meu time vive respondendo a mesma coisa no Teams. Vocês recomendam o quê?"

E eu respondi na hora: Microsoft Foundry. Arquitetura própria, RAG customizado, controle total, observabilidade, o pacote completo.

Se você trabalha com Azure e é desenvolvedor, aposto que teria respondido a mesma coisa. Então aqui vai a primeira confissão do post: eu respondi errado. E o pior é que eu respondi errado por um motivo que não tinha nada a ver com o problema dela.

Alguns dias atrás eu escrevi aqui no blog sobre o fim de semana que perdi construindo meu próprio harness de IA, e a lição foi mais ou menos essa: não construa o que já existe pronto e testado. Pois é. Levei alguns dias pra perceber que eu tinha acabado de cometer exatamente o mesmo erro, só que agora com o dinheiro do cliente.

Esse post nasceu de um artigo do time do Microsoft Foundry sobre como escolher o ponto de partida certo pra agentes corporativos. O framework de lá é bom. Mas eu quero contar essa história com uma camada a mais, que é o lugar de onde eu falo: somos um Solutions Partner, e parceiro tem incentivo. Vou ser honesto sobre esse incentivo antes de te dar qualquer recomendação.

O reflexo que eu preciso admitir

Por que eu disse "Foundry" antes mesmo de terminar de ouvir a pergunta?

Porque eu sou desenvolvedor. Passei os últimos quinze anos escrevendo C#. Quando eu vejo um problema, meu cérebro abre o Visual Studio antes de abrir a planilha. Ferramenta low-code me dá uma coceira: "e se eu precisar de um retry customizado?", "e se eu quiser trocar o modelo?", "e o pipeline de CI/CD?".

Perguntas legítimas. Mas repare em quem é o sujeito de todas elas. Eu. Nenhuma delas era sobre o cliente.

E tem uma segunda camada nesse reflexo, mais desconfortável ainda. Um projeto de Foundry fatura consultoria. Arquitetura, integração, deployment, observabilidade, sustentação. Um agente feito no Copilot Studio pela própria pessoa de RH fatura... quase nada. Se você é parceiro Microsoft e nunca sentiu esse puxão, ou você é melhor pessoa que eu, ou você não estava prestando atenção.

Sendo um dos maiores parceiros Microsoft do Brasil, esse incentivo aparece na nossa mesa toda semana. E a única forma de não ser capturado por ele é falar dele em voz alta, de preferência num post público, que é o que eu estou fazendo agora.

Voltando ao cliente: gastei tempo precioso desenhando um diagrama bonito. App Service, Azure AI Search, Foundry Agent Service, private endpoint, tudo dentro da VNet. Mandei pro cliente numa quinta-feira. Na sexta ele me respondeu com uma pergunta de uma linha que derrubou o desenho inteiro:

"Rafael, e quem vai mexer nisso quando a política de férias mudar em janeiro?"

Silêncio do meu lado. Porque a resposta honesta era "eu". Ou seja, eles ficariam dependentes de nós pra editar um documento de RH.

Quem vai manter isso daqui a seis meses? Guarda essa pergunta, porque ela vai voltar várias vezes até o final do post.

A pergunta certa não é "qual é melhor"

O problema é que a pergunta "Copilot Studio ou Foundry?" trata as duas plataformas como concorrentes. E elas não são.

Copilot Studio é uma plataforma low-code, gerenciada, onde você monta agentes por configuração: você conecta conhecimento (SharePoint, Dataverse, sites, arquivos), define tópicos, adiciona ações, publica no Teams, no site ou no WhatsApp. Microsoft Foundry é uma plataforma code-first, dentro da sua assinatura Azure, onde você constrói agentes como software: SDK, catálogo de modelos, orquestração customizada, tracing, avaliação, rede privada, CI/CD.

Perceba que eu não descrevi capacidade. Descrevi modelo de trabalho. E é aí que mora a decisão.

Na prática, a pergunta útil não é "qual plataforma é mais poderosa". É essa aqui:

Quem constrói, quem opera e quem responde por esse agente quando ele der problema numa sexta-feira às 18h?

Se a resposta for "o time de RH, que muda a política duas vezes por ano", você já tem a plataforma. Se a resposta for "o time de engenharia, que já tem repositório, pull request e pipeline", você também já tem a plataforma. E é outra.

O artigo do time de Foundry organiza isso em três perguntas que eu achei ótimas e adotei: quem constrói e mantém, como esse time trabalha hoje, e qual nível de controle o cenário realmente exige. Vou usar essas três como espinha dorsal daqui pra frente, mas com números brasileiros em cima.

Onde o Copilot Studio ganha — e ganha feio

Vamos ser honestos sobre uma coisa que desenvolvedor tem dificuldade de admitir: velocidade de entrega é capacidade técnica, não consolo pra quem não sabe programar.

O agente de RH daquele cliente? A analista de processos dele montou a primeira versão em dois dias. Dois dias. Apontou pra biblioteca do SharePoint com as políticas, escreveu as instruções em português, testou no painel e publicou no Teams. Sem chamado, sem sprint, sem deploy, sem eu.

E quando a política de férias mudar em janeiro, ela sobe o PDF novo no SharePoint. Não tem reindexação manual nem release, e ela não precisa abrir chamado com a gente.

Os cenários em que eu recomendo Copilot Studio sem hesitar hoje:

• Agentes de conhecimento departamental: política de RH, manual de procedimentos, base de conhecimento de produto, onboarding.
• Automação de processo de negócio, tipo abertura de chamado, solicitação de compra ou aprovação de despesa. Especialmente quando o processo já vive no Power Platform ou no Dataverse.
• Experiências dentro do Microsoft 365, porque se o usuário final já passa o dia no Teams, publicar ali é um clique.
• Conteúdo que muda toda semana e precisa ser editado por quem é dono dele, não por quem faz deploy.
• Empresas que não têm time de desenvolvimento.

Esse último merece um parágrafo próprio, porque é o ponto cego de quem escreve conteúdo técnico. Eu escrevo pra você, que provavelmente é dev ou arquiteto. Mas boa parte das empresas que compram Azure no Brasil tem "TI" formada por três pessoas que cuidam de rede, ERP, Microsoft 365 e do notebook do diretor. Não existe backlog nem sprint, e repositório de código muito menos. Recomendar Foundry pra elas não é ser rigoroso tecnicamente. É empurrar um problema operacional que elas não têm como absorver.

Low-code soa como limitação. Mas quando o gargalo real da empresa é capacidade de engenharia, tirar a engenharia do caminho é exatamente o que faz o projeto existir.

Onde o Foundry é inegociável

Agora vamos pro outro lado, porque eu detesto post que só defende uma tese.

Existem cenários em que recomendar Copilot Studio seria irresponsabilidade minha. E eles não são raros.

O primeiro é quando o agente é o seu produto, e não a sua ferramenta. Se o comportamento do agente é o que a sua empresa vende, você precisa ser dono das primitivas: prompt, retrieval, roteamento, retry, avaliação. Vale a mesma régua que eu usei no post sobre harness próprio, e o "custo de construir" deixa de ser desperdício pra virar roadmap de produto.

Depois vem rede privada e residência de dados. Cliente de serviço financeiro, saúde, setor público. Se o dado não pode sair da sua VNet, se você precisa de private endpoint, se auditoria exige controle sobre onde a inferência acontece, o Foundry roda dentro dos seus recursos Azure. Esse é um requisito binário: ou atende, ou não atende.

O terceiro é orquestração multi-agente ou fluxo de longa duração. Um processo de sinistro que passa por leitura de documento, análise de fraude, validação de apólice e escalonamento não é um chatbot. É um sistema distribuído com IA dentro, e você quer isso em código, versionado e testado.

Tem também o caso em que avaliação e tracing são requisito, e não desejo. Se você precisa medir qualidade de resposta com rigor, comparar versões de prompt e rastrear cada chamada de ferramenta, o Foundry Agent Service traz tracing ponta a ponta e integração com Application Insights. E aqui eu repito o que aprendi na marra no post anterior: não dá pra melhorar o que você não consegue medir.

O último é o time já trabalhar com engenharia de software. Se já existe repositório, pull request, pipeline e code review, o Foundry se encaixa no que o time faz todo dia. Pedir pra esse time configurar agente por interface gráfica é tirar deles a única ferramenta de controle de qualidade que eles têm.

Repare que nenhum desses cinco critérios é "o agente é complexo". Complexidade é um péssimo critério isolado, e esse é provavelmente o erro mais comum que eu vejo em decisão de plataforma. O que decide é quem opera, sob quais restrições, com qual nível de controle exigido.

A conta de guardanapo que muda tudo

Se você chegou até aqui, deve estar curioso pra saber quanto isso custa. Eu também estava, então fiz a conta. E ela me surpreendeu.

Comece pelo custo de construir. No Copilot Studio, o agente de RH saiu em dois dias de uma analista que já estava na folha, então o custo marginal foi praticamente zero. No Foundry, o mesmo agente com RAG, deployment e observabilidade decente é coisa de 4 a 6 semanas entre dev sênior e arquiteto. Com hora sênior no Brasil entre R$ 120 e R$ 180, você está falando de algo entre R$ 60.000 e R$ 100.000. Estimativa minha, baseada em projetos que a gente entregou, não é tabela oficial.

Agora o custo por interação, e aqui a maré vira. O Copilot Studio cobra Copilot Credits, e cada crédito sai por $0,01 no pay-as-you-go. Uma resposta generativa consome 2 créditos, uma ação de agente consome 5, e grounding no tenant graph consome 10. Ou seja, uma pergunta que puxa dado e executa uma ação facilmente vira 7 créditos, sete centavos de dólar. No Foundry você paga token na tarifa do modelo, e uma consulta RAG bem enxuta fica na casa de um centavo ou menos.

Sete centavos contra um. Parece que o Foundry ganha disparado, né?

MAS (aqui entra um GRANDE MAS): essa comparação só importa se você tiver volume pra amortizar os R$ 60.000 a R$ 100.000 da construção.

Vamos fazer a conta de guardanapo. Se a economia é de uns US$ 0,05 por interação e o investimento inicial é de uns US$ 15.000 (usando R$ 5,50 pro dólar, no meio da faixa), o ponto de equilíbrio fica em torno de 300.000 interações. Diluído em 24 meses, dá aproximadamente 12.500 interações por mês, ou algo como 500 por dia útil.

Agora olha o cliente do começo do post. São 600 funcionários, e a estimativa realista dele era de 3 a 5 perguntas por funcionário por mês. Não por dia. Isso dá entre 1.800 e 3.000 interações mensais, uns US$ 130 a US$ 210 por mês em créditos.

Pra chegar no ponto de equilíbrio do Foundry nesse volume, ele levaria mais de dez anos. E naquela altura o modelo, a plataforma e provavelmente a empresa já seriam outros.

Falta a linha que quase ninguém coloca no orçamento, que é o custo de manter. No Copilot Studio, manter é subir um PDF. No Foundry, manter é um time. Se o cliente não tem esse time, ele vai contratar sustentação, provavelmente a nossa. Some mais uns R$ 5.000 a R$ 8.000 por mês nessa hipótese e a conta do Foundry piora ainda mais no cenário dele.

E agora a parte que não favorece o meu próprio argumento. Existe um cliente meu, de outro segmento, com um agente de atendimento fazendo 40.000 interações por mês. Pra ele a conta inverte completamente: os créditos passariam de US$ 2.800 mensais, e a construção no Foundry se paga em menos de seis meses. Nesse caso eu recomendo Foundry sem pestanejar, e recomendaria mesmo que ele não tivesse time, porque aí a conta justifica montar o time.

Ou seja, não existe resposta única. O que decide é o volume, a capacidade de operação do cliente e o requisito regulatório, mais ou menos nessa ordem de importância.

Se você quiser fazer essa conta pro seu caso antes de decidir qualquer coisa, a Microsoft publicou um estimador de consumo de Copilot Credits que aceita tipo de agente, tráfego, orquestração e ferramentas. Use antes de assinar contrato, não depois.

Os dois juntos: o cenário mais comum e o menos discutido

Agora que a conta está na mesa, dá pra falar do cenário que a maioria das empresas acaba vivendo e quase ninguém planeja: usar os dois.

O padrão que mais funciona é esse: Copilot Studio como a cara do agente, Foundry como o cérebro nos pedaços que exigem código.

Na prática, você mantém a experiência no Teams, o time de negócio continua dono do conteúdo e dos fluxos, e o Copilot Studio chama um agente publicado no Foundry pras partes que precisam de orquestração customizada, integração com sistema legado ou raciocínio mais pesado. O Foundry Agent Service permite publicar agentes com endpoint estável e distribuí-los via Microsoft 365 Copilot e Teams, então essa ponte não é gambiarra, é caminho suportado.

Voltando ao meu cliente do varejo: foi exatamente onde a gente chegou. O agente de políticas de RH ficou 100% no Copilot Studio, com a analista dela como dona. O pedaço de solicitação de compra, que precisa consultar o ERP legado deles via uma API que ninguém em sã consciência exporia direto, virou um agente no Foundry, mantido por nós, chamado pelo Copilot Studio.

Dois donos diferentes, duas velocidades diferentes, e do ponto de vista de quem usa é um agente só. E o mais importante: a diretora de RH não depende de sprint nenhuma pra atualizar a política de férias em janeiro.

Vale ressaltar um ponto que costuma aparecer tarde demais nesses projetos: governança. No momento em que a empresa tem agentes nascendo em duas plataformas, criados por perfis diferentes, você precisa definir antes quem é dono de cada agente, qual identidade ele usa, a quais dados ele tem acesso e como você mede se ele está respondendo besteira. Isso não é burocracia. É o que separa "três agentes úteis" de "quarenta agentes que ninguém sabe quem criou". Defina esse mínimo antes do terceiro agente, não depois do trigésimo.

Uma sequência pragmática pra decidir

Se essa discussão está acontecendo aí na sua empresa agora, é assim que eu conduziria hoje. E repare que a plataforma só aparece no passo 4:

1. Identifique quem vai manter o agente daqui a seis meses. Não quem vai construir, quem vai manter. Se a resposta for "a gente contrata alguém", a resposta real é "ninguém".
2. Estime o volume mensal de interações usando o estimador oficial. Sem esse número, qualquer comparação de custo é chute com cara de planilha.
3. Liste os requisitos binários: rede privada, residência de dados, integração com sistema que não pode ser exposto, exigência de auditoria. Requisito binário não negocia com preferência de plataforma, ele decide sozinho.
4. Só agora escolha a plataforma. Time de negócio, volume baixo ou médio e nenhum requisito binário: Copilot Studio. Time de engenharia, ou volume alto, ou requisito binário: Foundry. Os dois ao mesmo tempo: híbrido, com fronteira clara de quem é dono de quê.
5. Comece pelo caso de uso mais chato que você tem. Política de RH, status de pedido, procedimento interno. Caso de uso empolgante é o que faz PoC virar cemitério.
6. Defina avaliação e monitoramento antes de publicar. Como você vai saber que o agente está errando? Se a resposta é "quando alguém reclamar", você não tem monitoramento, tem sorte.
7. Reavalie em seis meses. Ponto de partida não é sentença. Agente que nasce no Copilot Studio e cresce pode migrar pedaços pro Foundry. O contrário quase nunca acontece, e isso já diz muita coisa sobre por onde começar.

A lição que ficou

Voltando pra diretora de RH e pra pergunta dela de uma linha só: "quem vai mexer nisso quando a política de férias mudar em janeiro?"

A resposta certa era "você mesma, em três minutos". E eu quase entreguei uma arquitetura em que a resposta seria "abre um chamado com a gente".

A lição que ficou não é sobre Copilot Studio nem sobre Foundry. É sobre viés. Todo mundo recomenda a ferramenta que sabe usar. Desenvolvedor recomenda código. Parceiro recomenda o projeto que fatura mais. E a única defesa contra os dois vieses é começar a conversa pelo modelo operacional do cliente, não pela capacidade da plataforma.

O Foundry é mais poderoso? É, sem discussão. Mas capacidade que ninguém dentro do cliente consegue operar não vira autonomia, vira dependência de terceiro. E o terceiro sou eu.

E se você é dev como eu e ficou incomodado lendo isso: eu também fiquei escrevendo. A parte difícil de ser tecnicamente rigoroso é aceitar que rigor técnico inclui reconhecer quando a solução com menos código é a solução certa.

E aí, qual foi a última vez que você recomendou a ferramenta que você gosta em vez da que o cliente consegue manter? Conta nos comentários, prometo não julgar — eu acabei de fazer isso alguns dias atrás.

Aqui na AzureBrasil.cloud a gente ajuda times brasileiros a fazer exatamente esse tipo de escolha: onde vale low-code, onde vale código, e como faturar tudo dentro do contrato Azure em BRL. Se essa decisão está travada aí, fala com a gente.

[]s e até a próxima.

Referências

O artigo que motivou este post

• Choosing the Right Starting Point for Enterprise AI Agents with Copilot Studio and Microsoft Foundry — Microsoft Tech Community — o framework de decisão por persona e modelo operacional que serviu de base aqui

Copilot Studio

• Copilot Studio licensing — Microsoft Learn — pay-as-you-go, packs pré-pagos e plano de pré-compra de Copilot Credits
• Copilot Studio agent usage estimator — estime consumo por tipo de agente, tráfego, orquestração e ferramentas antes de decidir
• Copilot Credits billing rates — Microsoft Learn — quanto cada tipo de ação consome

Microsoft Foundry

• What is Microsoft Foundry Agent Service? — Microsoft Learn — prompt agents, hosted agents, Responses API e ciclo de vida
• Virtual networks no Foundry Agent Service — Microsoft Learn — isolamento de rede e residência de dados
• Agent identity — Microsoft Learn — identidade Entra dedicada por agente, RBAC e OBO
• Publicar agentes no Microsoft 365 Copilot e Teams — Microsoft Learn — a ponte que viabiliza o cenário híbrido

Posts relacionados aqui do blog

• "Eu construí meu próprio harness de IA num fim de semana (e foi assim que entendi por que não vale a pena)" — o post anterior, sobre o mesmo viés aplicado a ferramenta de desenvolvimento
• "Copilot Studio + Azure SQL Grátis: Agentes de IA por $10/Mês — Verdade ou Marketing?" — a análise de custo de Copilot Credits em três cenários de PME

Faça parte da comunidade da AZBR e conecte-se com profissionais de tecnologia de todo o Brasil. Receba vagas, eventos, conteúdos exclusivos, networking e acompanhe as principais novidades do ecossistema Microsoft, Azure e IA.