Job Queue (Redis / Valkey)

Redis/Valkey acts as the message bus between the Orchestrator and the Research Agents. Each specialist has its own queue.

Why Redis/Valkey

• Sub-millisecond enqueue/dequeue
• Built-in primitives: lists, streams, pub/sub, sorted sets
• Valkey is the open-source fork, drop-in compatible, no licensing concerns
• Supports delayed jobs, retries, dead-letter queues via patterns or libraries (BullMQ, Celery, RQ, or raw Streams)

Queue Topology

Two viable models:

• Per-agent queue (e.g., jobs:dining, jobs:hotels), simpler routing, each worker pool reads its own
• Single stream with consumer groups, better observability, flexible rebalancing, slightly more complex

Pick per-agent queues unless you need rebalancing.

Job Payload Schema

{
  "job_id": "uuid",
  "session_id": "uuid",
  "orchestrator_id": "orch-123",
  "agent_type": "dining",
  "task": "Find 3 dinner reservations in Tokyo for Feb 13-17, party of 2",
  "constraints": {
    "cuisines": ["sushi", "kaiseki", "izakaya"],
    "max_price_per_person": 200,
    "neighborhoods": ["Ginza", "Shibuya", "Roppongi"],
    "dietary": ["no_pork"]
  },
  "curated_shortlist": ["sukiyabashi-jiro", "den", "kyubey"],
  "result_format": "RestaurantOption[]",
  "created_at": "...",
  "ttl_seconds": 60
}

Result Delivery

Workers write results to result:{job_id} and publish a completion event. The Orchestrator subscribes or polls depending on volume.

Queue Depth as a Signal

Queue depth per agent type is the primary autoscaling signal. See Scaling.