TL;DR: O Azure Functions agora oferece um runtime serverless dedicado para agentes de IA (preview). Com um modelo markdown-first, você define agentes em arquivos .agent.md, declarando triggers e instruções em linguagem natural. A plataforma elimina a complexidade de conectar frameworks, filas, identidade e observabilidade, aproveitando o ecossistema Azure Functions (triggers, scale-to-zero, managed identity). Para empresas brasileiras, isso pode acelerar a criação de agentes de chat, monitores e automações cross-system com economia operacional.
A Microsoft anunciou o Azure Functions serverless agents runtime, agora em public preview. Ele traz um novo modelo de programação markdown-first para construir agentes de IA como workload de primeira classe no Azure Functions, com os triggers event-driven, economia scale-to-zero e integrações operacionais que a plataforma já oferece.
Algumas coisas que você pode construir em minutos:
- Agente de briefing diário: acorda com um timer, varre a web e deixa um resumo na sua caixa de entrada do Outlook todas as manhãs.
- Agente de chat no Teams: dispara a cada mensagem e responde a perguntas do time, consultando dados em sistemas conectados.
- Agente de troubleshooting on-call: investiga incidentes consultando logs no Azure Data Explorer e reporta o que encontrou.
Cada um é um único arquivo markdown com instruções mais um trigger, implantado como qualquer function app no plano Flex Consumption.
Por que um runtime serverless para agentes?
Construir agentes em produção hoje geralmente significa juntar um framework, uma camada de hospedagem, filas de mensagens, identidade, secrets, observabilidade e uma longa lista de integrações por serviço. A maior parte desse trabalho é encanamento, não o agente em si.
O Azure Functions simplificou há anos o compute event-driven: declare um trigger, escreva o handler, ganhe autoscale e managed identity de graça. O serverless agents runtime aplica o mesmo modelo para agentes:
- Agentes são a unidade de trabalho: você define o comportamento em linguagem natural, não boilerplate.
- Triggers para quase qualquer evento: HTTP, timers, filas, mudanças no banco de dados, mensagens do Teams, e-mail do Outlook e muito mais.
- Ferramentas, servidores MCP, conectores e execução em sandbox são declarados, não codificados.
- Implante e opere como qualquer function app: Flex Consumption para scale-to-zero e faturamento por segundo, managed identity, integração com VNet, Application Insights e as mesmas ferramentas de deployment que você já usa.
Markdown-first: a aparência de um agente
Um agente é um arquivo .agent.md. Seu app pode ter vários agentes, cada um com metadados que declaram o trigger. O corpo markdown vira as instruções do agente.
Exemplo de agente com timer que resume notícias de tecnologia e envia por e-mail:
---
name: Daily Tech News Email
description: Fetches top tech news and emails a summary daily.
trigger:
type: timer_trigger
args:
schedule: "0 0 15 * * *"
---
You are a news assistant. When triggered, do the following:
1. Scour the web for today's top tech news headlines. Use reputable sources;
Include links to the original articles.
2. Summarize the top stories in a concise, well-formatted HTML email body.
3. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary"
followed by today's date.
É a função inteira. Coloque o arquivo no seu app, faça deploy e ele roda no schedule. Sem fiação de framework, sem código de integração específico de serviço.
Seus agentes podem compartilhar configurações e capacidades através de alguns arquivos junto com as definições dos agentes:
agents.config.yaml: declara ferramentas do sistema e o modelo padrão.mcp.json: lista os servidores MCP que seus agentes podem chamar, incluindo conexões Azure habilitadas para MCP./tools: pasta para ferramentas Python customizadas./skills: pasta para fragmentos de prompt reutilizáveis.
Neste exemplo, o agente usa uma sessão dinâmica do Container Apps para navegar na web com Playwright e uma conexão Microsoft Office 365 (exposta como servidor MCP) para enviar o e-mail:
# agents.config.yaml
system_tools:
dynamic_sessions_code_interpreter:
endpoint: $ACA_SESSION_POOL_ENDPOINT
model: $AZURE_OPENAI_DEPLOYMENT
// mcp.json
{
"servers": {
"office365": {
"type": "http",
"url": "$MICROSOFT_365_CONNECTION_MCP_ENDPOINT",
"auth": {
"scope": "https://apihub.azure.com/.default"
}
}
}
}
A managed identity da function app autentica no endpoint MCP da conexão — sem secrets para gerenciar. Qualquer conector Azure que suporte MCP, ou qualquer servidor MCP remoto, pode ser adicionado da mesma forma.
Essas configurações globais podem ser sobrescritas por agente nos metadados.
O que você obtém no preview
- Triggers de todo o catálogo do Azure Functions: HTTP, Timer, Queue, Service Bus, Event Hubs, Cosmos DB, Blob, Event Grid, mais novos triggers com suporte a conexões como Teams messages, Outlook mail e eventos de calendário.
- Mais de 1.400 conectores Azure como ferramentas: crie uma conexão, habilite seu endpoint MCP, e o agente pode enviar e-mail, postar no Teams, criar registros, consultar dados — tudo sem código de integração ou autenticação.
- Qualquer servidor MCP remoto como ferramenta: use qualquer servidor MCP externo.
- Código em sandbox e automação de navegador: execute código ou um navegador Playwright em sessões dinâmicas do Azure Container Apps, isolado por sessão do agente.
- Chat UI integrada, HTTP API e endpoint MCP sem código extra.
- Ferramentas Python customizadas na pasta
tools/e skills reutilizáveis na pastaskills/, compartilhadas entre agentes. - Provedores de modelo plugáveis: Microsoft Foundry, Azure OpenAI e OpenAI prontos para uso.
Onde isso se encaixa
O serverless agents runtime foi projetado para os agentes que a maioria das empresas realmente precisa construir:
- Agentes de background agendados: que resumem, monitoram ou reconciliam com timer.
- Assistentes orientados a eventos: que reagem a mensagens, e-mails, alertas e mudanças no banco de dados.
- Agentes cross-system: que integram múltiplos SaaS e apps corporativos através de conexões — gatilho com uma mensagem do Teams, consulta o cliente no Salesforce, envia e-mail e atualiza um registro no banco, tudo de um agente.
- Frontends conversacionais: que combinam um ponto de entrada HTTP ou chat-UI com os mesmos agentes que seus triggers de evento invocam.
- Agentes como servidores MCP: que outros agentes e clientes MCP podem integrar diretamente.
Queremos seu feedback
O serverless agents runtime está em public preview, e estamos construindo ativamente com base em workloads reais de clientes. Conte-nos o que você construir, o que está faltando e para onde o modelo deve ir.
Comece agora
Documentação: aka.ms/azure-functions-agents-docs
Perguntas Frequentes
-
Como funciona o modelo markdown-first?
Cada agente é um arquivo .agent.md com metadados YAML (trigger, schedule) e instruções em markdown. O runtime interpreta esse arquivo como a função inteira, sem necessidade de código boilerplate para frameworks ou integrações. -
Quais triggers estão disponíveis no preview?
HTTP, Timer, Queue, Service Bus, Event Hubs, Cosmos DB, Blob, Event Grid, Teams messages, Outlook mail e calendário. Triggers novos com suporte a conexões MCP. -
Como a segurança é tratada com managed identity?
A function app usa managed identity para autenticar nos endpoints MCP dos conectores Azure – não há necessidade de gerenciar secrets manualmente. Isso reduz riscos e simplifica a governança. -
O que são MCP servers nesse contexto?
MCP (Model Context Protocol) servers são endpoints que expõem ferramentas para os agentes. No runtime, você declara servidores MCP remotos ou conectores Azure (como Office 365) em um arquivo mcp.json, permitindo que agentes enviem e-mails, postem no Teams, consultem dados, etc., sem código de integração. -
Qual a principal diferença para frameworks tradicionais como LangChain?
Frameworks tradicionais exigem que você monte manualmente a camada de hospedagem, filas, identidade e observabilidade. O serverless agents runtime incorpora tudo isso nativamente (autoscale, billing por segundo, Application Insights, VNet), deixando você focar apenas na lógica do agente em markdown.
Artigo originalmente publicado por Anthony Chu em Azure Updates - Latest from Azure Charts.
