I put together a practical sample for a thing I keep wanting as a builder: an agent that automates my Microsoft 365 workflow, but lives in a repo, debugs locally, deploys with IaC, and runs serverlessly. The sample is an M365 Inbox Agent on Azure Functions' Serverless Agents feature: - urgent VIP mail -> Teams (triggered on new emails) - action-required mail -> grounded draft replies - daily briefing -> inbox (triggered every morning) - rules -> markdown - guardrails -> code, python - auth -> Entra / managed identity - deployment -> azd + Bicep - local dev -> sample inbox data + dry run This is for the custom edge cases a power user and builder hits, connected to many more systems and data sources. These are YOUR Frontier Agents, for the last-mile stuff every team has: - "Keep it in a repo so I can review changes" - "Let me debug the thing before it touches real mail" - "Reach an internal API or database that isn't in any connector catalog" - "Pin my own model, prompt, and dependency versions, and roll back a bad one" - "Run in my own Azure subscription with my own networking, billing, and managed identity" And because the serverless agent includes Markdown plus real code, it can run tools and enforce things the model cannot talk its way around: - a hard never-send guardrail: code checks the recipient against an allowlist before any send, so "never email outside my org without approval" is enforced in code, not hoped for in a prompt - a sandboxed code interpreter: the agent writes a small Python snippet to crunch a messy attachment or reconcile a spreadsheet, runs it in an isolated sandbox, and feeds the exact result back instead of eyeballing numbers in the model And it is your function. Serverless billing, high scale, no platform-imposed turn limits or connector throttling. You pay for what runs and you push whatever limits you want: fan out across thousands of messages, run long jobs, hold your own rate limits, scale to zero when the inbox is quiet. The ceiling is your Azure subscription, not someone else's agent quota. That is where this pattern gets interesting. The agent itself is markdown. The skills are markdown too. So the workflow stays readable: - who counts as a VIP - what should be skipped - what escalates - what gets summarized - what gets a draft reply Then Azure Functions gives it production shape: - event trigger when mail arrives - timer trigger for the daily briefing - Application Insights traces - serverless billing - managed identity - M365 connector actions and AUTH (unsung hero to this) - private repo customization - repeatable deploy I like this because it gives you both ends: 1. markdown agents for the reasoning and policy 2. normal developer ergonomics for everything around them Local mode is intentionally safe. You can run it against sample inbox JSON, see the exact Teams post or email reply it would produce, and call no connector at all. When you are ready, wire the Outlook and Teams connectors and deploy. The anchor version is mostly markdown on purpose, with a little Python where I wanted hard rails and code-based tools (not required, but useful). It keeps the story clean: readable agent policy, real M365 actions, Azure Functions production shape, and real code when you want a hard guardrail or a sandboxed computation. My mental model: >the out-of-box agents are the product experience; this sample is the builder path for the workflows only your team has.< This m365 & Teams sample (try it!): github.com/Azure-Samples/m36… Serverless agents runtime: learn.microsoft.com/en-us/az… If you try it, I would love to hear the first workflow you customize.