From Human Realtime to Agent Realtime

NoLag was built to power human real-time experiences: chat rooms where people exchange messages, dashboards where operators monitor live data, and tracking systems where dispatchers watch vehicles move on a map. When we started exploring multi-agent AI systems, we realized the infrastructure we built for humans maps almost perfectly to agent coordination.

This post explains how NoLag's real-time primitives translate to agent coordination patterns, the design decisions we made for each, and the performance characteristics that matter for agent workloads.

The Mapping

Real-time messaging has three core primitives: topics (named channels for routing), rooms (groups of related topics), and presence (who is connected). Agent coordination has the same three needs: task routing, workflow grouping, and agent health tracking.

// Human chat: messages flow between users in a room
room:general:messages    // QoS 2, retained, 7-day replay
room:general:typing      // QoS 0, ephemeral
room:general:presence    // QoS 1, retained

// Agent coordination: same primitives, different semantics
_handoff/dispatch        // QoS 2, retained - task queue
_handoff/result          // QoS 2, retained - result queue
_blackboard/state        // QoS 2, retained - shared state
_observe/events          // QoS 1 - event stream
_approve/request         // QoS 2, retained - approval queue
_tools/invoke            // QoS 2 - tool calls

The topic names change. The semantics are different. But the underlying infrastructure - message routing, delivery guarantees, persistence, and fan-out - is identical.

Topics as Task Queues

In a chat app, a topic is a channel where messages flow from publishers to subscribers. In an agent system, a topic is a task queue. The Handoff pattern uses _handoff/dispatch as a work queue: the orchestrator publishes tasks, workers subscribe and claim them.

The key property that makes this work is QoS 2 (exactly-once delivery). In chat, QoS 2 prevents duplicate messages. In agent coordination, QoS 2 prevents duplicate task execution. A task dispatched once must be claimed by exactly one worker and completed exactly once.

Retained messages serve a different purpose in each context. For chat, retention means message replay - catch up on history after reconnecting. For agents, retention means task persistence - if no worker is online when a task is dispatched, it waits until one connects.

Presence as Health Monitoring

Human presence is simple: online, away, or offline. Agent presence needs more metadata: capabilities, current load, and health status. We extended the presence payload to carry this information without changing the underlying protocol.

// Human: "Alice is online in #general"
{
  actorId: "user-alice",
  rooms: ["general", "random"],
  status: "online",
  lastSeen: "2024-01-15T10:30:00Z"
}

// Agent: "research-worker-3 is available with 2/5 task slots"
{
  actorId: "research-worker-3",
  rooms: ["research-workflow"],
  status: "available",
  capabilities: ["research", "finance"],
  concurrency: { current: 3, max: 5 },
  lastHeartbeat: "2024-01-15T10:30:00Z"
}

The Handoff pattern uses presence to make routing decisions. When a task arrives with required capabilities, the system checks which workers are present, which have matching capabilities, and which have available capacity. This is the same fan-out logic that routes chat messages to room members, extended with capability-based filtering.

QoS Levels for Different Patterns

Not every agent message needs the same delivery guarantee. Just like in human real-time, the right QoS level depends on the consequence of a lost or duplicated message.

// QoS 0 (fire and forget): typing indicators, cursor positions
// Lost messages are harmless - next update overwrites anyway
room.observe.on("cursor:move", handler);  // Agent equivalent: ephemeral status

// QoS 1 (at least once): notifications, event stream
// Duplicate delivery is acceptable - events are idempotent
room.observe.on("task:completed", handler);

// QoS 2 (exactly once): chat messages, task dispatch
// Critical path - duplicates or missed messages break the workflow
room.handoff.dispatch({ ... });  // Must be delivered exactly once

This is one of the advantages of building on real messaging infrastructure rather than a custom agent framework. QoS levels are a solved problem in messaging. We don't need to reinvent delivery guarantees - we just map each pattern to the appropriate level.

Rooms as Workflow Boundaries

In chat, rooms group related conversations. In agent coordination, rooms group related workflows. A room called research-pipeline contains all the topics for that pipeline: task dispatch, results, shared state, and events. A separate room called content-review contains its own isolated set of topics.

This isolation is important. Just as you don't want messages from #general leaking into #engineering, you don't want tasks from one workflow accidentally being picked up by workers in another. Rooms provide that boundary for free.

Performance Characteristics

Agent workloads have different performance profiles than human real-time:

Agent workloads typically involve fewer connections but larger payloads and stricter delivery requirements. NoLag's 256KB message size limit accommodates most LLM outputs. The binary MessagePack protocol keeps overhead low even for large payloads. And QoS 2 with message persistence ensures no task is lost, even during worker restarts.

Access Control Carries Over

In human systems, access control prevents unauthorized users from reading messages in rooms they haven't joined. In agent systems, the same ACL mechanism prevents agents from accessing workflows they shouldn't participate in.

Each agent connects with an actor token that grants access to specific apps and rooms. A research worker can only subscribe to topics in the research workflow. A monitoring dashboard can observe events but not dispatch tasks. The same per-topic ACL that protects chat messages protects agent coordination.

The Insight

Agent coordination is a real-time messaging problem wearing a different hat. The primitives are the same: publish, subscribe, presence, persistence, and access control. The patterns change (task handoff instead of chat messages, blackboard instead of typing indicators, approval gates instead of read receipts), but the infrastructure doesn't.

That's why we built @nolag/agents as a high-level SDK on top of the same core infrastructure. No new servers, no new protocols, no new persistence layer. Just new patterns mapped onto proven primitives.

Explore @nolag/agents →