
TinyAGI
github.com/tinyagi/tinyagi- Category
- AI Agents
- Rank
- No. 991Tools index
- Pricing
- Open Source
- Type
- TOOL
- Use case
- Agent Building
- Interfaces
- Web
- Builder
- @jianxliao
- GitHub
- 3.6k stars
- Latest release
- v0.0.20
- Date
About
A multi-agent AI orchestrator that lets you run teams of specialized AI agents that collaborate with each other across Discord, WhatsApp, and Telegram channels. Features a web dashboard for managing agents, teams, and tasks with 24/7 operation capabilities.
What it does
TinyAGI runs several AI agent processes as a local background service, each driven by Anthropic's Claude CLI, OpenAI's Codex CLI, or a custom endpoint. Messages from chat apps or a REST call land in a SQLite queue: each agent works its own queue in order, while different agents run concurrently. An agent can tag a colleague in its reply to hand off work; the tag becomes a new queued message, so agents pass tasks back and forth or post to a shared room the group reads. Each agent keeps its own folder, settings, and conversation history. A browser console shows the queue, logs, and an org chart.
Why it's ranked here
The mechanism here is real: a working SQLite queue, per-provider adapters for Claude and Codex, a documented plugin and hook system, and a chat-room protocol that actual code implements, not just describes. That earns a look. But the project's own badge calls it experimental, and the way it invokes the underlying coding-agent CLIs turns off their permission prompts and sandboxing entirely, trading safety checks for hands-off automation. That is fine on a machine you already trust and risky anywhere else. Worth studying the architecture; worth hesitating before letting it run unattended on anything that matters.
What's good
The queue is built like production infrastructure, not a demo: retries with a capped count before a message is marked dead, automatic recovery for anything stuck mid-process after a crash, and separate append-only tables for chat history and per-agent messages. Provider support is a small adapter registry, so adding a new backend means writing one adapter, not touching the core. Plugin hooks that reshape incoming or outgoing text are isolated: the docs state a failing plugin cannot crash the queue processor. The agent handoff protocol, plain mentions in a reply that become new queued messages, is simple enough to reason about without reading the source.
Tradeoffs
The agent invocation deliberately turns off its own safety rails: the underlying coding-agent CLIs are called with flags that skip permission prompts and bypass the sandbox, so an agent that goes off script has no guard between it and the filesystem. Two history tables, chat messages and per-agent messages, are documented as append-only and growing indefinitely, with no pruning described for either, unlike the message queue's own cleanup of completed and acknowledged entries. The project labels itself experimental on its own badge, and the optional personality-customization file ships as a bracketed fill-in-the-blank template rather than a working default.
How to use it well
This fits someone who wants a fleet of coding agents reachable from chat apps, each in its own workspace with its own memory, handing tasks to each other without a human relaying messages between them. Run it on a machine you already trust with full CLI access, not a shared or public one, since the underlying agents' permission prompts are switched off by design. Plan to prune or archive the growing chat and per-agent history yourself, since the built-in cleanup only touches finished queue entries, not those logs. Skip it if you need agents constrained by a sandbox or an approval step before they touch files.
Technical notes+
packages/main/src/index.ts is the queue processor entry point: processMessage() resolves routing via parseAgentRouting(), invokes the agent through invokeAgent(), and on failure still records a synthetic assistant reply before calling handleTeamResponse() to fan out any [@agent: ...] tags handled by packages/teams/src/index.ts's conversation logic. packages/core/src/adapters/index.ts auto-registers claudeAdapter, codexAdapter, and opencodeAdapter into a provider-keyed registry exposed via getAdapter(). docs/AGENTS.md documents the actual shell invocations: claude --dangerously-skip-permissions ... -p and codex exec resume --last --dangerously-bypass-approvals-and-sandbox --json. docs/QUEUE.md specifies chat_messages and agent_messages as append-only with no listed pruning, while packages/main/src/index.ts runs a 60-second maintenanceInterval that only calls pruneAckedResponses() and pruneCompletedMessages(). packages/server/src/index.ts mounts the REST/SSE API (Hono) on port 3777, configurable via TINYAGI_API_PORT. SOUL.md ships with unfilled bracketed placeholders throughout. LICENSE confirms MIT; package.json confirms an npm workspaces monorepo with a single tinyagi CLI bin.
Observed
- License
- MIT (LICENSE file)
- Language & packaging
- TypeScript, npm workspaces monorepo with a single tinyagi CLI binary
- Install surface
- Shell install script, npm install from source, or Docker Compose
- Interfaces
- CLI, REST + SSE API (default port 3777, configurable), browser dashboard, and Discord/Telegram/WhatsApp channel bots
- Platform support
- macOS, Linux, and Windows via WSL2; requires Node.js v18+
- Agent execution
- Shells out to the Claude and Codex CLIs with permission-prompt and sandbox flags disabled
- Persistence
- SQLite-backed queue; chat and per-agent history tables documented as append-only with no pruning
Read from README.md, package.json, packages/core/src/index.ts, packages/main/src/index.ts, packages/server/src/index.ts, packages/teams/src/index.ts, docs/AGENTS.md, docs/MESSAGE-PATTERNS.md, docs/PLUGINS.md, docs/QUEUE.md, packages/core/src/adapters/index.ts, SOUL.md, LICENSE.
What it can do
Deploy AI agent teams across messaging platforms
AI agent configurations and messaging platform credentials → Active AI agents operating on Discord, WhatsApp, and Telegram channels
Orchestrate collaboration between multiple AI agents
Task requirements and team of specialized AI agents → Coordinated responses and task completion through agent collaboration
Manage AI agent teams through web dashboard
Agent configurations, team settings, and task parameters → Configured and monitored AI agent operations
Create isolated workspaces for different agent teams
Team definitions and workspace requirements → Separate operational environments for each agent team
Monitor agent performance and tasks 24/7
Running agent operations and system metrics → Real-time monitoring data and operational status reports
Route conversations between specialized AI agents
User messages and agent specialization mappings → Directed conversations to appropriate specialized agents
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.