Guides  /  Streaming and flow control

How do you feed real-time data into an agent’s context?

Answer

An agent answers from the state it holds when the turn begins. The freshness of its context is set by the path the data took to reach that state, and a store the agent polls on a schedule carries whatever staleness the schedule allows.

Akka runs stream processing in the same runtime that executes the agent. A consumer applies the arriving event to the durable state, and the next turn reads that state in under 10ms.

The mechanism

The path the data takes decides how old the context is.

A price moves, a position limit changes, an order ships. An agent reasoning about any of those answers from what it read at the start of the turn, so an update arriving after the read is invisible to that answer.

The common path sends the event to a broker, then to a stream job, then to a store the agent queries. Each hop adds latency to the age of the context and each is provisioned, scaled, secured and billed on its own.

A consumer component running in the agent runtime subscribes to the event and writes the state the agent reads. The write and the read are in the same system, so the update is available to the next turn without crossing a network.

THROUGH A SEPARATE PIPELINEeventbrokerstream jobstoreagent turnpolledIN THE RUNTIME THAT EXECUTES THE AGENTeventconsumeragent stateagent turnno network hop
What the path has to deliver

A context feed is judged on order, durability and read cost.

Order within a subjectEvents for one customer or one instrument are applied in the order they occurred, so the state the agent reads is internally consistent.
Flow control on the feedA burst of updates is held to the rate the consumer sustains, so the feed survives the spike that made the data worth reading.
A durable writeThe applied event is recorded in the journal, so a restarted or rescheduled agent reads the same context it had before.
A read the turn can affordEvery turn reads the context, so the read has to sit inside the latency budget of the response.
What this changes

The feed stops being a system of its own.

Agents, memory, orchestration, streaming and endpoints run on shared compute in the Akka runtime. Streaming carries no separate throughput bill, because throughput is a property of the platform the agents already run on.

Fox shrank its AI personalization engine from 150,000 cores to 22,000 after porting to Akka, and that shared model is what the reduction measures.

Questions

Related questions.

How fresh is the context on the next turn?

The consumer applies the event as it arrives and the agent reads its own state in under 10ms, so the turn sees every update the runtime has applied by the time it starts.

Do we still need a message broker?

A broker moves events between systems, and the messaging systems an enterprise already runs are integrated into the runtime. Events produced by components inside the system are already in the journal, so a consumer subscribes to them directly.

What about data in a system we cannot stream from?

Retrieval during the turn is a tool call, and its latency is paid on the response path. A feed suits data that changes continuously and is read on most turns.

Does a burst of updates slow the agent down?

Backpressure holds the feed to the rate the consumer sustains. The agent turn reads state, so the depth of the feed does not appear in the response time.

On Akka. Consumers, views, real-time stream processing and sub-10ms durable memory are described in the Akka SDK documentation. Customer figures. Fox results are reported by the customer.