TGO: Open-Source Platform for Deploying AI Agent Teams in Customer Service

AI Agent Teams for Multi-Channel Enterprise Customer Service

TGO addresses a gap in enterprise customer service: deploying AI agents that can handle conversations across multiple channels while providing a path to escalate to human staff. The platform targets companies that need to manage web chat, WeChat Official Accounts, WeChat Mini Programs, Feishu, DingTalk, Telegram, Slack, and email from a single dashboard, routing sessions to either AI agents or human operators depending on context.

The platform bundles four interconnected capabilities. The first is agent orchestration: engineers configure multiple AI agents with different specializations for distinct business scenarios. The second is a knowledge base layer that accepts documents, Q&A pairs, and website content for retrieval-augmented generation. The third is an MCP tool layer that connects agents to external systems. The fourth is a handoff protocol that moves conversations to human agents when the AI cannot resolve a query.

This positions TGO for teams that already operate AI workloads and want to wire them into a customer-facing support flow without building conversation routing, channel adapters, and human escalation logic from scratch.

Ten Microservices Coordinated by Docker Compose

The tgoai/tgo repository is a monorepo that coordinates ten distinct backend services, each in its own subdirectory under repos/. The services split between Python FastAPI backends and a TypeScript React frontend.

tgo-api handles core business logic including user management, visitor tracking, session assignment, and communication routing. tgo-ai manages AI and ML operations: agent configuration, tool bindings, knowledge base management, and usage analytics. tgo-rag runs the retrieval-augmented generation pipeline with document processing and hybrid semantic plus full-text search. tgo-workflow is a DAG-based workflow execution engine supporting LLM, API, condition, and tool nodes. tgo-platform ingests messages from external channels including WeChat, Feishu, DingTalk, Telegram, Slack, and email. tgo-cli is a TypeScript Node.js CLI and MCP Server that exposes over 40 built-in tools so agents can execute customer service operations directly. tgo-device-agent is a Go binary that runs on managed devices and provides file and shell capabilities over TCP JSON-RPC.

The messaging layer uses WuKongIM, an open-source instant messaging server. The main docker-compose.yml also launches PostgreSQL 16 with the pgvector extension for vector storage and Redis 7 for caching. A production deployment therefore runs at minimum fifteen containers.

Installing TGO with the Bootstrap Script

The README documents two paths for getting TGO running. For server deployments, one command downloads the bootstrap script, which checks system requirements, clones the repository, and starts all services:

REF=latest curl -fsSL https://raw.githubusercontent.com/tgoai/tgo/main/bootstrap.sh | bash

For local development, copy the example environment file and use the provided Makefile:

cp .env.dev.example .env.dev
make dev

The make dev command starts the full Docker Compose development stack. The Makefile also supports optional profiles. To include the monitoring tools (Celery Flower and Adminer), pass the monitoring profile:

make dev PROFILES=monitoring

To skip specific workers, pass a comma-separated list to DISABLE:

make dev DISABLE=tgo-rag-beat,tgo-workflow-worker

The .env.example file shows the environment variables the stack reads, including POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD, REDIS_PORT, API_PORT, AI_PORT, PLATFORM_PORT, RAG_PORT, and WEB_PORT. For production, the environment file also covers Nginx reverse proxy configuration, with SSL_MODE accepting none, auto for Let's Encrypt, or manual for custom certificates. The bootstrap script uses REF=latest, which always pulls the current main branch rather than a pinned commit.

RAG Pipelines, MCP Tools, and Workflow DAGs

The tgo-rag service supports three types of knowledge sources. Document knowledge bases accept uploaded files and index them for semantic retrieval. Q&A knowledge bases store question-answer pairs that the system returns directly when confidence is high, bypassing the LLM for known queries and reducing latency on predictable requests. Website knowledge bases crawl URLs to keep content current without manual re-upload.

The tool layer uses the Model Context Protocol. The platform ships a built-in tool store that teams can browse and enable per project. Engineers can also register custom tools by providing an OpenAPI schema, which the platform parses to generate request forms automatically.

The tgo-workflow engine runs agent tasks as directed acyclic graphs. Each node in a DAG can be an LLM call, an external API call, a conditional branch, or a tool invocation. This structure lets teams build multi-step service flows: for example, one agent retrieving order status from an API and a second agent composing the reply based on that data.

The widget system adds a structured display layer. The tgo-widget-js package embeds a chat widget on any website. The platform also ships native clients for iOS in Swift and SwiftUI, a cross-platform Flutter client for iOS and Android, and a WeChat Mini Program component.

Constraints and When TGO Is the Wrong Choice

The stated minimum hardware requirement is a 4-core CPU and 8 GiB of RAM. That is the production floor for a stack of fifteen or more containers, not a recommendation for a development laptop.

The repository has no published GitHub releases. There is no version number to pin to, no per-version changelog, and no stable artifact. A team adopting TGO picks a commit from the main branch. The bootstrap script uses REF=latest, so every fresh deployment pulls the current state of main rather than a specific known revision.

The license metadata field reports NOASSERTION, meaning automated tooling could not resolve a standard SPDX identifier from the repository. There is a LICENSE file at the repository root and a separate LICENSE_CN file, but the usable terms are not clear from that metadata alone. Legal review before internal deployment is warranted.

Chatwoot is an open-source customer support platform written in Ruby on Rails. It handles multi-channel messaging and human-agent assignment without LLM integration as a core feature. Teams that need a stable, versioned, and clearly licensed support desk and want to connect to AI via webhooks will find Chatwoot's release cadence and documentation more predictable than TGO's current state.

Maintenance Activity and Upgrade Complexity

The last push to the repository was on 2026-04-28. The repository is not archived.

Maintaining TGO across ten Python FastAPI services, a React frontend, a Go binary, and multiple TypeScript packages means that a dependency update in one service may require coordinated changes in several others. The Makefile centralises development commands, but upgrade paths for each individual service are not documented in the README.

The docker-compose.yml file pins specific image versions in several places: pgvector/pgvector:pg16 for PostgreSQL, redis:7-alpine for Redis, and WuKongIM at the tag v2.2.5-20260422. New deployments using the bootstrap script with REF=latest will pull the current main branch, but the underlying infrastructure images remain at those pinned versions unless someone updates the Compose file manually.

The repository has no GitHub releases, which means there is no release notes history to consult when upgrading. Teams running TGO in production will need an internal process for reviewing commits between the version they are running and the one they intend to deploy.

Editorial conclusion

TGO suits teams building enterprise customer service systems that need AI agent orchestration, RAG knowledge bases, and multi-channel support in a single self-hosted stack, and that have the capacity to run fifteen or more Docker containers in production. Teams that need versioned releases, clear licensing, or a lighter deployment footprint should look elsewhere. Before adopting TGO, verify the license terms in the LICENSE file at the repository root and confirm that the ten-service architecture matches your operational capacity.

Frequently asked questions

Official sources

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