GOAT 2.0

GOAT2 is an open-source Python project that wires together a Telegram bot interface, a DAG-based task runner, and a three-tier memory system to support multi-agent workflows where agents need to remember what happened before. The core loop is: a Telegram message arrives, the orchestrator parses intent, tasks are distributed across agents in a dependency graph, results are stored to the appropriate memory tier, and responses return through Telegram. The registry and config directories act as a central control plane — agent definitions, model backends, and plugin configurations are declared there rather than scattered across agent files.

The memory architecture is the sharpest differentiator. Most open-source agent frameworks offer one memory layer, usually a vector store. GOAT2 layers three: Redis handles fast, ephemeral session context so an in-progress conversation does not have to re-fetch state; ChromaDB handles semantic retrieval across prior sessions; and Letta handles behavioral learning — the docs describe this as the system adjusting agent behavior based on accumulated interaction history. That combination means an agent can recall what a specific user asked two weeks ago and also surface documents semantically similar to the current query, without those two lookups interfering with each other.

This architecture fits teams building personal or team-facing Telegram assistants that need continuity across sessions — support agents, research assistants, internal tools. It fits less well when you need a web or mobile frontend, when you need to expose an API for external systems to call, or when your team lacks the Python depth to configure Redis, ChromaDB, and Letta as separate services. The GitHub repository shows zero open issues and two stars at the time of curation — this is a solo or small-team project without a public community to troubleshoot against, which matters when you hit an undocumented edge case.

The repository structure is explicit: agents, orchestrator, memory, plugins, registry, tools, telegram_interface, and benchmark directories each hold their own logic, connected by a central config registry. The project ships with a requirements.txt for production dependencies and a requirements-dev.txt for testing, plus a separate SETUP.md — which the vendor states covers the configuration steps for getting all three memory backends running together.