crosstalk-runtime

Prompt-driven multi-agent orchestration. A system daemon that delivers messages between humans and AI agents using a git repo as the message bus. Agents coordinate through their standing orders — plain-language system prompts that define how they delegate, escalate, and collaborate. No code graphs. No visual builder. The markdown file is the workflow.

Watches Crosstalk transport repos, dispatches messages to agent CLIs (Claude, Gemini, agy, etc.), and commits replies back — all as git commits.

Haven't set up a transport yet? Start there first → cordfuse/crosstalk

Platform support

Linux and macOS only. Windows is not supported — run crosstalk inside WSL2:

# Elevated PowerShell — one-time setup
wsl --install
# Reboot, then open a WSL terminal and use the Linux installer below

Install

Linux / macOS — one-line installer:

curl -fsSL https://github.com/cordfuse/crosstalk-runtime/releases/latest/download/install.sh | bash

Detects your OS and package manager, downloads the right package, and installs it.

Manual:

| Platform | Command | |---|---| | Arch / CachyOS | sudo pacman -U crosstalk-runtime-bin-<version>-1-x86_64.pkg.tar.zst | | Debian / Ubuntu | sudo apt install ./crosstalk-runtime_<version>_amd64.deb | | Fedora / RHEL | sudo dnf install ./crosstalk-runtime-<version>-1.x86_64.rpm | | macOS (Homebrew) | brew install cordfuse/tap/crosstalk-runtime |

All packages are on the releases page.

Quickstart

# 1. Generate an SSH deploy key
sudo crosstalk keygen
# Add the printed public key to your transport repo:
# GitHub → repo Settings → Deploy keys → Add deploy key (allow write access)

# 2. Install the daemon and clone your transport (requires sudo)
sudo crosstalk install [email protected]:you/your-transport.git

# 3. Start the daemon
sudo systemctl start crosstalk   # Linux
# sudo launchctl load -w /Library/LaunchDaemons/ai.cordfuse.crosstalk.plist  # macOS

# 4. (Optional) Add a project repo as a workspace
crosstalk add-workspace [email protected]:you/your-project.git

# 5. Open a session
crosstalk open

crosstalk open drops you into a session with the concierge. Type your directive — "fix the auth bug, route frontend tickets to junior-developer" — and the swarm acts on it. The concierge delegates, agents execute, replies come back as git commits.

The daemon runs as a system service (crosstalk.service) and starts automatically on boot.

Commands

Setup (requires sudo)

sudo crosstalk keygen                    Generate SSH deploy key and print public key
sudo crosstalk install <git-url>         Clone primary transport, install binary, register service
sudo crosstalk uninstall [--purge]       Stop and remove the service (--purge wipes /var/lib/crosstalk)

sudo crosstalk agent install <cli>       Install an agent CLI into the daemon user home
sudo crosstalk agent upgrade <cli>       Upgrade an installed agent CLI to latest
sudo crosstalk agent uninstall <cli>     Remove an agent CLI from the daemon user home
crosstalk agent list                     Show known agents and installation status

sudo crosstalk auth <cli>                Authenticate an agent CLI as the daemon user (OAuth / API key flow)

Supported agents: claude, agy, gemini, codex, qwen, opencode.

Operator day-to-day (no sudo needed)

crosstalk add-transport <git-url> [--name <alias>]         Register an additional transport
crosstalk remove-transport <name>                          Unregister a transport

crosstalk add-workspace <git-url> [--transport <name>]     Clone and register a project repo
crosstalk remove-workspace <name> [--transport <name>]     Unregister a workspace

crosstalk open [--transport <name>] [--workspace <name>] [--agent <name>] [--actor <name>]
                                                           Open an interactive agent session
crosstalk status                                           Show daemon state, transports, and workspaces

crosstalk open flags

| Flag | Description | |---|---| | --transport <name> | Which transport to use (required if multiple registered) | | --workspace <name> | Which workspace to open in (required if multiple in the transport) | | --agent <name> | Agent tier to invoke (e.g. claude, agy) | | --actor <name> | Actor to address (default: concierge) |

Multi-transport

Each transport is an independent Crosstalk channel repo. Register as many as you like:

sudo crosstalk install [email protected]:you/transport-a.git
crosstalk add-transport [email protected]:you/transport-b.git --name work

crosstalk add-workspace [email protected]:you/project.git --transport work
crosstalk open --transport work --workspace project

The daemon polls all registered transports concurrently.

Service management

sudo systemctl start crosstalk
sudo systemctl stop crosstalk
sudo systemctl status crosstalk
journalctl -u crosstalk -f

Agent setup

After crosstalk install, set up each agent CLI the daemon will use:

# 1. Install the CLI into the daemon user home
sudo crosstalk agent install claude

# 2. Authenticate (OAuth browser flow or API key entry — runs as the daemon user)
sudo crosstalk auth claude

# 3. Restart so the daemon picks up the new binary and credentials
sudo systemctl restart crosstalk

All CLIs must be invoked with a headless skip-permissions flag in your host file:

| CLI | Flag | |---|---| | claude / agy | --dangerously-skip-permissions | | gemini / qwen | --yolo | | codex | -s danger-full-access | | opencode | (none) |

Example host file entry:

actors:
  concierge:
    sonnet:
      cli: claude --model claude-sonnet-4-6 --print --dangerously-skip-permissions

SSH / Git auth

crosstalk keygen generates an SSH key at /var/lib/crosstalk/.ssh/id_ed25519 and prints the public key. Add it as a deploy key on each transport repo (GitHub → repo Settings → Deploy keys → Add deploy key, allow write access).

After adding the key, verify the connection before starting the daemon:

sudo -Hu crosstalk ssh -T [email protected]

How orchestration works

Most orchestrators define agent workflows in code or a visual graph — you wire nodes together and the routing is structural. Crosstalk is different: orchestration lives in the standing orders.

Each actor has a system prompt (manifest/custom/actors/<name>.md in the transport). That prompt defines who they are, how they delegate, and how they escalate. The concierge might say:

"When you receive an engineering task, delegate it to junior-developer. If it involves security or production infrastructure, escalate to senior-engineer instead."

That prose is the routing table. Change the orchestration by editing a markdown file — no redeploy, no graph editor, no code change.

Execution happens through crosstalk open. You open a session, give the concierge a directive — "fix the auth bug this sprint, deprioritise everything else" — and the standing orders determine what happens next: who gets delegated to, what gets escalated, how the swarm organises around the task. The directive is the marching order; the standing orders are the rules of engagement.

The tradeoff vs code-defined graphs: prompt-driven routing uses agent judgment, not deterministic if-else. For async workflows that's usually a feature, not a bug.

Host file

The daemon reads your machine's actor config from manifest/hosts/<alias>.md in the transport:

---
alias: my-machine
hostname: my-hostname
actors:
  concierge:
    claude: claude --model claude-sonnet-4-6 --print
  engineer:
    haiku:
      cli: claude --model claude-haiku-4-5 --print
      count: 3
    gemini: gemini --model gemini-2.5-flash -p
---

• alias — human-readable name; used in actor@host message addressing
• hostname — must match os.hostname() on this machine
• Tier names (claude, haiku, gemini) are your labels mapping to CLI commands
• count sets parallel workers per tier; omit for a single worker

Requirements

• A Crosstalk transport repo → cordfuse/crosstalk
• At least one agent CLI installed and authenticated (claude, gemini, agy, etc.)
• Linux (x64/arm64), macOS (x64/arm64), or WSL2 on Windows

License

MIT