08-02-01 — Decision tree: Foundry vs Copilot Studio vs Power Platform vs Agent Framework
TL;DR
A pergunta certa não é "qual produto é melhor?" — é "quem vai manter isso e que nível de controle eu preciso?". Regra rápida: Copilot Studio para extensões do M365 Copilot e bots sem dev; AI Foundry para agentes pro-code com controle total; Power Platform para automação de processos com AI; AutoGen/Semantic Kernel para orquestração de múltiplos agentes custom. Nada impede combinar.
Decision tree
flowchart TD
Start(["🤔 O que você quer construir?"]) --> Q1{"É extensão do\nM365 Copilot ou bot\npara Teams/SharePoint?"}
Q1 -->|Sim| CS["✅ Copilot Studio\nDesigner visual, connectors,\npublica em M365 Copilot"]
Q1 -->|Não| Q2{"Precisa de código?\nLógica complexa?\nFeramentas customizadas?"}
Q2 -->|Não — citizen dev| PP["✅ Power Platform\nAI Builder + Power Automate\nAutomate processos com AI"]
Q2 -->|Sim — dev team| Q3{"Multi-agente?\nOrquestração complexa\nentre vários agentes?"}
Q3 -->|Não — agente único| Foundry["✅ Azure AI Foundry\nAgent Service GA\nResponses API + tools built-in"]
Q3 -->|Sim — sistema multi-agent| Q4{"Framework preferido?"}
Q4 -->|Python| AutoGen["✅ AutoGen v0.4\nOrquestração multi-agent\nPython-first"]
Q4 -->|C# / .NET| SK["✅ Semantic Kernel\nAgents + Process Framework\n.NET-first"]
Q4 -->|Ambos| Both["✅ AI Foundry\n+ AutoGen ou SK\nFoundry como backend de modelos"]
CS --> Note1["⚠️ Limite: lógica customizada\nlimitada, sem código full-stack"]
Foundry --> Note2["✅ Control total:\nBYOM, private network, tracing"]
AutoGen --> Note3["✅ Multi-agent:\nGroupChat, Swarm, MagenticOne"]
Comparativo detalhado
| Dimensão | AI Foundry | Copilot Studio | Power Platform | AutoGen/SK |
|---|---|---|---|---|
| Público | Dev team (.NET/Python) | Makers, PM, BA | Citizen dev, ops | Engenharia avançada |
| Modelo de build | Pro-code + portal | Low-code visual | No-code/Low-code | Código puro |
| Agente single | ✅ Agent Service | ✅ nativo | ✅ via Copilot | ✅ framework |
| Multi-agente | ⚠️ via SDK externo | ❌ limitado | ❌ | ✅ nativo |
| Custom tools | ✅ total (REST, code, MCP) | ⚠️ via connectors | ⚠️ via connectors | ✅ total |
| Integração M365 | ⚠️ via API | ✅ nativa | ✅ nativa | ❌ |
| Private network | ✅ VNet + Entra | ⚠️ limitado | ⚠️ limitado | ✅ via Azure |
| Observabilidade | ✅ Tracing GA + Eval | ⚠️ básico | ⚠️ básico | ✅ via OTEL |
| Custo modelo | Azure OpenAI (token/PTU) | Incluído na licença M365C | AI Builder créditos | Direto AOAI |
| Time to MVP | 1–3 semanas | 1–3 dias | 1–5 dias | 2–6 semanas |
Quando combinar
💡 Padrão comum: Use Copilot Studio como frontend conversacional do M365 Copilot e AI Foundry como backend de lógica complexa. O Copilot Studio pode chamar APIs externas — essas APIs são implementadas em .NET usando o AI Foundry SDK.
Padrões de combinação validados
- Copilot Studio + Foundry: Studio para UI/UX no Teams, Foundry para RAG e tools avançadas via HTTP action
- Semantic Kernel + Foundry: SK orquestra a lógica, Foundry provê modelos e storage de threads
- Power Automate + Foundry: Power Automate trigga o processo, chama agente Foundry via REST e posta resultado no Teams
- AutoGen + Foundry: AutoGen orquestra múltiplos agentes, cada agente usa modelos deployados no Foundry
Red flags: quando NÃO usar cada um
- ❌ Copilot Studio não é adequado para lógica de negócio complexa, pipelines de dados, ou quando você precisa de deploy em infraestrutura própria.
- ❌ AI Foundry não é a melhor opção para extensões nativas do M365 Copilot — Copilot Studio tem integração mais profunda.
- ❌ Power Platform não escala bem para agentes com alto volume de chamadas ou lógica de orquestração complexa.
- ❌ AutoGen/SK puros sem Foundry perdem observabilidade, model management e safety features built-in.