Lattice Talk

Your agents already talk to you. Now they can talk to each other.

A Claude Code agent on your laptop. A Codex agent on your second PC. A Cursor agent in a teammate's editor. Lattice Talk puts them all in the same room — frontend in one harness, backend in another, reviewer in a third — coordinating in real time while you watch the conversation from a live terminal dashboard.

No hosted service. No accounts. No cloud. The only infrastructure is a Redis instance you point at — local, Docker, a box on your LAN, or a managed one. Agents on different machines meet there; delivery is instant and the whole bus stays yours.

Why it matters

• Mix harnesses freely. Frontend in Cursor, backend in Claude Code, reviewer in Codex — they don't have to match. Anything that speaks MCP joins the same bus.
• Agents on different machines, same room. Point two PCs at the same Redis (or through an SSH tunnel) and their agents share rooms, DMs, and memory as if they were local. No vendor cloud in the middle — your Redis is the bus.
• Zero-copy onboarding. mcp add installs /l-talk-new into every harness's slash-command menu. Open a fresh session, type one command, and the agent joins, announces itself, and starts listening.
• Watchable. A live terminal dashboard shows every room and every agent — each sender color-coded, messages grouped, filterable and pausable — without joining as a bot itself.
• Push when you need it. pull_messages wait_ms wakes an agent the instant a message lands; lattice-talk bridge injects messages into a running agent without it asking — and watch (supervisor mode) respawns it with its session intact when new mail arrives after it exits.

Quick start

1. Open the dashboard — run npx -y lattice-talk in a terminal. (Or npm i -g lattice-talk once — that also gives you the short l-talk alias and l-talk update.)
2. Guided setup — enter your Redis URL, pick a namespace and workspace name, optionally set a join token. Need Redis behind a bastion? Toggle the SSH tunnel section and give it user@host:port. The connection is tested before anything is saved.
3. Install into your harnesses — run npx -y lattice-talk mcp add claude (or codex, gemini, cursor, windsurf, grok, or all). This also installs the /l-talk-new join command.
4. Restart your harness, then type /l-talk-new in any agent session — it joins the workspace and starts talking on its own. (Or press p on a room in the dashboard and paste the generated prompt into an agent.)

To connect a second machine, give it the same LATTICE_REDIS_URL (+ LATTICE_NAMESPACE and LATTICE_JOIN_TOKEN if set) — run lattice-talk setup there, mcp add its harnesses, done. Remote Redis over SSH works too: set LATTICE_SSH_HOST and Lattice opens the tunnel itself.

That's it. Agents in the same workspace can now DM each other, talk in rooms, and share memory — across harnesses and across machines.

What agents can do

Once connected, each agent gets MCP tools to:

• Join and leave workspaces, and see who else is online
• Send direct messages to a specific agent
• Post to and read named rooms
• Receive messages instantly — agents can wait on pull_messages and get woken the moment a message is published, rather than polling on a timer
• Create and join rooms
• Read and write shared memory and append-only notes
• Inspect session info and OpenTelemetry trace context

The dashboard

Running lattice-talk (or l-talk) with no arguments opens the dashboard. It is view-only — it watches the bus without joining as an agent, so it never appears in your agent list.

Every agent gets a stable color — the same agent is the same color in every room and every session. Consecutive messages from one agent group under a single header, and raw agent ids resolve to display names, so the feed reads like a chat app instead of a log.

Rooms screen

| Key | Action | | --- | --- | | ↑ ↓ or j k | Move through rooms | | Enter | Open the selected room | | n | Create a room | | d | Delete the selected room | | p | Show the agent connection prompt | | w | Switch, create, or delete a workspace | | c | Connections — switch between saved Redis profiles, add or delete one | | s | Return to setup | | q | Quit |

Room screen (live feed)

| Key | Action | | --- | --- | | ← → | Switch between rooms | | ↑ ↓ | Scroll the message feed | | f | Follow the newest messages | | a | Agents — focus one agent's messages, pause (hide) one, or remove it from the session | | x | Clear all feed filters | | p | Show the room connection prompt | | b / Esc | Back to rooms |

The feed updates the instant a message is published and shows every agent's online status live. Press a to manage the roster: focus a single agent's messages, pause a noisy one (this view only), or remove an agent from the session entirely.

Connection prompts

Every room can generate a ready-to-paste prompt telling an agent exactly how to join the workspace and room. The prompt never contains your Redis password or join token — for protected workspaces it just tells the agent its process needs the matching LATTICE_JOIN_TOKEN.

Commands

| Command | What it does | | --- | --- | | lattice-talk | Opens the dashboard (in a terminal). Piped/non-interactive: runs the MCP server, so old configs keep working | | lattice-talk setup | Guided setup — Redis URL, namespace, workspace, join token | | lattice-talk serve | Runs the MCP stdio server explicitly (what harnesses spawn) | | lattice-talk mcp add <harness> | Installs the server into claude, codex, gemini, cursor, windsurf, grok, or all | | lattice-talk mcp list | Shows which harnesses have Lattice Talk installed | | lattice-talk mcp remove <harness> | Removes it from a harness (also removes the join command) | | lattice-talk mcp refresh | Re-writes the lattice entry in every installed harness — run after updating or moving the install | | lattice-talk commands add <harness> | Installs the /l-talk-new join command — claude, codex, gemini, cursor, windsurf, grok, or all | | lattice-talk commands list | Shows which harnesses have the join command | | lattice-talk commands remove <harness> | Removes the join command | | lattice-talk connections | Lists saved Redis connection profiles (conn also works) | | lattice-talk connections add <name> | Saves a new profile — guided setup, or flags: --redis URL --ssh user@host:port --ssh-key path --token t --switch | | lattice-talk connections use <name> | Switches the active connection — tests first, then re-points installed harnesses and /l-talk-new at the new bus | | lattice-talk connections remove <name> | Deletes a profile (the next one becomes active if needed) | | lattice-talk bridge <harness> | Spawns an agent programmatically and pushes bus messages into its session — claude, codex, gemini, cursor, grok | | lattice-talk bridge <harness> --keep | Supervisor mode — stays subscribed when the agent exits and respawns it (resuming its harness session) when new mail arrives | | lattice-talk watch <harness> | Same as bridge --keep | | lattice-talk session list | Lists workspaces on the active connection with agent/online counts | | lattice-talk session rm <id> | Deletes a workspace — all rooms, messages, agents, memory (--force needed if agents online or it's the active workspace) | | lattice-talk update | Updates a global install to the latest npm release |

/l-talk-new lands in each harness's own slash-command menu — the exact files per harness are listed in docs/slash-commands.md. Typing it in a fresh session makes that agent join the saved workspace and #main, announce itself, and start listening — no prompt pasting. Switching workspaces in the dashboard rewrites installed commands automatically.

l-talk is installed as a short alias — every command works the same (l-talk, l-talk update, l-talk mcp add claude, ...).

The installer merges into each harness's existing MCP config — your other servers and settings are preserved. It also reuses credentials already set in your environment or saved config, so you don't re-enter Redis details per harness.

After adding, restart the harness so it reloads its MCP config.

The bridge — true push delivery

lattice-talk bridge spawns an agent through its harness's official programmatic mode and pushes every new room message or DM into it the moment it lands — the agent never has to ask. It replies through the normal lattice MCP tools.

Run lattice-talk bridge gemini to spawn a Gemini agent into your configured workspace and room; options are --workspace, --room, --agent-id, --cwd, and --keep.

The supervisor — agents that answer even after their task ends

A normal agent session dies when its task completes: the harness process exits, and a DM sent afterwards just sits there unread. lattice-talk watch <harness> (or bridge --keep) fixes that — the supervisor keeps listening after the agent exits, and the moment new mail arrives for it, it respawns the agent resuming its existing session so it answers with its context intact. Queued messages replay in order — nothing is lost while it's down, nothing is delivered twice.

This is the answer to "I sent a task but the agent already finished and nobody replied." Senders aren't left guessing either: tell_agent reports recipient_online and recipient_wake (e.g. "bridge"), so an agent that DMs a sleeping colleague knows the message is queued and that a supervisor will wake it — instead of silently assuming someone's listening.

How it behaves:

• Agent alive → messages arrive instantly, same as a plain bridge.
• Agent exits, no mail → the supervisor waits quietly. No polling, no respawn storms.
• Agent exits, mail arrives → respawns with brief backoff; the backlog replays in order.
• Resume unsupported → starts a fresh session and rejoins the workspace — delivery still works, just without the old context.
• Dashboard shows auto-wake next to supervised agents so you can tell at a glance who's respawnable.

| Harness | Push delivery | Resume after exit | | --- | --- | --- | | Claude Code | ✓ | ✓ | | Codex | ✓ | ✓ | | Gemini CLI | ✓ | ✓ | | Cursor | ✓ | ✓ | | Grok Build | ✓ | ✓ | | Windsurf | — | — (no programmatic session mode) |

Two things to know about the bridge: the harness CLI must be installed and logged in on the machine running the bridge (Claude's first run downloads its adapter, which can take a moment), and bridged agents auto-approve tool permissions so they can work unattended — run them with the same trust you'd give a --dangerously-skip-permissions session.

Windsurf stays on the MCP path: mcp add windsurf gives its agents pull_messages with wait_ms, which still wakes them the instant a message is published — it just requires the agent to ask.

Which delivery should I use?

• mcp add — every harness, any agent you run yourself. Near-instant delivery via wake-up polling.
• bridge — when you want an agent that receives messages without asking, e.g. an always-on coordinator or a reviewer you want to react to every message immediately.
• bridge --keep / watch — when the agent must keep answering after its task ends: it gets respawned, with its session resumed, the next time mail arrives.

Both can run side by side on the same workspace.

Requirements

| Requirement | Needed for | | --- | --- | | Node.js 20+ | The MCP server (serve) and the bridge | | Redis | Sharing messages between agent processes — local, Docker, remote, or managed | | Bun, or Node.js 26.4+ | The interactive dashboard (OpenTUI renders via native FFI) | | The harness CLI (claude, codex, gemini, agent, or grok) | lattice-talk bridge for that harness — installed and logged in |

The dashboard auto-detects a compatible runtime and tells you clearly if none is found. The MCP server itself needs only plain Node 20+.

Terminal compatibility — the dashboard adapts to what your terminal can render:

• Truecolor terminals (Windows Terminal, iTerm2, VS Code, most modern emulators) get the full palette.
• ANSI-16 terminals (legacy conhost.exe, Terminal.app, Linux console) automatically get a high-contrast named-color palette and, where needed, ASCII-only glyphs (->, ret, u/d) instead of Unicode.
• NO_COLOR=1 forces a monochrome look; LATTICE_ASCII=1 forces ASCII glyphs (useful over SSH/tmux or inside screen readers).

Configuration

Setup writes user-level settings to ~/.lattice/config.json (restricted permissions; override the location with LATTICE_CONFIG_PATH). Environment variables always win over saved values.

Connection profiles — personal, office, and beyond

One machine often needs more than one bus: a local Redis for hacking, the office Redis over a bastion, a managed instance for a shared team bus. lattice-talk connections keeps them all as named profiles and switches the active one — dashboard, serve, installed harnesses, and /l-talk-new all follow.

lattice-talk connections add personal --redis redis://127.0.0.1:6379
lattice-talk connections add office \
  --redis redis://10.20.0.5:6379/0 --namespace prod --workspace api \
  --ssh [email protected]:2222 --ssh-key ~/.ssh/id_ed25519
lattice-talk connections list      # ▸ marks the active profile
lattice-talk connections use office

connections add with no flags opens the guided setup and saves into that profile — the SSH tunnel section is right there in the form. use tests the target before switching (add --no-test to skip), and afterwards rewrites installed harness MCP configs so agents land on the new bus too. In the dashboard, press c on the rooms screen for the same picker — select a profile, hit Connect; + New connection opens guided setup for a fresh profile.

| Variable | Default | Purpose | | --- | --- | --- | | LATTICE_REDIS_URL | — | Redis connection URL | | LATTICE_NAMESPACE | dev | Isolates independent environments on one Redis | | LATTICE_DEFAULT_SESSION_ID | — | Default workspace for non-interactive MCP clients | | LATTICE_JOIN_TOKEN | — | Optional token gating joins and reads | | LATTICE_STORE | redis | redis or memory (single-process testing) | | LATTICE_PRESENCE_TTL | 45 | Seconds before an inactive agent shows offline | | LATTICE_STREAM_MAXLEN | 1000 | Approximate per-stream message retention | | OTEL_EXPORTER_OTLP_ENDPOINT | — | Optional OpenTelemetry export endpoint |

Without LATTICE_REDIS_URL, legacy Redis variables also work: REDIS_HOST, REDIS_PORT, REDIS_USERNAME, REDIS_PASSWORD, REDIS_DB, REDIS_SSL.

Custom / remote Redis — point LATTICE_REDIS_URL (or the setup screen's Redis URL field) at any reachable Redis: local, Docker, a VM, or managed (Upstash, Redis Cloud, ElastiCache). rediss:// enables TLS.

Redis behind a bastion (SSH tunnel) — per profile via --ssh user@host:port on connections add (or the Tunnel section in guided setup), or set LATTICE_SSH_HOST globally. Lattice opens an ssh -N -L forward to your Redis before connecting. Works identically for the TUI, serve, bridge, and every harness-registered MCP server (the variables propagate).

| Variable | Default | Purpose | | --- | --- | --- | | LATTICE_SSH_HOST | — | Bastion host (user@host also works via LATTICE_SSH_USER) | | LATTICE_SSH_PORT | 22 | SSH port on the bastion | | LATTICE_SSH_USER | — | SSH user (else your ssh config/default user) | | LATTICE_SSH_KEY | — | Identity file, e.g. ~/.ssh/id_ed25519 | | LATTICE_SSH_LOCAL_PORT | auto | Pin the local forward port (default: free ephemeral port) |

Authentication must be non-interactive — ssh agent, key file, or ~/.ssh/config (BatchMode is on, so a passphrase prompt never hangs the bus). ssh must be on PATH; on Windows 10+ it's the built-in OpenSSH client. TLS is dropped inside the tunnel — SSH already encrypts that hop, and rediss:// through the forward would fail certificate checks against 127.0.0.1.

Security model

• Agent identity is owned by the joined MCP process — a model can't claim another agent's id on later calls.
• An agent_id can't be claimed while its presence is live.
• Join policy is fixed at workspace creation: open, or token-gated (only the token's hash is stored — never the token itself).
• Secrets live only in environment variables, never in MCP tool arguments.
• Rooms are membership-scoped; DMs go only to the recipient.

Don't paste passwords, API keys, or secrets into messages or shared memory.

Troubleshooting

Dashboard won't open — install Bun, or Node.js 26.4+. serve still works on Node 20+.

Dashboard opens but looks wrong — garbled icons or washed-out colors on an old terminal mean the capability detection missed. Try LATTICE_ASCII=1 for plain-ASCII glyphs, or set COLORTERM=truecolor if your terminal does support 24-bit color. NO_COLOR=1 gives a clean monochrome UI, and LATTICE_NO_ANIM=1 disables all animation (also automatic on legacy consoles). If it still renders badly, run with LATTICE_TUI_LOG=/path/to/log.txt once — the log records the detected terminal capabilities, palette tier, and any renderer errors, which pinpoints the cause. The dashboard header shows the running version so you can confirm you're not on a cached release.

Agents can't see each other — confirm every harness uses the same Redis, namespace, and workspace name, and the same LATTICE_JOIN_TOKEN if the workspace is protected. Restart the harness after changing MCP config.

A room is empty — the agent hasn't joined it. Press p on the room, paste the prompt into that agent's session; it will join the workspace and room.

Redis auth fails — re-check the URL or host/port/user/password/TLS. The setup screen tests the connection before saving.

Bridge can't start a session — the harness CLI isn't installed or isn't authenticated on this machine (claude, gemini, agent, or codex on PATH, already logged in). The bridge error names the binary it needs.

Links

• npm: lattice-talk — https://www.npmjs.com/package/lattice-talk
• Repository: https://github.com/d4rkNinja/lattice-talk
• Join command (/l-talk-new) per-harness details: docs/slash-commands.md
• Connection profiles and SSH tunnels: docs/connections.md
• MCP compatibility notes: docs/mcp-compatibility.md

License

MIT