Serverless in the Agent Era

Why September 2026 confirms what EVRTNG already runs

The serverless market is converging on isolated, long-lived compute environments for agents.

Introduction: A Month of Validation

In March we published our market analysis Serverless Computing 2026; in August we followed up with an update covering the consolidation of the market, the public winding-down of Apache OpenWhisk, and our own answer: a completed Pekko fork, an announced migration to Fission, and Kata-Firecracker as the constant isolation tier. This article is not another date-based update. It is a thesis: the market is converging on the architecture EVRTNG already operates - a thin, Kubernetes-native FaaS layer, VM-level isolation, and pay-per-use economics.

Three developments from the last five weeks support that thesis: long-running workloads are becoming the norm, VM isolation is becoming a purchase criterion, and functions are becoming agent tools. And the migration we announced in August is now product reality - functions.evrtng.cloud runs on Fission with Firecracker-isolated workloads, on Swiss infrastructure.

What Happened Since Mid-August

Five weeks, one direction. The September releases read like a checklist of requirements that agent workloads impose on serverless platforms.

Chronological Timeline

• August 31 - Google Cloud Run instances: public preview of dedicated, singleton runtimes for long-lived, stateful workloads such as AI agents - up to 7 days continuous runtime, stable HTTPS URL, USD 5.70/month for 1 vCPU/1 GiB [Google Cloud]
• September 1 - Google Agent Platform: system-managed Agent Identities and Agent Registry (preview) for authenticating agents and MCP servers on Cloud Run; Go 1.27 runtime GA [Google Cloud]
• September 2 - AWS Lambda SnapStart for container images: startup times drop from several seconds to sub-second for functions packaged as container images - up to 10 GB [AWS][3]
• September 4 - AWS MCP Server: new serverless capability lets coding agents diagnose Lambda functions and their connected resources (API Gateway, EventBridge, S3, DynamoDB, SQS, Step Functions) [AWS]
• September 9 - AWS Lambda 90-minute timeout: 6× the previous limit for asynchronous and event-source-mapping invocations on Managed Instances; durable functions can checkpoint and replay steps for up to 1 year [AWS]
• September 9 - AWS Graviton5 on Lambda: C9g/M9g instances with up to 25% better compute performance for Managed Instances [AWS][6]
• September 10 - AWS recursive loop detection in Europe Sovereign Cloud: serverless safety features reach sovereign regions - a signal that sovereignty is becoming a mainstream requirement [AWS][7]
• September 12 - Firecracker v1.17.0: the microVM monitor behind AWS Lambda's isolation continues its steady release cadence [Firecracker]
• September 14 - Azure Functions runtime 1.x support ends: v3 Linux Consumption workloads stop running September 30; the in-process model ends November 10 - full consolidation on the v4 runtime [Microsoft]
• September 16 - Kata Containers 4.2.0: the second minor release after the Rust-rewritten 4.0.0 (runtime-rs as default, July 20) - with Firecracker remaining a first-class VMM [Kata Containers]
• Ongoing - Azure Connector Namespace (preview): Logic Apps connectors as a .NET SDK for code-first Function Apps [Microsoft]

Three Convergences

Read together, these releases reveal a pattern that goes beyond individual features. Three lines converge - and all three point toward the architecture we described in August.

1. Long-running is the new normal

AWS extends the Lambda timeout to 90 minutes; durable executions run up to a year. Google introduces a dedicated resource type whose entire purpose is workloads that run for days - explicitly for AI agents. The early-FaaS reflex "a function is a short request" no longer holds. Agents run for minutes, days, or weeks, and serverless platforms that cannot keep up are being extended until they can[5][1]. What was an edge case in March is now the mainline use case the hyperscalers optimize for.

2. VM isolation becomes a purchase criterion

Agent code is untrusted code. Running it in a shared container kernel is a risk decision more and more enterprises are unwilling to make. The market responds: Firecracker - the VMM behind AWS Lambda - ships v1.17.0[9]; Kata Containers delivers its third release since the Rust rewrite, with Firecracker as a first-class VMM[10]; and the Kubernetes sig-arch Agent Sandbox project explicitly recommends kata-fc for serverless-style workloads. VM-level isolation has moved from a niche feature to a requirement - precisely the isolation tier EVRTNG has been running on its invoker nodes all along.

3. Functions become agent tools

The Model Context Protocol is becoming the connective tissue between agents and infrastructure: AWS ships a serverless diagnostics capability in its MCP Server[4], Google manages agent identities and a central registry[2], Azure positions Functions as the runtime for agents and MCP servers[11]. And Fission - the engine EVRTNG migrated to - shipped functions-as-MCP-tools in v1.26.0[8]. A function is no longer just an HTTP endpoint; it is a tool that agents discover and call. Platforms that cannot expose their functions this way will be invisible to the agent era.

EVRTNG: The Migration Is Complete

In August we described the migration to Fission as the next step. Today it is product reality: functions.evrtng.cloud runs on Fission, with function workloads isolated in Firecracker microVMs. A Python function deploys through the provisioning API and is reachable at its tenant URL within seconds - no servers, no infrastructure management[12].

What the migration delivered, concretely:

• A thinner engine layer: no CouchDB, no Kafka for the FaaS engine to operate - function and trigger state lives in Kubernetes CRDs. The operational surface our team maintains shrank measurably.
• Unchanged isolation: kata-fc carries over one-to-one via the Kubernetes RuntimeClass - the strongest isolation tier survived the stack change without modification.
• Unchanged commerce layer: billing-consumer, provisioning-api, and quota-enforcer continue to meter, provision, and enforce - the layer that makes a FaaS engine a product.
• Transparent pricing: CHF 9.95/month base, CHF 0.20 per million requests, compute per GB-second - idle functions cost nothing[12].

The engine choice is also proving itself in its roadmap. Fission v1.26.0 shipped Gateway-API-based routing, OCI-native package delivery, streaming responses (SSE, chunked, WebSocket) that are no longer bound by the function timeout - and functions as MCP tools[8]. An RFC for function versions, aliases, and instant rollback is in review[8]. In other words: the engine is developing in exactly the direction the agent era demands - long-lived streaming interactions, agent-consumable tools, safe rollouts.

Isolation is future-proof as well. With Kata 4.x, the Rust-based runtime-rs becomes the default runtime, while Firecracker remains fully supported.[10] For us this means: a RuntimeClass update in the cluster, not a migration.

What This Means for Customers

The convergences above are market observations; this is what they translate to for teams building on EVRTNG Functions today.

Agent workloads without compromise

Untrusted or third-party agent code executes behind a VM boundary - different customers share hardware, but never a kernel. You do not have to wait for a hyperscaler to extend its timeout or roll out microVM sandboxes in your region; the isolation model that AWS Lambda proved at a scale of 15 trillion monthly invocations is standard on our invoker nodes[13].

Functions that agents can use

With Fission's MCP tool support, your functions can be exposed as tools that agents discover and call - no separate MCP server infrastructure required. Build the business logic once; serve humans via HTTP and agents via MCP[8].

Workloads that outgrow the 15-minute reflex

Streaming responses - SSE, chunked, WebSocket - are no longer cut off by a function timeout. Agent conversations, long-running transformations, and interactive workflows fit the platform instead of being squeezed into architectural workarounds[8].

Sovereignty from day one

While AWS brings recursive loop detection to its Europe Sovereign Cloud - a worthwhile step - sovereignty at EVRTNG is not a product tier, it is the location: cluster in ch-ge1-az3, data, logs, and activation records under Swiss jurisdiction. For regulated industries, this is the difference between a feature request and a signed contract.

Conclusion: The Market Is Moving Toward an Architecture That Already Exists

September 2026 validated the three bets we made in August. Long-running workloads: the hyperscalers are extending their platforms until agents fit. VM isolation: Firecracker and Kata are maturing in lockstep, and isolation is becoming a purchase criterion. Agent integration: MCP is becoming the standard interface between agents and infrastructure - and Fission supports it natively.

The difference between observing this trend and being ready for it is an architecture. Ours is not on a roadmap - it is in production: a thin, Kubernetes-native FaaS layer, Firecracker-isolated workloads, a metering and billing layer that makes it a product, and a Swiss cluster that keeps customer data under Swiss jurisdiction.

The serverless market is moving toward the architecture EVRTNG already runs. For teams building agent workloads today, the question is not whether platforms will support them - it is whether to wait, or to build where the support already exists. functions.evrtng.cloud is that place.

1. Google Cloud Blog, "Introducing Cloud Run instances," August 31, 2026, Google Cloud - Cloud Run instances; Sara Ford, "Continuing the coffee shop saga with Cloud Run instances," September 14, 2026 ↩︎
2. Google Cloud Run release notes, September 1, 2026 - Agent Platform Agent Identities, Agent Registry (preview), Go 1.27 GA, cloud.google.com/run/docs/release-notes ↩︎
3. AWS, "AWS Lambda now supports SnapStart for container image functions," September 2, 2026, aws.amazon.com/about-aws/whats-new; InfoQ, "Lambda SnapStart Comes to Container Images," September 12, 2026 ↩︎
4. AWS, "AWS MCP Server adds a serverless capability for AWS Lambda functions," September 4, 2026, aws.amazon.com/about-aws/whats-new ↩︎
5. AWS, "AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances," September 9, 2026, aws.amazon.com/about-aws/whats-new ↩︎
6. AWS, "AWS Lambda now supports Graviton5-powered EC2 instances on Lambda Managed Instances," September 9, 2026, aws.amazon.com/about-aws/whats-new ↩︎
7. The AWS News Feed, "AWS Lambda recursive loop detection is now available in Europe Sovereign Cloud," September 10, 2026, aws-news.com ↩︎
8. Fission v1.26.0 release notes - Gateway API route provider, OCI-native package delivery, streaming responses, functions as MCP tools, fission.io/docs/releases/v1.26.0; RFC-0025 (function versions, aliases, instant rollback), PR fission/fission#3599 ↩︎
9. Firecracker v1.17.0 release, September 2026, github.com/firecracker-microvm/firecracker ↩︎
10. Kata Containers 4.0.0 (July 20, 2026, runtime-rs as default), 4.1.0 (August 21, 2026), 4.2.0 (September 16, 2026), github.com/kata-containers - releases ↩︎
11. Microsoft Learn, "Compare Azure Functions runtime versions" - v1.x support ends September 14, 2026; v3 Linux Consumption stops September 30, 2026; in-process model ends November 10, 2026, learn.microsoft.com - functions-versions ↩︎
12. EVRTNG Cloud Functions, evrtng.cloud/functions; Functions platform, functions.evrtng.cloud ↩︎
13. AWS Lambda MicroVMs, June 2026 GA - Firecracker design paper, aws.amazon.com/blogs/aws; invocation scale per EVRTNG Serverless Computing 2026 - Update August ↩︎