Microsoft adds serverless agents runtime for Azure Functions in preview
Microsoft has introduced a serverless agents runtime for Azure Functions, currently in preview, that defines agents in Markdown files and runs them as ordinary Function Apps. The runtime discovers agent definitions from project files, integrates with MCP servers and custom tools, and inherits standard Functions features like scale-to-zero and managed identity. It targets event-driven agents that are started by timers, queues, or HTTP requests without needing a dedicated agent server.

Listen to this dispatch
Narrated by an AI-generated voice.
Microsoft has added another way to build AI agents on Azure: a serverless agents runtime for Azure Functions, currently in preview, that defines agents in Markdown files and runs them as ordinary Function Apps.
The core idea is that agent definitions live in project files rather than in code. A file such as ai_news_digest.agent.md holds front matter for schedule, model, and tool configuration, with the Markdown body serving as the agent's instructions. The timer trigger is part of the agent definition itself, using the six-field NCRONTAB format; no separate timer function is needed. The application entry point is a single call to create_function_app(). When the Functions host starts, the runtime discovers agent files, MCP servers listed in mcp.json, custom Python tools in tools/, skills, and app-wide settings in agents.config.yaml.
The sample workload is a scheduled AI news digest that searches for recent AI news and sends a summary card to Teams. Web search runs through a remote MCP server (Tavily), so the application contains no Tavily client code. A custom Python tool handles the posting logic: validating articles, removing ones already sent, building the Adaptive Card, and storing article IDs in Blob Storage. The model is referenced by an environment variable rather than hardcoded, and the Function App uses a managed identity to access it.
An emerging pattern across agent runtimes is agents as collections of files rather than one large class or prompt. Vercel's eve and LangChain's Managed Deep Agents take similar filesystem-first approaches, with instructions, tools, skills, and schedulers defined separately from operational code.
Where this fits among Microsoft's existing agent options: Foundry prompt agents work when instructions and configured tools are enough, but they did not fit this workload because the digest needs custom code to ensure unique links. Foundry hosted agents package your own container and let Foundry manage the endpoint and lifecycle — overkill here. Logic Apps is workflow-first, better suited when approvals, connectors, and business orchestration outweigh the agent code itself.
The serverless runtime inherits normal Functions features: scale-to-zero under Flex Consumption, per-second billing, managed identity, Application Insights, and virtual network integration. Session history is stored through the app's AzureWebJobsStorage account, which is separate from application state such as the seen-articles file.
Deployment is standard Functions deployment, and agent runs appear in Application Insights with MCP discovery, model tool calls, and custom tool execution. The runtime is in preview, so features can still change; the current Microsoft documentation is the authoritative reference. For now, it fills a specific niche: agents that are naturally started by an event — a timer, queue message, blob change, or HTTP request — without operating a dedicated agent server.
Read the original at baeke.info →