Case study
JARVIS v4 — the harness we run on ourselves.
Before we talk about a harness, we run one. JARVIS v4 is that system: domain-scoped agents, each with its own channel, session, and host — operated from one laptop through chat.
The problem we were solving.
Agent number five is where spreadsheets stop working. Each new domain meant another SSH key, another chat channel, another set of credentials, and another place to look when something failed at 2 a.m.
We needed a control plane that stayed on hardware we owned, kept blast radius readable, and let a human approve work from a phone without opening a terminal.
Three layers.
- ChatThe control surface. Humans dispatch work, agents reply in-channel, files attach inline. No separate dashboard required for day-to-day ops.
- DeskA fleet view on the operator laptop — live pane previews, draggable agent cards, in-browser terminal when you need fingers on glass.
- HostEach agent runs in a persistent tmux session on a server they control. Credentials never leave that boundary.
One name, four things.
Every agent shares a single name across four resources: working directory, channel, tmux session, and SSH host alias. When one name misbehaves, you know exactly which session, which channel, and which key — without a lookup table.
That convention is the harness. The models are interchangeable; the boundaries are not.
Supervision and record.
- Live panesWatch an agent work in real time. One command halts a run mid-task.
- Dispatch logEvery inbound message and outbound reply appended per agent as JSON lines — audit trail by default.
- Sandbox scopeEach agent directory is isolated. Cross-scope reads are blocked at the rule layer, not by politeness.
- Contact formsSites post leads straight into the agent's channel through a small PHP handler — no shared inbox to triage.
What shipped.
JARVIS v4 is open source under MIT — docs, monitor, deploy tooling, and the agent template. We use it daily; the case study is the system we keep tightening.