Data Streaming Infrastructure for the Agent Era

The unit of scale in software is changing.

For the last two decades, most online systems were sized around human actions: a page view, a search, a checkout, a dashboard refresh. A person initiated a request, the application did some work, and the system waited for the next request.

Agents do not wait.

They observe, plan, retrieve, call tools, emit partial results, update memory, hand work to other agents, evaluate outcomes, retry failures, and continue running. A single user request can become hundreds or thousands of machine-generated events. A fleet of agents can do that continuously, 24 hours a day.

The model receives most of the attention. The data path determines whether the system works.

We believe the agent era needs a new data fabric: one built for an expanding volume of real-time events, ultra-low tail latency, efficient use of modern hardware, durable replay, and native agent-to-agent data exchange.

That is the layer we are building at LaserData.

Agent workloads change the infrastructure equation

Human traffic is naturally rate-limited by attention. Agent traffic is limited by compute, budgets, and policy.

An agent can fork work across researchers, planners, executors, and reviewers. Each one can run several tool calls in parallel. Every step can generate prompts, responses, state transitions, memory writes, audit records, metrics, traces, and downstream events. The output of one workflow becomes the context for the next.

The new load shape is closer to:

users × agents × concurrent tasks × events per task × hours running

This is not only more traffic. It is more varied traffic with much tighter dependencies.

Agents consume real-time data from operational databases, applications, sensors, markets, logs, and other agents. They also produce a new class of real-time data: reasoning traces, tool results, token streams, memory updates, approvals, state changes, evaluations, and provenance. Those records need different retention windows and access patterns, but they belong to the same execution history.

When this history is scattered across a queue, cache, vector database, workflow engine, telemetry backend, and a web of point-to-point APIs, every agent loop pays a coordination tax. Teams then have to reconcile duplicated state, recover partial work, trace causality across systems, and decide which store is the truth.

That approach is already expensive at human scale. It becomes structurally wrong when software is generating the majority of the events.

Tail latency is the real agent experience

Average latency is a comforting number and often the wrong one.

An agent workflow crosses many boundaries: fetch context, read memory, call a model, invoke a tool, write state, notify another agent, wait for a reply, and persist the result. Its elapsed time includes every one of those steps. Variance at the data layer therefore becomes visible as pauses in the product and idle time in the compute layer.

If one boundary occasionally stalls for tens or hundreds of milliseconds, a multi-step workflow encounters that tail far more often than a single request does. Fan-out makes it worse: a coordinator usually waits for the slowest required branch.

This is why p99 and p99.9 matter more than a good median for agent infrastructure. A tight tail means:

• an interactive agent feels responsive instead of intermittently broken;
• multi-agent coordination completes inside predictable deadlines;
• expensive inference capacity spends less time waiting for context or state;
• timeouts and retries do not create avoidable duplicate work;
• SLOs can be based on the normal operating envelope, not generous jitter buffers.

Ultra-low tail latency is not a luxury reserved for trading systems. In an agentic system, it is a resource-efficiency feature and a product feature at the same time.

Faster and cheaper are the same architecture problem

The agent era will be compute-hungry. That makes waste in the rest of the stack more—not less—important.

It makes little sense to provision scarce accelerators for fast inference and then leave them waiting behind a slow or unpredictable data path. It makes equally little sense to compensate for an inefficient broker by adding cores, memory, replicas, and operational headcount.

The cost of an agent workload is larger than the model bill:

inference + data movement + stored state + idle time + retries + operations

Better infrastructure reduces several terms at once. More useful work per core lowers the broker footprint. Predictable latency reduces idle compute and retry storms. A durable log reduces duplicate storage and bespoke recovery systems. A shared data model reduces the glue required to keep services consistent.

This is the standard the next data plane has to meet: faster, cheaper, and better together. Optimizing only one dimension simply moves the bill somewhere else.

Apache Iggy is the backbone

LaserData is built on Apache Iggy (Incubating), a persistent streaming engine written in Rust for high throughput and predictable low latency.

Its performance is the result of architectural choices, not a layer of tuning over a legacy execution model:

• Thread per core. Iggy pins a shard to each CPU core and steers partition work to its owning shard. Keeping the hot path local reduces cross-core synchronization and improves cache locality.
• Shared-nothing data path. Partitions have clear shard ownership, so common data-plane operations avoid global locks and shared mutable state.
• Completion-based I/O. On Linux, Iggy uses io_uring through the compio runtime. Work is submitted in batches through ring buffers shared with the kernel instead of paying the traditional readiness and blocking-thread-pool cost for disk I/O.
• Zero-copy and allocation-aware paths. Raw buffers, vectored writes, and a pre-allocated memory pool reduce copying and heap churn where messages are sent, stored, and read.
• Native Rust. There is no garbage collector introducing periodic pauses into the latency profile.
• A durable append-only log. Consumers read by offset, replay history, and scale through partitions and consumer groups. Durability and recovery are native properties of the substrate, not separate services attached later.

The practical result is a broker that uses modern CPUs, memory, NVMe, and kernel I/O primitives as they were designed to be used. You can read the details in the Apache Iggy architecture guide and the project's thread-per-core migration write-up.

The benchmark shape agents need

Raw throughput matters because it creates headroom. Tail latency determines whether that headroom is usable.

In a recent VeloDB benchmark, Iggy and Kafka were tested back-to-back on the same broker hardware with 256-byte messages, batches of 1,000, and eight parallel producers:

In that workload, Iggy delivered roughly 3x the throughput and a much tighter tail. The test also measured the full path into VeloDB Cloud. At a steady 2,000 events per second, Iggy held event-to-queryable-row p99.9 near 1.35 seconds, while the Kafka path reached roughly 10 seconds.

One benchmark is not a universal prediction for every deployment. Workload shape, durability settings, hardware, connectors, batching, and topology all matter. What the result demonstrates is the property agent systems need: an architectural advantage at the broker can survive through a realistic data pipeline and preserve a tighter freshness envelope.

Our full benchmark analysis includes the setup, end-to-end results, and limitations.

A fast broker is the beginning, not the whole data plane

Agents need more than messages in flight.

They need to replay a failed run, reconstruct context, discover peers, correlate a request with its response, stream partial output, coordinate shared state, enforce deadlines, deduplicate effects, and explain why a decision occurred. A conventional broker can carry bytes for these patterns, but every team is left to invent the contracts around those bytes.

This is the gap between a transport and an agent data plane.

MCP is valuable for exposing context and tools. A2A is valuable for interoperability between agents. They define important interaction boundaries. But internal agent systems still need a lower layer that owns durable movement, ordering, offsets, replay, fan-out, working state, and provenance.

That lower layer is what we are designing with AGDX, the Agent Data Exchange Protocol.

AGDX: a wire-speed data contract for agents

AGDX is a substrate-neutral specification for agents and conventional services to exchange data over a durable log. It is designed to keep the data plane close to wire speed without reducing agent communication to opaque byte arrays.

The current design uses a compact, typed, versioned CBOR envelope for commands, responses, events, token chunks, status, and errors. Information required for routing—such as version, content type, ordering key, operation, and correlation—can travel out of band so a router does not have to decode the full body to make a decision.

That distinction matters at scale. An agent message should be rich enough to preserve causality, deadlines, idempotency, task state, token usage, and provenance, but the infrastructure should not repeatedly parse a large JSON document just to partition or route it.

AGDX treats the durable log as the source of truth and brings three surfaces onto one authenticated connection:

agents · services · MCP/A2A/AG-UI bridges
                      │
                one connection
                      │
     ┌────────────────┼────────────────┐
     │                │                │
  streaming      materialized      working
  and replay        views            state
     │                │                │
     └──────── durable, partitioned log ────────┘
                     Apache Iggy

• Streaming carries typed records and agent envelopes with offset-based replay.
• Materialized views make projections queryable without introducing a hand-synchronized second source of truth.
• Working state provides key-value coordination and copy-on-write forks for speculative work.

MCP and A2A can remain at the edge, where capability discovery, tool invocation, and cross-vendor interaction belong. AGDX sits underneath them as the durable data exchange layer. Edge requests can be mapped into log-native records; internal participants can consume, replay, audit, and fan out those records without building an N-by-M mesh of synchronous calls.

Wire speed also has to be transport-honest. A same-host agent, a service across a region, and a datacenter worker should share semantics while using the lowest-latency path available to their locality. Apache Iggy provides the high-performance binding today; the AGDX data model is intentionally separated from transport framing so it can survive as substrates and network paths evolve.

AGDX is currently a pre-1.0 design and specification. Breaking wire changes are still possible. We are publishing it early because agent infrastructure needs an open, inspectable contract—and because interoperability is stronger when it is designed in public rather than reverse-engineered after adoption.

Laser SDK turns the log into agent primitives

The Laser SDK is the developer surface for this data plane. Rust is the reference implementation, Python binds the same Rust core, and TypeScript is a native client checked against the same fixtures and behavior scenarios.

It exposes one consistent grammar across the core primitives:

object.verb(input).await

Developers use that shape for logs, views, changes, key-value state, copy-on-write forks, graphs, memory, context, agent contracts, workflows, and run history. The same connection that publishes an event can recall memory, query a projection, coordinate a lease, or send a correlated agent command when the backing deployment supports that capability.

This matters because agent frameworks will continue to change quickly. The durable data layer should not have to change with them. An application can adopt a new model, planner, or orchestration library while its events, offsets, state, causality, and replay contract remain stable.

The open streaming path and agent runtime run on Apache Iggy. Managed surfaces are discovered through capability negotiation, so an unsupported operation fails explicitly instead of silently weakening its guarantees.

Laser Stack locally, LaserData Cloud in production

Laser Stack packages one Iggy server and one LaserData plane for local development, SDK examples, and CI. It gives developers the complete local SDK surface—including streaming and the managed query, projection, key-value, fork, graph, and run paths—through one connection string.

That creates a short path from idea to production:

1. Build and test locally with Laser Stack.
2. Use the same Laser SDK and data model against LaserData Cloud.
3. Choose managed cloud, BYOC, or an on-premises operating model without rewriting the application around a different broker API.

LaserData Cloud adds the operating layer: deployment automation, isolation, observability, security controls, credentials, audit, storage choices, and the operational work required to keep the data plane healthy.

The separation is deliberate. Apache Iggy is the open streaming backbone. AGDX defines the agent data contract. Laser SDK gives applications a coherent programming model. Laser Stack makes the full surface available locally. LaserData Cloud operates it for production teams.

The infrastructure contract for the agent era

The next infrastructure shift will not be driven only by larger models. It will be driven by more software acting more often on more live data.

That future cannot run economically on a data layer that treats tail latency as an afterthought, consumes hardware inefficiently, or scatters one workflow across a collection of loosely synchronized systems. Agents need a substrate that can keep context moving, preserve what happened, coordinate what happens next, and make the entire history reusable.

Our position is simple:

• real-time data volume will grow faster as machines become producers as well as consumers;
• agent compute needs a data path with ultra-low and predictable tail latency;
• resource efficiency is necessary to make always-on agent workloads affordable;
• durable logs, offsets, replay, and ordering should be foundational primitives;
• agent-to-agent data exchange needs a compact, typed, open protocol designed for the hot path;
• developers should be able to work with streams, state, context, memory, and coordination through one coherent SDK.

This is what we mean by data streaming infrastructure for the agent era.

Faster. Cheaper. Better. Built on Apache Iggy, made agent-native through AGDX and Laser SDK, and operated as a production platform by LaserData.

Start with Laser SDK, run the Laser Stack locally, or try LaserData Cloud.