IA & Agentes
Copilot Studio do zero [1] - Onde cada Copilot vive no ecossistema Microsoft AI
Copilot Studio from scratch [1] - Where each Copilot lives in the Microsoft AI ecosystem
Fala dataholics, bora começar série nova por aqui! Essa é a parte 1 da nossa série Copilot Studio do zero, e antes de sair criando agente é melhor a gente resolver uma confusão que pega todo mundo: hoje tudo se chama Copilot. GitHub Copilot, Microsoft 365 Copilot, Copilot Studio, Teams Copilot, Security Copilot... e no meio disso ainda tem o Microsoft Foundry. Onde cada um vive? E principalmente: onde é que EU crio os meus próprios agentes?
O que veremos nesse post:
Por que o nome "Copilot" virou uma sopa de letrinhas
O mapa: o que você só usa pronto vs. o que você cria
Copilot Studio vs Microsoft Foundry: low-code vs pro-code
Como escolher entre os dois (e por que não é "ou um ou outro")
Resumo

A sopa de Copilots
Se você sentiu que toda semana a Microsoft lança um Copilot novo, calma, não é impressão sua. O "Copilot" deixou de ser um produto e virou uma marca guarda-chuva para basicamente toda IA da empresa. O problema é que isso embola coisas que servem para públicos completamente diferentes: tem Copilot para o desenvolvedor escrever código, Copilot para o usuário montar um slide, e tem a plataforma onde VOCÊ constrói o seu próprio agente.
A forma mais fácil de não se perder é parar de pensar nos nomes e pensar numa pergunta só: eu vou USAR algo pronto ou vou CRIAR alguma coisa? Essa é a linha que divide o mapa.
O que você USA pronto
Aqui ficam os Copilots que já vêm prontos, embutidos num produto. Você liga e usa, não precisa construir nada.
GitHub Copilot: o assistente de código, dentro do seu IDE (VS Code, Visual Studio, JetBrains). Autocompletar, chat e até agentes que abrem PR sozinhos. É o queridinho dos devs, com mais de 20 milhões de usuários.
Microsoft 365 Copilot: a IA dentro do Word, Excel, Outlook e Teams, para o usuário final do dia a dia. E aqui mora metade da confusão: Teams Copilot, Security Copilot, Sales Copilot e companhia são basicamente "sabores" do M365 Copilot aparecendo dentro de cada produto. Não são plataformas separadas, são o mesmo conceito vestido de outra fantasia.
Repara que nesses dois você é consumidor. Ótimos, mas não é deles que a nossa série trata. A nossa série é sobre o outro lado do mapa.
O que você CRIA: Copilot Studio vs Microsoft Foundry
Quando o assunto é construir o seu próprio agente, a Microsoft te dá dois caminhos. E é exatamente aqui que a maioria das dúvidas aparece, porque os dois fazem "agente de IA", mas de jeitos opostos.
Copilot Studio é a porta low-code. Ele vive em cima do Power Platform e a ideia é montar um agente arrastando blocos, num visual gráfico, com pouquíssimo (ou nenhum) código. Conectores prontos para centenas de sistemas, integração nativa com o Microsoft 365 e publicação fácil no Teams. Dá para ter um agente conversando com a sua base de conhecimento em horas, e o melhor: quem mantém pode ser o analista de negócio ou o time de TI, sem depender de um esquadrão de desenvolvedores.
Microsoft Foundry (o antigo Azure AI Foundry) é a porta pro-code. Aqui o time de engenharia é dono do ciclo de IA inteiro: escolha do modelo (são mais de 11 mil disponíveis, incluindo open source do Hugging Face), fine-tuning, pipelines de RAG, deploy em produção e observabilidade de verdade, com governança via Entra, Purview e Defender. É controle total, e em troca exige código e mão de engenheiro.
Resumindo o eixo: Copilot Studio = rápido e low-code de um lado; Foundry = controle total e pro-code do outro.
Então qual eu escolho?
Regrinha prática que eu uso para decidir:
Quer um agente rápido, integrado ao M365, com base de conhecimento enxuta e mantido pelo próprio time de negócio? Copilot Studio.
Precisa de modelo customizado ou não-Microsoft, base gigante de documentos, lógica complexa em Python, deploy fora do mundo Office e monitoramento de produção? Microsoft Foundry.
Reginaldo, mas então eu preciso escolher UM e abandonar o outro?
Não! E essa talvez seja a parte mais importante do post. A Microsoft desenhou os dois para conversarem. O padrão mais comum em projeto sério é justamente o híbrido: Copilot Studio na frente (a cara do agente, onde o usuário fala no Teams) e Foundry como motor por trás, cuidando do raciocínio pesado, dos modelos e da orquestração. Os famosos "fusion teams", maker e dev trabalhando no mesmo agente, cada um na ferramenta certa.
IMPORTANTE: não trate a escolha como religião. Começar no Copilot Studio para validar a ideia e depois plugar o Foundry quando precisar de músculo é um caminho totalmente válido, e bem comum.
RESUMO
USA pronto → GitHub Copilot (código no IDE) e Microsoft 365 Copilot (apps Office; Teams/Security/Sales Copilot são sabores dele).
CRIA agente → Copilot Studio (low-code, Power Platform, rápido) ou Microsoft Foundry (pro-code, controle total).
Copilot Studio: makers e TI, integração M365, agente em horas, base de conhecimento enxuta.
Microsoft Foundry: engenharia, modelo customizado, RAG, fine-tuning, observabilidade e governança.
Não é "ou um ou outro": dá para usar Copilot Studio na frente e o Foundry como motor.
Bom, esse era o mapa pra você nunca mais se perder no meio de tanto "Copilot". No próximo post da série a gente entra de fato no Copilot Studio e cria nosso primeiro agente do zero.
Referências:
https://learn.microsoft.com/en-us/microsoft-copilot-studio/fundamentals-what-is-copilot-studio
https://azure.microsoft.com/en-us/products/ai-foundry
Microsoft Copilot Studio vs. Microsoft Foundry (Tech Community)
Fique bem e até a próxima.
#copilotstudio #microsoftai #microsoftfoundry #m365copilot #githubcopilot #ia #agentes #datainaction
Hey dataholics, let's kick off a brand new series! This is part 1 of our Copilot Studio from scratch series, and before we rush into building an agent, let's clear up the confusion that trips everyone up: these days everything is called Copilot. GitHub Copilot, Microsoft 365 Copilot, Copilot Studio, Teams Copilot, Security Copilot... and on top of all that there's Microsoft Foundry. Where does each one live? And more importantly: where exactly do I build my own agents?
What we'll cover in this post:
Why the name "Copilot" turned into alphabet soup
The map: what you only use off the shelf vs. what you actually build
Copilot Studio vs Microsoft Foundry: low-code vs pro-code
How to choose between the two (and why it's not "either/or")
Recap

The Copilot soup
If it feels like Microsoft ships a new Copilot every week, relax, it's not just you. "Copilot" stopped being a product and became an umbrella brand for basically every piece of AI in the company. The problem is that it lumps together things built for completely different audiences: there's a Copilot for the developer writing code, a Copilot for the user putting together a slide, and there's the platform where YOU build your own agent.
The easiest way not to get lost is to stop thinking about the names and think about a single question: am I going to USE something ready-made, or am I going to BUILD something? That's the line that splits the map.
What you USE off the shelf
This is where the ready-made Copilots live, baked right into a product. You switch it on and use it; there's nothing to build.
GitHub Copilot: the coding assistant, inside your IDE (VS Code, Visual Studio, JetBrains). Autocomplete, chat, and even agents that open PRs on their own. It's the developers' darling, with more than 20 million users.
Microsoft 365 Copilot: the AI inside Word, Excel, Outlook and Teams, for the everyday end user. And here's where half the confusion lives: Teams Copilot, Security Copilot, Sales Copilot and friends are basically "flavors" of M365 Copilot showing up inside each product. They're not separate platforms, they're the same concept wearing a different costume.
Notice that in these two you're a consumer. Great tools, but they're not what this series is about. Our series is about the other side of the map.
What you BUILD: Copilot Studio vs Microsoft Foundry
When it comes to building your own agent, Microsoft gives you two paths. And this is exactly where most of the questions show up, because both do "AI agents," but in opposite ways.
Copilot Studio is the low-code door. It lives on top of the Power Platform and the idea is to assemble an agent by dragging blocks in a graphical canvas, with very little (or no) code. Ready-made connectors for hundreds of systems, native Microsoft 365 integration, and easy publishing to Teams. You can have an agent chatting with your knowledge base in hours, and best of all: whoever maintains it can be the business analyst or the IT team, without depending on a squad of developers.
Microsoft Foundry (formerly Azure AI Foundry) is the pro-code door. Here the engineering team owns the entire AI lifecycle: model choice (there are more than 11 thousand available, including open source from Hugging Face), fine-tuning, RAG pipelines, production deployment and real observability, with governance through Entra, Purview and Defender. It's full control, and in exchange it demands code and an engineer's hands.
To sum up the axis: Copilot Studio = fast and low-code on one side; Foundry = full control and pro-code on the other.
So which one do I choose?
The rule of thumb I use to decide:
Want a fast agent, integrated with M365, with a lean knowledge base and maintained by the business team itself? Copilot Studio.
Need a custom or non-Microsoft model, a huge document base, complex logic in Python, deployment outside the Office world, and production monitoring? Microsoft Foundry.
Reginaldo, so do I have to pick ONE and abandon the other?
No! And this might be the most important part of the post. Microsoft designed the two to talk to each other. The most common pattern in a serious project is exactly the hybrid one: Copilot Studio up front (the face of the agent, where the user talks in Teams) and Foundry as the engine behind it, handling the heavy reasoning, the models and the orchestration. The famous "fusion teams," maker and dev working on the same agent, each in the right tool.
IMPORTANT: don't treat the choice like a religion. Starting in Copilot Studio to validate the idea and then plugging in Foundry when you need muscle is a totally valid path, and a very common one.
RECAP
USE off the shelf → GitHub Copilot (code in the IDE) and Microsoft 365 Copilot (Office apps; Teams/Security/Sales Copilot are flavors of it).
BUILD an agent → Copilot Studio (low-code, Power Platform, fast) or Microsoft Foundry (pro-code, full control).
Copilot Studio: makers and IT, M365 integration, an agent in hours, a lean knowledge base.
Microsoft Foundry: engineering, custom model, RAG, fine-tuning, observability and governance.
It's not "either/or": you can use Copilot Studio up front and Foundry as the engine.
Alright, that was the map so you never get lost again in the middle of so many "Copilots." In the next post of the series we actually dive into Copilot Studio and build our first agent from scratch.
References:
https://learn.microsoft.com/en-us/microsoft-copilot-studio/fundamentals-what-is-copilot-studio
https://azure.microsoft.com/en-us/products/ai-foundry
Microsoft Copilot Studio vs. Microsoft Foundry (Tech Community)
Take care and see you next time.
#copilotstudio #microsoftai #microsoftfoundry #m365copilot #githubcopilot #ai #agents #datainaction
Gostou? Tem mais no YouTube e no LinkedIn.
Enjoyed it? There's more on YouTube and LinkedIn.