Agent-Framework | The .NET Blog

Microsoft Foundry Abril 2026: Foundry Local GA, GPT-5.5, CodeAct com Hyperlight

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Um mês movimentado para o Microsoft Foundry. Estes são os anúncios mais importantes.

Foundry Local está Geralmente Disponível

Foundry Local — o runtime de IA local multiplataforma da Microsoft — passa de preview para GA no Windows, macOS (Apple Silicon) e Linux x64. Inferência de modelos locais pronta para produção com um SDK amigável para desenvolvedores. A versão 1.1 adiciona suporte a transcrição, embeddings e API Responses.

GPT-5.5

O mais recente modelo da família GPT-5 está agora disponível no Foundry. Cota padrão para assinaturas Tier 5 e Tier 6. Se você trabalhou com variantes anteriores do GPT-5, vale a pena avaliar para seus casos de uso.

Rastreamento do Agent Framework no Foundry

Dois recursos de rastreamento são lançados em preview este mês:

Rastreamento do Microsoft Agent Framework — Os agentes MAF agora podem emitir rastreamentos OpenTelemetry no Foundry. Depure o comportamento dos agentes, rastreie a execução em múltiplas etapas, exponha latência e erros nas chamadas de ferramentas. Isso preenche uma lacuna real: saber o que seu agente realmente fez na produção, não apenas o que retornou.

Rastreamento de agentes hospedados — Sessões, chamadas de ferramentas e etapas de execução de agentes hospedados também aparecem nos rastreamentos do Foundry. A mesma história de observabilidade estendida ao nível hospedado.

CodeAct com Hyperlight (Alpha)

Esta é a adição tecnicamente mais interessante: Agent Framework agora pode executar código Python dentro de micro-máquinas virtuais Hyperlight.

CodeAct é o padrão onde um agente gera e executa código Python como ferramenta. A preocupação óbvia é a segurança — você está executando código gerado pelo modelo. As micro-VMs do Hyperlight fornecem isolamento em nível de processo com tempo de inicialização próximo ao nativo, tornando a execução de código em sandbox prática sem a sobrecarga de contêineres ou VMs completos.

Para fluxos de trabalho agênticos onde a execução de código é necessária, isso é uma melhoria significativa de segurança em relação à execução de código no processo host.

Painel de Monitoramento de Agentes (Preview)

Um painel de operações unificado combinando uso de tokens, latência, taxa de sucesso de execução e pontuações de avaliadores em uma única visualização. A distinção dos painéis de observabilidade regulares: inclui resultados de avaliação junto com métricas operacionais, para que você possa correlacionar “o agente está mais lento” com “as pontuações do avaliador caíram” — ou confirmar que não estão relacionados.

Avaliadores Personalizados de Avaliação Contínua (Preview)

Agora você pode trazer seus próprios avaliadores baseados em código ou prompt para pipelines de avaliação contínua. Anteriormente, a avaliação contínua estava limitada a avaliadores integrados. Os avaliadores personalizados permitem que você aplique critérios de qualidade específicos da equipe em seu loop de monitoramento de produção.

Inventário de Agentes no Plano de Controle

A visualização Operate do Plano de Controle do Foundry agora mostra todos os agentes suportados em uma assinatura: agentes Foundry, Azure SRE Agent, loops de agentes do Logic Apps e agentes personalizados registrados. Uma visualização para entender o que está implantado e onde.

Postagem original: What’s new in Microsoft Foundry | April 2026

O Padrão Handoff: Quando Um Agente Não É Suficiente

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

Em algum momento, todo sistema multi-agente supera um roteador simples. O primeiro sinal é geralmente quando um agente especialista precisa fazer uma pergunta de acompanhamento, ou percebe no meio do turno que outro agente deveria continuar. Um pipeline fixo falha aí. Um roteador de passagem única falha aí.

Exatamente para isso é que o padrão de orquestração Handoff no Microsoft Agent Framework foi projetado.

Como Handoff Funciona

O desenvolvedor declara um grafo: aqui estão os agentes, aqui estão as arestas entre eles. O framework faz o resto — sintetiza uma ferramenta handoff por aresta de saída e a injeta em cada agente. Quando um agente decide passar o controle, ele chama a ferramenta. O framework aplica a topologia.

Três coisas tornam isso diferente de simplesmente fazer com que os agentes se chamem:

Uma transcrição compartilhada — o agente receptor vê o histórico completo da conversa. Sem começar do zero.
Aplicação de topologia — um agente só pode fazer handoff para destinos declarados. Bugs de roteamento são detectados no momento de criação, não em produção.
Terminação natural — quando o agente ativo termina seu turno sem chamar uma ferramenta de handoff, o fluxo de trabalho cede ao usuário. Sem polling, sem condições de saída explícitas.

Um Exemplo Mínimo

Em .NET, construir um fluxo de trabalho handoff fica assim:

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triagem pode enviar para qualquer especialista. Ambos os especialistas podem enviar de volta para triagem. O grafo é compatível com acíclico, mas suporta arestas de retorno quando você as precisa (“preciso de mais informações” → de volta à pesquisa).

Quando Usar Handoff (e Quando Não)

Handoff é uma boa escolha quando:

A propriedade pode mudar no meio da conversa — um agente pode perceber que é o especialista errado
Arestas de retorno importam — você pode precisar revisitar um passo anterior sem reiniciar
As decisões de roteamento são difusas — a decisão de fazer handoff é contextual e melhor tomada pelo modelo do que por predicados tipados

Não é a escolha certa quando:

Seu pipeline é fixo e sequencial — use o fluxo de trabalho Sequential para isso
Cada passo é independente — agentes compartilhando uma transcrição onde apenas um deles precisava dela é apenas ruído
Você precisa de garantias rígidas de processamento — o não-determinismo do roteamento orientado por modelo não é o que você quer

Arestas de Retorno e Human-in-the-Loop

Uma das formas mais interessantes que o Handoff permite são as arestas de retorno genuínas. Um agente pode decidir “não tenho informações suficientes” e rotear de volta para um passo de pesquisa, não com um loop codificado, mas porque o modelo decide que é a decisão certa.

As interações human-in-the-loop também se compõem naturalmente. Quando um especialista precisa de entrada do usuário, o fluxo de trabalho cede de volta ao usuário via o loop de turno padrão, coleta a resposta e retoma com contexto completo. O agente nunca perdeu a conversa.

Conclusão

Handoff é um desses padrões que parece simples, mas permite muito uma vez que você o internaliza: roteamento descentralizado, contexto compartilhado, topologia aplicada, terminação natural. É o próximo passo certo quando seus agentes começam a dizer “na verdade, alguém mais deveria lidar com isso.”

Leia o passo a passo completo no post original: A Tour of the Handoff Orchestration Pattern

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

Seu Agente MAF Local Acabou de Ganhar um Lar em Produção

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Fazer um agente funcionar localmente é a parte divertida. A parte complicada é tudo que vem depois: implantá-lo sem enlouquecer, gerenciar sessões, configurar identidade, conectar observabilidade. Normalmente isso significa muita infraestrutura personalizada.

O Foundry Hosted Agents acabou de remover a maior parte dessa infraestrutura para usuários do Microsoft Agent Framework (MAF).

O Que o Foundry Hosted Agents Realmente Faz

Quando você implanta um agente MAF no Foundry Hosted Agents, a plataforma lida com uma lista surpreendentemente longa de coisas que você teria que construir por conta própria:

Escalar para zero — seu agente não custa nada quando ocioso e volta automaticamente
Sandboxes isolados por VM por sessão — cada sessão de usuário tem seu próprio sandbox com persistência do sistema de arquivos que sobrevive a eventos de redução de escala
Entra ID integrado — cada agente tem sua própria identidade para chamar modelos Foundry, Toolbox e serviços Azure sem segredos na imagem
Implantações versionadas — cada implantação é um snapshot imutável, com suporte a blue/green e canary rollout
Observabilidade sem configuração — APPLICATIONINSIGHTS_CONNECTION_STRING é injetado em tempo de execução para que os traces OpenTelemetry do MAF fluam automaticamente para o App Insights

Esse último é genuinamente agradável. Sem fiação extra, sem configuração adicional. Os traces simplesmente aparecem.

A Diferença no Código É Mínima

Isso é o que mais aprecio nessa integração. Você não reescreve seu agente. Você simplesmente o envolve:

Em .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

Em Python:

server = ResponsesHostServer(agent)
server.run()

É isso. A mesma lógica que você testou localmente é o que roda em produção. A plataforma a envolve na infraestrutura de gerenciamento de sessões, identidade e escalamento.

Dois Protocolos, Um Agente

Os Hosted Agents suportam dois estilos de endpoints:

Responses (/responses) — compatível com OpenAI, gerencia histórico de conversas e streaming. Bom padrão para agentes em forma de chat.
Invocations (/invocations) — você define o esquema de requisição/resposta. Bom para workflows não conversacionais.

Se você está construindo algo que parece uma conversa, comece com Responses. Se está construindo um agente em forma de API que recebe entrada estruturada e retorna saída estruturada, Invocations te dá a flexibilidade.

O Fluxo de Implantação com `azd`

Quando você executa azd up com um agente MAF:

Opcionalmente cria um projeto Foundry e implanta um modelo
Empacota seu código e envia uma imagem para o Azure Container Registry
Provisiona compute a partir da imagem ACR
Atribui um Entra ID dedicado ao agente
Expõe um endpoint estável (https://{project_endpoint}/agents/{agent_name})
Lida com tudo mais a partir desse ponto

As sessões persistem por até 30 dias. O compute ocioso é desprovisionado após 15 minutos e restaurado transparentemente na próxima requisição. Da perspectiva do agente, nada mudou.

Conclusão

A distância entre “funcionando localmente” e “rodando em produção” tem sido historicamente longa e dolorosa para agentes de IA. Foundry Hosted Agents + MAF fecha essa lacuna significativamente. Se você já tem um agente local construído com Agent Framework, vale a pena tentar hoje.

A equipe diz que o GA está chegando em breve — atualmente está em preview. Confira os docs de integração MAF Hosted Agent e os exemplos .NET para começar.

Artigo original: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Construir Agentes É a Parte Fácil — Executá-los com Segurança É a Parte Difícil

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Existe um padrão no desenvolvimento de agentes de IA que comecei a chamar de “arrependimento de demo”. O agente funciona muito bem nas demos. Então alguém pergunta: o que acontece se ele chamar a ferramenta errada? E se acessar dados que não deveria? Quem auditou isso?

Microsoft Agent Framework te apoia na construção e orquestração. Agent Governance Toolkit (AGT) cobre a parte posterior — governança, aplicação de políticas e auditabilidade em tempo de execução.

O Que Cada Projeto Realmente Faz

Microsoft Agent Framework (MAF) fornece o modelo de programação: workflows multi-agente, interoperabilidade do protocolo A2A, hooks de middleware, memória e hospedagem gerenciada via Foundry Agent Service. Lida com segurança de conteúdo no nível de entrada/saída do modelo.

Agent Governance Toolkit (AGT) se conecta a esse mesmo pipeline de middleware para governar ações. Cada chamada de ferramenta, acesso a recursos e mensagem inter-agentes é avaliada contra a política antes da execução. Overhead submilissegundo. Sem sidecars, sem proxies, sem prompts modificados.

Ação do Agente --> Verificação de Política --> Permitir / Negar --> Log de Auditoria (< 0.1 ms)

Camadas diferentes, cobertura completa, um pipeline.

Conectar-se É Apenas Adicionar Middleware

Em Python, o AGT adiciona ao mesmo parâmetro middleware que você usaria para registro ou filtros de conteúdo:

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

Em .NET, mesmo padrão via .Use():

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

Mesmo agente, mesma orquestração, mesmas ferramentas. O AGT adiciona capacidades de governança sem tocar na lógica do agente.

O Que Você Obtém

GovernancePolicyMiddleware — avalia cada ação contra regras de política declarativas
CapabilityGuardMiddleware — lista de permissão das ferramentas que um agente pode chamar (a ferramenta approve_small_loan não está na lista permitida acima — deliberadamente)
RogueDetectionMiddleware — detecta padrões de comportamento anômalo em tempo de execução
AuditTrailMiddleware — log de auditoria encadeado com Merkle para que cada ação seja criptograficamente resistente a adulterações

Este último importa para conformidade. Uma cadeia Merkle significa que se alguém modificar o log, a cadeia quebra. A auditoria é a evidência.

Cinco Cenários da Indústria

O repositório AGT inclui cinco cenários completos de ponta a ponta: serviços financeiros (agente de empréstimos), saúde (dados de pacientes), jurídico (revisão de contratos), governo (serviços ao cidadão) e manufatura (controle de qualidade). Cada um combina agentes MAF reais com middleware de governança AGT real.

Não são demos de brinquedo. São o tipo de cenários em que você realmente precisaria de governança em produção.

Conclusão

Se você está construindo agentes que tocam dados reais, tomam decisões com consequências, ou executam sem supervisão em produção — a governança não é opcional. A combinação MAF + AGT fornece o stack completo: construa com Agent Framework, governe com AGT.

Ambos os projetos são open source. O artigo original tem links para os exemplos de código completos.

Post original: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

A2A v1 Chegou: Comunicação Entre Agentes Cross-Platform no Microsoft Agent Framework para .NET

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

A2A v1 Chegou: Comunicação Entre Agentes Cross-Platform no Microsoft Agent Framework para .NET — o Protocolo A2A acaba de atingir v1.0, e os pacotes A2A Agent (cliente) e A2A Hosting (servidor) para .NET foram atualizados.

O que é Realmente A2A v1

A2A é um protocolo de interoperabilidade aberto para agentes de IA apoiado por um comitê diretor técnico com representantes da AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP e ServiceNow. O rótulo v1 significa que agora é um padrão estável e pronto para produção. Os pacotes SDK e Agent Framework que o implementam ainda estão em preview, mas o protocolo em si está bloqueado.

v1 melhora v0.3 com suporte multi-tenant, Agent Cards assinadas para identidade criptográfica, fluxos de segurança melhorados e uma arquitetura alinhada com a web.

Conectar-se a um Agente A2A Remoto

Um agente A2A remoto é simplesmente um AIAgent no seu código — mesmo RunAsync, mesmo streaming, mesmo gerenciamento de sessões:

// Descoberta via URI well-known
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));

// Configuração direta
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(name: "my-agent", description: "A helpful assistant.");

// O streaming funciona da mesma forma
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

Expor Seu Agente como Endpoint A2A

Qualquer AIAgent que você construiu — no Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic ou AWS Bedrock — pode ser exposto como endpoint A2A com duas linhas no ASP.NET Core:

builder.Services.AddKeyedSingleton<AIAgent>("weather-agent", (sp, _) => ...);
builder.AddA2AServer("weather-agent");

O cartão do agente é servido automaticamente em /.well-known/agent-card.json.

O que Isso Significa na Prática

O protocolo estável v1 significa que você pode conectar seus agentes .NET com agentes construídos em Python, Java ou qualquer outra linguagem sem se preocupar com mudanças que quebrem compatibilidade. A identidade criptográfica nas Agent Cards assinadas também fornece uma base para verificação de confiança entre agentes.

Veja o post completo para o changelog completo e notas de migração do v0.3.

CodeAct no Agent Framework: Como Reduzir a Latência do seu Agente pela Metade

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Existe aquele momento em todo projeto de agentes em que você olha para o trace e pensa: “por que isso está demorando tanto?” O modelo está ótimo. As ferramentas funcionam. Mas há sete round trips para obter um resultado que poderia ser calculado de uma só vez.

Esse é exatamente o problema que o CodeAct resolve — e a equipe do Agent Framework acabou de lançar suporte alpha via o novo pacote agent-framework-hyperlight.

O que é CodeAct?

O padrão CodeAct é elegantemente simples: em vez de dar ao modelo uma lista de ferramentas para chamar uma por uma, você dá a ele uma única ferramenta execute_code e deixa-o expressar o plano completo como um curto programa Python. O agente escreve o código uma vez, o sandbox o executa, e você recebe de volta um único resultado consolidado.

Fiação	Tempo	Tokens
Tradicional	27,81s	6.890
CodeAct	13,23s	2.489
Melhoria	52,4%	63,9%

A peça de segurança: Micro-VMs do Hyperlight

O pacote agent-framework-hyperlight usa micro-VMs do Hyperlight. Cada chamada execute_code obtém sua própria micro-VM recém-criada. A inicialização é medida em milissegundos. O isolamento é essencialmente gratuito.

Suas ferramentas continuam sendo executadas no host. O código de cola gerado pelo modelo é executado no sandbox. Essa é a divisão correta.

Configuração mínima

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Quando usar o CodeAct (e quando não usar)

Use o CodeAct quando:

A tarefa encadeia muitas chamadas pequenas de ferramentas (lookups, joins, cálculos)
A latência e o custo de tokens importam
Você quer isolamento forte por chamada no código gerado pelo modelo

Fique com o tool-calling tradicional quando:

O agente só faz uma ou duas chamadas de ferramentas por turno
Cada chamada tem efeitos colaterais a serem aprovados individualmente
As descrições de ferramentas são esparsas ou ambíguas

Experimente agora

pip install agent-framework-hyperlight --pre

Confira o post completo no blog do Agent Framework para uma cobertura mais profunda.

GPT-5.5 Chegou ao Azure Foundry — O que Desenvolvedores .NET Precisam Saber

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

A Microsoft acaba de anunciar que GPT-5.5 está geralmente disponível no Microsoft Foundry. Se você tem construído agentes no Azure, esta é a atualização que você estava esperando.

A progressão do GPT-5

GPT-5: unificou raciocínio e velocidade em um único sistema
GPT-5.4: raciocínio multi-etapas mais sólido, capacidades agênticas para empresas
GPT-5.5: raciocínio de contexto longo mais profundo, execução agêntica mais confiável, maior eficiência de tokens

O que realmente mudou

Codificação agêntica aprimorada: GPT-5.5 mantém contexto em grandes bases de código, diagnostica falhas arquiteturais e antecipa requisitos de testes. O modelo raciocina sobre o que mais uma correção afeta antes de agir.

Eficiência de tokens: Saídas de maior qualidade com menos tokens e menos tentativas. Custo e latência diretamente menores em produção.

Análise de contexto longo: Lida com documentos extensos e históricos multi-sessão sem perder o fio.

Preços

Modelo	Entrada ($/M tokens)	Entrada em cache	Saída ($/M tokens)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Por que o Foundry importa

O Foundry Agent Service permite definir agentes em YAML ou conectá-los com Microsoft Agent Framework, GitHub Copilot SDK, LangGraph ou OpenAI Agents SDK — e executá-los como agentes hospedados isolados com sistema de arquivos persistente, identidade Microsoft Entra e preços de escala a zero.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Você é um assistente útil.", name: "MeuAgente");

Veja o anúncio completo para todos os detalhes.

Onde seu Agente se Lembra das Coisas? Guia Prático de Armazenamento do Histórico de Chat

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Ao criar um agente IA, você gasta a maior parte da energia no modelo, nas ferramentas e nos prompts. A pergunta de onde vive o histórico de conversa parece um detalhe de implementação — mas é uma das decisões arquiteturais mais importantes que você tomará.

Ela determina se usuários podem bifurcar conversas, desfazer respostas, retomar sessões após uma reinicialização e se seus dados saem da sua infraestrutura. A equipe do Agent Framework publicou uma análise aprofundada.

Dois padrões fundamentais

Gerenciado pelo serviço: o serviço IA armazena o estado da conversa. Seu app mantém uma referência e o serviço inclui automaticamente o histórico relevante em cada requisição.

Gerenciado pelo cliente: seu app mantém o histórico completo e envia mensagens relevantes com cada requisição. O serviço é stateless. Você controla tudo.

Como o Agent Framework abstrai isso

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Meu nome é Alice.", session);
var second = await agent.RunAsync("Qual é o meu nome?", session);

session = agent.create_session()
first = await agent.run("Meu nome é Alice.", session=session)
second = await agent.run("Qual é o meu nome?", session=session)

Referência rápida de provedores

Provedor	Armazenamento	Modelo	Compactação
OpenAI/Azure Chat Completions	Cliente	N/A	Você
Foundry Agent Service	Serviço	Linear	Serviço
Responses API (padrão)	Serviço	Ramificável	Serviço
Anthropic Claude, Ollama	Cliente	N/A	Você

Como escolher

Precisa de ramificação ou “desfazer”? → Responses API gerenciado pelo serviço
Precisa de soberania de dados? → Gerenciado pelo cliente com provedor de banco de dados
É um chatbot simples? → Gerenciado pelo serviço linear está ótimo

Leia o post completo para a árvore de decisão completa.

As Agent Skills no .NET ficaram realmente flexíveis

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

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

Se você tem construído agentes com o Microsoft Agent Framework, já conhece o processo: define skills, conecta a um provider e deixa o agente decidir qual invocar. O que há de novo é como você cria essas skills — e o salto em flexibilidade é significativo.

A última atualização introduz três padrões de autoria para agent skills: baseadas em arquivos, baseadas em classes e definidas em código inline. As três se conectam a um único AgentSkillsProviderBuilder, o que significa que você pode misturar e combinar sem lógica de roteamento nem código especial. Vou te mostrar cada uma e quando usar.

Skills baseadas em arquivos: o ponto de partida

Skills baseadas em arquivos são exatamente o que parecem — um diretório no disco com um arquivo SKILL.md, scripts opcionais e documentos de referência. A forma mais direta de dar novas capacidades ao seu agente:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

O frontmatter do SKILL.md declara o nome e descrição, e a seção de instruções diz ao agente como usar os scripts e referências:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Depois você conecta com SubprocessScriptRunner.RunAsync para execução de scripts:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

O agente descobre a skill automaticamente e invoca o script de provisioning quando precisa verificar o status das contas. Limpo e simples.

Skills baseadas em classes: distribuir via NuGet

Aqui é onde fica interessante para times. Skills baseadas em classes derivam de AgentClassSkill<T> e usam atributos como [AgentSkillResource] e [AgentSkillScript] para que o framework descubra tudo por reflexão:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

O legal é que um time pode empacotar isso como pacote NuGet. Você adiciona ao projeto, coloca no builder e funciona junto com suas skills de arquivo sem coordenação:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Ambas as skills aparecem no system prompt do agente. O agente decide qual usar baseado na conversa — sem código de roteamento.

Skills inline: a ponte rápida

Sabe aquele momento quando outro time está construindo exatamente a skill que você precisa, mas só vai ficar pronta no próximo sprint? AgentInlineSkill é sua ponte:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Adicione ao builder assim como as outras:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Quando o pacote NuGet finalmente sair, você troca a skill inline pela versão baseada em classe. O agente não percebe a diferença.

Mas skills inline não são só para pontes. Também são a escolha certa quando você precisa gerar skills dinamicamente em runtime — pense em uma skill por unidade de negócio carregada de configuração — ou quando um script precisa capturar estado local que não pertence a um contêiner DI.

Aprovação de scripts: humano no loop

Para nós desenvolvedores .NET construindo agentes de produção, essa é a parte que realmente desbloqueia conversas de deploy. Alguns scripts têm consequências reais — inscrever alguém em benefícios, consultar infraestrutura de produção. Ative UseScriptApproval e o agente pausa antes de executar qualquer script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Quando o agente quer executar um script, retorna um pedido de aprovação. Seu app coleta a decisão — aprovar ou rejeitar — e o agente continua. Em ambientes regulados, essa é a diferença entre “podemos fazer deploy disso” e “o jurídico disse não.”

Por que essa combinação importa

O verdadeiro poder não está em nenhum padrão individual — está na composição. Você pode:

Começar pequeno com uma skill de arquivo, iterar nas instruções e publicar sem escrever C#
Distribuir skills reutilizáveis como pacotes NuGet que outros times adicionam com uma linha
Cobrir lacunas com skills inline quando precisa de algo agora
Filtrar diretórios compartilhados com predicados para que seu agente só carregue o que deve
Adicionar supervisão humana para scripts que tocam sistemas de produção

Tudo isso se compõe via AgentSkillsProviderBuilder. Sem roteamento especial, sem lógica condicional, sem verificações de tipo de skill.

Para encerrar

As agent skills no .NET agora têm um modelo de autoria genuinamente flexível. Seja você um desenvolvedor solo prototipando com skills de arquivo ou um time enterprise distribuindo capacidades empacotadas via NuGet, os padrões se encaixam. E o mecanismo de aprovação de scripts o torna pronto para produção em ambientes onde você precisa daquele checkpoint humano.

Confira o anúncio original, a documentação de Agent Skills no Microsoft Learn e os exemplos .NET no GitHub para começar.

Construindo UIs Multi-Agente em Tempo Real Que Não Parecem uma Caixa Preta

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

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

A questão com sistemas multi-agente é a seguinte: eles ficam incríveis nas demos. Três agentes passando trabalho entre si, resolvendo problemas, tomando decisões. Aí você tenta colocar na frente de usuários reais e… silêncio. Um indicador girando. Nenhuma ideia de qual agente está fazendo o quê ou por que o sistema pausou. Isso não é um produto — é um problema de confiança.

O time do Microsoft Agent Framework acabou de publicar um tutorial fantástico sobre como combinar fluxos MAF com AG-UI, um protocolo aberto para transmitir eventos de execução de agentes para um frontend via Server-Sent Events. E sinceramente? Essa é a ponte que estava faltando.

Por que isso importa para desenvolvedores .NET

Se você está construindo apps com IA, provavelmente já bateu nesse muro. Sua orquestração backend funciona perfeitamente — agentes passam tarefas entre si, ferramentas disparam, decisões são tomadas. Mas o frontend não faz ideia do que está acontecendo nos bastidores. AG-UI resolve isso definindo um protocolo padrão para transmitir eventos de agentes (pense em RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) diretamente para sua camada de UI via SSE.

A demo que construíram é um fluxo de suporte ao cliente com três agentes: um agente de triagem que roteia solicitações, um agente de reembolso que cuida de questões financeiras, e um agente de pedidos que gerencia substituições. Cada agente tem suas próprias ferramentas, e a topologia de handoff é definida explicitamente — nada de “descubra a partir do prompt”.

A topologia de handoff é a verdadeira estrela

O que me chamou a atenção é como o HandoffBuilder permite declarar um grafo dirigido de roteamento entre agentes:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Cada add_handoff cria uma aresta dirigida com uma descrição em linguagem natural. O framework gera ferramentas de handoff para cada agente baseado nessa topologia. Então as decisões de roteamento são fundamentadas na sua estrutura de orquestração, não apenas no que o LLM resolve fazer. Isso é enorme para confiabilidade em produção.

Human-in-the-loop que realmente funciona

A demo mostra dois padrões de interrupção que qualquer app de agentes do mundo real precisa:

Interrupções de aprovação de ferramentas — quando um agente chama uma ferramenta marcada com approval_mode="always_require", o fluxo pausa e emite um evento. O frontend renderiza um modal de aprovação com o nome da ferramenta e seus argumentos. Sem loops de retry queimando tokens — apenas um fluxo limpo de pausa-aprovação-retomada.

Interrupções de solicitação de informação — quando um agente precisa de mais contexto do usuário (como um ID de pedido), ele pausa e pergunta. O frontend mostra a pergunta, o usuário responde, e a execução retoma exatamente de onde parou.

Ambos os padrões são transmitidos como eventos AG-UI padrão, então seu frontend não precisa de lógica personalizada por agente — simplesmente renderiza qualquer evento que chegue pela conexão SSE.

Conectar tudo é surpreendentemente simples

A integração entre MAF e AG-UI é uma única chamada de função:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

O workflow_factory cria um fluxo novo por thread, então cada conversa tem estado isolado. O endpoint cuida de toda a tubulação SSE automaticamente. Se você já usa FastAPI (ou pode adicioná-lo como uma camada leve), isso tem praticamente zero fricção.

Minha opinião

Para nós desenvolvedores .NET, a pergunta imediata é: “Posso fazer isso em C#?” O Agent Framework está disponível para .NET e Python, e o protocolo AG-UI é agnóstico de linguagem (é apenas SSE). Então embora essa demo específica use Python e FastAPI, o padrão se traduz diretamente. Você poderia montar uma API mínima ASP.NET Core com endpoints SSE seguindo o mesmo schema de eventos AG-UI.

A conclusão mais importante é que UIs multi-agente estão se tornando uma preocupação de primeira classe, não algo deixado para depois. Se você está construindo qualquer coisa onde agentes interagem com humanos — suporte ao cliente, fluxos de aprovação, processamento de documentos — essa combinação de orquestração MAF e transparência AG-UI é o padrão a seguir.

Concluindo

AG-UI + Microsoft Agent Framework te dá o melhor dos dois mundos: orquestração multi-agente robusta no backend e visibilidade em tempo real no frontend. Sem mais interações de agentes como caixas pretas.

Confira o tutorial completo e o repositório do protocolo AG-UI para se aprofundar.

Microsoft Agent Framework Chega à 1.0 — Eis O Que Realmente Importa para Desenvolvedores .NET

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

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

Se você tem acompanhado a jornada do Agent Framework desde os primeiros dias do Semantic Kernel e AutoGen, este é significativo. O Microsoft Agent Framework acabou de chegar à versão 1.0 — pronto para produção, APIs estáveis, compromisso de suporte de longo prazo. Está disponível tanto para .NET quanto para Python, e está genuinamente pronto para cargas de trabalho reais.

Vou cortar o ruído do anúncio e focar no que importa se você está construindo apps com IA usando .NET.

A versão curta

Agent Framework 1.0 unifica o que costumava ser Semantic Kernel e AutoGen em um único SDK open source. Uma abstração de agente. Um motor de orquestração. Múltiplos provedores de IA. Se você estava alternando entre Semantic Kernel para padrões enterprise e AutoGen para workflows multi-agente de nível pesquisa, pode parar. Este é o único SDK agora.

Começar é quase injustamente simples

Aqui está um agente funcional em .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

É isso. Um punhado de linhas e você tem um agente de IA rodando contra o Azure Foundry. O equivalente em Python é igualmente conciso. Adicione ferramentas de funções, conversas multi-turno e streaming conforme avança — a superfície da API escala sem ficar estranha.

Orquestração multi-agente — isso é pra valer

Agentes individuais são bons para demos, mas cenários de produção geralmente precisam de coordenação. Agent Framework 1.0 vem com padrões de orquestração testados em batalha diretamente da Microsoft Research e AutoGen:

Sequencial — agentes processam em ordem (escritor → revisor → editor)
Concorrente — distribui para múltiplos agentes em paralelo, converge resultados
Handoff — um agente delega para outro baseado na intenção
Chat em grupo — múltiplos agentes discutem e convergem para uma solução
Magentic-One — o padrão multi-agente de nível pesquisa do MSR

Todos suportam streaming, checkpointing, aprovações com humano no loop, e pausa/retomada. A parte de checkpointing é crucial — workflows de longa duração sobrevivem a reinícios de processo. Para nós desenvolvedores .NET que construímos workflows duráveis com Azure Functions, isso é familiar.

As funcionalidades que mais importam

Aqui está minha lista do que vale a pena saber:

Hooks de middleware. Sabe como o ASP.NET Core tem pipelines de middleware? Mesmo conceito, mas para execução de agentes. Intercepte cada estágio — adicione segurança de conteúdo, logging, políticas de compliance — sem tocar nos prompts do agente. É assim que você torna agentes prontos para enterprise.

Memória plugável. Histórico conversacional, estado persistente chave-valor, recuperação baseada em vetores. Escolha seu backend: Foundry Agent Service, Mem0, Redis, Neo4j, ou crie o seu próprio. Memória é o que transforma uma chamada LLM sem estado em um agente que realmente lembra do contexto.

Agentes YAML declarativos. Defina as instruções do seu agente, ferramentas, memória e topologia de orquestração em arquivos YAML versionados. Carregue e execute com uma única chamada de API. Isso é um divisor de águas para equipes que querem iterar no comportamento do agente sem reimplantar código.

Suporte A2A e MCP. MCP (Model Context Protocol) permite que agentes descubram e invoquem ferramentas externas dinamicamente. A2A (protocolo Agent-to-Agent) habilita colaboração entre runtimes — seus agentes .NET podem se coordenar com agentes rodando em outros frameworks. O suporte ao A2A 1.0 está chegando em breve.

As funcionalidades em preview que valem acompanhar

Algumas funcionalidades foram lançadas como preview na 1.0 — funcionais mas as APIs podem evoluir:

DevUI — um depurador local baseado em navegador para visualizar a execução do agente, fluxos de mensagens e chamadas de ferramentas em tempo real. Pense no Application Insights, mas para o raciocínio do agente.
GitHub Copilot SDK e Claude Code SDK — use o Copilot ou Claude como harness de agente diretamente do seu código de orquestração. Componha um agente capaz de programar ao lado dos seus outros agentes no mesmo workflow.
Agent Harness — um runtime local customizável que dá aos agentes acesso a shell, sistema de arquivos e loops de mensagens. Pense em agentes de código e padrões de automação.
Skills — pacotes reutilizáveis de capacidades de domínio que dão aos agentes capacidades estruturadas prontas para uso.

Migrando do Semantic Kernel ou AutoGen

Se você tem código existente de Semantic Kernel ou AutoGen, existem assistentes de migração dedicados que analisam seu código e geram planos de migração passo a passo. O guia de migração do Semantic Kernel e o guia de migração do AutoGen te guiam por tudo.

Se você estava nos pacotes RC, atualizar para 1.0 é apenas uma mudança de versão.

Finalizando

Agent Framework 1.0 é o marco de produção que as equipes enterprise estavam esperando. APIs estáveis, suporte multi-provedor, padrões de orquestração que realmente funcionam em escala, e caminhos de migração tanto do Semantic Kernel quanto do AutoGen.

O framework é totalmente open source no GitHub, e você pode começar hoje com dotnet add package Microsoft.Agents.AI. Confira o guia de início rápido e os exemplos para colocar a mão na massa.

Se você estava esperando o sinal de “seguro para usar em produção” — é este.

Respostas em segundo plano no Microsoft Agent Framework: chega de ansiedade com timeouts

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Se você já construiu algo com modelos de raciocínio como o3 ou GPT-5.2, conhece a dor. Seu agente começa a pensar numa tarefa complexa, o cliente fica esperando, e em algum ponto entre “tá tudo bem” e “será que travou?” sua conexão expira por timeout. Todo aquele trabalho? Perdido.

O Microsoft Agent Framework acabou de lançar respostas em segundo plano — e honestamente, essa é uma daquelas funcionalidades que deveria ter existido desde o primeiro dia.

O problema com chamadas bloqueantes

Num padrão tradicional de requisição-resposta, seu cliente bloqueia até o agente terminar. Funciona bem para tarefas rápidas. Mas quando você pede a um modelo de raciocínio que faça pesquisa profunda, análise em múltiplas etapas, ou gere um relatório de 20 páginas? São minutos de tempo real. Durante essa janela:

Conexões HTTP podem expirar
Quedas de rede matam toda a operação
Seu usuário fica olhando um spinner se perguntando se algo está acontecendo

Respostas em segundo plano invertem isso completamente.

Como os tokens de continuação funcionam

Em vez de bloquear, você dispara a tarefa do agente e recebe um token de continuação. Pense nisso como um ticket de retirada numa oficina — você não fica parado no balcão esperando, volta quando está pronto.

O fluxo é direto:

Envie sua requisição com AllowBackgroundResponses = true
Se o agente suporta processamento em segundo plano, você recebe um token de continuação
Consulte no seu ritmo até o token retornar null — isso significa que o resultado está pronto

Aqui está a versão .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Consultar até completar
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Se o agente completa imediatamente (tarefas simples, modelos que não precisam de processamento em segundo plano), nenhum token de continuação é retornado. Seu código simplesmente funciona — sem tratamento especial necessário.

Streaming com retomada: a verdadeira mágica

Polling é bom para cenários de disparar e esquecer, mas e quando você quer progresso em tempo real? Respostas em segundo plano também suportam streaming com retomada embutida.

Cada atualização do stream carrega seu próprio token de continuação. Se sua conexão cair no meio do stream, você retoma exatamente de onde parou:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simular uma interrupção de rede
}

// Retomar exatamente de onde paramos
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

O agente continua processando no servidor independentemente do que aconteça com seu cliente. Isso é tolerância a falhas embutida sem que você escreva lógica de retry ou circuit breakers.

Quando realmente usar isso

Nem toda chamada ao agente precisa de respostas em segundo plano. Para completações rápidas, você está adicionando complexidade sem razão. Mas aqui é onde elas brilham:

Tarefas de raciocínio complexo — análise em múltiplas etapas, pesquisa profunda, qualquer coisa que faça um modelo de raciocínio realmente pensar
Geração de conteúdo longo — relatórios detalhados, documentos de múltiplas partes, análises extensas
Redes pouco confiáveis — clientes móveis, deployments no edge, VPNs corporativas instáveis
Padrões UX assíncronos — envie uma tarefa, vá fazer outra coisa, volte para os resultados

Para nós desenvolvedores .NET construindo apps empresariais, esse último é particularmente interessante. Pense numa app Blazor onde um usuário solicita um relatório complexo — você dispara a tarefa do agente, mostra um indicador de progresso, e os deixa continuar trabalhando. Sem ginástica de WebSocket, sem infraestrutura de filas personalizada, apenas um token e um loop de polling.

Para finalizar

Respostas em segundo plano estão disponíveis agora tanto em .NET quanto em Python através do Microsoft Agent Framework. Se você está construindo agentes que fazem algo mais complexo que simples Q&A, vale a pena adicionar isso ao seu toolkit. O padrão de token de continuação mantém as coisas simples enquanto resolve um problema de produção muito real.

Confira a documentação completa para a referência completa da API e mais exemplos.

Agent-Framework | The .NET Blog

Microsoft Foundry Abril 2026: Foundry Local GA, GPT-5.5, CodeAct com Hyperlight

Foundry Local está Geralmente Disponível

GPT-5.5

Rastreamento do Agent Framework no Foundry

CodeAct com Hyperlight (Alpha)

Painel de Monitoramento de Agentes (Preview)

Avaliadores Personalizados de Avaliação Contínua (Preview)

Inventário de Agentes no Plano de Controle

O Padrão Handoff: Quando Um Agente Não É Suficiente

Como Handoff Funciona

Um Exemplo Mínimo

Quando Usar Handoff (e Quando Não)

Arestas de Retorno e Human-in-the-Loop

Conclusão

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

Os Blocos de Construção Fundamentais

O Runner In-Memory para Desenvolvimento Local

Adicionando Durabilidade com Durable Task

Hospedagem no Azure Functions

Por Que Isso Importa

Seu Agente MAF Local Acabou de Ganhar um Lar em Produção

O Que o Foundry Hosted Agents Realmente Faz

A Diferença no Código É Mínima

Dois Protocolos, Um Agente

O Fluxo de Implantação com azd

Conclusão

Construir Agentes É a Parte Fácil — Executá-los com Segurança É a Parte Difícil

O Que Cada Projeto Realmente Faz

Conectar-se É Apenas Adicionar Middleware

O Que Você Obtém

Cinco Cenários da Indústria

Conclusão

A2A v1 Chegou: Comunicação Entre Agentes Cross-Platform no Microsoft Agent Framework para .NET

O que é Realmente A2A v1

Conectar-se a um Agente A2A Remoto

Expor Seu Agente como Endpoint A2A

O que Isso Significa na Prática

CodeAct no Agent Framework: Como Reduzir a Latência do seu Agente pela Metade

O que é CodeAct?

A peça de segurança: Micro-VMs do Hyperlight

Configuração mínima

Quando usar o CodeAct (e quando não usar)

Experimente agora

GPT-5.5 Chegou ao Azure Foundry — O que Desenvolvedores .NET Precisam Saber

A progressão do GPT-5

O que realmente mudou

Preços

Por que o Foundry importa

Onde seu Agente se Lembra das Coisas? Guia Prático de Armazenamento do Histórico de Chat

Dois padrões fundamentais

Como o Agent Framework abstrai isso

Referência rápida de provedores

Como escolher

As Agent Skills no .NET ficaram realmente flexíveis

Skills baseadas em arquivos: o ponto de partida

Skills baseadas em classes: distribuir via NuGet

Skills inline: a ponte rápida

Aprovação de scripts: humano no loop

Por que essa combinação importa

Para encerrar

Construindo UIs Multi-Agente em Tempo Real Que Não Parecem uma Caixa Preta

Por que isso importa para desenvolvedores .NET

A topologia de handoff é a verdadeira estrela

Human-in-the-loop que realmente funciona

Conectar tudo é surpreendentemente simples

Minha opinião

Concluindo

Microsoft Agent Framework Chega à 1.0 — Eis O Que Realmente Importa para Desenvolvedores .NET

A versão curta

Começar é quase injustamente simples

Orquestração multi-agente — isso é pra valer

As funcionalidades que mais importam

As funcionalidades em preview que valem acompanhar

Migrando do Semantic Kernel ou AutoGen

Finalizando

Respostas em segundo plano no Microsoft Agent Framework: chega de ansiedade com timeouts

O problema com chamadas bloqueantes

Como os tokens de continuação funcionam

Streaming com retomada: a verdadeira mágica

O Fluxo de Implantação com `azd`