At Microsoft Build 2026, the Azure Functions team shipped something that blurs the line between serverless compute and autonomous AI. The serverless agents runtime is now in public preview, letting developers define entire AI agents in .agent.md markdown files and deploy them like any other function app. You write the agent’s instructions in plain text, configure its triggers in YAML front matter, and let the runtime handle the orchestration, tool dispatch, and response generation. No boilerplate Python projects required, at least for the basic cases.
How the programming model works
The core unit of work is a single .agent.md file. The top portion uses YAML front matter to declare the agent’s name, description, and trigger. Below the front matter divider, the markdown body becomes the system prompt that the model sees at runtime. Microsoft Learn’s documentation gives a concrete example: a timer-triggered agent that scans tech news and emails a daily summary can be a self-contained file with a cron schedule, a short instruction block, and nothing else.
Triggers work across the full Azure Functions catalog. Agents can start from HTTP requests, schedules, queues, Service Bus messages, Event Hubs, SQL changes, Cosmos DB changes, or the new managed connector triggers for Teams, Outlook, SharePoint, and other SaaS events. Because the agent is registered as a standard Azure Function, you get the same deployment slots, virtual network integration, managed identity, and Application Insights tracing as any other Functions workload. The runtime handles agent discovery, trigger registration, and tool assembly at startup by scanning the project for .agent.md files, mcp.json server definitions, skills in the skills/ folder, and custom tools in tools/.
What connects to what
Tool integration is where this gets genuinely useful. Agents can call remote MCP servers, MCP servers hosted in connector namespaces, reusable skills packaged as SKILL.md files, sandboxed code execution via Azure Container Apps dynamic sessions, and custom Python tools. The InfoQ coverage highlights that agents get access to 1,400+ managed connectors spanning Microsoft 365, Teams, Outlook, Salesforce, ServiceNow, and SAP. There is no extra billing for the agents infrastructure: it runs on Flex Consumption at standard function execution pricing with scale-to-zero between runs. The product team confirmed that cold start overhead is no worse than a regular HTTP trigger on Flex Consumption, and the real latency bottleneck is the LLM call itself, not the platform.
For app specific logic, you drop Python files into a tools/ folder. Each file can define a decorated function using @tool from azure_functions_agents, or just a plain function with a docstring that the runtime auto wraps. App wide defaults like model selection (Azure OpenAI, Azure AI Foundry, or OpenAI), timeout (defaults to 900 seconds), and sandbox endpoints go in agents.config.yaml. Session history is persisted to Blob Storage using the function app’s existing storage account.
What this means
This release signals that Microsoft treats event-driven AI agents as a first class cloud workload, not a sidecar experiment. By folding agents into the existing Functions deployment and operations model, Microsoft avoids forcing teams to learn a separate platform for agent runtime concerns like scaling, identity, and observability. The markdown first approach is a deliberate bet that the operational skeleton of an agent (triggers, tool wiring, auth, session storage) matters more than the choice of programming language for the agent definition itself. Whether that bet pays off depends on how comfortable infrastructure teams feel trusting a YAML file to describe production behavior. For teams already running Functions on Flex Consumption, there is now very little friction between wanting an AI agent and having it deployed.
Getting started (and what to watch out for)
- Try the quickstart first. Microsoft Learn has a step by step guide that walks through deploying a serverless agents app with a chat agent, a timer triggered blog summary agent, sandboxed execution, and optional connector MCP tools.
- Read the sample on GitHub. The Azure-Samples/functions-markdown-agent repo shows a working agent project with
.agent.mdfiles, skills, and connector tools. - Treat preview as preview. Features, configuration names, and supported connectors can change before general availability. Do not deploy production critical agents on this runtime yet.
- Mind the cost model. You pay for the underlying function execution and for the LLM tokens your agent consumes. There is no separate agents tax, but multi turn conversations with large context windows can burn through tokens fast. Set aggressive timeouts and test with realistic loads.
- Use managed identity wherever possible. The runtime supports Microsoft Entra authentication for model providers, MCP servers, sandboxed execution, and blob backed session history. Avoid storing API keys in
mcp.jsonor agent files. - Store prompts and instructions under version control.
.agent.mdfiles are plain markdown, so they can be reviewed, diffed, and tested like any other infrastructure artifact. Take advantage of that. Do not hand production agent prompts to an LLM to write and ship the output without human review.