Introducing the Azure Functions serverless agents runtime (preview)

AnthonyChu

Microsoft

Jun 02, 2026

A declarative markdown-first programming model for event-driven agents

We're thrilled to announce the Azure Functions serverless agents runtime, now in public preview. It brings a new, markdown-first programming model for building AI agents as a first-class workload on Azure Functions, with the event-driven triggers, scale-to-zero economics, and operational integrations you know and love from the platform.

A few things you could build in a matter of minutes:

A daily briefing agent that wakes up on a timer, scours the web, and drops a summary in your Outlook inbox every morning.
A Teams chat agent that triggers on every message and answers your team's questions, looking up data across your connected systems.
An on-call troubleshooting agent that investigates incidents by querying logs in Azure Data Explorer and reports back what it found.

Each one is a single markdown file with instructions plus a trigger, and deployed like any other function app and running on the Flex Consumption plan.

Why a serverless agents runtime

Building production agents today usually means stitching together a framework, a hosting layer, message queues, identity, secrets, observability, and a long list of per-service integrations. Most of that work is plumbing, not the agent.

Azure Functions has spent years making event-driven compute simple: declare a trigger, write the handler, get autoscale and managed identity for free. The serverless agents runtime applies that same model to agents:

Agents are the unit of work. You define behavior in natural language, not boilerplate.
Trigger agents from almost any event. HTTP requests, timers, queues, database changes, Teams messages, Outlook mail, and more.
Tools, MCP servers, connectors, and sandboxed execution are declared, not coded.
Deploy and operate like any function app. Flex Consumption for scale-to-zero and per-second billing, managed identity, VNet integration, Application Insights, and the same deployment tools you already use.

Markdown-first: what an agent looks like

An agent is a .agent.md file. Your app can have multiple agents, each with its own metadata that declares the trigger. The markdown body becomes the agent's instructions.

Here's a timer-triggered agent that summarizes the day's tech news and emails it:

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

That's the whole function. Drop the file into your app, deploy, and it runs on the schedule. No framework wiring, no service-specific integration code.

Your agents can share configuration and capabilities through a few files alongside the agent definitions. agents.config.yaml declares system tools and the default model. mcp.json lists the MCP servers your agents can call, including MCP-enabled Azure connections. A /tools folder holds custom Python tools and a /skills folder holds reusable prompt fragments. Everything here is optional and available to every agent automatically when present.

In this example, the agent uses a Container Apps dynamic session to browse the web with Playwright, and a Microsoft Office 365 connection (exposed as an MCP server) to send the email:

# 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"
      }
    }
  }
}

The function app's managed identity authenticates to the connection's MCP endpoint, so there are no secrets to manage. Any Azure connector that supports MCP, or any remote MCP server, can be added the same way.

Any of these global settings can be overridden per agent in the agent's metadata.

What you get in the preview

Triggers across the Azure Functions catalog. HTTP, Timer, Queue, Service Bus, Event Hubs, Cosmos DB, Blob, Event Grid, plus new connection-backed triggers like Teams messages, Outlook mail, and calendar events.
1,400+ Azure connectors as tools. Create a connection, enable its MCP endpoint, and an agent can send mail, post to Teams, create records, query data, all without integration code or auth plumbing.
Any remote MCP server as tools. Use any remote MCP server.
Sandboxed code and browser automation. Run code or a Playwright-powered browser in Azure Container Apps dynamic sessions, isolated per agent session.
Built-in chat UI, HTTP API, and MCP server endpoint with no extra code.
Custom Python tools in a tools/ folder and reusable skills in a skills/ folder, shared across agents.
Pluggable model providers. Microsoft Foundry, Azure OpenAI, and OpenAI out of the box.

Where this fits

The serverless agents runtime is designed for the agents most enterprises actually need to build:

Scheduled background agents that summarize, monitor, or reconcile on a timer.
Event-driven assistants that react to messages, emails, alerts, and database changes.
Cross-system agents that tie multiple SaaS and enterprise apps together through connections. Trigger with a Teams message, look up the customer in Salesforce, send an email, and update a database record, all from one agent.
Conversational front-ends that pair an HTTP or chat-UI entry point with the same agents your event triggers invoke.
Agents as MCP servers that other agents and MCP clients can integrate with directly.

We want your feedback

The serverless agents runtime is in public preview, and we're actively building it out with input from real customer workloads. Tell us what you build, what's missing, and where the model should go next.