Your personal AI, on your own box.
A self-hosted assistant built on the TnsAI framework. Runs as a background daemon, talks over Telegram, executes tools through MCP, and ships as a single fat JAR with a bundled JRE.
Bundles Temurin JRE 21 when no system Java 21+ is present. macOS / Linux / WSL on x64 + aarch64.
What you get
TnsAI framework, end-to-end
Sona is the framework dogfooding it. tnsai-core agents, tnsai-llm clients (Anthropic / OpenAI / Gemini / Ollama), tnsai-tools, tnsai-mcp.
Telegram-first, multi-channel by SPI
Ships with a Telegram channel adapter. New channels are tnsai-channels plugins — Sona auto-discovers them at boot, zero code changes.
Workspaces, sessions, pairing
Different chats route to different agents. Conversations persist to ~/.sona/sessions/. Unknown senders get a pairing code before they reach the LLM.
Project context via AGENTS.md
Point a workspace at a code repo and Sona reads its AGENTS.md (or CLAUDE.md / README.md) at session boot and augments the agent's system prompt. Implements the open agents.md spec — your repo bootstraps any compliant coding agent.
Machine-readable mode
Every sona command takes --json and emits a single envelope shape. Orchestrators, CI pipelines, and parent agents drive Sona without scraping human output.
Auto-update + rollback
Boot-time version check against tnsai.dev/sona/version. `sona update` pulls the new JAR in place; `sona update --rollback` restores the previous one.
One message in, one streamed reply out
The shape is the same whether you're on Telegram or the CLI: channel adapter → Gateway → agent BDI loop → LLM, with memory and skills in the loop and a streaming path back out.
- 01
Message arrives
A channel adapter (Telegram / CLI / future Slack) receives an inbound message. The Gateway routes it to the right Workspace + Session — unknown senders go through a pairing-code check before they reach the LLM.
- 02
Agent thinks
The session's agent runs a BDI loop: pulls memory (per-user profile + session history), checks skills (operational shortcuts like /remember or /todo), and assembles its tool set (built-in @Tool POJOs + any MCP servers you've wired). Then it calls the LLM.
- 03
Stream back
LLM tokens flow through StreamingChannelAdapter#sendChunk so users see the reply build up in real time. The full UnifiedResponse is also written back to the session store so the next turn has the context.
Deeper architecture walkthrough: Sona docs — how it works.
Reach people where they already are
Channel adapters are tnsai-channels SPI plugins. Sona discovers them at boot via META-INF/services; adding a new platform doesn't touch Sona's own code.
Telegram
Shipped 0.0.xBot API + per-chat pairing
CLI
Shipped 0.0.xREPL + ndJSON for scripting
IMAP poll + SMTP send (TNS-354)
Slack
Shipped 0.10.4Socket Mode WebSocket (TNS-350)
Discord
Shipped 0.10.4Gateway WebSocket + heartbeats (TNS-351)
Cloud API webhook (TNS-352)
Cheap routing, not a hot path
Sona's Gateway adds single-digit-millisecond overhead on top of whatever the LLM gives you. Numbers below are p50 of n=30from the latency benchmark suite — stub LLM holds first-token at 50 ms so what's measured is Gateway routing + channel chunk fan-out, not the model.
~7 ms
Gateway + chunk fanout, on top of LLM
~57 ms
single-turn, with 50 ms simulated LLM
~5 ms
second turn on warmed session
<1 ms
CLI vs Telegram stubs — routing is channel-agnostic
Methodology + raw samples: bench README in the Sona repo. Real-LLM and real-adapter HTTP cost are out of scope of this suite — they're tracked on the resource utilization axis (TNS-467).
How Sona compares to its closest peers
Self-hosted personal assistants in roughly the same shape as Sona. Facts pulled from each project's marketing site + GitHub metadata in May 2026; "not stated" means the site doesn't claim either way (we don't infer). Open an issue on the Sona repo if you spot drift.
| Axis | Sona | OpenClaw | Hermes |
|---|---|---|---|
| License | Apache 2.0 | MIT | MIT |
| Self-host | Yes (single fat JAR + bundled JRE 21) | Yes (Mac, Windows, Linux) | Yes (bash install on a server) |
| Language | Java 21 | TypeScript | Python |
| Channels | Telegram, CLI, Email; Slack, Discord, WhatsApp (Sona-side wiring in progress) | WhatsApp, Telegram, Discord, Slack, Signal, iMessage, CLI | Telegram, Discord, Slack, WhatsApp, Signal, Email, CLI |
| MCP support | Yes (tnsai-mcp — client + server) | Not stated | Not stated |
| Multi-agent | Yes (tnsai-coordination — 8 group topologies) | Yes ("agent army" / Codex worker fleet) | Yes (isolated subagents with own conversations) |
| Project context | Yes (AGENTS.md / CLAUDE.md / README.md auto-load per workspace) | Not stated | Not stated |
| Machine-readable mode | Yes (single --json envelope across every command; ndJSON streaming for chat) | Not stated | Not stated |
| Source | repo ↗ | repo ↗ | repo ↗ |
Built on the TnsAI framework — see the framework site for module docs, providers, and architecture.