AgentChat: A Self-Hosted Agent Platform That Generates MCP Servers From OpenAPI Specs

The Gap AgentChat Fills: A Runnable Agent Stack, Not an Agent Library

Most agent frameworks ship as libraries. You get a loop, a tool abstraction, and a prompt template, then you build the chat UI, the user model, the vector store wiring, and the deployment scripts yourself. AgentChat takes the opposite position. The README describes it as a modern intelligent dialogue system built on large language models, with a front-end and back-end split, and the repository layout backs that up: src/backend for the FastAPI service and src/frontend for a Vue 3 application. The intended user is a team that wants agents running behind a login page this week, not a team that wants to compose primitives. The feature list is correspondingly broad: multi-model support, streaming responses, visible reasoning, multi-agent collaboration, a knowledge base with semantic chunking and vector retrieval, more than ten built-in tools, MCP server integration, user management with permission control, and a data dashboard that filters call counts and token usage by agent, model, and time range. That last item is a signal about audience. Token accounting by agent and model is an operations concern, which means the project assumes someone other than the original author will run it and pay for the inference.

Three-Tier Memory Replaced the Recent-Five-Turns Window

The 2026-4-12 changelog is the most concrete design document in the repository. It states that context management was refactored from a simple recent-five-conversations approach into what the release notes call a three-layer memory architecture. The layers are named and bounded: short-term memory keeps the most recent conversation content within 3000 tokens, a summarization layer condenses history beyond that 3000-token boundary and extracts key information, and long-term memory persists user preferences, habits, and important details. The 3000-token figure is the only hard number the material gives for context. Everything else about the summarization trigger, including whether summarization runs synchronously before a model call or as a background job, is not stated, and that distinction matters for latency. A synchronous summarization step adds a second model round trip to any turn that crosses the threshold. The long-term layer is also underspecified: the README says it records preferences and habits, but does not say where that store lives, how entries are retrieved, or how a user clears them. Treat the three-tier claim as a documented intent with one verifiable constant, not as a fully specified memory subsystem.

HITL MCP Server Generation Is the Feature Worth Evaluating

The headline item in the same changelog is conversational generation of MCP servers from OpenAPI information, with human intervention at key decision points. The README's phrasing is that critical decision nodes support manual intervention and confirmation, enabling dynamic configuration and real-time interaction. Read that against the alternative: hand-writing an MCP server means translating every endpoint into a tool definition, deciding argument names and types, and writing descriptions the model can route on. AgentChat's flow asks the user to confirm decisions during generation instead of after. The screenshot caption in the feature gallery shows the same flow, and a separate changelog entry notes that custom tools can now be built by uploading a Swagger or OpenAPI document, which previously did nothing when clicked. Those two features are adjacent but not identical: one uploads a spec to create a tool, the other generates an MCP server through dialogue. The material does not explain how the two paths relate, whether generated servers are persisted as files, or how they are versioned. If you are evaluating AgentChat for this capability alone, that is the first thing to establish from the source, because the README stops at describing the interaction, not the artifact.

Getting It Running: Docker Compose or Two Local Processes

The README gives two paths. The Docker path is four commands: git clone https://github.com/Shy2593666979/AgentChat.git, cd AgentChat, edit docker/docker_config.yaml, then cd docker and run docker-compose up --build -d. The config file is the single place the README points to for deployment settings, and it is also where you would expect model credentials, database connection details, and object storage settings to live, though the README does not enumerate the keys. The local path splits into two processes. For the backend, cd src/backend, then either pip install -r requirements.txt or the recommended route: pip install uv followed by uv sync. For the front end, cd src/frontend, npm install, npm run dev. Stated requirements are Python 3.12+, Node.js 18+, MySQL 8.0+, Redis 7.0+, and Docker 20.10+. Note the mismatch between the stated stack and the storage options: the tech stack section lists ChromaDB, while the advanced deployment section says the system supports Milvus or ChromaDB as vector databases and Elasticsearch as a search engine, and the repository topics include Milvus and Elasticsearch. The README also mentions OSS and MinIO as object storage options, pointing to docs/development/install_minio_win.md for local MinIO on Windows, and notes a start_win.bat one-click script for Windows. Which of these is required versus optional is not stated. Budget for reading the deployment docs before you clone, because the README alone does not tell you the minimum viable configuration.

The LangChain 1.0 Split and Other Upgrade Costs

AgentChat v2.2.0 moved to LangChain 1.0, and the README is explicit that this was a breaking change: the version table separates v2.1.x and below (LangChain 0.x, old API) from v2.2.0 and above (LangChain 1.0+, described as a major update with large API changes), and a note says some tool and agent configuration methods have changed. That means any custom tool or agent definition written against v2.1.x will not carry forward without edits, and the README defers to a migration guide it does not inline. The 2026-4-12 changelog also records fixes for dependency conflicts among Pydantic, LangChain, and FastAPI, which tells you the dependency graph has been tight enough to break. If you pin AgentChat, you are pinning a LangChain generation with it. The licence is MIT, which the README summarizes as free use, modification, and distribution. That is a permissive baseline and the repository includes a LICENSE file, but MIT covers the code, not the model weights or hosted services you connect to it, and not the terms of any MCP server you generate against a third-party API. No release artifacts were retrieved for this review, so there is no versioned changelog beyond the two dated entries in the README to track against.

Where AgentChat Is the Wrong Tool

The architecture assumes infrastructure. A FastAPI backend plus MySQL, Redis, a vector database, and optionally Elasticsearch and an object store is a reasonable footprint for a shared internal platform and an unreasonable one for a CLI tool or a single-purpose script. If your agent needs to run inside an existing application as a function call, AgentChat's value (the UI, the user model, the dashboard, the permission layer) is weight you would carry without using. The memory design is also a constraint rather than a feature in some cases: a fixed 3000-token short-term window with summarization beyond it is a policy, and applications that need verbatim full-history context, such as code review or legal drafting, will find the summarization layer lossy by design. There is a narrower failure mode worth naming. The changelog entry about first-startup errors caused by missing model configuration, now fixed with a configuration check and a prompt, indicates that the system does not degrade gracefully without a working model provider. An air-gapped or offline evaluation is not described anywhere in the material.

How It Differs From Wiring LangChain Yourself

The honest alternative is not another agent platform. It is LangChain plus FastAPI plus a Vue front end, which is essentially what AgentChat is, assembled. The difference is in what comes pre-decided. If you build it yourself, you choose your memory strategy, your vector store, your tool registry, and your MCP client, and you own the seams between them. AgentChat has already chosen: three-tier memory with a 3000-token short-term window, ChromaDB or Milvus for vectors, Elasticsearch optionally for search, a built-in tool set of more than ten tools, and an MCP client that the README says loads servers dynamically at runtime. You are trading control for a working starting point. The trade is favorable if your requirements are close to the defaults and unfavorable if they are not, because changing a pre-decided layer means working inside someone else's abstraction. The MCP server generation feature is the one piece that is harder to replicate casually, since it involves a dialogue-driven code generation loop with confirmation checkpoints, and it is the part of the project with the least documentation relative to its prominence.

Editorial conclusion

Adopt AgentChat if you want a self-hosted multi-agent chat platform with RAG, MCP, and a UI you do not have to build, and you are willing to run MySQL, Redis, and a vector store alongside it. Do not adopt it if you need a small embeddable agent loop, or if you cannot commit to the LangChain 1.0 API surface introduced in v2.2.0. Verify first that docker/docker_config.yaml exposes the model, vector store, and object storage keys your environment needs, and confirm whether your deployment targets Milvus or ChromaDB, since the README lists both.

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. Shy2593666979/AgentChat on GitHub