How I got my AI to do jobs from a text on my phone

This week I nearly threw out the whole AI setup I’ve spent months building. A new self-hosting agent had just come out that you can message from anywhere, and it looked like the future. Then I noticed what I actually wanted from it: not a new brain, just a way to reach the one I already had when I’m not at my desk. So I kept my setup and added the one missing piece. Now I send a command from my phone and my always-on computer does the whole job, no laptop needed. Here’s how it works, and how to set up your own.

💡 The principle: when a shiny new tool tempts you, work out which one piece you actually envy — then add just that piece to the setup you already know, instead of starting over.

The job I sent from my phone

The test that told me it worked: from a terminal app on my iPad, away from my desk, I typed one line — “restart the media server” — and sent it. My home computer picked it up, worked out what I meant, ran the job, and reported back. No screen to log into, no laptop, nothing to click. The server was back up, and I never sat at a keyboard.

That’s the entire feature. The AI I write and work with every day now answers to a text message, and it brings all of its usual abilities with it — my notes, my shortcuts, the tools it already knows how to use.

What tempted me, and what I did instead

The tool that started this was Hermes, a self-hosting agent from Nous Research. Its pitch is genuinely good: run it on a cheap always-on server and talk to it from your phone while it works in the background.

https://github.com/NousResearch/hermes-agent

I cloned it and read through it properly before committing. The conclusion surprised me: running it would mean starting a second, empty assistant next to the one I’d already taught — my writing voice, all my custom shortcuts, my memory, every tool I’d connected. The new agent had none of that on day one. What it had that I didn’t was one thing: I could reach it from my phone.

So rather than move house, I borrowed that single idea and built it onto what I had. I have an assistant for exactly this kind of job — it studies an outside tool, keeps the good pattern, and adapts it to fit my own setup instead of bolting the whole thing on.

https://jimchristian.net/blog/2026/01/07/borg-agent/

What “headless” and SSH actually mean

Two words do the heavy lifting here, and both are simpler than they sound.

SSH is a secure way to type a command on one computer and have a different computer run it. Think of it as a locked tunnel between your phone and your home machine: whatever you type at one end, the other end does. It’s decades old and it’s what professionals use to run servers they never physically touch.

Headless means “with no screen or keyboard attached.” A headless program runs on its own, in the background, driven by a command instead of by someone clicking. When I say I run my AI headless, I mean it works from a single typed instruction with nobody sitting in front of it.

The command that ties them together is a one-shot version of my AI assistant: give it one instruction, let it use all its tools to carry that out, and have it stop when it’s done. Send that command down the SSH tunnel from your phone, and your home computer does the work.

Why the setup matters more than the tool

The lesson I nearly missed is worth more than the trick itself. The value in an AI setup isn’t the model — those change every few months and you can swap them freely. The value is everything you’ve taught it: your preferences, your files, the little workflows you’ve built up so it does things your way without being told each time. That accumulated setup is hard to rebuild and easy to underrate. A brand-new agent, however clever, starts with none of it.

The real gap for me was never a smarter assistant — it was reach: being able to hand it a job when I’m away from my desk. Once you see that, you stop shopping for a replacement and start looking for the one small piece that closes the gap. That habit of adding the missing piece instead of restarting will save you far more time than any single tool.

Set up your own, from the simplest version up

You’ll need three things: a computer that stays on (a home machine you leave running is fine), an AI assistant that has a command-line mode, and a phone. Start at step one and stop wherever it’s useful enough.

Get a terminal on your phone. Install a terminal app that speaks SSH. I use Termius; it’s free to start and runs on iPhone, iPad, and Android.
Connect to your home computer once. In the app, add your always-on machine and connect to it over SSH on your home network. When it works, you’ll get a text prompt on your phone that’s really running on the other computer. Your AI assistant probably has a setup page for this — the sample prompts below walk you through it in plain steps.
Run your assistant from that connection — the step that usually needs a second try. Typing the command by hand from your desk works straight away. Running it headless, with nobody logged in at the screen, often fails at first, and the reason is boring rather than hard. On my Mac, the stored login sat in a keychain that stays locked until someone signs in at the actual screen, so over SSH the assistant couldn’t find its own login and refused to start. The fix was three small changes: create a long-lived access token so it doesn’t depend on the locked keychain, mark the working folder as trusted so it doesn’t stop to ask, and make sure the assistant’s program is findable in a bare, no-frills session. Do those once per machine and the headless command works every time. Give this step the most patience; everything before it is easy.
Put a safety floor in front of it — do not skip this. Once you can trigger jobs remotely, and especially if you let the assistant run without pausing to ask permission, you need a hard rule that refuses catastrophic commands before they run — wiping a disk, deleting your home folder, piping a random web script straight into your shell. I added exactly this: a check that inspects every command first and blocks the dangerous shapes. It proved itself the same afternoon by blocking one of my own commands mid-build. Build the guardrail when you build the feature, not after something goes wrong.

Sample prompts

Paste these into your AI assistant, on the home computer, and fill in the brackets.

Diagnose why the headless run fails:

I want to run you headless — triggered over SSH from my phone with nobody
logged in at the screen — but it fails when no one is signed in. Ask me for
whatever you need (my operating system, the exact error), then explain in plain
terms why a background SSH session can't reach a saved login, and list the
fixes in order.

Set it up so it works every time:

Walk me through making yourself runnable headless on [my operating system],
one step at a time, checking each worked before the next: (1) create a
long-lived access token so you don't depend on the locked keychain, (2) mark
[the folder I work in] as trusted, (3) make sure your program is on the PATH in
a non-interactive shell. Keep any secret out of anywhere it could be logged.

Build the safety floor before you go hands-free:

Before I let you run jobs from my phone without approving each one, help me add
a safety check that inspects every command and refuses the catastrophic ones —
erasing a disk, deleting my home folder, piping a downloaded script straight
into a shell. Write it, give me a list of dangerous commands to test it against,
and confirm it blocks each one while still allowing safe everyday commands.

Where this can go wrong, and where it goes next

Two cautions. First, treat the safety floor as mandatory, not optional — remote, hands-free command-running is exactly the setup where a single bad instruction does real damage, so the guardrail is the price of admission. Second, when the assistant kicks off other programs, make sure your keys and passwords aren’t quietly handed down to them; keep secrets scoped to the one process that needs them.

Where it goes next, for me, is a proper phone front-door: message a chat bot, tap a button to approve, instead of typing a command in a terminal app. I’ve sketched that design but haven’t built it, because typing one line in Termius already does the job — and a feature you don’t need yet is one you don’t have to maintain. That’s the same instinct that started this: add the piece that closes a real gap, and leave the rest until it earns its place.