Hmm… maybe LangGraph’s conditional workflow could be useful here?
Yes — I think the architecture you described is quite feasible in LangGraph.
I would probably start a little simpler than a full multi-agent setup, while keeping exactly the same product goal. Your flow already has a fairly clear decision boundary:
Chat UI
-> Python API
-> LangGraph
-> retrieve/search FAQ + rules
-> is that enough to answer?
|-- yes -> answer from FAQ/rules
`-- no
-> does this request need user-specific data?
|-- yes -> fetch authorized user data
| -> combine with FAQ/rules
| -> answer
`-- no -> clarify / fallback
That can be implemented as one explicit LangGraph workflow first. If one branch later becomes much larger — for example it gets its own prompt, many tools, separate permissions, independent context, or genuinely independent work — that branch can become its own subgraph or specialist agent later without changing the overall design.
The current LangChain/LangGraph docs are useful here because they treat custom workflows and routers as first-class patterns. A complex application does not automatically need several autonomous agents; when the categories are fairly explicit, a conditional graph is usually easier to inspect, test, and debug.
I would separate five things from the beginning:
thread_id and a checkpointer.
That separation is probably more important than deciding whether you have one agent or two agents.
Why I would start with one conditional workflow So my suggested first version would be:
1. One explicit LangGraph conditional workflow.
2. FAQ/rules as semantic retrieval.
3. Private structured user data as authenticated DB/API tools.
4. Stable thread_id + persistent checkpointer for conversation continuity.
5. Treat "last 7" as a model-context policy, not automatically a storage policy.
6. Add user-scoped long-term memory only for facts that really should cross threads.
7. If you literally use HF Chat UI, add a small OpenAI-compatible adapter and decide
how Chat UI conversation IDs map to LangGraph thread IDs.
8. Promote a branch into its own agent/subgraph only when it develops genuinely
independent complexity.
A tiny route test set plus a two-user isolation test would probably tell you more at this stage than adding another agent immediately.