Serverless Eventing: Agents Are Going Serverless. Their Data Pipelines Are Not.

Agents are going serverless, but the data pipelines that feed them are not. That gap is what I talked about at OSA CON 2026, and this post is the written version of that talk.

I started writing about serverless eventing back in 2020. Google Cloud launched Cloud Run the year before and Knative a year before that. I was learning more about serverless containers and at the same time, I was working with Kafka as many of my customers were using it. While I was searching around, I found Knative Eventing by chance, and the two things I was already doing turned out to be one topic. That is how this series, and this site, got started.

Six years later, the thing at the end of the pipeline has changed. It is not just a function or a dashboard anymore. It is an agent. The question I was asking in 2020 is back, and the stakes are higher.

What makes something serverless

I’ve said it before and I will say it again: If you ask a room of people to define serverless, you will get various answers. Most people mean functions. When I say serverless, I mean four things:

1. Pay per use. You pay only for what you use.
2. Zero infrastructure. There are no servers for the developer to manage.
3. Auto-scaling. The platform scales with demand.
4. Event-driven. Your code runs when something happens.

The last one is the one this post is about.

Something has to wake it up

Since serverless apps can scale to zero, something has to “wake them up” to do their work. This “something” is an event. An event can be someone visiting your website, someone sending an HTTP request, a row being updated on a database, and more.

If that something else is a process you have to run, size and keep alive, you have broken the contract. You now have always-on infrastructure sitting in front of your serverless app.

This is the conclusion I keep coming back to: to be event-driven, serverless needs serverless delivery and serverless consumption. The brokers and the routing have to be serverless, and the consumers have to scale with events, down to zero.

The eventing plane

My answer is what I call an eventing plane. An eventing plane abstracts the data sources from the application. The application asks for the events it cares about, and it does not know or care which broker, queue or source produced them.

There are three parts. Sources, like databases, object storage and message streams, produce events. The plane handles routing, delivery and scaling. Consumers, like functions, serverless apps, AI endpoints and AI agents, just receive what they subscribed to.

The nice thing about this split is that the plane does not change when a new kind of consumer shows up. AI endpoints were already consumers in 2020. AI agents were not. Now they are, and the plane did not have to change for them.

What changed since 2020

A lot has moved since I started writing. Four changes matter for this story.

• Agents moved onto serverless. The big cloud platforms now have a story for hosting agents on serverless runtimes, and there is a growing group of serverless compute and agent-sandbox providers built for running agent code.
• The question changed. In 2020 the ask was to be data-driven, which mostly meant people reading dashboards and reports. Today it is that agents need fresh context. The data has to be fresher, it has to reach more consumers, and it has to flow both ways, because agents also publish what they decide.
• The stack changed. I wrote about NATS Streaming in 2020. Its deprecation was announced in April 2021, and it reached end of life on June 1, 2023, with JetStream as the replacement. Knative went from an incubating CNCF project to a graduated one, announced in October 2025.
• Data went serverless too. There are now serverless Postgres offerings from several vendors, and serverless event streams are starting to show up. Cloudflare launched K2 in public beta in October 2026. It is built on R2 object storage, and InfoQ reports about one second of produce latency at p99. It is a beta, not generally available.

The specific bus keeps changing. The need for events to be routed and scaled does not.

Where the manual work still lives

Agents are going serverless. For most teams, the data pipelines feeding them are not. The agent can scale to zero, but the event plumbing behind it still needs people. There are three jobs:

• Provision. Every data source needs a message bus, and someone has to stand it up and size it. With Kafka, that can mean a cluster per source, or a shared one you have to capacity-plan.
• Scale. When traffic shifts, someone retunes how many consumers run and how topics are partitioned. The bus does not follow the load the way the agent does.
• Configure. Every source has to be wired to every application by hand, with topics, credentials and filters. The work multiplies with each new source or app.

This work is manual by default, but it does not have to be. Many Kubernetes-native and serverless data platforms can automate it, and Knative Eventing is one example. There are also proprietary solutions like Google Eventarc and Amazon EventBridge.

That is the point of the eventing plane. The platform provisions the brokers, scales the consumers and handles the wiring, so the application only has to declare which events it wants.

Events agents can read

Events were designed for programs: small, structured payloads, usually JSON. Agents work in text, so the useful part of an event is often a short, readable message.

CloudEvents does not need to change for this. The spec has a datacontenttype attribute, and the data can be any content type, so text/markdown is allowed today. What is missing is a shared convention. I would like to see agent-facing events carry a short Markdown body, while the attributes stay structured so the plane can still route on type and source.

{
  "specversion": "1.0",
  "type": "com.example.order.delayed",
  "source": "/shop/orders",
  "id": "[unique-event-id]",
  "datacontenttype": "text/markdown",
  "data": "## Order 4417 is late\n\nCarrier reports a two-day delay.\nCustomer is on the premium plan."
}

The attributes are for the plane. The body is for the agent, which can read it as it is, with no parsing. This event is an illustration, not a published profile. I think it is worth defining one in the open.

A plane for agents and subagents

Agents rarely work alone. An orchestrator agent breaks a job into tasks and hands them to subagents, and the subagents hand results back. That is a lot of events, and it needs a plane designed for it.

The plane carries tasks out and results back as events. Four things matter:

• Fan out. One task event reaches many subagents, and each one scales up from zero.
• Correlate. Every result carries the parent task ID, so the parent can gather them. A CloudEvents extension attribute or the subject could carry it.
• Set limits. Budgets and rate limits stop a runaway agent from flooding the bus or running up the bill.
• Trace. One trace follows a task from the parent through every subagent. CloudEvents has a distributed tracing extension that could carry it.

These are design goals, not a list of what any product ships today. Knative Eventing already covers parts of fan out and delivery. The gaps are the interesting part.

Building blocks you can use today

The eventing plane is not a single product. You can put one together from open source pieces.

Swap in whatever fits your stack. What matters is that the application does not have to care which one it is.

Three takeaways

1. Treat events as a platform service, not application plumbing.
2. Standardize on one event format across every source.
3. Let event volume drive scaling, all the way down to zero.

Agents are going serverless. Their data pipelines should follow.

Written by Jason Smith, the Cloud Alchemist. AI was used to help me form my thoughts