Azure Functions Agents Runtime: Stop Paying for Idle Agents

Agent programs keep producing the same invoice line: containers or AKS pods running around the clock for agents that handle a few hundred requests a day. The compute idles. The bill does not.

The Azure Functions agents runtime exists because of that line item. Agents are workloads, not apps, and most of them are bursty workloads that belong on serverless. Microsoft now documents hosting AI agents directly on Functions as a first-class scenario in the serverless agents runtime page on Learn. That one move turns “where do we host agents” from an architecture debate into a cost decision.

What the Azure Functions agents runtime actually is, in 60 seconds

Strip the announcement language and the shape the Learn doc describes is simple. Your agent code runs inside a Functions app. It wakes on a trigger. It scales to zero when nothing is happening. You pay consumption billing for execution, not for existence.

That is the whole pitch for serverless AI agents on Azure: the platform already knew how to run event-driven, scale-to-zero compute, and agents turn out to be event-driven, scale-to-zero compute with an LLM call in the middle.

Microsoft Agent Framework writes the agent, Functions runs it

Keep the layers separate in your head. Microsoft Agent Framework is the agent logic: the convergence of Semantic Kernel and AutoGen, with .NET and Python as its first-class SDKs. The Functions runtime is the hosting layer Microsoft positions underneath it. If you are still deciding whether your problem even needs an agent rather than a deterministic flow, settle that first - I walked through that decision in Agent Framework 1.0 and when to reach for each pattern.

Two caveats before you commit roadmaps. First, this is a new surface, and the specifics that matter for planning - exact trigger support, language coverage, and release status - live on the Learn page and will move. Read it fresh, not from a blog post, mine included. Second, Azure capabilities at this early stage typically ship without a production SLA. Fine for internal tools, a conversation with your risk owner for anything customer-facing. Confirm the current status on the page before that conversation.

The takeaway: this is Microsoft making agent hosting a documented Functions scenario, not a sample repo you fork and babysit.

Why “AKS or Container Apps?” was the wrong question

The hosting debate of the last two years carried a hidden assumption: agents need always-on compute. Watch what a typical agent actually does. It wakes on an event, calls a model, calls two or three tools, writes state, and goes quiet. For an internal expense-review agent or a ticket-triage agent, quiet is typically the dominant state. Treat that as a pattern description, not a measured statistic; your telemetry will tell you your own number.

That usage shape is the Functions profile, exactly. So here is the position: if your agent is request-driven and tolerates cold start, Functions is the right default. Not one option among several. The default, from which you deviate with a reason.

The docs describe the happy path, and production adds a wrinkle: cold start stacks on top of model latency. A user who waits four seconds for the model will not forgive two more seconds of runtime spin-up. For user-facing agents, the realistic configuration is the Flex Consumption plan with always-ready instances, which keeps a warm floor under your latency while everything above the floor stays pay-per-use.

Pick the host by traffic shape, not by what the platform team already operates.

Do the math: scale-to-zero changes agent TCO

Here is an illustrative scenario. Industry-standard inputs; calibrate against your own data, actuals vary. The rates below are the pay-as-you-go figures listed on the public pricing pages as I write this; they vary by region and change over time, so verify against the live pages before you model anything.

One internal agent. 9,000 invocations a month, roughly 300 a day. Average execution of 3 seconds at 512 MB of memory. Idle the rest of the time.

On the classic Functions Consumption plan, the Azure Functions pricing page lists $0.20 per million executions and $0.000016 per GB-second, with a monthly free grant of 1 million executions and 400,000 GB-seconds. Our agent consumes 13,500 GB-seconds a month (9,000 runs, 3 seconds each, 0.5 GB). That lands entirely inside the free grant: effective compute cost, zero. Even with no grant, it is about 22 cents. Flex Consumption meters differ, but the billing shape is the same: you pay for execution, not hours.

Now the same agent on Azure Container Apps with minReplicas: 1, which is how teams commonly run it to dodge cold start. Be fair to Container Apps: its consumption plan scales to zero too, and it bills active seconds and idle seconds at different rates. The moment you pin a minimum replica, though, you pay for existence around the clock. For an agent that is quiet nearly all month, the idle rate dominates, so I will use it for the whole month; that slightly understates the real bill, since active seconds cost more.

The Container Apps pricing page lists idle usage at $0.000003 per vCPU-second and $0.000003 per GiB-second as I write this. A modest replica at 0.5 vCPU and 1 GiB works out to 1.5 billable units, or $0.0000045 per second. Over roughly 2.63 million seconds in a month, that is about $12, before free grants.

Twelve dollars sounds like nothing. Multiply it. Forty small agents is roughly $470 a month for compute that does nothing most of the day, versus effectively zero. Now size the replicas the way teams size them “to be safe”: 2 vCPU and 4 GiB is 6 billable units, or $0.000018 per second, which comes to about $47 per agent per month and roughly $1,900 for the same forty agents, idle. Check my arithmetic against the live page; the structure is the point. Always-on compute bills 100 percent of hours, scale-to-zero bills execution, and for a mostly-idle agent the gap between those two numbers is almost the entire bill.

The honest caveat: for heavy agents, model inference cost dwarfs compute cost, and token spend needs its own discipline - I covered that in engineering AI cost governance for Azure LLM workloads. This compute math matters most for the long tail of small internal agents, which is exactly the kind of agent that multiplies fastest once hosting them gets cheap. That is why serverless AI agents on Azure are an economics story, not a features story.

The plumbing you can stop hand-rolling

The quieter value of the runtime is everything agent teams have been rebuilding from scratch.

Long-running conversations need durable state. Durable Functions gives you orchestrations with automatic checkpointing and replay, which maps directly onto multi-step agent work: survive a restart mid-task, resume where you left off, no custom state machine.

Tool connections need plumbing. Bindings hand your agent Service Bus queues, Event Grid events, and Cosmos DB documents without a custom client in sight. Teams building agents on raw containers typically write that connection code themselves, then the retry logic, then the config loading for all of it. Bindings make that stack someone else’s problem.

Secrets need to not exist. Managed identity gives the Functions app secretless auth to model endpoints and data stores, which removes a whole category of key-rotation incidents before they happen.

The takeaway: the win is less “new runtime” and more “stop writing infrastructure code the platform already ships.”

Where Functions is the wrong answer

The boundary is real, so draw it honestly.

GPU-adjacent work and self-hosted inference point to Container Apps, which offers serverless GPUs per its docs, region availability permitting, plus full runtime control. Strict sub-100ms latency budgets point away from any cold-start architecture, always-ready floors included. Dense multi-agent topologies with many long-lived, chattering agents fit Container Apps or the Foundry Agent Service better, and I will say the unfashionable part out loud: Durable Functions orchestration code gets genuinely hard to reason about past a certain graph density. Do not oversell it to yourself.

None of this says Kubernetes is dead for agents. The claim is narrower and sharper: most agents never needed it.

The ladder, and your move

Step back and the shape of Microsoft’s bet is visible. Copilot Studio holds the low-code rung. Foundry Agent Service holds the managed-platform rung - I compared those hosting modes in detail in Foundry hosted vs in-process vs Copilot Studio agents. The Functions agents runtime is the pro-code rung in between, and it is the one Azure developers have been missing.

Read the signal in it. Microsoft is betting agents will be numerous and small, not few and monolithic. You do not build cheap, scale-to-zero hosting for a world of three big agents. You build it for a world of two hundred small ones, most of them asleep at any given moment.

So here is the move. Audit your running agents this week. Tag the bursty ones, which will likely be most of them. Start with internal tools where a cold start costs you nothing but a shrug, and move them to Functions before the next cost review - because the first question in that review will be why the idle containers cost what they cost, and “that was the default” stopped being an answer.