GustoBot: a three-layer LangGraph agent stack for recipe Q&A

The problem GustoBot picks: recipe questions that span tables, graphs and prose

Recipe knowledge does not sit in one shape. Ingredient amounts and cooking steps are structured. Historical anecdotes and regional cooking culture are prose. Cuisine counts and rankings are aggregations. A keyword search over a single index handles none of these well, and a single retrieval-augmented pipeline tends to answer the structured half badly. GustoBot's stated goal is a customer service bot for Chinese recipe knowledge that answers all three kinds of question from one conversational entry point. The README frames the project as a template rather than a finished product: a three-layer design that can be moved to another vertical by swapping the knowledge source and graph schema. The examples it gives for that migration are a Pokémon encyclopedia, a traditional medicine reference, legal consultation and government services. That framing matters when you evaluate it. The interesting part is the orchestration skeleton, not the recipe corpus.

Routing, subgraphs and a fixed retrieval fallback order

The architecture is three layers. L1 is a main router node, analyze_and_route_query, which combines heuristic keyword matching with an LLM that emits structured output against a Router Pydantic model. A conditional edge named route_query then sends the request down one of several branches: general-query, additional-query, graphrag-query, text2sql-query, kb-query, image-query or file-query. L2 holds the tool subgraphs. The GraphRAG subgraph starts at create_research_plan, and the knowledge base path starts at create_kb_query. Inside a subgraph the flow is Guardrails check, planner decomposition, tool selection, parallel tool calls, then a Summarize Node that merges results before a final answer is produced. L3 is the atomic tool layer: Neo4j for graph queries, MySQL for statistics, Milvus and PostgreSQL for semantic retrieval. The retrieval order is explicit and worth noting. Structured data from PostgreSQL pgvector is tried first, Milvus vector search is the fallback, and an external search API is the last resort in hybrid mode. That is a deliberate design choice: prefer the precise store, degrade to semantic recall, then go outside. The planner uses a Map-Reduce shape, splitting a complex question into independent subtasks that call different tools in parallel before summarization. Retrieval in the PostgreSQL path is filtered by two thresholds, KB_POSTGRES_SIMILARITY_THRESHOLD and KB_POSTGRES_RERANK_THRESHOLD, with support for Cohere, Jina, Voyage and BGE rerankers. Conversation state is held by a LangGraph Checkpointer backed by Redis.

Getting it running: Docker for the backend, npm for the frontend

The README gives a short setup path. Clone the repository, copy .env.example to .env and fill in the API keys, then run docker-compose up -d for the backend. The frontend is installed locally: cd web, npm install, npm run dev. The documented defaults are http://localhost:5173 for the frontend, changeable through VITE_PORT, and http://localhost:8000 for the backend API. Prerequisites are Python 3.10, Node.js 16 or newer, and Docker with Docker Compose. What the README does not give is a per-service breakdown of the compose file, a list of which environment variables are mandatory versus optional, or a migration and seeding procedure for Neo4j, MySQL, Milvus and PostgreSQL. Because four datastores plus Redis sit behind one compose command, expect the .env file to be the real configuration surface, and expect to read the compose file and the settings module yourself before the stack comes up cleanly. The repository also links a fine-tuned model download through a Baidu Pan URL, which suggests the authors expect you to supply model weights rather than pull them automatically.

Data provenance is the weakest part of the repository

The README is unusually direct here, and it deserves credit for that. The bundled recipe master data comes from OpenKG RecipeGraph. Beyond that, the README states that some historical food texts and eight pgvector sample records have no verifiable upstream source retained in the original commit, and that they are suitable only for pipeline demonstration. That is a real constraint, not a footnote. If you plan to expose this bot to users, the demo records are not a corpus you can stand behind, and you will need to replace them before the retrieval thresholds mean anything. The README points to docs/DATA_SOURCES.md for full lineage, usage and licence notes. Apache-2.0 covers the code in this repository. It does not automatically cover third-party datasets pulled in at runtime, and the project itself flags that distinction. Read that document before you ship anything built on the bundled data.

Where the design will fight you

The PostgreSQL-first fallback is a good default for recipe facts and a poor one for open-ended cultural questions. A question about the history of a dish will miss the structured lookup, fall through to Milvus, and only then reach external search, which adds latency to exactly the queries where users expect a fast, readable answer. The dual-threshold reranker is the mitigation, but it is also a tuning surface: set KB_POSTGRES_SIMILARITY_THRESHOLD and KB_POSTGRES_RERANK_THRESHOLD too high and you fall through to Milvus constantly, too low and you answer from weak matches. Nothing in the supplied material states default values or guidance for setting them. The Guardrails layer is described as a scope check with schema validation for Neo4j, but the README does not describe how rejection is evaluated or what happens when a legitimate question sits near the domain boundary. And the whole stack assumes you can operate Neo4j, MySQL, Milvus, PostgreSQL and Redis. For a team that wants a recipe bot, that is a lot of infrastructure for a demo corpus.

How it differs from a single-store RAG chatbot

The obvious alternative is a plain retrieval-augmented chatbot over one vector store, with a function-calling loop for anything structured. That design is simpler to run and easier to debug, and for a narrow recipe FAQ it is probably enough. The difference is in what happens when a question needs both a count and a paragraph. In a single-store RAG setup, the model either guesses the count from retrieved text or you hand-write a tool for each aggregation. GustoBot instead makes the routing decision explicit at L1 and pushes decomposition into the subgraph planner, so a question like a cuisine count is sent to the Text2SQL branch against MySQL while an anecdote question goes to the knowledge base branch. The cost is that you now maintain a router prompt, a planner, a summarizer and four datastores. If your questions are mostly one shape, the single-store approach wins on operational cost. If they genuinely span graph relations, aggregates and prose, the layered routing is the part worth copying, and you could lift that pattern into your own project without adopting the rest of the stack.

Maintenance cost and what the release history tells you

The project is at v0.1.2, released in April 2026, following v0.1 in November 2025. The default branch is develop, not main, and the last push recorded is August 2026. Two releases in roughly nine months, with development happening on develop, means you should treat the API surface as unsettled and pin to a tag rather than tracking the branch. The dependency weight is the real maintenance cost. LangGraph, LangChain, LightRAG, Neo4j, Milvus, MySQL, PostgreSQL with pgvector and Redis all move, and each has its own upgrade path. The reranker abstraction over Cohere, Jina, Voyage and BGE means provider API changes land in your configuration rather than in the code, which helps, but you still own four datastore upgrades. On licensing, Apache-2.0 permits commercial use and modification with the usual notice and patent terms; the bundled datasets are a separate question and the README directs you to docs/DATA_SOURCES.md for it. That is a documentation pointer, not legal advice, and dataset licensing needs its own review.

Editorial conclusion

Adopt GustoBot if you want a working reference for LangGraph subgraph orchestration and multi-store retrieval, and you are prepared to run Neo4j, MySQL, Milvus, PostgreSQL and Redis behind it. Do not adopt it if you need a maintained, documented product: the README is the main specification, the data lineage for the bundled recipes is only partly traceable, and the project is still at v0.1.2. Before committing, read docs/DATA_SOURCES.md and confirm the licence status of every bundled dataset, then check that the .env.example keys match the services you actually intend to run.

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. skygazer42/GustoBot on GitHub