I turned an old laptop into an always-on home for my AI agent

I have an AI agent named Hermes. It reads my email, drafts replies, runs my morning briefing, triages real estate deals, and quietly keeps my life organized in the background. For a while, it lived on my laptop. Which meant it only existed when my laptop was open, awake, and online.

That's a strange thing to accept once you notice it. I'd built an assistant that was supposed to work for me around the clock, and it clocked out the moment I closed the lid to go to dinner. A morning briefing that runs at 7:15 a.m. is useless if the machine that runs it is asleep on my nightstand. An agent that watches my inbox can't watch anything when the laptop's in a bag.

So the real project wasn't "set up a server." It was: give this thing a body that never sleeps. Here's the whole story — why I did it, how it actually works now, and the parts that broke and taught me the most.

Why an agent needs a place to live

An AI agent isn't just a chatbot you talk to. The interesting part is the stuff it does when you're not talking to it — the scheduled jobs, the inbox watching, the "check this every 30 minutes and tell me if something matters." That's the whole value. And all of it depends on one boring requirement: the agent has to be running, continuously, somewhere.

You have a few options for "somewhere":

• A managed cloud AI service — easiest, but you're renting someone else's box on their terms, and you don't fully control the agent's runtime, its memory, or what it's allowed to touch.
• A cloud server (VPS) — a small computer you rent by the month. Total control, always on, but it costs money and you own the maintenance.
• Hardware you already own — free, private, yours. You just have to make it behave like a server.

I wanted control and privacy without a monthly bill, so I ended up at option three. But I didn't start there — and the path is the useful part.

The whole point of an agent is what it does while you're not watching. That only works if it never turns off.

Renting a computer in a data center

My first move was the conventional one: I rented a VPS — a virtual private server. Think of it as a small computer sitting in a data center that you rent for a few dollars a month. Mine was a tiny box in Dallas: one processor core, two gigabytes of memory, running Linux. Small. Cheap. Always on.

For a few weeks it did the job. Hermes lived there full-time, answered me over Telegram and Slack, and ran its scheduled jobs whether my laptop was open or not. This was the first time the agent felt real — like something that existed independently of me.

But two gigabytes of memory is not a lot of room, and I learned that the hard way (more on the specific disaster below). The box was cramped. Every scheduled job was a small game of "will this run without running out of memory." It worked, but it felt like keeping a large dog in a studio apartment.

The old laptop in the closet

Then I remembered the HP Spectre sitting in our closet. It had been my wife Anne's laptop all through college — right up until I may or may not have accidentally cracked the screen, which left it pretty much useless as a laptop. We bought her a MacBook Air M1 not long after, and the Spectre had sat idle ever since: screen cracked, lid mostly shut, decidedly not worth fixing.

Which, it turned out, made it perfect. Under the busted screen it was still a capable machine — Intel i7, four processing threads, seven gigabytes of usable memory, more than triple the cramped little cloud box. And here's the thing about a server: it runs closed, in a corner, with nobody ever looking at the screen. The one flaw this laptop had was the one thing a server would never need.

So I decided to give it a second life as the agent's permanent home. Same job as the cloud box, better body — and no monthly bill.

This is where the project got genuinely interesting — and where most of the actual work was. A laptop is not a server. It runs Windows, it's built to sleep the moment you close it, and it assumes a human is sitting in front of it. I had to undo all of that. I want to walk through the real process, because I'd seen people mention doing this online, but I still had to research every step to make it actually work.

Turning a Windows laptop into a Linux server

The first decision was the operating system. The Spectre came with Windows, which is heavy, hungry for resources, and full of things a headless server will never use. I wanted Ubuntu instead — a free, lightweight version of Linux that's the standard for servers. Running it would free up all the space Windows was eating and leave the machine's modest memory for the work that matters.

Installing a whole new operating system sounds intimidating, but the whole conversion — wiping Windows through to a configured server — is just a handful of steps:

I downloaded the Ubuntu installer — a single large file called an "ISO," basically the whole operating system in one download. To install from it, you can't just double-click it; you have to write it onto a USB flash drive in a special bootable way. The tool for that is BalenaEtcher: you point it at the ISO and a flash drive, hit go, and it turns the stick into an installer. Plug that stick into the Spectre, tell it to boot from USB, and Ubuntu's installer takes over.

During the install I chose to erase Windows entirely rather than dual-boot. That was deliberate — Windows would have kept eating disk space and memory for an interface this machine will never show anyone again. When it finished, the Spectre was a clean Linux box: nearly the whole drive free, memory unburdened, nothing running but what I put there.

I had an AI set up the server for the AI

Here's my favorite part. Once Ubuntu was installed, I needed to reach the laptop and configure it — and I did not want to hunch over a closed laptop typing arcane Linux commands by hand.

Two tools solved that. First, Tailscale — a tool that builds a small private network between your own devices, wherever they are. My phone, my Mac, and the Spectre all join the same private mesh; to each other they look like they're on the same home network even when I'm across the country, and nothing is exposed to the public internet. Second, SSH — the standard way to control one computer from another over a network, as a text terminal.

With those two in place, I could SSH into the Spectre from my Mac — and that meant I could point Claude Code, the AI coding assistant I already use, straight at the server. Instead of me researching and hand-typing every configuration command, I described what I wanted in plain English and had the AI write and run it: never sleep, ignore the lid, set the timezone, install the runtime, wire up the background service. I used one AI to build the home for another.

I described the server I wanted in plain English, and had one AI build the home for the other.

Teaching a laptop to never sleep

The most important change: a laptop sleeps when you close the lid, which is the exact opposite of what a server needs. Linux calls this the "lid switch," and you can tell it to ignore the lid entirely — plugged in or on battery. Now the Spectre lives closed, standing in a corner, quietly working. People call this "clamshell mode," and it turns any laptop into a compact, silent server with a battery backup built right in — cracked screen and all.

# From my Mac, hop onto the laptop-server over the private network
$ ssh bwnankee@bryant-vps

# Tell it to keep running with the lid shut (the key setting)
$ sudo nano /etc/systemd/logind.conf
  HandleLidSwitch=ignore
  HandleLidSwitchExternalPower=ignore

Making the agent restart itself

A server has to survive things you're not around for — a crash, a power blip, an update. On Linux, the tool for this is systemd, which supervises long-running programs. I set Hermes up as a systemd "service," so the operating system itself is responsible for keeping it alive: if it crashes, systemd restarts it; if the laptop reboots, the agent comes back on its own. That's the difference between "a program I ran once" and "a service that runs."

Moving Hermes without losing anything

Setting up an empty server is one thing. My real challenge was that Hermes was already alive on the cloud VPS — with its memory, its saved conversations, its credentials, its scheduled jobs, its whole personality. I had to move an entire running system off the cloud and onto the laptop cleanly, without losing its history or leaving it broken in between.

That meant carefully transferring the agent's config, its secrets, its saved state, and its schedule, then standing it up on the new machine and verifying every piece still worked before retiring the old box. A few things you learn only by doing it: the agent's brain runs as a different system user on a real laptop than it did on the bare cloud box, so file paths shift. Exactly one copy of the agent is allowed to answer a given chat account at a time, so the old and new can't both be live for the same channel. And its saved memory has to come across intact, or it wakes up an amnesiac.

Once the laptop had taken over — answering on Telegram and Slack, running every scheduled job, remembering everything it used to — I shut the cloud VPS down for good. The agent never noticed it had moved.

One workspace, kept in sync everywhere

There was one more problem to solve, and it's the piece I'm most glad I got right. My whole life runs out of a folder called BryantOS — notes, project files, the context my agent reads to know what's going on. That folder lives on my Mac. But now Hermes lives on the laptop-server. If those two copies drifted apart, the agent would be working from stale information the moment I edited anything.

The fix is a tool called Syncthing. It keeps a folder mirrored across two machines in real time — no cloud service in the middle, just my two computers talking directly over that same private Tailscale network. I change a note on my Mac, and a second later it's on the server. The agent adds something to its memory on the server, and it shows up on my Mac. Both machines always hold the same truth.

The practical payoff: I can be at my desk on the Mac or away with just my phone, and it doesn't matter. There's one workspace, and it's everywhere at once. Getting the sync rules right took some fiddling — you have to teach it which files to skip, like the internal bookkeeping folders that shouldn't be copied — but once it's dialed in, it's invisible, which is exactly what you want from infrastructure.

What's actually running

Here's the whole setup, in one place. None of these pieces are exotic — that's kind of the point. This is standard, boring infrastructure, assembled to do something personal.

A detail I care about: the model has a fallback chain. The agent's brain is a large language model it calls over the internet. My primary is a free, fast model; if that one's throttled or down, it automatically drops to a paid backup, and below that to a smaller model. So a single provider having a bad night doesn't take my assistant offline. That resilience matters more than raw speed when the thing is supposed to run unattended.

How it works for me, 24/7

The always-on part unlocks the feature I actually wanted: scheduled jobs. Hermes runs on a timer. A few of the standing jobs:

• Morning briefing — every morning it pulls my calendar, tasks, unread email, and the weather, and sends me one clean summary before I'm even up.
• Email triage — every 30 minutes it reads new mail, sorts it, drafts replies to the ones that need them (but never sends without me), and turns action items into to-dos and calendar events.
• Deal triage — for my real estate side, it screens new property leads against my criteria.
• Weekly writing — it drafts recurring content on a schedule.

None of that is possible on a laptop that sleeps. All of it is trivial on a machine that never does. That's the entire return on this project: the agent went from "a thing I open" to "a thing that's just running," and everything it does in the background became possible the moment it had a place to live.

The part where I took down my own server

I'll end with the mistake, because it's the most useful thing I learned.

Back on that cramped two-gigabyte cloud box, I wanted to test one of the scheduled jobs by hand instead of waiting for its timer. Seemed reasonable. I logged in and ran it directly.

The job ran wild. On a normal scheduled run, the system caps how much memory a job is allowed to eat — a safety fence. But by running it manually from my login session, I'd started it outside that fence. With no cap, it devoured all the memory the little box had, then started thrashing. The machine got so starved it couldn't even let me log back in to stop it. My assistant went silent. I'd knocked over my own server by being impatient.

That single mistake taught me more about how these systems really work — memory limits, process isolation, why the "boring" supervisor exists — than any amount of reading would have. Which is the theme of most of what I build: I learn the thing by needing it, breaking it, and fixing it.

You don't need much to start

Here's what I'd tell anyone eyeing something similar. You don't need a data center or a big budget. You need a computer that stays on, a private way to reach it, something to keep your program alive, and the patience to break it a few times. The old laptop in your drawer is very possibly enough.

The mindset shift is the real unlock. Once you stop thinking of your AI as something you open and start thinking of it as something that runs, a whole category of "just handle this for me in the background" becomes available. Giving the agent a permanent home was the moment mine stopped being a toy and started being infrastructure.