BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Azure Functions Ships Serverless Agents Runtime at Build 2026

Azure Functions Ships Serverless Agents Runtime at Build 2026

Listen to this article -  0:00

Microsoft announced the Azure Functions serverless agents runtime in public preview at Build 2026, turning the event-driven compute service into a platform for building and hosting AI agents.

The headline change: agents are defined in .agent.md files, a markdown-first programming model in which an agent's instructions, tools, connections, and behavior are declared in a single readable document rather than scattered across code files. Any Azure Functions trigger can now spawn an agent: HTTP, Timer, Service Bus, Event Hubs, SQL, Cosmos DB, or the new connection-backed triggers for Teams messages, Outlook mail, calendar events, and SharePoint items.

The Azure Functions team writes:

Azure Functions now has a first-class programming model for AI agents. Agents get access to MCP tool servers, sandboxed code, and browser execution via Azure Container Apps dynamic sessions, and the full 1,400+ connector catalog. Built-in surfaces like chat UI, HTTP chat API, and MCP server endpoint are opt-in with no extra code.

The operational model stays exactly what Functions developers already know. Flex Consumption handles scale-to-zero with per-second billing. Managed identity handles auth. Application Insights handles traces. The difference is what the function does when it wakes up: instead of processing a queue message or responding to an HTTP request, it runs an agent that can reason, call tools, invoke MCP servers, and interact with enterprise systems through 1,400+ managed connectors, including Microsoft 365, Teams, Outlook, SharePoint, Salesforce, and ServiceNow.

InfoQ asked the Azure Functions product team two questions that practitioners will immediately face. On cold start, the Functions team responded:

The agents runtime doesn't add any extra cold start beyond what you'd see with a regular HTTP trigger on Flex Consumption. The infra is not the bottleneck, the LLM is.

Agent execution latency comes from model invocation and prompt complexity, not from the serverless platform.

On cost, the team confirmed there is no "agents tax": it is billed as a standard function execution with scale-to-zero, identical to running any other function on Flex Consumption.

The .agent.md format is the most distinctive architectural choice. Where other agent frameworks define agents in Python or TypeScript, Azure Functions uses structured markdown that describes the agent's system prompt, available tools, MCP server connections, and trigger configuration in one file. A timer-triggered agent that summarizes daily tech news and emails it looks like this:

---
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.

YAML frontmatter declares the trigger and metadata. The markdown body becomes the agent's instructions. MCP servers and tools are declared in companion mcp.json and agents.config.yaml files. The runtime parses everything and handles orchestration, tool dispatch, and response generation. A timer-triggered agent that summarizes daily tech news and emails it is a single .agent.md file, not a Python project with dependencies and boilerplate.

Microsoft is dogfooding the runtime internally. Thiago Almeida, Principal Program Manager from Azure Functions, told InfoQ:

The Azure Functions team built a timer-triggered .agent.md agent that continuously audits security posture across all of its GitHub organizations and repositories. On each scheduled run, it reasons over branch protection, secret scanning, and workflow permissions across every repo, then reports findings through the same connectors and MCP tool servers any external agent would use. Because it runs on Flex Consumption, it costs nothing between runs.

The Build 2026 update shipped several other features alongside the agents runtime. The MCP extension reached GA, growing from a single tool trigger into full MCP server support with tool, resource, and prompt triggers across .NET, Java, Python, TypeScript, and JavaScript. Built-in OBO (On-Behalf-Of) authentication means MCP servers hosted on Functions inherit the caller's identity. Integration with Microsoft Foundry Toolbox is planned so that MCP servers published from Functions become automatically discoverable to Foundry agents.

Separately, Durable Task Scheduler got two notable updates. First, the scale validation: as Microsoft Copilot grew to support complex, long-running AI workflows, engineering teams standardized on Durable Task Scheduler in Azure Functions, unifying state management, retries, and recovery across services. The system now runs hundreds of millions of executions weekly. Second, On-demand Sandboxes (private preview) add isolated compute for individual orchestration steps. Each execution runs in a clean, microVM-backed sandbox. The use cases are concrete: native toolchains (ffmpeg, LibreOffice, Pandoc), CPU-heavy preprocessing like OCR, cross-runtime steps where a Python inference activity is called from a .NET orchestrator, and sandboxed execution of customer plugins or LLM-generated code.

Additional Build 2026 announcements include Go as a first-class language, Azure Functions Skills that let coding agents like Claude Code and GitHub Copilot leverage Functions expertise for scaffolding and debugging, built-in Grafana dashboards, rolling updates for Flex Consumption (now GA for zero-downtime deployments), and support for OS-level dependencies via containers on Flex Consumption.

The positioning within Azure's agent platform stack is now clear. Azure Functions targets code-first developers building agents in their preferred language. Logic Apps targets low-code integration workflows with a visual canvas and AI assistant. Azure API Management provides the governance layer across both, with unified model routing, content safety for MCP and A2A traffic, and enterprise token metrics. Almeida confirmed to InfoQ that this is deliberate:

The three-product frame, Functions for code-first, Logic Apps for low-code, APIM for governance, is exactly how we think about it, too.

The serverless agents runtime is in public preview. The MCP extension and Flex Consumption rolling updates are generally available.

About the Author

Rate this Article

Adoption
Style

BT