The complete guide to real-time streaming vs batch for agentic workflows

Who should use this guide?

This guide is for architects and engineering teams deciding where fresh events materially improve an agentic workflow without making the entire system continuous. It is most useful when a team is considering live user updates, presence, event-driven decisions, or faster responses to operational changes.

Role or situation	Fit	Why
Platform or solution architect	Strong	The rubric maps business latency needs to transport, storage, and processing choices.
AI/ML engineer deploying tool-using agents	Strong	It separates context freshness from model execution and token cost.
Product engineer building live status, support, dispatch, or collaboration	Strong	It identifies when UI and presence events justify real-time fan-out.
Data engineer modernizing scheduled ETL	Moderate	The hybrid patterns help, but engine-specific design still requires platform documentation.
Team doing offline analytics or periodic model training only	Poor	Batch is usually the clear default; a streaming platform is unlikely to add enough value.
Safety-critical or regulated system seeking certified thresholds	Poor without specialist review	The framework can structure the discussion, but it cannot replace domain risk analysis, validation, or regulatory guidance.

Skip the streaming move when no one can state an acceptable delay, identify who is harmed by stale data, or own the new event path. "It feels more modern" is not an SLO.

How should you decide whether a workflow step uses streaming, batch, or both?

First, let's start with the use case for streaming, and when it makes sense to work with batches. These rules are deliberately compact enough to use in an architecture review.

• Stream when a live participant can act within the SLO window: an operator becomes available, a device crosses a threshold, or a customer is watching progress.

• Batch work when the value comes from completeness, repeatability, and economical throughput: reconciliation, large aggregations, retraining, compliance exports, or deterministic verification.

• Use a hybrid when the live path and source of truth have different jobs: persist the event, publish a small notification, update a read model, and reconcile later.

• Gate model calls even when events stream continuously. Filter, debounce, cache, coalesce, or require a material state change before invoking an LLM.

• Keep business state durable. A notification can say something changed; a database or durable log should prove it and support recovery.

Before adding a streaming dependency, answer these questions:

• Does stale data cause measurable harm within a defined time window?

• Can a fresh event change the agent's next action?

• Is a person, device, or service waiting, or do multiple participants need the update?

• Can model calls be filtered or cached rather than triggered for every event?

• Is there a durable source of truth for replay, audit, and recovery?

• Are idempotency keys, versions, and event timestamps part of the contract?

• Can the team observe lag, duplicates, late events, and failed consumers—and recover when the live path is unavailable?

If the first three answers are "no," batch should remain the default. If they are "yes" but durability or operations answers are "no," build those foundations before streaming agent actions.

When it comes to adopting a scoring methodology, decide one step at a time with a weighted score: add points when freshness, fan-out, or live coordination creates value, and subtract points when determinism, replay, consistency, inference cost, or operational burden dominates. A total of 4 or more is a streaming candidate, -4 or less favors batch, and the middle usually calls for a hybrid.

Decision dimension	Batch signal	Hybrid signal	Streaming signal
Maximum acceptable delay	Minutes, hours, or scheduled	Seconds to minutes	Sub-second to a few seconds
Cost of stale state	Low and reversible	Noticeable but recoverable	Revenue, safety, or coordination harm grows quickly
User visibility and fan-out	No live consumer	A live status view plus offline processing	Many users, devices, or agents must react now
Work characteristics	Deterministic and idempotent	Agentic decision with deterministic side effects	Current context can change the next decision
Model inference cost	High per call or high event volume	Calls can be gated, cached, or coalesced	Calls are selective and budgeted
Replay and audit need	Full reruns are routine	Durable log plus live projection	Recent recovery is enough for the live path
Ordering and consistency	Global or transactional consistency	Per-entity ordering plus reconciliation	Loose or per-channel order is sufficient
Operational readiness	Limited streaming experience	Managed real-time layer plus durable systems	Mature observability, backpressure, and incident response

Calibrate these starting points against the real cost of delay and the capabilities of the team that will be on call.

What should increase the streaming score?

Add points for the following conditions:

• +3 — Low tolerance for delay: the maximum acceptable delay is measured in seconds or less.

• +3 — High staleness cost: old state can cause a wrong action, safety issue, lost sale, or rollback.

• +2 — User-visible progress: a person is waiting for status, feedback, or an agent response.

• +2 — Multi-party fan-out: several clients, services, agents, or operators need the same update.

• +1 — Live presence or ownership: the workflow needs to know who or what is connected, available, or responsible now.

What should increase the batch score?

Subtract points for the following conditions:

• -3 — Deterministic and replayable: the step is a pure transformation or aggregation that benefits from reruns.

• -2 — Large verifier surface: several automated or manual checks must reproduce the exact input and output.

• -2 — High inference cost: sending every event to a model would multiply tokens, latency, or spend.

• -2 — Strict cross-entity consistency: the result depends on a transaction or global order rather than a per-key sequence.

• -2 — Low operational readiness: the team cannot yet own offsets, late arrivals, duplicates, backpressure, and stream monitoring.

How should you interpret the score?

• 4 or more — streaming candidate: build a live path, but still persist business-critical events.

• -4 or less — batch candidate: keep the scheduled or queued flow and optimize its cadence before introducing streaming.

• -3 to 3 — hybrid candidate: stream a notification, state delta, or agent decision while retaining batch processing and reconciliation.

TIP: Score the same step with product, platform, data, and security stakeholders. A large disagreement is useful evidence that the SLO, failure behavior, or source of truth is not yet defined.

When it comes to low-latency, PubNub will publish messages in under 30 milliseconds worldwide, but delivery speed alone is not a decision rule; persistence, consistency, verification, and operational ownership must still be designed for the workflow.

Which agentic workflow scenarios belong in streaming, batch, or hybrid architectures?

Customer support, inventory, incident response, and long-running workflow status usually produce different answers at different steps, which is why a hybrid architecture is the production default. The examples below map the business need to the smallest useful real-time slice.

1. Customer support routing: use a hybrid

Routing combines queue state, agent availability, customer context, and sometimes an LLM or policy engine. The assignment must appear quickly, but the conversation, decision trace, and ownership history must remain auditable.

Persist the customer message, publish a compact triage event, and use PubNub Presence for agent availability. Write the assignment to the system of record, notify the interfaces, and batch historical conversations for quality analysis.

2. Inventory updates: batch the bulk work and stream storefront deltas

ERP imports and catalogue transformations are deterministic bulk processes. Storefront and checkout views need recent availability to reduce overselling.

Use change data capture (CDC) or application events to update a durable log, reconcile inventory in batch, and publish versioned availability deltas to storefront read models. The notification should identify the item and version, not replace the transactional inventory service.

3. Incident response: stream coordination and batch the investigation

Incident commanders, responders, automated agents, and dashboards need a shared timeline, live ownership, and prompt status changes. Root-cause analysis needs complete logs, repeatable queries, and a stable incident record.

Stream alerts, acknowledgements, presence, escalations, and status changes. Persist each event with a trace ID, then run correlation and post-incident analysis against durable history.

4. Long-running workflow status: use a CQRS-style hybrid

A user should not refresh a page for ten minutes to learn whether an agent has finished, but the heavy work does not need to execute as a continuous stream. Keep commands and results in the authoritative store, then project progress events into a fast read model and notify subscribed interfaces.

The companion reference architecture for real-time agentic workflows applies the same boundary: writes prove state; real-time messages distribute changes that affect immediate decisions.

5. Offline classification and model training: use batch

Weekly intent analysis, evaluation-set generation, embedding refreshes, and model training benefit from completeness and reproducibility. Unless an online feature needs incremental updates, schedule these tasks and version their inputs.

If no consumer benefits from the result within seconds, queues or batch runs are simpler to budget and validate—even when the work includes an LLM.

6. Human approval for a time-sensitive action: use a hybrid

The proposed action and current context should reach an available approver quickly, especially when the context can expire. The approval decision, policy version, evidence, and final side effect still require durable records.

Use a live channel for the request, a durable approval record, and a timeout that returns the task to a queue. Never interpret a missing response as approval.

For instance, PubNub Presence reports channel occupancy and user join, leave, timeout, and state-change events; Message Persistence can retain published messages with channel names and publish timetokens for later retrieval.

Which hybrid patterns make mixed real-time and batch systems safer?

Safe hybrid systems separate immediate distribution from durable truth and make every streamed update versioned, idempotent, observable, and recoverable. Five patterns cover most designs without forcing the real-time layer to become a database, workflow engine, and analytics platform at once.

How does change data capture feed live agent context?

CDC converts committed database changes into events for downstream consumers. Debezium's reference architecture shows how log-based connectors capture row changes for event consumers.

Publish only necessary fields or derived signals, with a source position, entity key, schema version, and timestamp. CDC still needs schema governance because a breaking change can spread quickly through live consumers.

When should events carry state rather than only identifiers?

Event-carried state transfer lets a consumer decide without a synchronous lookup. It reduces read amplification but increases payload size and exposure risk.

Use a minimal snapshot, apply token-based access control, version the contract, and keep sensitive records out of broad channels.

Why use CQRS-style read models for agent interfaces?

Using Command Query Responsibility Segregation (CQRS) read models keep authoritative writes in a transactional store and build fast projections for clients. A message triggers the update; the read model supplies the current view.

Display the last-updated version when users must judge freshness, and provide a repair process that rebuilds the projection from durable events.

When do you need a durable event log?

A durable log is the right companion when the team needs long retention, consumer-controlled replay, or high-volume downstream processing. Kafka, for example, stores events in partitions and preserves order within a partition; consumers can reread retained events from an offset.

Choose partition keys that match the ordering boundary, such as tenant_id or order_id. A global partition creates total order at the expense of parallelism.

What are the main implementation challenges, and how should teams solve them?

The hardest problems are not opening a stream; they are controlling ordering, duplicate side effects, inference volume, verification, authorization, and degraded operation. Address these boundaries before moving a decision or action from a scheduled path to a live one.

How do you handle duplicates, retries, and late arrivals?

Assume at-least-once delivery at system boundaries and design consumers to be idempotent. Give every event a stable ID, give each entity a monotonic version, and record the last applied version with the resulting state. Separate a retried delivery from a new business command.

For late arrivals, discard an older version, recompute from canonical state, or route the event to reconciliation. Do not let network arrival time overwrite business event time.

How do you prevent streaming from multiplying LLM cost?

Do not connect a high-volume topic directly to an expensive inference call. Filter irrelevant event types, debounce rapid changes, coalesce updates by entity, cache stable results, and trigger the model only when a decision boundary changes.

For example, stream location updates to a map but invoke a routing agent only when a vehicle crosses a geofence, the route becomes invalid, or an operator asks for a plan. Transport can be continuous while reasoning remains selective.

How do you preserve auditability for non-deterministic decisions?

Persist the input snapshot, model and prompt version, tool calls, policy version, verifier result, action, and correlation IDs. Use W3C Trace Context to propagate interoperable trace identity across HTTP boundaries.

Use the durable record for audit and the live channel for coordination. PubNub Message Persistence retrieves stored messages by timetoken; external storage may better suit complex queries and cross-system evidence.

How do you secure live context for agents and human operators?

Use least-privilege, time-limited credentials scoped to the channels and operations each participant needs. Avoid one broad tenant stream when consumers have different permissions. Redact or transform sensitive fields before delivery, and log grants, revocations, and privileged actions.

PubNub Access Manager supports time-limited tokens for channels and channel groups. PubNub Functions can block or transform messages before delivery or run asynchronous logic after publish; keep network calls out of latency-sensitive synchronous paths.

What happens when the real-time path is unavailable?

Define degraded behavior before launch: a UI can poll, an approval can remain pending, a device can buffer a bounded queue, and a non-critical agent can pause. Safety-sensitive actions should fail closed or require durable confirmation.

Test disconnects, replay gaps, slow consumers, unavailable verifiers, and duplicate notifications. Recovery and data-loss objectives belong in the design review alongside latency.

What are the honest limitations of this decision framework?

The deterministic-versus-agentic lens is a useful first cut, not proof that a system belongs in streaming or batch. Combine it with domain risk, measured volume, cost, consistency, data residency, vendor limits, and operating capacity.

1. Non-determinism does not define latency. An agentic step can be slow, asynchronous, and safely queued. A deterministic step can be time-critical. The staleness window remains the primary question.

2. Real-time transport does not make slow reasoning real time. Model inference, tool calls, rate limits, and verifier queues may dominate end-to-end latency even when message delivery is fast. Measure from source event to accepted action, not broker ingress to broker egress.

3. "Exactly once" rarely spans the whole business workflow. A platform may offer exactly-once processing within defined boundaries, yet an external payment, email, device command, or database write can still be repeated after a failure. Use idempotency keys and compensating actions at side-effect boundaries.

4. Hybrid systems move complexity rather than erase it. Separate stores and projections create reconciliation, schema evolution, and eventual-consistency work. The team still owns the seams.

5. The proposed score is not an industry benchmark. Its weights expose trade-offs. Change them when a safety case, revenue model, regulation, or measured workload shows a different cost of delay.

6. Product capabilities and limits change. Verify current message-size, retention, throughput, regional, and pricing requirements against the chosen provider's documentation and contract before implementation.

How does the streaming decision fit into the broader agentic workflow stack?

Streaming is the delivery and coordination layer between changing operational state and consumers; it is not the entire agentic platform. A production design normally includes six distinct responsibilities, each with its own latency, storage, and trust boundary.

• Systems of record: databases and business services validate commands and own canonical state.

• Durable event and batch layer: logs, queues, warehouses, and scheduled jobs support replay, reconciliation, analytics, evaluation, and training.

• Real-time distribution layer: channels, subscriptions, and presence events deliver compact changes to connected users, devices, services, and agents.

• Context and read-model layer: caches, materialized views, and the companion live context graph provide small, current, versioned context slices.

• Agent and tool layer: models, policies, tools, and orchestration select proposed actions using authorized context.

• Verifier and audit layer: automated checks and human approvals accept, reject, record, and review decisions.

For every event, define who created it, where canonical state lives, who may consume it, how long it is valid, and how consumers recover from gaps.

Where does PubNub fit in a hybrid agentic architecture?

PubNub fits the low-latency distribution and presence portion of a hybrid architecture: it can fan out small events to connected clients, show who or what is online, and retain selected messages for recovery, while databases and durable logs continue to own transactional truth and long-term processing.

Does PubNub replace Kafka in an agentic workflow?

Not generally; PubNub and Kafka optimize different responsibilities and can be complementary. PubNub is suited to low-latency fan-out, connected-client updates, and presence, while Kafka is suited to durable event retention, partitioned processing, and consumer-controlled replay. The correct boundary depends on clients, retention, processing, and operational requirements.

Use Publish/Subscribe for workflow notifications, state deltas, tool results, and user-visible progress. Use Presence when routing depends on whether a human, device, or agent is connected. Use Message Persistence for the recovery window appropriate to the application, or route selected events to external systems for longer retention and analysis.

A pragmatic flow looks like this:

1. An API validates the command and writes canonical state to a database or durable event log.

2. The backend publishes a small, versioned notification to a scoped PubNub channel.

3. A user interface or agent receives the update and fetches full context only when the event does not safely carry it.

4. The agent records its proposal, evidence, and tool results in durable storage.

5. A verifier approves or rejects the proposal; the accepted side effect is executed idempotently.

6. PubNub notifies subscribed users and agents of the resulting status.

Against a do-it-yourself connection layer, PubNub can remove client connection, channel, presence, and fan-out work. It does not remove the need for business persistence, idempotency, or agent verification.

Conclusion: when should agentic workflows use real-time streaming instead of batch?

Use real-time streaming when the value of fresh state and live coordination exceeds the added cost of continuous delivery; use batch when repeatability, completeness, and economical processing matter more than immediate reaction. For most production agentic workflows, implement the boundary as a hybrid rather than choosing one mode for the whole system.

• Decide locally: score every workflow step, not the application as a whole.

• Lead with staleness: define who is harmed, how quickly, and by how much when state is old.

• Keep truth durable: persist canonical business events and make streamed consumers idempotent.

• Separate events from inference: stream continuously if needed, but gate expensive or non-deterministic reasoning.

• Design failure first: test disconnects, duplicates, replay gaps, late events, unavailable verifiers, and degraded operation.

Talk to PubNub about your real-time architecture when you are ready to validate the streaming slice of an agentic workflow.

Related guides

• Reference architecture: real-time data for agentic workflows — Map freshness requirements across perception, reasoning, action, verification, and audit.

• Build a live context graph for agentic workflows — Use CDC, incremental materialization, and versioned deltas to supply fresh context.

• PubNub Presence dashboard walkthrough — See how online state and channel occupancy support live coordination.

• How PubNub's data communication interface works — Explore PubNub patterns for routing real-time application data.