A memnos-native coding orchestrator, published independently as tommy-orchestrator. It sits in front of a coding-agent CLI — Claude Code, Codex, aider, goose, cursor-agent or kiro — and gives that session the persistent, shared memory it wouldn’t have on its own.
Tommy is not a domain-capability agent — it doesn’t read code, write diffs, or review a merge request itself. It launches a coding-agent CLI, gives that session your relevant memnos memory up front, and — on its interactive path — hands it a coordinator system prompt built on one rule: a coordinator that does the work itself has become the thing it’s supposed to dispatch to. The real implementation happens inside the harness session Tommy launches, using that harness’s own subagent mechanism — not inside Tommy.
tommy — interactive CLIResolves your config, runs a memnos health check, builds a layered system prompt, and launches your configured harness in the foreground with that prompt attached — staying alive to capture its transcript once the harness exits.
tommy --mcp — MCP serverRuns as an MCP stdio server that an editor — Claude Desktop, Cursor, Continue, Zed — drives directly over JSON-RPC, instead of a human running the CLI at a terminal. Exposes 11 tools, including tommy_recall, tommy_dispatch and tommy_status.
Every fresh coding-agent session starts with no memory of yesterday’s work — the harness itself is stateless between invocations. Tommy sits in front of that gap.
Tommy queries memnos for context relevant to the task and front-loads it into the harness’s prompt — the harness session itself won’t call memnos on its own initiative unless it’s separately wired to.
On the interactive CLI path, Tommy ingests the harness’s own session transcript into memnos and consolidates it, so decisions made during the session become recallable in the next one. This step is Claude-Code-specific today.
If you (or a teammate) run more than one Tommy session against the same ticket at once, a memnos lease — acquire, heartbeat, release — keyed on the work item is meant to stop two sessions from picking it up independently.
Rather than always reaching for the same model regardless of task, a static routing table or (with SMART_ROUTING on) a memnos-backed policy corpus picks the model/harness tier for the work.
A built-in registry knows how to launch claude, codex, aider, goose, cursor-agent and kiro as a subprocess — plus TOML drop-ins for anything the registry doesn’t know yet.
Rather than dispatching everything at once, the coordinator prompt asks for wave-based dispatch, typed PURPOSE headers, and named tasks — so a human reviewing a session can tell what was dispatched, to what, and why.
Tommy is two different things that both get called “the orchestrator.” Knowing which is which is the most important thing to understand about how Tommy actually behaves.
A launcher and memory bridge. It detects harnesses on PATH, builds the prompt, opens a control-channel socket, launches the harness as a subprocess, writes “session started/ended” facts to memnos, and — on the interactive CLI path only — ingests the finished Claude Code session's transcript and consolidates it. This talks to memnos directly through memnos-sdk and doesn't depend on anything the harness does.
core.md)The lease/routing/wave-dispatch rules described above are not implemented in Tommy's Python code — they're a system prompt attached to the harness session. Whether the harness actually acquires a lease or calls corpus_check depends entirely on that specific harness's own LLM session choosing to follow the instruction, using memnos MCP tools that must be separately registered with it.
Layer 2 only does something once the harness you're launching has memnos registered as its own MCP server — a separate, one-time setup per harness (memnos claude-setup for Claude Code, memnos agent-setup codex for Codex). Skip that step and core.md's instructions to call recall, lease_acquire or corpus_check simply have nothing to call. And transcript journaling — part of Layer 1 — looks specifically for a Claude Code session transcript today; running a different harness through Tommy doesn't get that step yet. Full breakdown in the guide →
Plus any harness that isn't in the built-in registry yet, via a ~/.memnos/harnesses/*.toml drop-in.
Requires Python ≥ 3.10. Talks to memnos over HTTP — it doesn't need the full memnos server package installed in the same environment.
# uv (recommended)
uv tool install tommy-orchestrator
# fallback if you don't have uv
pip install tommy-orchestrator
# first-time setup — writes tommy.conf, copies prompt layers you can edit
tommy --install
# launch — recalls context, runs your configured harness, journals after
tommyCLI flags, MCP tool signatures, the control-channel wire protocol, configuration keys, and every documented limitation — the complete Tommy guide covers all of it.