squad
Cloud agents on a machine you own. Give one a standing job: it wakes on its own, does it, and writes back.
$ curl -fsSL https://squad.mormon.garden/client.sh | sh
$ squad
You choose where the agents live: on your own computer, or in the cloud. It is the first thing it asks — this machine, or a server you have SSH to. A $5 VPS is enough for a few of them.
> every morning at 8, read the board and mail me the things that are stuck on me
Booked for 08:00, every day. I keep what I sent yesterday, so tomorrow's is what changed rather than the same list again.
‹wake› 08:00 · read the board, mail the short list
‹→ email› Two things. ENG-403 has been waiting on your review since Tuesday, and the release branch has had a red check since Friday with nobody on it. The other nine are moving.
A standing job, and it goes and does it
| watch a repo | A check goes red. It reads the failure, fixes it, pushes, and says what it did on the pull request — while you were at lunch. |
| track a rival | Monday at eight: three pricing pages, three changelogs. One mail, and it is what moved. |
| a long errand | Deploy when CI goes green is not one turn. It checks, books itself another turn, and writes when it is live. |
| keep watch | A URL every ten minutes, a certificate that expires. The message arrives from a machine that is not the one that went down. |
| a desk to ask at | Mail it, or message its bot from the airport. It has the repository, the tools and four months of what you told it. |
One agent per job — the column on the left of that console. Making the next one is a name and ⏎.
Its own machine, and root on it
Every agent gets a box of its own. It can pull down a toolchain at three in the morning, run your test suite forty times and fill the disk with a bad build — your laptop is not in the blast radius, and neither is the agent next door. That is what makes it worth handing real work: it does not describe the fix, it makes the fix and runs the tests.
Two things outlive the container. ~/workspace holds your projects, and ~/.self is the agent itself — a git repository it owns:
| soul.md | who it is; added to the prompt every turn |
| memory/ | what it chose to remember |
| skills/ | how things are done here, written down once |
| tools/ | scripts it wrote for itself |
| agent.yaml | the capabilities it asks an operator for |
tools/ is the one to look at twice. An agent that shelled out to something awkward three times writes itself a script for the fourth, and is better at your work on Friday than it was on Monday.
! opens a shell in that same box, and /serve 3000 brings a port out of it onto the machine your browser is on. Agents is the long version.
It books its own next turn, and the day has a ceiling
Two clocks. One you wrote — cron, in a time zone you name. One it sets itself: wake_me asks for another turn in three minutes or three days and leaves a note for the version of itself that wakes up. That is why a long job is something you can hand over rather than sit through.
> /limit 5 Spending limit set to $5.00 a day. $0.42 spent today, of $5.00 a day.
An agent running with nobody watching has a ceiling in dollars a day. Reaching it stops the next turn rather than the one in flight. An agent may ask to be held to less; it gets nowhere asking for more.
What it thinks with is a command and not a redeploy. The key is yours and the bill is your provider's — there is no account here to hold either. Schedules, spending and models.
It has an address and a phone
One mailbox for the whole plane, connected with /email. Every agent has its own address in it — agents+scout@… — and answers in the thread. | |
| telegram | A bot per agent: a token into /telegram, and your phone is where the one-line errands get typed. |
| webhook | For systems rather than people: GitHub, a deploy, anything that can sign a request. |
A reply goes back the way the ask came in. Telegram and mail can be paired to a person, and what that person writes is an instruction. Everyone else is heard, quoted, and not obeyed.
None of the three costs a domain, a certificate or an open port. Email, Telegram and webhooks.
Give it Linear without giving it the key
> /mcp add linear https://mcp.linear.app/mcp "linear" is on the shelf, and this agent has it. Any other agent can have it too, with /mcp linear.
One line, and on its next turn the agent has Linear's tools registered as its own. MCP servers go on a shelf the plane keeps, so every agent after the first is a name off a list.
A server that wants an account is logged into from the console, and the token that comes back stays on the plane. What the agent gets is the tool; what it never gets is the secret.
MCP servers, and web search, which is one granted endpoint and the reading done on the far side of it.
One screen, and it is a terminal
squad on its own opens the console at the top of this page: every agent on the left, the conversation on the right, tab for the log feed, / for the commands and ! for the shell inside the box.
A key, a model, a mailbox, an MCP server, a ceiling — everything is set from in there, and holds from the next turn with nothing restarted.
| /limit | what it has spent today, and the ceiling for it |
| /model | what it thinks with, and what else there is |
| /mcp | the MCP servers it has, and the shelf to add from |
| /serve | a port inside it, on the machine you are sitting at |
| /telegram | the bot it answers on, and how to pair one |
| the address it is reached at, and how to connect a mailbox |
And it is a program on your PATH, so the parts of it that belong in a script are a script. The console has every key and every command.
| squad chat demo | talk to one in the scrollback, turn after turn |
| squad ls | what each agent is and whether it is up |
| squad wake "check the open issues" | take one turn, and wait for the answer |
| squad logs | follow what every agent runs, answers and spends |
| squad rm demo --purge | the sandbox, and with --purge the repository inside it |
Every turn says what it ran, what it answered and what it cost
A request that was refused, or came back 401, is said the moment it happens. The hundred that worked are counted rather than printed.
18:12:53 builds bash pnpm -r test18:12:53 builds bash ✗ after 12.4s: FAIL test/turn.test.ts > carries the failure detail18:12:53 builds read packages/control-plane/src/turn.ts18:12:53 tickets egress ✗ denied GET api.github.com/repos — no_matching_host18:12:53 builds answer The test asserted the old message.18:12:53 builds spent 1m38s · 91.2k tokens · $0.02 · api.deepseek.com ×12
squad logs — what every agent runs, answers and spends.
Three rules it cannot talk its way past
An unattended agent reads what strangers write
A GitHub webhook is authentic and still relays an issue body typed by anyone. Everything that did not come from you arrives fenced, as data.
Only an operator gives instructions.
A credential can be spent anywhere
So the agent never holds one. What it reaches for goes out through a proxy that checks the request against what you approved and attaches the secret afterwards. An agent talked into sending you its API key has nothing to send.
The agent never sees a key.
An agent can edit its own definition
It owns its repository, and a line in it is a request. What it may reach is answered in a file it cannot write.
Nothing it says can grant it anything.
The sandbox network is unrouted, so the proxy is not a convenience it could route around — even reaching the model provider is an approval. Trust and reach are where that is spelled out.
The honest list
- Slack, Discord and the rest. Mail, Telegram and webhooks are there. The others are adapters nobody has written yet.
- Anything multi-tenant. One config file, one operator, one machine.
- Isolation stronger than a container. One Docker container per agent, not a microVM — because if self-hosting needed microVMs nobody would run it.
- A hosted anything. No account, no dashboard and no bill from us. You bring a machine and a model key, and what it costs is what your provider charges.