Agent Sweep Engine: a ReAct customer-service agent for robot vacuums, pinned to LangChain and local Ollama

A single agent doing pre-sales, support and usage reports

Agent Sweep Engine is a consumer-facing customer-service system for robot vacuum users. The README frames the problem it targets: buyers and owners need immediate answers across a product's whole life, from pre-purchase feature questions to post-purchase maintenance, and traditional support is slow and fragments knowledge across channels.

Its answer is one agent with two jobs. The first is question answering, split into pre-sales, product features, price comparison, and after-sales operation guidance and troubleshooting, grounded by retrieval so responses stay tied to a knowledge base rather than the model's memory. The second is usage reporting: for existing owners, the README describes analysing device data such as cleaning frequency, consumable status and error logs to produce a personalised report with maintenance suggestions.

The project is Chinese-language and reads as a learning or portfolio reference for building an Agentic RAG system, complete with an evaluation harness. It is the kind of repository someone studies to see how the pieces fit, more than a product to deploy as-is. That framing is important for judging it fairly, and it shapes everything from the folder layout to the linked tutorial articles.

ReAct over two tools, with a factory that swaps the model out

The architecture is a clean separation the README documents directory by directory. The `Agent/` module is the decision centre and implements the ReAct pattern, reasoning and acting, to interpret intent, plan the task path and decide when to call a tool. The `Tools/` module holds the atomic capabilities: RAG retrieval from the vector database and report generation from device data. That two-tool design keeps the agent's job small and legible.

The `Models/` module uses a factory pattern that decouples model invocation from business logic, so the base model, the README names Qwen and Llama as options, and the embedding model can be swapped without touching the rest of the code. Prompts live in `prompts/` as templates kept separate from code, which lets someone tune the system prompt and task prompts without editing logic.

Data flows through two stages the layout makes explicit. Raw knowledge-base material sits in `data/`, and after embedding it becomes a vector index stored under `Chroma/`, the ChromaDB path, used to accelerate semantic retrieval. This split between raw source and built index is the standard RAG shape, and seeing it laid out as separate directories makes the project readable as a teaching example.

Standing up the environment

Setup begins with a Conda environment on Python 3.10, which the README specifies:

conda create -n agent_se python=3.10
conda activate agent_se

Dependencies are installed from the pinned requirements file, and the pinning here is thorough, every package fixed to an exact version:

pip install -r requirements.txt

That file pins the stack the project actually runs on, including `langchain==0.3.27`, `chromadb==1.0.15`, `langchain-ollama==0.3.6`, `gradio==4.44.0`, `streamlit==1.51.0` and `torch==2.7.0`. Exact pins make a project reproducible, which is exactly what you want in a reference build someone else will try to run, and it is a discipline many example repositories skip.

The README names three interaction entry points as separate scripts: `app.py` provides a Flask API for backend integration or Postman testing, while `app_web_gradio.py` and `app_web_streamlit.py` start Gradio and Streamlit web interfaces for a quick demo. It also documents a supplementary install for LangChain basics, `pip install openai langchain modelscope`, matching the tutorial articles it links. The evaluation model, `bert-base-chinese`, is downloaded separately from a Baidu Pan link the README provides.

Local models via Ollama, cloud models via Bailian

The model story has two documented halves, and understanding both matters before deploying. The README states the project uses Ollama for local large-model management and deployment, which lets the whole system run against a locally hosted model without a cloud dependency. That is the privacy-friendly path and the one the linked tutorials walk through.

At the same time the README says the project connects to Alibaba Cloud's Bailian platform to obtain model capabilities such as the Qwen series, and that this requires applying for an API Key and Secret Key in advance. So the same codebase supports a local Ollama backend and a hosted Bailian backend, and the factory pattern in `Models/` is what makes that switch a configuration change rather than a rewrite.

This dual path is a genuine strength for a learning project, because it lets a reader start entirely locally and later point at a stronger hosted model. It also means anyone evaluating the project has to decide which backend they are testing, since retrieval quality and answer quality will differ between a small local model and a hosted Qwen, and the README's evaluation harness measures whichever one you wire up.

Evaluation is included, but the knowledge base is the missing piece

A point in the project's favour is that it ships evaluation rather than asserting quality. The README describes `evals.py` computing metrics like accuracy and recall, with a validation dataset in `Eval/` and the `bert-base-chinese` model used to score answer quality. Including a way to measure the RAG system's answers is the part most demo projects leave out, and it is what lets the retrieval claims be checked instead of trusted.

The real limitation sits in the data layer. A retrieval agent is only as good as the knowledge base behind it, and this repository's usefulness for any specific robot vacuum depends entirely on populating `data/` with accurate product documentation, which is the user's responsibility, not the project's. The device-data analysis for usage reports similarly assumes access to real cleaning-frequency, consumable and error-log data in a shape the report tool expects. Without those inputs the architecture runs but has little to say.

The README also leans heavily on external tutorial articles and a Baidu Pan download for the evaluation model, so reproducing the full setup means following links outside the repository. That is normal for a teaching project but worth knowing: the code is here, and some of the operational detail lives in the linked write-ups.

Against a managed RAG customer-service platform

The alternative a company would reach for is a managed customer-service or RAG platform: upload documents, connect a channel, and let a hosted service handle retrieval, the model and scaling. That path is faster to a working bot and carries no infrastructure to run.

The difference is control and transparency. A managed platform hides the retrieval pipeline, the prompt handling and the model behind an interface, so you cannot easily change how the ReAct loop decides to call a tool or how documents are chunked and embedded. Agent Sweep Engine exposes all of it: the ReAct logic in `Agent/`, the two tools in `Tools/`, the prompt templates in `prompts/` and the swappable models in `Models/` are all editable, and it can run fully locally on Ollama with no data leaving the machine. The cost is that you own the assembly, the model hosting, the knowledge base and the maintenance. Choose the managed platform to ship a support bot quickly. Choose this project when the goal is to understand and control an Agentic RAG pipeline end to end, or to run one on local models for data-sensitivity reasons.

No license, a recent push, and what that means for reuse

The most consequential gap is legal, not technical: the repository ships no license. Under default copyright that means the author retains all rights and grants none in writing, so despite being public and educational, the code cannot be safely reused, redistributed or built into another product until a license is added. Anyone considering more than reading it should treat that as a blocking question and ask the author to add a license file.

On maintenance, the repository's last push was on 2026-07-29, which is recent relative to today, so the project is not stale. The exact version pinning in `requirements.txt` helps reproducibility, but it is also a future maintenance cost, since pinned versions age and eventually conflict with a current Python or CUDA environment, and `torch==2.7.0` in particular ties the project to a specific compatibility window.

The practical first step is to get the two backends straight before anything else: decide whether you are running Ollama locally or Bailian in the cloud, because the API-key requirement, the cost and the answer quality all follow from that choice, and the README documents both paths without picking one for you.

Editorial conclusion

Study Agent Sweep Engine if you want a readable, end-to-end Agentic RAG reference: a ReAct agent over ChromaDB retrieval and report tools, with a model factory that swaps between local Ollama and Alibaba Bailian and an evaluation harness in evals.py to measure it. It is the wrong choice as a drop-in support bot, because the knowledge base in data/ and the device-data inputs are yours to supply and the repository ships no license, which blocks reuse until the author adds one. Before running it, decide between the local Ollama and the Bailian backend, since the API-key requirement and answer quality both follow from that, and confirm the pinned requirements.txt still installs on your Python 3.10 environment.

Frequently asked questions

Official sources

1. Issues
2. phoenix-zhou/agent-sweep-engine on GitHub
3. README