Orchestrator

The Orchestrator is the long-lived, stateful service that owns a user's conversational session. It is the only agent in the system that has direct access to member and trip state.

Responsibilities

• Holds the active session: member context, trip state, conversation history
• Runs the LLM loop that decomposes, dispatches, and synthesizes
• Calls the internal tool cascade to load context
• Enqueues jobs to Redis/Valkey and tracks their lifecycle
• Persists results as workers complete

State

In-memory (working copy):

• The current turn's context
• Pending job IDs and their expected agents
• Intermediate results as they arrive

Persistent (source of truth):

• Database (Postgres), member profile, trip metadata, conversation history
• Redis, session state for fast recovery (see Scaling)

What the Orchestrator Does Not Do

• It does not perform research. Specialists do.
• It does not call external travel/dining/hotel APIs directly. Workers do.
• It does not expose member state to workers. It only passes scoped briefs.

Input / Output

Receives: A user message (text, structured intent, or both) plus the session_id.

Produces: A user-facing response plus any persisted state updates.

The Orchestrator is the only place where a member's full context is in scope. Workers see a narrow slice of it. This boundary is the security and privacy model of the system.

Failure Recovery

If the Orchestrator instance handling a session dies, the next request hits a different instance, which reconstructs session state from the database and Redis, re-reads any completed worker results, and resumes. See Failure Modes.