Azure Functions introduces serverless agents runtime with markdown-first AI agents

Microsoft put a real stake in the ground at Build 2026 with the public preview of the Azure Functions serverless agents runtime — a markdown-first programming model for AI agents that runs natively on every Azure Functions trigger. As Microsoft's announcement puts it, 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." This is not another wrapper or extension. It is a genuine attempt to make the agent the unit of serverless work.

The pitch is simple: if you already ship code as a function, you can now run an AI agent with zero new infrastructure. One .agent.md file holds an agent's instructions, tools, and connections, deployed like any other function app and running on the Flex Consumption plan with scale-to-zero and per-second billing. For teams already wiring event-driven compute to large language models, this collapses a lot of plumbing into a single reviewable file.

Agents become functions, not sidecars

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. Microsoft's own framing is blunt: most of that work is plumbing, not the agent. Azure Functions spent years making event-driven compute simple — declare a trigger, write the handler, get autoscale and managed identity for free — and the serverless agents runtime applies that same model to agents. You define behavior in natural language, trigger it from almost any event, declare tools and MCP servers instead of coding them, and deploy and operate the result like any function app, with managed identity, VNet integration, Application Insights, and the same deployment tools teams already use.

The .agent.md convention will feel familiar to anyone tracking the agent-context movement. A markdown file with front-matter metadata declares the trigger; the markdown body becomes the agent's instructions. Microsoft's announcement shows a timer-triggered agent that summarizes the day's tech news and emails it — the whole "function" is a name, a description, a timer_trigger schedule, and three numbered instructions. Drop the file into the app, deploy, and it runs on schedule. That minimalism is the point: the markdown is both code and documentation, producing explicit, reviewable agent logic that fits cleanly into existing serverless patterns and code review.

The broader convention behind this is worth knowing. The AGENTS.md project documents the emerging standard of markdown files that give coding agents their instructions, and Azure's .agent.md is a direct descendant of that idea, extended with trigger declarations and tool bindings so the file is deployable, not just advisory.

Every trigger is now an agent host

The runtime's real use is trigger coverage. Per InfoQ's Build 2026 coverage, the declaration model spans HTTP, timer, Service Bus, Event Hubs, SQL, and Cosmos DB triggers, plus new native surfaces in Teams, Outlook, and SharePoint — and agents get MCP tool servers plus a large connector ecosystem for reaching connected systems.

Concretely, that means:

• HTTP triggers turn agents into AI-enabled API endpoints or bot webhooks, one agent run per request, with the platform's existing auth and scale behavior.
• Timer triggers schedule recurring agent work — Microsoft's own examples include a daily briefing agent that wakes on a timer, scours the web, and drops a summary in an Outlook inbox every morning.
• Service Bus and Event Hubs triggers put language-model enrichment and validation directly inside message pipelines, including IoT and business-system flows.
• SQL and Cosmos DB triggers let agents react to data changes as they land — tagging, QA, or transformation of new records without a separate pipeline stage.
• Teams, Outlook, and SharePoint triggers are the headline addition: a Teams chat agent that fires on every message and answers from connected systems, or an agent that handles incoming Outlook mail and calendar events natively, with no glue code.

An on-call troubleshooting agent rounds out Microsoft's example set — investigating incidents by querying logs in Azure Data Explorer and reporting back what it found. Each of these is a single markdown file plus a trigger, which is a strikingly small surface area for what used to be a multi-service project.

What "preview" means for your planning

Status labeling matters here, because it changes what you should bet on. This runtime is in public preview, not general availability. APIs, pricing details, trigger semantics, and the .agent.md schema can all shift before GA, and preview services carry no SLA. That does not make it a toy — Microsoft is explicitly positioning it as the production path for event-driven agents on Azure — but platform teams should treat adoption as a pilot: ship an internal agent on a timer or queue trigger, learn the operational shape, and keep the blast radius small until the GA announcement lands.

There is also a design judgment to make about instructions-as-code. A markdown file that anyone can edit is wonderfully reviewable, and it diffs cleanly in pull requests. It is also, by nature, prompt text sitting in a repo — which means the same prompt-injection hygiene you apply to any agent system applies here. Treat tool declarations and connector permissions as a security boundary: grant least privilege, review .agent.md changes with the same seriousness as infrastructure code, and keep an eye on what data each trigger can expose to the model. Our AI app security checklist walks through the controls that matter most when agents touch production data.

How this compares to rolling your own agent stack

The alternative most teams know is the hand-assembled stack: a framework for orchestration, a separate host for execution, queues for events, and bespoke code for every integration. That stack is flexible, but every seam is something you own — scaling behavior, identity, secret handling, retries, tracing. The serverless agents runtime absorbs those seams into the Functions platform: autoscale, managed identity, and Application Insights come along for free, and background execution inherits the same operational surface as the functions teams already run. If your agents are fundamentally event-driven — and most production agents are, waking on schedules, messages, or data changes — the comparison strongly favors the managed path. Our guide to AI production background jobs covers the execution patterns that map most cleanly onto this model.

Data access deserves its own planning pass. Agents that read and write production stores need row-level guarantees, not just a connection string — which is why pairing this runtime with patterns like Supabase RLS in production thinking (enforce access policy at the data layer, never in the prompt) pays off regardless of which cloud hosts the agent.

The bottom line for builders

The serverless agents runtime is Microsoft's clearest statement yet that agents are becoming ordinary cloud workloads: declared in markdown, triggered by events, billed by the second, observed like everything else. The markdown-first model lowers the authoring bar far enough that the agent's behavior can live in the same repo, the same review flow, and the same deployment pipeline as the rest of the system. For teams already on Azure Functions, the pilot is cheap — one .agent.md file, one trigger, one internal workflow — and the operational upside is the entire Functions platform working for agents instead of against them. Just remember the two caveats: it is a preview, so pilot before you bet the roadmap on it, and instructions-as-code still needs the security review that any production agent deserves.

If you are turning agent prototypes into shippable products, start from a foundation your coding agent already understands — browse the OTF production kits and ship something your on-call will not regret.

Sources

• Microsoft Tech Community, "Introducing the Azure Functions serverless agents runtime (preview)" — official announcement; preview status, markdown-first model, .agent.md format, trigger coverage, Flex Consumption plan, and example agents: https://techcommunity.microsoft.com/blog/appsonazureblog/introducing-the-azure-functions-serverless-agents-runtime-preview/4523804
• InfoQ, "Azure Functions Serverless Agent" (June 2026) — .agent.md declaration model, trigger coverage, MCP tool servers and connector ecosystem: https://www.infoq.com/news/2026/06/azure-functions-serverless-agent/
• AGENTS.md project — background on the markdown-instructions convention for coding agents: https://agents.md/