The right way to set up AI agents
For the past few years, the way most of us have used AI is simple: open a chat window, ask a question, get an answer. That’s chatbots. It’s a great starting point, and it’s genuinely useful.
But it’s just the starting point.
Agents are the next step. Instead of a general AI you chat with, you build specialized assistants that have a specific job, deep context in that area, and the ability to do work without you being in the loop.
Specialization and memory are what make agents different
My dad used to say that to make real money you have to figure out how to make money while you sleep. Same idea applies to productivity. If you want to get significantly more done, figure out how to get work done while you sleep.
That’s what agents let you do.
An agent doesn’t just answer questions. It maintains context over time, has access to your actual tools, and can act on your behalf. An agent built to help you write knows your voice, your published work, your content calendar. An agent built to manage your calendar and communications knows your priorities and how you like to operate. You don’t explain yourself every time you open a chat window. The agent already knows.
Because they run continuously - not just when you’re talking to them - they can do work overnight. You hand something off before bed and it’s done in the morning. That’s closer to having someone on your team.
Why the platform you run them on matters
When I started experimenting with agents, I tried OpenClaw first. Getting it connected to WhatsApp was the moment it clicked for me - texting a specialized agent from my phone like you’d text a person. That’s the experience you’re building toward.
But OpenClaw had real problems. It kept breaking. There’s an active CVE against it. When I went looking for community-built skills to extend it, I found a researcher’s report documenting 341 malicious packages on ClaHUB designed to steal your data. No audit process, and your data flowing through infrastructure you don’t control.
A friend, Andrew Draper, mentioned he’d switched to Nanoclaw. The security model was better - each agent runs in its own Docker container. But Nanoclaw uses the Claude SDK rather than Claude Code natively, which means you lose MCP servers and the native tool integrations that make Claude Code powerful. You’re working around limitations from the start.
What you actually want is a setup that gives you the full capability of Claude Code: native MCP servers that connect your agents to your real tools - Gmail, Calendar, Slack - without routing your data through a third party.
How to set this up
Dave North pointed me toward running multiple tmux sessions to keep persistent Claude contexts alive. That was the starting point for what I built.
The full setup: a remote Linux server with Claude Code installed, each agent running in its own tmux session. Claude Code’s remote-control feature connects those sessions to the official Claude desktop and mobile apps. Each agent appears as a separate conversation you can message from your laptop or your phone - through Anthropic’s own apps, not a third-party platform.
Your agents run around the clock. They maintain context between sessions. They have full access to your tools via MCP. And you can reach them from anywhere.
I put the complete setup in a public GitHub repo: github.com/mikeypotter/remote-claude-template. Get a remote server, install Claude Code, follow the README. The only requirement is a Claude subscription that includes Claude Code.
Chatbots were a good first step. This is what comes next.