TinyAGI: a TypeScript orchestrator for teams of AI agents

The problem TinyAGI targets: one operator, several agent teams

The project describes itself as the agent teams orchestrator for One Person Company, and the README's headline is multi-agent, multi-team, multi-channel, 24/7 AI assistant. The intended user is a single operator who wants more than one agent working at once, each with a specialized role, without those agents overwriting each other's files or conversations. TinyAGI answers that with isolated workspaces per agent, team-level handoffs, and persistent sessions that survive a restart.

The scope is deliberately wider than a chat wrapper. The README lists Discord, WhatsApp and Telegram as channels, a browser dashboard called TinyOffice, a live TUI dashboard, and a SQLite queue with atomic transactions, retry logic and dead-letter management. That combination points at unattended operation: the daemon runs as a background process or Docker container, and messages arrive from chat platforms rather than from a terminal you are sitting in front of. If you only want a single agent answering questions in your terminal, the multi-team machinery here is overhead you will pay for in configuration surface.

How the pieces fit: daemon, SQLite queue, teams, channels

The repository is a npm workspace root with packages under packages/, and package.json exposes separate build targets for @tinyagi/core, @tinyagi/teams, @tinyagi/channels, @tinyagi/server, @tinyagi/visualizer and @tinyagi/main. That layout is the clearest statement of the architecture: channels ingest messages, the queue persists them, teams execute them, and the server and visualizer expose state to the browser and the terminal.

The queue is the part worth understanding before adopting. The README says it uses SQLite with atomic transactions, retry logic and dead-letter management. In practice that means a message is not lost when an agent process dies mid-task; it can be retried, and after repeated failure it moves to a dead-letter path you can inspect through the logs and events view in TinyOffice. The daemon, started by tinyagi start, owns that loop. Teams hand off work to teammates through chain execution and fan-out, so one incoming message can trigger a sequence of agents rather than a single response.

Channels are optional at first run. The README states that no channels are configured initially and that you add them later with tinyagi channel setup. Auth tokens are stored per provider, which the README frames as removing the need for separate CLI authentication. Providers covered are Anthropic Claude, OpenAI Codex, and custom providers that speak an OpenAI or Anthropic compatible endpoint.

Installing TinyAGI and running a first agent

The README's primary install path is a shell script that downloads and installs the tinyagi command globally. Prerequisites listed are macOS, Linux or Windows under WSL2, Node.js v18 or newer, and the Claude Code CLI or Codex CLI depending on which provider you intend to use.

curl -fsSL https://raw.githubusercontent.com/TinyAGI/tinyagi/main/scripts/install.sh | bash

Running the command with no subcommand is the whole first-run flow. According to the README it auto-creates default settings, starts the daemon, and opens TinyOffice in the browser. The default workspace is ~/tinyagi-workspace and the default agent is named tinyagi and uses Anthropic Opus.

tinyagi

From there, the CLI exposes start, stop and an agent subcommand. The README's development section shows listing agents after starting:

npx tinyagi start
npx tinyagi agent list

If you prefer containers, docker-compose.yml maps port 3777 to the host, mounts a tinyagi-data volume at /root, and reads ANTHROPIC_API_KEY, OPENAI_API_KEY, DISCORD_BOT_TOKEN and TELEGRAM_BOT_TOKEN from the environment. The Dockerfile installs git and chromium in the production stage, sets PUPPETEER_EXECUTABLE_PATH to /usr/bin/chromium, and installs @anthropic-ai/claude-code, @openai/codex and agent-browser globally. The API is then reachable at http://localhost:3777. The browser portal at office.tinyagicompany.com connects to that local API with no account, or you can run tinyagi office to build and serve it on http://localhost:3000.

Where TinyAGI gets awkward: experimental status and CLI dependencies

The README carries a stability badge reading experimental, and the current release is v0.0.20. Three releases shipped in the last week of March 2026 (v0.0.18, v0.0.19 and v0.0.20), and the last push to main was on 2026-03-30. That is a fast, early-stage cadence, and it means interfaces can move between patch versions. Treat any internal package boundary as unstable.

The install script installs the tinyagi command, not the model CLIs. The README lists Claude Code CLI and Codex CLI as prerequisites, and the Dockerfile installs them globally inside the image. On a bare host you supply them yourself. If neither CLI is present and you have not configured a custom OpenAI or Anthropic compatible endpoint, the default Anthropic agent has nothing to drive.

The channel integrations carry their own weight. The Dockerfile installs chromium because WhatsApp uses Puppeteer and agent-browser uses Playwright, and the README's WhatsApp setup is a QR code scan through Linked Devices. Setting PUPPETEER_SKIP_DOWNLOAD=true in the root package.json avoids a duplicate browser download during npm install, but the container still needs the system package. This is a heavier footprint than a plain HTTP service, and it is the main reason the Docker path is more predictable than a host install for WhatsApp use.

Finally, the README does not document rollback for tinyagi update, and it does not describe a migration path for the SQLite queue between versions. If you run this in production, test upgrades against a copy of the workspace first, because the documentation is silent on what happens to queued work during an upgrade.

TinyAGI compared with a single-agent CLI workflow

The nearest alternative is not another orchestrator but the plain agent CLI you already have. Claude Code CLI or Codex CLI each run one agent in one working directory with one conversation. TinyAGI wraps those same CLIs and adds the parts they do not have: a persistent queue, multiple isolated workspaces, team-level handoffs, chat channels, and a dashboard that shows queue state and live events.

The difference in approach is where state lives. A bare CLI keeps conversation context in the process; TinyAGI keeps it in persistent sessions and a SQLite queue, which is what allows the daemon to survive restarts and to retry a failed task. That is also the cost. A CLI has no daemon, no port 3777, no dead-letter queue and no channel tokens to rotate. If your work is one person typing into one terminal, the orchestrator adds moving parts without adding capability. If your work is several agents reacting to messages that arrive while you are asleep, the queue is the feature that makes the rest usable.

Maintenance, licensing and what to check before adopting

TinyAGI is MIT licensed, and the LICENSE file is at the repository root. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be retained in copies or substantial portions. That is a summary of the identifier, not legal advice; read the LICENSE file and your own obligations before redistributing a modified build.

On maintenance, the last push to main was on 2026-03-30, and the repository is not archived. The release history shows v0.0.20 on 2026-03-26, v0.0.19 on 2026-03-24 and v0.0.18 on 2026-03-24, so the project was moving quickly in that window. The README also states that the maintainers are actively looking for contributors, which is a signal about team size rather than about code quality.

Upgrade cost is the real variable. The root package.json exposes granular build scripts (build:core, build:teams, build:channels, build:server, build:visualizer), and the README notes that tinyagi office auto-detects when dependencies or builds are needed after tinyagi update. That suggests updates rebuild local artifacts rather than pulling a prebuilt binary. Budget time for a rebuild and a queue check on each upgrade, and keep the workspace directory under version control or backup so a failed update does not take your agent history with it.

Editorial conclusion

Adopt TinyAGI if you already run Claude Code CLI or Codex CLI and want several agents with separate workspaces handing work to each other over Discord, Telegram or WhatsApp. Do not adopt it if you need a stable API, because the README labels the project experimental and the version is 0.0.20. Before installing, check that Node.js v18 or newer is present and that the agent CLI for your chosen provider is on the PATH, since the installer only fetches the tinyagi command itself.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. TinyAGI/tinyagi on GitHub