Job Lifecycle

A user request flows through the system in six steps.

Sequence

Note: LPUSH adds items to a Redis list; BRPOP blocks until an item is available; SUBSCRIBE listens for events.

Steps in Detail

1. Load context: The Orchestrator calls the tool cascade to establish working context, situational context, and a pre-filtered shortlist.
2. Dispatch: The Orchestrator enqueues one job per specialist to Redis. Independent jobs go in parallel.
3. Execute: Workers pull from their queues, run their tools and LLM, and write structured results to result:{job_id}.
4. Synthesize: The Orchestrator aggregates results as they arrive, with a per-job timeout. It may re-plan if results conflict (see below).
5. Persist: Final state and any confirmed reservations are written to the database.
6. Respond: The user-facing answer is returned to the channel.

Conflict & Re-planning

If worker outputs conflict (e.g., the three best options all blow the budget), the Orchestrator re-plans rather than forcing a bad answer. It may:

• Re-dispatch with tighter constraints
• Re-dispatch to a different specialist
• Surface the trade-off to the user and ask

This is the plan-then-execute loop layered on top of the basic orchestrator-worker pattern.