TGO: Self-Hosted AI Agent Customer Service, Assembled From Eleven Services

The gap TGO fills: channels, RAG and handoff in one repo

Most teams building AI customer service end up gluing three unrelated things together: a chat widget, a retrieval pipeline over their help docs, and an escalation path to a human. Each piece has decent standalone options. The integration work is where the weeks go. TGO's pitch is that all three ship in one repository and one deployment, under an open-source licence, so the data stays on your infrastructure. The README describes the project as a platform for helping enterprises "Build AI Agent Teams for Customer Service", and the feature list maps directly onto that glue problem: multi-agent orchestration, three kinds of knowledge base (document, Q&A, and crawled website content), MCP tool integration, and smart handoff to human agents. The intended user is an engineering team at a company that already has support staff and a help centre, and wants an agent layer it controls. It is not aimed at a solo developer who wants a hosted widget pasted into a marketing site.

Eleven services, not one binary: the architecture you are signing up for

The repository structure table is the most informative part of the README. TGO is not a monolith. It is a collection of services under repos/, each with its own tech stack. tgo-ai handles agent management, tool bindings, knowledge bases and usage analytics in Python and FastAPI. tgo-api holds user management, visitor tracking, session assignment and communication. tgo-rag does document processing and what the README calls hybrid semantic/full-text search, with async processing. tgo-platform is the intake layer for WeChat, Feishu, DingTalk, Telegram, Slack and email. tgo-workflow executes agent workflows as a DAG with LLM, API, condition and tool nodes. tgo-plugin-runtime manages plugin lifecycle and tool synchronisation. There is also tgo-cli (a TypeScript CLI and MCP server with what the README counts as 40+ built-in tools), tgo-device-agent and tgo-device-control for remote device management over TCP JSON-RPC, tgo-web as the React 19 admin frontend, and five widget SDKs covering JavaScript, iOS, Flutter, WeChat Mini Program and a visitor-facing CLI. The data flow implied by this layout is: a message arrives at tgo-platform from a channel, tgo-api resolves the visitor and session, tgo-ai runs the agent turn with retrieval from tgo-rag and tools from the plugin runtime or MCP servers, and the reply travels back out through the same channel while tgo-web shows the human agent what happened. The README does not document the internal API contracts between these services, so treat that flow as the layout implies rather than a published specification.

Bootstrap script versus make dev: two setup paths

The README gives two ways in. For a server, the one-click path is a shell script piped to bash: REF=latest curl -fsSL https://raw.githubusercontent.com/tgoai/tgo/main/bootstrap.sh | bash. The README says this checks requirements, clones the repository and starts the services. A China-mirrored variant points at Gitee and Aliyun instead. Piping a remote script into bash is a real supply-chain decision, and the README offers no checksum or signature step, so review bootstrap.sh before running it on anything you care about. The second path is local development: copy .env.dev.example to .env.dev, then make dev. The Makefile accepts at least two variables, shown as make dev PROFILES=monitoring and make dev DISABLE=tgo-rag-beat,tgo-workflow-worker. DISABLE takes a comma-separated list of service names, which tells you the compose file names services individually and that you can run a reduced stack. That is useful for a laptop, and it is also a hint about resource pressure: the stated system requirements are 4 CPU cores and 8 GiB of RAM as a floor, on macOS, Linux or WSL2, for the full stack. The README does not list individual environment variables in .env.dev.example, so model provider keys and database credentials have to be discovered from that file or from the documentation site.

Where TGO gets heavy: the operational bill for self-hosting

The honest limitation is the one the architecture table states without saying it: you are operating a distributed system to answer support tickets. Eight FastAPI services, a React frontend, a workflow engine, a plugin runtime, a RAG service with asynchronous processing, plus WuKongIM for messaging and WebSocket connections. Each is a process that can crash, leak memory, or fall behind on its queue. The README mentions tgo-rag-beat and tgo-workflow-worker as things you might disable, which means background workers exist and will need monitoring. There are no published releases in the material provided, so there is no versioned upgrade path to point at, and the last push recorded is 2026-04-28. For a team of two engineers who wanted a chatbot on a docs site, this is the wrong tool: the surface area exceeds the problem. A second limitation is documentation depth. The README defers to tgo.ai for details, and for a project of this size the README alone is not enough to understand the inter-service contracts, the database schema, or how retrieval quality is tuned. The licence is listed as NOASSERTION, which means GitHub could not classify the LICENSE file automatically. That is not a red flag by itself, but it means the licence terms are unknown until you open the file, and for a commercial deployment that check comes before any code is written.

How TGO differs from a single-process agent framework

The natural comparison is a Python agent framework such as LangChain or a similar library, where you write an orchestration script and expose it through your own web server. That approach gives you full control of the agent loop and almost nothing else: no admin console, no visitor tracking, no channel adapters, no human handoff inbox. TGO inverts the trade. You give up the freedom to define the orchestration model from scratch, and in exchange you get tgo-web as a ready admin interface, tgo-platform as a channel intake layer that already speaks WeChat, Feishu, DingTalk, Telegram, Slack and email, and a workflow engine that expresses agent logic as a DAG of LLM, API, condition and tool nodes rather than as code. The difference in approach matters at the boundary: with a framework, adding WeChat means writing an adapter; with TGO, adding WeChat means configuring a channel that the platform service already implements. The cost is that your agent logic now lives partly in a DAG configuration rather than in a repository you can unit test. If your team's strength is code and your weakness is operations, the framework route is the better fit. If the opposite is true, and channel breadth is the requirement, TGO's split is the more direct path.

RAG, MCP tools and the widget protocol: what the feature list actually commits to

Three mechanisms in the README deserve attention because they shape what the product can do. First, the knowledge base comes in three ingestion forms: uploaded documents, hand-written question-answer pairs, and crawled website content. The Q&A form is the pragmatic one, because it lets support staff encode the answers they already give without waiting for a document pipeline. The README describes retrieval as vector-based semantic search with hybrid semantic and full-text matching in the tgo-rag service, which suggests keyword and embedding results are combined, though the ranking method is not specified. Second, MCP tools. TGO ships a tool store, per-project custom tool configuration, and auto-parsing of OpenAPI schemas into interactive forms. That last detail is concrete: point it at an OpenAPI document and the admin UI generates a form for invoking the operation, which is how an agent gets to call your order lookup API without bespoke code. Third, the widget system uses what the README calls a standardized URI action protocol, so an agent reply can render an order card, a logistics tracker or a product comparison instead of plain text. The protocol is described but not specified in the README, so SDK implementers will need the documentation site. Streaming responses over SSE and conversation context memory are listed as agent features; neither has tuning parameters in the README.

Maintenance surface and what to check before you commit

Upgrade cost here is proportional to the number of services you run, and the README gives no release notes to judge how often they change. The one-click bootstrap takes REF=latest, which means the default deployment tracks the tip of main rather than a pinned version. That is convenient on day one and awkward on day ninety, when you want to know what changed. If you deploy this, pin REF to a commit or tag rather than leaving it at latest, and read bootstrap.sh before executing it. The DISABLE variable in the Makefile is your lever for trimming the stack, and PROFILES=monitoring suggests an optional observability profile exists, which is worth enabling if you run the full set. On licensing, the NOASSERTION classification means the terms are whatever the LICENSE file says, and nothing in the supplied material states them. Check that file against your distribution model before you build on top of it. The README also does not cover backup and restore for the knowledge base or the message store, which are the two pieces of state you cannot regenerate from code. Until the documentation addresses that, treat data durability as an open question rather than a solved one.

Editorial conclusion

Adopt TGO if you need WeChat Official Account or Mini Program support alongside a web widget, want the RAG pipeline and MCP tool execution inside your own network, and have someone who can run Docker Compose and watch eight FastAPI services. Do not adopt it if you want a hosted chat widget live this afternoon, or if one Postgres and one Node process is the ceiling of what your team will operate. Before committing, verify three things in the repository: the actual contents of the LICENSE file behind the NOASSERTION label, whether commit activity after April 2026 continues, and whether the documentation at tgo.ai covers backup and restore for the RAG vector store, because the README does not.

Official sources

1. Issues
2. Project website
3. README
4. tgoai/tgo on GitHub