Hi everyone,
I’m currently working on a fairly large healthcare conversational use case and would appreciate advice from the community on architecture and best practices.
Use Case Overview
The assistant is expected to handle end-to-end patient journeys, including (but not limited to):
- Fetching patient information
- Fetching a patient’s appointment details
- Confirming or cancelling appointments
- Booking appointments:
- Asking the user about symptoms
- Fetching hospitals near the user’s location
- Fetching clinics based on the selected hospital
- Fetching available doctors with dates and time slots
- Supporting both “nearest available” appointments and bookings on a specific date
- Sending appointment details via SMS or WhatsApp
- Sending hospital location via SMS or WhatsApp
- Fetching and updating insurance details
- Fetching insurance status
- Fetching user-submitted queries to doctors
All backend capabilities are exposed as tools via an MCP server.
Current Architecture
I’m using a multi-agent architecture:
- A supervisor agent created using
create_agent
- Multiple sub-agents, also created using
create_agent, exposed as tools to the supervisor
- Each sub-agent owns a specific domain and has access to its own set of tools
Challenges
- Flow reliability
In complex scenarios (especially booking), the supervisor sometimes skips steps or jumps ahead, even though the steps are logically required.
I’m concerned about whether this architecture can reliably handle all edge cases and long, structured workflows without missing mandatory steps.
- Bilingual support (Arabic & English)
- ~90% of usage will be in Arabic, ~10% in English
- Arabic responses require heavy customization:
- Strict response structures for hospital lists
- Different formatting rules for doctor lists, appointment slots, confirmations, etc.
- This currently requires a lot of prompt-level instructions, and I’m worried about prompt complexity, maintainability, and consistency.
What I’m Looking For
I’d love guidance on:
- Whether this supervisor + sub-agent pattern is the right approach for such deterministic, step-heavy workflows
- Techniques to enforce step-by-step execution (e.g., state machines, planners, guardrails, or explicit workflow validation)
- Best practices for handling highly structured, multilingual responses, especially when one language (Arabic) dominates and has strict formatting requirements
- Any real-world patterns you’ve used successfully for similar healthcare or booking flows in LangChain
Any suggestions, examples, or references would be greatly appreciated.
Thanks in advance! 
@razaullah, instead of creating multiple agents, I’d suggest trying the new sub-agent workflow in DeepAgents. You can have a single primary agent, with sub-agents exposed as tools for each workflow or domain. This is a adpation of Supervisor Architecture but is much more reliable as opposed to creating individual nodes for each of your agent since when invoking agents as tool, the execution condition can be made more clearer to main agent..
You can take a look at Sub-Agents as Tools (DeepAgents): Subagents - Docs by LangChain .
For highly structured, multilingual responses, I’d recommend two things:
@keenborder786 Thank you very much for your response. I had use the same approach i.e. one supervisor agent declared using the create_agent and other sub_agents exposed as tools to the supervisor using the same create_agent function.
I think you are talking about the same.
@razaullah Ahh, I see, I am referring to the same. I think so, then you are following the best approach. Just make sure that execution conditions in tool description for each sub agent are clear and well-structured….
Okay. Thank you very much for your time.
Hi @razaullah ,
Use Case
A healthcare assistant handling complex, step-driven workflows like:
-
Patient info retrieval
-
Appointment booking (multi-step)
-
Hospital → clinic → doctor → slot selection
-
Insurance management
-
SMS/WhatsApp notifications
-
Arabic-first multilingual support
-
All backend logic exposed via MCP tools
Current Architecture
-
Supervisor agent (create_agent)
-
Multiple sub-agents (also create_agent)
-
Sub-agents exposed as tools to the supervisor
-
Each sub-agent owns a specific domain
Main Challenges
-
Flow reliability
-
Arabic-heavy structured responses
Community Guidance
-
The supervisor + sub-agent (sub-agents-as-tools) pattern is valid.
-
Ensure tool descriptions clearly define execution conditions.
-
Make invocation conditions explicit and structured.
-
Use strict=True for structured outputs.
-
Add a dedicated ## Language section in prompts to enforce Arabic/English behavior.
Key Takeaway
The architecture is sound, but:
-
Reliability depends heavily on clear tool descriptions
-
Deterministic workflows may benefit from stronger state control
-
Structured multilingual output should rely more on schema enforcement, less on long prompts
Hi @Bitcot_Kaushal
Thank you for your time. The only point I didn’t fully understand was your comment about ‘deterministic workflows may benefit from stronger state control.’ Could you elaborate on how we can make the state more controllable in this type of architecture?
I appreciate your insights and look forward to your response.
Thanks in advance!
Best regards,
Raza
@Bitcot_Kaushal Also I am sharing one of the tool name, description and it’s purpose, I need your guidance how this description can be improved for better control by the agent.
Name of the tool: mssql_confirm_appointment
Description: [MSSQL] [MSSQL] Confirms an existing patient appointment in the HIS system. IMPORTANT: Use AppointmentNo from the appointment details. Do NOT use SetupID. The appointment is identified using appointment_no and project_id.
Purpose: This tool is used for confirming an appointment of a patient.
Please review it and let me know your insights regarding this too.
Thanks
Hey @razaullah ,
What I meant by “stronger state control”
Right now your supervisor is reasoning freely each turn. That works for open-ended tasks, but booking flows are deterministic (Hospital → Clinic → Doctor → Slot → Confirm).
To make this more controllable:
Option A — Explicit Workflow State (Recommended)
Maintain a structured state like:
{
"workflow": "appointment_booking",
"step": "select_doctor", # hospital_selected | clinic_selected | ...
"hospital_id": ...,
"clinic_id": ...,
"doctor_id": ...,
"slot_id": ...
}
Then:
This turns the flow into a guided state machine, not pure LLM reasoning.
Option B — Guardrail Before Tool Execution
Before calling a tool, validate:
If not → respond with corrective prompt instead of executing.
Option C — Split Deterministic vs Conversational
Let:
This is the most reliable pattern for healthcare.
Improving Your Tool Description
Current:
Confirms an existing patient appointment…
This is too loose for deterministic control.
Better version:
[MSSQL] Confirms an existing appointment in the HIS system.
Execution Conditions:
- Use ONLY after appointment slot has been selected.
- Requires: appointment_no (NOT SetupID) and project_id.
- appointment_no must come from previously fetched appointment details.
- Do NOT fabricate or infer values.
Do NOT call this tool if:
- appointment_no is missing
- appointment is already confirmed
- user has not explicitly agreed to confirm
Why this works:
In Short
For healthcare booking:
-
Don’t rely purely on agent reasoning.
-
Introduce explicit workflow state + step gating.
-
Make tool descriptions rule-based, not just descriptive.
-
Treat booking like a state machine, not free conversation.
That’s what I meant by “stronger state control.”