Azure Functions | The .NET Blog

Workflows Duráveis no Microsoft Agent Framework: De In-Memory ao Azure Functions

Emiliano Montesdeoca — Sun, 31 May 2026 00:00:00 +0000

Um dos pontos problemáticos com os primeiros workflows de agentes de IA: eles são frágeis. Um workflow multi-etapas de longa duração vinculado a um único processo significa que reinicialização do processo = estado perdido. Para demos simples está bem. Para cargas de trabalho em produção não está.

O modelo de programação de workflows do Microsoft Agent Framework agora suporta execução durável, apoiada pelo framework Durable Task, com hospedagem no Azure Functions. Aqui está como o modelo de programação funciona e por que a história de durabilidade importa.

Os Blocos de Construção Fundamentais

Executors são a unidade fundamental de trabalho. Cada um é tipado — pega uma entrada específica e produz uma saída específica:

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // buscar o pedido, retorná-lo
 return new Order(Id: message.OrderId, ...);
 }
}

Workflows conectam executors em grafos direcionados usando um builder fluente. O framework cuida da execução, do fluxo de dados entre os passos e da propagação de erros.

Você pode modelar:

Cadeias sequenciais (passo A → passo B → passo C)
Fan-out/fan-in paralelo (executar agentes A, B, C em paralelo, agregar resultados)
Ramificação condicional
Aprovações de humano no ciclo (pausar workflow, esperar sinal externo)

O Runner In-Memory para Desenvolvimento Local

Começar é rápido:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

O pacote principal inclui um runner leve em processo. Sem dependências externas, sem banco de dados, sem recursos Azure. Funciona muito bem para desenvolvimento local e testes unitários.

Adicionando Durabilidade com Durable Task

Quando um workflow precisa sobreviver a reinicializações de processo — porque é de longa duração, porque tem passos de humano no ciclo, porque se distribui em muitas chamadas de agentes em paralelo — o runner in-memory não é suficiente.

A integração Durable Task do MAF armazena o estado do workflow no Azure Storage. Se o processo for reiniciado, o workflow retoma de onde parou. O modelo de programação permanece o mesmo; você apenas troca o runner.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

Os mesmos executors, o mesmo grafo de workflow — apoiado por estado durável.

Hospedagem no Azure Functions

A terceira camada é a hospedagem no Azure Functions. Seu workflow se torna um aplicativo Function: acione o workflow via um endpoint HTTP, e o runtime durável cuida do escalonamento, estado e confiabilidade.

Isso significa que um workflow multi-agente com chamadas paralelas, ramos condicionais e aprovações humanas pode escalar em um ambiente Functions serverless sem gerenciamento de estado personalizado.

Por Que Isso Importa

A combinação é significativa para sistemas de IA reais:

Chamadas de agentes em paralelo — distribuir para múltiplos agentes especializados simultaneamente sem bloqueio, agregar resultados quando todos concluírem
Processos de longa duração — workflows que envolvem aprovação humana ou eventos externos podem pausar e retomar ao longo de horas ou dias
Escalonamento — Azure Functions escala a execução horizontalmente; o framework Durable Task gerencia a coordenação do estado paralelo

Se você está construindo workflows MAF além de demos locais simples, este é o caminho para execução de qualidade produção.

Post original: Durable Workflows in the Microsoft Agent Framework

Pare de Bombardear uma Dependência em Dificuldades: Padrões de Retry para Azure Functions + Service Bus

Emiliano Montesdeoca — Thu, 21 May 2026 00:00:00 +0000

Veja como uma falha recuperável se torna uma interrupção em um aplicativo Functions: uma dependência começa a dar timeout, cada instância Functions tenta novamente imediatamente e indefinidamente, a dependência é bombardeada com centenas de requisições com falha concorrentes, e o que começou como um soluço transitório se torna um evento de contrapressão em todo o sistema.

Você provavelmente conhece essa história. Azure Functions escala rapidamente — esse é todo o ponto. Mas “escalar rapidamente” e “tentar novamente imediatamente” juntos podem piorar dramaticamente as falhas.

Dois padrões ajudam. Exponential backoff e circuit breaker. Ambos agora são suportados nativamente para Azure Functions acionadas pelo Service Bus.

Dois Padrões, Papéis Diferentes

Esses padrões são complementares, não alternativos:

O exponential backoff responde a: quando devo tentar novamente? Aumenta o atraso entre as tentativas para que uma dependência tenha tempo de se recuperar. No nível da mensagem, regulando o tempo de retry.

O circuit breaker responde a: devo chamar essa dependência agora? Interrompe chamadas repetidas a uma dependência não saudável após atingir um limiar de falhas e, em seguida, sonda cuidadosamente após um período de resfriamento. No nível do sistema, prevenindo tempestades de retry.

Você quer os dois. O backoff gerencia o ritmo de retry por mensagem. O circuit breaker gerencia as decisões de saúde agregadas.

Por Que Isso Importa Especialmente para Service Bus

A fila absorve o tráfego em rajadas, o que é bom. Mas sem controles, a fila pode crescer enquanto os workers continuam desperdiçando recursos de computação em chamadas que vão falhar. Mensagens envenenadas ficam ativas por mais tempo do que deveriam. Partições quentes ou capacidade downstream limitada criam problemas em cascata.

O design mais seguro:

Detectar a falha transitória
Atrasar a próxima tentativa com exponential backoff
Parar de chamar a dependência quando um limiar de falha é atingido (circuito aberto)
Retomar cuidadosamente após um período de resfriamento (sonda de circuito)
Mover o trabalho irrecuperável para dead-letter ou um caminho de quarentena

Como É o Suporte Nativo

O novo suporte se integra com o modelo de host Azure Functions existente — sem bibliotecas extras, sem implementações personalizadas. A configuração vai no seu host.json:

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

A configuração do circuit breaker define o limiar de falha e o intervalo de reset para que dependências não saudáveis não sejam bombardeadas durante a recuperação.

Linguagens Cobertas

Isso não é apenas para .NET. O recurso cobre dotnet, JavaScript, TypeScript e Python — o conjunto completo de linguagens suportadas pelo trigger Service Bus no Azure Functions.

Conclusão

Os padrões de retry não são emocionantes de configurar até a primeira vez que uma interrupção downstream faz com que suas Functions piorem o problema em vez de degradar graciosamente. Configurá-los proativamente é barato. Adaptá-los durante um incidente não é.

Post original: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

Conecte seus servidores MCP no Azure Functions aos Foundry Agents — Veja como

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Isso é algo que eu amo no ecossistema MCP: você constrói seu servidor uma vez e ele funciona em qualquer lugar. VS Code, Visual Studio, Cursor, ChatGPT — cada cliente MCP pode descobrir e usar suas ferramentas. Agora, a Microsoft está adicionando mais um consumidor a essa lista: os agentes Foundry.

Lily Ma da equipe do Azure SDK publicou um guia prático sobre como conectar servidores MCP implantados no Azure Functions com agentes Microsoft Foundry. Se você já tem um servidor MCP, isso é puro valor agregado — sem necessidade de reconstruir nada.

Por que essa combinação faz sentido

Azure Functions te dá infraestrutura escalável, autenticação integrada e cobrança serverless para hospedar servidores MCP. Microsoft Foundry te dá agentes de IA que podem raciocinar, planejar e agir. Conectar os dois significa que suas ferramentas personalizadas — consultar um banco de dados, chamar uma API de negócio, executar lógica de validação — se tornam capacidades que agentes de IA empresariais podem descobrir e usar autonomamente.

O ponto-chave: seu servidor MCP continua o mesmo. Você está apenas adicionando o Foundry como mais um consumidor. As mesmas ferramentas que funcionam no seu setup do VS Code agora alimentam um agente de IA com o qual sua equipe ou clientes interagem.

Opções de autenticação

É aqui que o post realmente agrega valor. Quatro métodos de autenticação dependendo do seu cenário:

Método	Caso de uso
Baseado em chave (padrão)	Desenvolvimento ou servidores sem autenticação Entra
Microsoft Entra	Produção com identidades gerenciadas
Passthrough de identidade OAuth	Produção onde cada usuário se autentica individualmente
Sem autenticação	Dev/testes ou apenas dados públicos

Para produção, Microsoft Entra com identidade do agente é o caminho recomendado. O passthrough de identidade OAuth é para quando o contexto do usuário importa — o agente solicita que os usuários façam login, e cada requisição carrega o token próprio do usuário.

Configurando

O fluxo geral:

Faça deploy do seu servidor MCP no Azure Functions — exemplos disponíveis para .NET, Python, TypeScript e Java
Habilite a autenticação MCP integrada na sua function app
Obtenha sua URL de endpoint — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Adicione o servidor MCP como ferramenta no Foundry — navegue até seu agente no portal, adicione uma nova ferramenta MCP, forneça o endpoint e as credenciais

Depois teste no playground do Agent Builder enviando um prompt que acionaria uma das suas ferramentas.

Minha opinião

A história de composabilidade aqui está ficando realmente forte. Construa seu servidor MCP uma vez em .NET (ou Python, TypeScript, Java), faça deploy no Azure Functions, e cada cliente compatível com MCP pode usá-lo — ferramentas de programação, apps de chat, e agora agentes de IA empresariais. É um padrão “escreva uma vez, use em qualquer lugar” que realmente funciona.

Para desenvolvedores .NET especificamente, a extensão MCP do Azure Functions torna isso simples. Você define suas ferramentas como Azure Functions, faz deploy, e tem um servidor MCP de nível de produção com toda a segurança e escalabilidade que o Azure Functions proporciona.

Finalizando

Se você tem ferramentas MCP rodando no Azure Functions, conectá-las aos agentes Foundry é uma vitória rápida — suas ferramentas personalizadas se tornam capacidades de IA empresarial com autenticação adequada e sem alterações de código no servidor.

Leia o guia completo para instruções passo a passo sobre cada método de autenticação, e confira a documentação detalhada para configurações de produção.

MCP Apps ganham uma API fluente — Construa interfaces ricas para ferramentas de IA em .NET em três passos

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Ferramentas MCP são ótimas para dar capacidades aos agentes de IA. Mas e se a sua ferramenta precisa mostrar algo ao usuário — um dashboard, um formulário, uma visualização interativa? É aí que entram as MCP Apps, e elas ficaram muito mais fáceis de construir.

Lilian Kasem da equipe do Azure SDK apresentou a nova API de configuração fluente para MCP Apps no Azure Functions com .NET, e é o tipo de melhoria na experiência do desenvolvedor que faz a gente se perguntar por que não era sempre assim tão simples.

O que são MCP Apps?

MCP Apps estendem o Model Context Protocol permitindo que as ferramentas carreguem suas próprias views de UI, assets estáticos e controles de segurança. Em vez de apenas retornar texto, sua ferramenta MCP pode renderizar experiências HTML completas — dashboards interativos, visualizações de dados, formulários de configuração — tudo invocável por agentes de IA e apresentado aos usuários pelos clientes MCP.

O problema era que conectar tudo isso manualmente exigia conhecer a especificação MCP a fundo: URIs ui://, tipos MIME especiais, coordenação de metadados entre ferramentas e recursos. Não era difícil, mas trabalhoso.

A API fluente em três passos

Passo 1: Defina sua função. Uma ferramenta MCP padrão do Azure Functions:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Passo 2: Promova-a a MCP App. No startup do seu programa:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Passo 3: Adicione sua view HTML. Crie assets/hello-app.html com a interface que você precisa.

É isso. A API fluente cuida de toda a encanação do protocolo MCP — gera a função de recurso sintético, define o tipo MIME correto e injeta os metadados que conectam sua ferramenta à sua view.

A superfície da API é bem projetada

Algumas coisas que eu realmente gosto:

As fontes de views são flexíveis. Você pode servir HTML a partir de arquivos no disco, ou embutir recursos diretamente no seu assembly para deploys independentes:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

O CSP é componível. Você permite explicitamente as origens que sua app precisa, seguindo princípios de menor privilégio. Chame WithCsp várias vezes e as origens se acumulam:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Controle de visibilidade. Você pode tornar uma ferramenta visível apenas para o LLM, apenas para a UI do host, ou ambos. Quer uma ferramenta que só renderiza UI e não deve ser chamada pelo modelo? Fácil:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Primeiros passos

Adicione o pacote preview:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Se você já está construindo ferramentas MCP com Azure Functions, isso é apenas uma atualização de pacote. O quickstart de MCP Apps é o melhor lugar para começar se você é novo no conceito.

Finalizando

MCP Apps são um dos desenvolvimentos mais empolgantes no espaço de ferramentas de IA — ferramentas que não apenas fazem coisas, mas podem mostrar coisas aos usuários. A API fluente remove a complexidade do protocolo e permite que você se concentre no que importa: a lógica da sua ferramenta e sua interface.

Leia o post completo para a referência completa da API e exemplos.