Hi @razaullah

This is a really solid and realistic healthcare use case. You’re right to be concerned about reliability, especially for booking flows where steps are mandatory and can’t be skipped.

Based on similar structured workflows I’ve worked on, I’d suggest slightly shifting the architecture rather than relying fully on a supervisor + sub-agent setup.

1. Supervisor + Sub-Agents

That pattern is powerful for reasoning-heavy or open-ended tasks, but for deterministic, step-by-step flows (like booking), it can become unpredictable. LLMs are probabilistic planners, so they may occasionally skip or reorder steps.

For booking pipelines, I would strongly recommend using LangGraph with explicit state and controlled transitions.

2. Move Booking to a State-Driven LangGraph

Instead of letting a supervisor decide the flow dynamically, define a state object and explicit nodes.

Example state:

from typing import TypedDict, Optional

class BookingState(TypedDict):

patient_id: str

symptoms: Optional\[str\]

hospital_id: Optional\[str\]

clinic_id: Optional\[str\]

doctor_id: Optional\[str\]

slot_id: Optional\[str\]

confirmed: bool

step: str

Each node performs one atomic action:

1. collect_symptoms
2. fetch_hospitals
3. select_hospital
4. fetch_clinics
5. fetch_doctors
6. select_slot
7. confirm_booking
8. send_notifications

Example node:

def collect_symptoms(state: BookingState):

if state\["symptoms"\]:

    return state

\# ask user for symptoms here

state\["step"\] = "awaiting_symptoms"

return state

Example conditional transition:

def route_after_symptoms(state: BookingState):

if not state\["symptoms"\]:

    return "collect_symptoms"

return "fetch_hospitals"

This guarantees that hospitals are never fetched before symptoms are present, etc. The graph enforces order instead of the LLM.

3. Hybrid Pattern (Recommended)

Use the LLM for:

1. Intent classification
2. Extracting structured fields from user messages
3. Clarification questions

Use LangGraph for:

1. Workflow control
2. Mandatory step enforcement
3. Tool execution
4. State validation

Think of it as:

LLM = interpreter

Graph = controller

This pattern tends to be much more stable in production.

4. Enforcing Step Reliability

A few practical suggestions:

1. Validate required fields before every transition.
2. Keep tool calls idempotent (especially for booking/cancellation).
3. Persist state in Redis or a database.
4. Log every state transition for audit (important in healthcare).

Add guard nodes like:

def validate_required_fields(state: BookingState):

required = \["hospital_id", "doctor_id", "slot_id"\]

for field in required:

    if not state.get(field):

        return "collect_missing_info"

return "confirm_booking"

In healthcare systems, determinism and traceability matter more than agent cleverness.

5. Arabic + English Strategy

I would strongly avoid solving strict formatting purely in prompts. That becomes fragile and hard to maintain.

Instead:

1. Have the LLM return structured JSON.
2. Use a separate rendering layer for Arabic and English.

Example LLM output:

{

“hospitals”: [

{"id": "1", "name": "Al Noor Hospital", "distance_km": 3.2}

]

}

Then format in code:

def render_hospitals_ar(data):

return "\\n".join(

    \[f"{i+1}. {h\['name'\]} - {h\['distance_km'\]} كم"

     for i, h in enumerate(data\["hospitals"\])\]

)

This keeps:

1. Prompts simpler
2. Formatting deterministic
3. Arabic structure fully controlled

The LLM should handle reasoning and extraction, not presentation rules.

6. Where Multi-Agent Still Makes Sense

Multi-agent is still useful for:

1. Insurance Q&A
2. General medical inquiries
3. Doctor-submitted questions
4. Knowledge retrieval (RAG)

But for strict booking pipelines, a graph-based workflow is usually safer.

7. High-Level Architecture Suggestion

Intent Classifier

→ Route to:

1. Booking Graph
2. Insurance Graph
3. General Q&A Agent
4. Escalation / Human Handoff

This prevents a supervisor from hallucinating control flow in critical paths.