Chat ui with multi agent and history - langraph

A developer guidance post recommends starting a chat UI with history as a single explicit LangGraph conditional workflow rather than a full multi-agent setup, routing requests through FAQ/rules retrieval and authenticated user-data tools. The post advises separating thread_id and a persistent checkpointer from the start, treating "last 7" as a model-context policy rather than a storage policy, and promoting a branch into its own agent or subgraph only when it develops genuinely independent complexity. It points to LangChain/LangGraph documentation on custom workflows and routers as first-class patterns and suggests a small route test set plus a two-user isolation test before adding another agent.

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: php 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 https://docs.langchain.com/oss/python/langchain/multi-agent/custom-workflow and routers https://docs.langchain.com/oss/python/langchain/multi-agent/router 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.