Fala dataholics! Depois de passar pelo GitHub Copilot no post anterior, hoje eu volto pro nosso terreno de construir agente e coloco lado a lado os dois caminhos que a Microsoft te dá pra isso: o Copilot Studio, que a gente conhece de cor a essa altura, e o Foundry Agent Service, que é o irmão pro-code da história. É a hora de responder aquela pergunta que sempre volta: quando é que vale largar o low-code e descer pro código?

O que veremos nesse post:

• O eixo low-code vs pro-code, revisitado

• O que é o Foundry Agent Service

• Quando descer pro código de verdade

• Minha leitura de quando cada um vale

---

Low-code de um lado, pro-code do outro

Lá no mapa do início eu já tinha cravado esse eixo, e agora dá pra abrir ele com calma. O Copilot Studio é a porta low-code: você arrasta bloco, configura no visual, publica no Teams e mantém sem precisar de um time de engenharia. O Microsoft Foundry (o antigo Azure AI Foundry) é a porta pro-code, e dentro dele mora o Foundry Agent Service, que é onde você constrói agente escrevendo código de verdade.

---

O que é o Foundry Agent Service

O Foundry Agent Service é o serviço gerenciado da Microsoft pra construir e rodar agente em código, já em GA. A ideia é você escrever a lógica do agente num SDK (tem Python, .NET, JavaScript e Java) e o Foundry cuida da parte chata de produção: hospedagem, escala, identidade e observabilidade. Você empacota o agente e ele roda num endpoint gerenciado, sem você ter que montar servidor na mão.

E tem um ponto que eu curti bastante: ele não te prende num framework só. Dá pra escrever o agente com o Microsoft Agent Framework, mas também com LangGraph, com o OpenAI Agents SDK ou com o Claude Agent SDK, empacotar como container e deixar o Foundry rodar. Junta com suporte a MCP, tools e memória, e você tem uma casa pro-code pra agente que não te obriga a jogar fora o que você já sabe.

---

Quando descer pro código

Descer pro Foundry Agent Service faz sentido quando você bate num limite do low-code. Os sinais mais comuns:

• Precisa de modelo customizado ou de um modelo que não é da Microsoft, com fine-tuning e controle fino do prompt.

• A orquestração é complexa: vários agentes conversando, lógica pesada em Python, passo condicional que o visual não expressa bem.

• O agente vai viver fora do mundo Office, plugado numa aplicação sua, e você quer ser dono do deploy e do versionamento no seu pipeline.

• Você precisa de observabilidade e governança de nível de engenharia, com trace, avaliação e integração no seu CI/CD.

Reginaldo, eu sou mais do time low-code e de dados, isso de SDK tá longe demais de mim?

Não precisa começar por aí, e essa é a boa notícia. O caminho saudável na maioria dos casos é validar a ideia no Copilot Studio, que é rápido, e só migrar ou complementar com o Foundry quando o projeto pedir músculo que o low-code não dá. Ninguém é obrigado a abrir o VS Code no dia 1. Você desce pro código quando o problema exige, não porque é mais bonito no currículo.

---

Minha leitura

Na prática, a maioria dos agentes corporativos que eu vejo nem precisa de pro-code, o Copilot Studio dá conta e mantém o custo de manutenção baixo. O Foundry Agent Service brilha no projeto que virou produto sério, com engenharia dedicada, modelo próprio e requisito de produção que o low-code não alcança. E o combo mais comum continua sendo o híbrido: Copilot Studio na frente, cuidando da conversa e da publicação no Teams, e o Foundry como motor por trás quando o raciocínio aperta. Não trate como religião, é ferramenta certa pro problema certo.

---

RESUMO

• Copilot Studio: low-code, rápido, mantido por maker e TI, integrado ao M365.

• Foundry Agent Service: pro-code em SDK (Python, .NET, JS, Java), hosted com escala, identidade e observabilidade.

• Ele aceita Agent Framework, LangGraph, OpenAI Agents SDK e Claude Agent SDK, além de MCP e tools.

• Desce pro código quando precisa de modelo customizado, orquestração complexa, deploy fora do Office ou governança de engenharia.

• Comece validando no Studio e use o Foundry quando o projeto pedir. O híbrido (Studio na frente, Foundry motor) é o mais comum.

Com isso a gente cobriu os dois lados de construir agente na Microsoft. No próximo post eu fecho a série com o que faltava pra amarrar tudo: uma árvore de decisão com poucas perguntas pra você escolher, sem sofrimento, qual plataforma usar no seu caso. Comenta aí se você já precisou descer pro código num agente ou se o low-code sempre deu conta.

Referências:

https://learn.microsoft.com/en-us/azure/foundry/agents/overview

https://azure.microsoft.com/en-us/products/ai-foundry/agent-service/

Fique bem e até a próxima.

#copilotstudio #microsoftfoundry #foundryagentservice #ia #agentes #datainaction

Hey dataholics! After going through GitHub Copilot in the previous post, today I come back to our home turf of building an agent and put side by side the two paths Microsoft gives you for it: Copilot Studio, which we know by heart at this point, and the Foundry Agent Service, the pro-code sibling of the story. It's time to answer the question that always comes back: when is it worth dropping the low-code and going down to code?

What we'll cover in this post:

• The low-code vs pro-code axis, revisited

• What the Foundry Agent Service is

• When to actually go down to code

• My take on when each one is worth it

---

Low-code on one side, pro-code on the other

Back in the map at the start I'd already nailed down this axis, and now we can open it up slowly. Copilot Studio is the low-code door: you drag blocks, configure it in the canvas, publish to Teams and maintain it without needing an engineering team. Microsoft Foundry (formerly Azure AI Foundry) is the pro-code door, and inside it lives the Foundry Agent Service, which is where you build an agent by writing real code.

---

What the Foundry Agent Service is

The Foundry Agent Service is Microsoft's managed service for building and running agents in code, already GA. The idea is that you write the agent's logic in an SDK (there's Python, .NET, JavaScript and Java) and Foundry handles the boring production part: hosting, scaling, identity and observability. You package the agent and it runs on a managed endpoint, without you having to stand up a server by hand.

And there's one point I really liked: it doesn't lock you into a single framework. You can write the agent with the Microsoft Agent Framework, but also with LangGraph, with the OpenAI Agents SDK or with the Claude Agent SDK, package it as a container and let Foundry run it. Add support for MCP, tools and memory, and you've got a pro-code home for agents that doesn't force you to throw away what you already know.

---

When to go down to code

Going down to the Foundry Agent Service makes sense when you hit a low-code limit. The most common signs:

• You need a custom model or a non-Microsoft model, with fine-tuning and fine-grained control of the prompt.

• The orchestration is complex: several agents talking to each other, heavy logic in Python, a conditional step the canvas doesn't express well.

• The agent will live outside the Office world, plugged into an application of yours, and you want to own the deployment and versioning in your pipeline.

• You need engineering-grade observability and governance, with tracing, evaluation and integration into your CI/CD.

Reginaldo, I'm more of the low-code and data crowd, is this SDK stuff too far from me?

You don't have to start there, and that's the good news. The healthy path in most cases is to validate the idea in Copilot Studio, which is fast, and only migrate to or complement it with Foundry when the project asks for muscle the low-code can't give. Nobody's forced to open VS Code on day 1. You go down to code when the problem demands it, not because it looks nicer on the resume.

---

My take

In practice, most corporate agents I see don't even need pro-code, Copilot Studio handles it and keeps the maintenance cost low. The Foundry Agent Service shines on the project that turned into a serious product, with dedicated engineering, its own model and production requirements the low-code can't reach. And the most common combo is still the hybrid one: Copilot Studio up front, handling the conversation and publishing to Teams, and Foundry as the engine behind it when the reasoning gets heavy. Don't treat it like a religion, it's the right tool for the right problem.

---

RECAP

• Copilot Studio: low-code, fast, maintained by maker and IT, integrated with M365.

• Foundry Agent Service: pro-code in an SDK (Python, .NET, JS, Java), hosted with scaling, identity and observability.

• It accepts Agent Framework, LangGraph, OpenAI Agents SDK and Claude Agent SDK, plus MCP and tools.

• Go down to code when you need a custom model, complex orchestration, deployment outside Office or engineering governance.

• Start by validating in Studio and use Foundry when the project asks. The hybrid (Studio up front, Foundry as engine) is the most common.

With that we've covered both sides of building an agent on Microsoft. In the next post I close the series with what was missing to tie it all together: a decision tree with a few questions so you can pick, without the pain, which platform to use in your case. Comment below if you've already had to go down to code on an agent or if low-code always got the job done.

References:

https://learn.microsoft.com/en-us/azure/foundry/agents/overview

https://azure.microsoft.com/en-us/products/ai-foundry/agent-service/

Stay well and see you next time.

#copilotstudio #microsoftfoundry #foundryagentservice #ai #agents #datainaction