🤖Agents running on the mini-PC

Until now, you launched the agent by hand, watched it work, closed the terminal. That’s perfectly fine, but it’s also missing the real power of a dedicated machine. Your laptop, you close it, it sleeps, it goes to meetings with you. The mini-PC, on the other hand, stays on, silent, sipping next to no electricity, day and night. And that changes everything: it becomes the perfect host for agents that work without you.

This is exactly what a laptop can’t do. An agent that wakes up every morning at 7 a.m. while you sleep, that watches a feed all day long, that prepares a report for you over your weekend, it needs a machine that never turns off. You have one. Let’s see what to do with it.

The idea: an always-present machine = agents that run without you

An agent, as we saw in What is an agent, is a loop: goal, action, observation, repeat. Nothing forces this loop to unfold before your eyes. If you can trigger it on its own : on a schedule, on an event, in the background, then your mini-PC turns into a colleague that works while you live your life.

A few examples that become possible the day the machine stops sleeping:

• Every morning, an agent rereads the open pull requests and posts you a summary on Slack.
• An agent watches an RSS feed or an API and warns you when something moves.
• A recurring report (yesterday’s numbers, the state of a service) generated and sent without you lifting a finger.
• An agent that monitors a service and alerts you when it goes down.

The common thread: nobody is in front of the screen. And that’s where the dedicated mini-PC beats the laptop hands down.

Agents in the background or on a schedule

How do you go from “an agent I launch” to “an agent that launches itself”? With Linux’s two old scheduling tools: cron and systemd timers. You ran into them in System settings, they’re the ones that fire a command at a fixed time, over and over, without you.

The trick is that your agent knows how to run in non-interactive mode (“headless”): instead of opening a terminal and chatting, you hand it a task all at once, it executes it, returns its result, and stops. Plug this mode into a timer, and you have a recurring agent.

The real shape, without the syntax details:

# crontab -e, every morning at 7 a.m., we wake the agent on a fixed task
0 7 * * *  cd ~/projects/watch && /path/to/agent "Review the open PRs and post a summary" >> ~/logs/watch.log 2>&1

The timer calls the agent with a task, the agent loops on its own until “it’s done”, writes to a log, and hands back control. Tomorrow morning, same again.

The winning combo: local agents + Ollama

An agent that runs a hundred times a day, you don’t want to pay for a hundred times a day. And if it handles sensitive data, you don’t want it leaving for a third party on every loop. This is exactly the playground of the hybrid cloud + local, applied to autonomous work.

The idea: for high-frequency, private, or offline loops, you point the agent at a local model served by Ollama. Marginal cost: zero. Data leaving: none. A background agent that classifies, summarizes, or monitors a thousand times a day runs for free and in private on your machine. You save the cloud (Claude) for the rare moment when you really need top-tier reasoning.

Reachable from anywhere

The mini-PC is on your private network. So you don’t need to be physically in front of it to hand it work or check where it’s at. From your phone on the subway, from your laptop at a client’s: you text a task to your machine, it works while you’re elsewhere, and you review the result later.

That’s the whole point of the networking chapter coming up, Tailscale weaves the private link between your devices, and Working remotely shows how to drive the agent from anywhere. The mini-PC becomes a workshop you carry in your pocket without ever unplugging it.

Keeping a session alive with tmux

Not all agents are scheduled jobs. Sometimes you launch a long interactive session, you close your laptop, and… it dies with your connection. Unless you launched it inside tmux (installed back in System settings).

tmux is a terminal session that survives your disconnection. You start the agent inside it, you detach, the session keeps running on the mini-PC. Later, from anywhere, you reattach and find the agent right where you left it.

tmux new -s agent      # create a named session and launch your agent inside it
# Ctrl-b then d          → you detach, the agent keeps going
tmux attach -t agent   # later, from wherever you want, you take back control

The security of an autonomous agent

We come to the serious point. An agent that acts with no human in the loop is precisely where the rule of least privilege matters most. When you’re in front of the screen, you can say “no” before the blunder. In the background at 3 a.m., nobody will say no for you.

Setting up a recurring agent: the checklist

An honest word on long-running autonomy

Let’s be clear: unsupervised autonomy on long, open-ended tasks remains the frontier of the field. Local models, in particular, are far better as well-bounded background workers than as fully autonomous operators, we said it plainly in Choosing your local model. Let loose on a vague, distant goal, a local model will produce plausible-but-wrong output, confidently, in a loop.

The answer is simple and holds in two words: bound and verify. Break it into short, clean tasks, make them idempotent jobs, keep a human who reviews the result. A background agent that does one small thing well a thousand times is infinitely better than an ambitious agent that loses its way. It’s less spectacular, and far more useful.