One binary, no daemon zoo: from `brew install` to a working agent in five minutes

Self-hosting an AI agent usually costs a weekend of gateway daemons and pairing codes. We timed the rysh version on camera: 1:47.

Everyone is self-hosting AI assistants right now, and the untold cost isn't the model. It's the plumbing: an always-on gateway process, device pairing, channel plugins, a config file you edit with your heart rate slightly elevated — and then the operational question nobody budgets for: how do I manage this thing when I'm not sitting at the box?

I've been building rysh — an agentic terminal multiplexer where every pane can be a shell, an agent, or a chat — and we recently timed the thing we care most about, on camera, in one take: from brew install to an agent answering a teammate's question on the company Slack in 1 minute 47 seconds. Real clock on screen, no mockups.

This post walks through the mechanics, because I think the mechanics are the argument. As always: real commands, and an honest list of what's not done at the end.

The baseline: what self-hosting usually costs

The most popular self-hosted assistant stack right now is OpenClaw — ~383k GitHub stars, MIT-licensed, genuinely impressive, and I mean that without a wink. But look at what its own docs describe as the happy path:

1. Install a Node runtime (22.22.3+)
2. curl … install.sh | bash, then an onboarding wizard that installs a daemon
3. The gateway is "one always-on process" — a LaunchAgent on macOS, a systemd user unit (plus loginctl enable-linger) on Linux
4. Real chat channels are plugins: channels add → restart the gateway → QR login → pairing-code approval (codes expire in an hour) → allowlist edits in a JSON5 config
5. Remote administration, per the docs: SSH tunnel or Tailscale to a localhost dashboard

None of that is a bug. It's the honest cost of the architecture: a gateway daemon that bridges chat networks needs to always run, needs pairing, needs config. But it's a weekend, and then it's an ops burden — and researchers reported roughly 40,000 of those gateways sitting exposed on the public internet earlier this year, which tells you how the "keep a daemon alive and tunnel into it" model goes for busy people.

(To be precise about the comparison rules I'm holding myself to: everything above is from OpenClaw's own documentation; "researchers reported" is SecurityScorecard's number, not OpenClaw's; and none of this is a claim about what OpenClaw can't do — only about what its documented path costs.)

The rysh version: two artifacts

rysh collapses that stack into two things you can read in one sitting.

Artifact one: a self-contained binary. The message broker (NATS) is embedded — there is no separate daemon zoo to stand up. The session daemon is rysh.

brew install rysh-ai/rysh/rysh
rysh

Artifact two: a markdown file that IS the agent. Persona in the body, channels in the frontmatter, secrets as ${ENV} tokens — which means your agent is versionable, reviewable, and diffable like any other file in the repo:

---
name: support-bot
description: Support engineer for the #support-desk channel
contacts:
  slack:
    enabled: true
    bot_token: "${SLACK_BOT_TOKEN}"
    app_token: "${SLACK_APP_TOKEN}"
    reply_mode: mentions
    channels:
      - "#support-desk"
---
You are support-bot, the support engineer for our CLI product.
Answer briefly, only from the product facts below. If you don't
know, say so and offer to open a ticket.

Spawn it and connect the channel — two commands inside the rysh TUI:

##humanoid spawn support-bot
##humanoid channel start support-bot slack

That's the whole setup. Slack connects over Socket Mode (no public webhook, nothing exposed), and when a teammate @-mentions the bot in the channel, it answers on its own. On our filmed run, the clock read 0:47 when the channel connected and 1:47 when we got to the step below.

The part chat-bridge stacks don't have: the terminal is a surface

Here's the thing I actually wanted to show off. An agent in rysh isn't a process behind a bridge — it lives in a pane, a real terminal. And panes are shareable, live:

##share pane view          # → returns a share ID

From any other rysh session — another machine, another person:

##upstream subscribe e9780ee4-... view

…and they're watching the agent's actual terminal in real time. view is read-only; control exists as a per-share decision, not a global switch. The docs-verified remote story of the DIY stack above is an SSH tunnel to a dashboard; here, observing your agent is a first-class primitive of the tool.

Manage it like infrastructure

The other operational half: a rysh session is manageable headlessly, from any shell, without attaching a UI:

rysh send northwind "git status" --mode shell   # inject a command into the running session
rysh attach northwind                            # pick up the live session from any terminal

And inside the session, the lifecycle verbs you'd expect:

##humanoid channel stop support-bot slack
##unshare pane

Detach, and the session keeps running. rysh send is the piece I use most — it turns "SSH in and poke around" into "fire a command at the session from a script."

What's not done (the honest list)

This section is the reason I like publishing here.

• Channels today: Slack, email, website chat. WhatsApp and phone are on the roadmap — there's scaffolding in the codebase, but I'm not claiming them until they're real.
• The pane doesn't yet mirror the Slack conversation. We found this gap while filming: you can register a pane for an agent's output, but ai-mode channel exchanges don't surface in any pane stream yet. The conversation is fully observable in Slack itself; in-pane mirroring is a tracked fix.
• Share streams are not value-redacted yet. Pane sharing does not currently scrub secret values from shared output. ##secret masking exists as a separate feature, but treat a shared pane like a screen-share: don't share panes where credentials get printed.
• Duplicate replies, rarely. Two live sessions running the same humanoid = two Slack sockets = duplicate answers. We hit this in testing; run one session per agent until the guard ships.
• rysh runs on Anthropic Claude, on your key. This is not a "better model" story and never will be — the work is in the surface around the model: channels, sharing, governance, headless ops.
• Self-hostable ≠ open source. You run it on your box with your keys; the source isn't open today.

The clock, one more time

brew install → TUI → ##humanoid spawn → Slack connected (0:47) → teammate's question answered on the company Slack → pane shared to a second session (1:47). One take, timer burned into the frame, trims disclosed on screen.

We're recruiting design partners — hands-on early adopters running agents for a real team, with a direct line to the founder. Early is a feature: rysh.ai/design-partner

Related: Rysh vs OpenClaw · Humanoids: agents with a Slack handle and an email address