Azure Functions serverless agents runtime pune agenții AI pe Flex Consumption, cu scale-to-zero, facturare pe secundă și managed identity. Asta este partea interesantă. Nu markdown-ul. Nu povestea cu promptul într-un fișier. Valoarea reală este că Microsoft încearcă să transforme agenții din aplicații construite din multă infrastructură într-un workload serverless de primă clasă.
Cred că direcția este bună, cu două rezerve: este încă în preview, iar lucrurile devin rapid riscante dacă echipele tratează „1,400+ connectors” ca acces liber al agenților în tot tenantul.
Ce este Azure Functions serverless agents runtime?
Acest preview adaugă un nou model de programare pentru Azure Functions în care un agent este definit într-un fișier .agent.md, setările implicite ale aplicației stau în agents.config.yaml, iar serverele MCP remote sunt listate în mcp.json. Azure Functions descoperă aceste fișiere, înregistrează triggerul și endpointurile built-in opționale și rulează agentul când apare un eveniment.
Partea asta este reală și se potrivește bine cu modul în care multe echipe livrează deja automatizări: event-driven, observabile, cu identitate gestionată și ieftine când nu rulează. Dacă deja construiți Microsoft Copilot și AI agents, acesta este unul dintre cele mai curate modele de găzduire Azure-native pe care le-am văzut până acum.
Anunțul sursă surprinde corect forma de bază:
---
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.
Și conectarea tool-urilor este declarativă:
{
"servers": {
"office365": {
"type": "http",
"url": "$MICROSOFT_365_CONNECTION_MCP_ENDPOINT",
"auth": {
"scope": "https://apihub.azure.com/.default"
}
}
}
}
De ce este util în practică
Câștigul real nu este că prompturile stau în markdown. Câștigul real este că Azure Functions oferă deja piesele plictisitoare, dar necesare pentru producție: triggers, monitoring, managed identity, integrare VNet pe Flex Consumption și scalare serverless.
Documentația Microsoft confirmă și endpointuri built-in pentru chat UI, chat APIs și un endpoint MCP. Sunt utile pentru dezvoltare și diagnosticare. Eu le-aș trata ca suprafețe de conveniență, nu ca interfața principală a aplicației în producție.
Asta contează pentru echipele care construiesc automatizări de fundal sau event-driven, mai ales dacă altfel urma să lipiți manual queue listeners, clienți Azure OpenAI, secret storage, un web host și un strat ad hoc de tool-uri. Pentru genul acesta de lucru, se așază bine lângă AI workflow automation și chiar lângă o strategie de custom MCP servers.
Ce aș urmări înainte să am încredere în el
În primul rând, preview înseamnă preview. Documentația Microsoft spune explicit că funcțiile, numele de configurare și conectorii suportați se pot schimba înainte de GA. Dacă construiți ceva critic acum, așteptați-vă la drift.
În al doilea rând, modelul de securitate are nevoie de supraveghere serioasă. Managed identity este alegerea corectă implicit și este mult mai bună decât secrete împrăștiate prin configurații. Dar o managed identity cu acces larg este tot un cec în alb. Un agent nu ar trebui să poată posta în Teams, citi mail, actualiza înregistrări și accesa jumătate din sistemele line-of-business doar pentru că poate. Folosiți cel mai mic set posibil de servere MCP, tools și connections per aplicație și per agent.
În al treilea rând, costul este mai bun decât la multe platforme de agenți, dar nu devine automat ieftin. Facturarea Flex Consumption este în continuare bazată pe timp de execuție și număr de execuții, iar always-ready instances elimină free grant-ul. Exemplul Microsoft despre cost este un bun semnal de alarmă: același workload de 40 requests per second poate costa aproximativ 1.9296 USD pe oră când scalează la 10 instanțe active pentru lucru CPU-bound, față de aproximativ 0.245 USD pe oră când o singură instanță gestionează aceeași concurență pentru lucru IO-bound. Designul agentului, concurența și latența tool-urilor vor decide pe ce parte a liniei ajungeți.
Efectul de ordinul doi este important: odată ce echipele înțeleg că „agent apps” sunt de fapt Functions apps cu connectors, costurile se pot răspândi discret prin subscriptions dacă nimeni nu deține FinOps și access reviews.
Concluzia mea
Acesta este unul dintre anunțurile Azure despre agenți mai credibile, pentru că rezolvă hosting și operations, nu doar demo-uri. Dar astăzi este clar mixed: runtime promițător, model Azure-native sensat, maturitate de preview și un blast radius real de guvernanță dacă îl supraconectați.
Pentru majoritatea organizațiilor, eu l-aș pilota mai întâi pentru agenți programați și event-driven, aș ține permisiunile foarte înguste și aș evita să tratez suprafețele built-in de chat drept arhitectură de producție. Acolo pare util, nu doar teatru scump.
