Appearance
Research Agents
Research Agents are the specialists. Each owns a focused domain (dining, hotels, visas, local transit, etc.) and is an independent service with its own tools, model, and scaling characteristics.
Contract
From the Orchestrator's perspective, every Research Agent is opaque. The Orchestrator knows:
- The agent's name
- Its expected input shape (the job payload)
- Its expected output shape (the result format)
Anything else is an implementation detail.
Internal Anatomy
Each agent typically has:
- A worker process pool pulling jobs from its queue
- Its own LLM configuration (model, temperature, system prompt)
- Its own tools (dining reservation APIs, hotel booking APIs, visa rules DBs, etc.)
- Its own scaling characteristics
Example: The Dining Agent
- Tools: OpenTable, SevenRooms, Resy, direct restaurant APIs, review aggregators
- Typical input: A scoped brief with cuisines, neighborhoods, budget, party size, dietary restrictions, and a curated shortlist
- Typical output: An array of
RestaurantOptionobjects with availability windows, price estimates, and notes - Latency budget: 5–15 seconds
What Workers Don't Have
- Member profile data
- Trip context
- Other workers
- The Orchestrator's tool cascade
A worker that needs to ask a clarifying question cannot. It must return a structured result (success, partial, or failed) and let the Orchestrator handle the conversation.
Worker Process Lifecycle
- Pull job from Redis (blocking pop with timeout)
- Execute the research task using its tools and LLM
- Write result back to
result:{job_id} - Notify the Orchestrator (pub/sub event or HTTP callback)
- Ack the job
The "Abstracted Server" Framing
The Orchestrator doesn't care if the Dining agent is a Python service using Claude with tool use, while the Hotels agent is a Node service calling a fine-tuned small model. They all look the same to the queue. This lets us evolve each specialist independently (swap models, change tools, rewrite in a different language) without touching the rest of the system.