Agent setups for people and businesses

An assistant in a browser tab forgets you when you close it. It cannot be reached from your phone at the weekend, it has no idea what was agreed last month, and it certainly is not going to do anything at three in the morning. That is the difference between a chat window and an agent.

The gap is not the model. Good models are available to everybody at roughly the same price. The gap is everything around the model: where it runs, what it remembers, what it is allowed to touch, and who fixes it when it stops.

What we usually choose

The agents we set up run on platforms with full time teams behind them, moving faster than any studio could match. Picking one and running it well is worth more to a client than a private version that stops improving the day we stop touching it. Today that means two: Hermes Agent and Claude.

Hermes Agent, from Nous Research, is the default for an assistant that lives on the client’s own hardware. It runs as a long lived process rather than a session, keeps memory across conversations, and writes its own skills as it goes, refining them with use. One gateway process reaches Telegram, Discord, Slack, WhatsApp, Signal, and a terminal, so a person talks to the same agent from wherever they happen to be. It carries a scheduler, so unattended work like a nightly report or a weekly audit is ordinary rather than a separate system. It is not tied to one model provider either, which means a change of supplier is a change of setting.

Claude, from Anthropic, is the choice where the work lives in a codebase or in a team’s documents. We set up Claude Code with the instructions, skills, and checks a repository needs, Claude itself for a team’s everyday work, and custom agents on Claude’s API where a job needs one of its own.

What the setup actually involves

The platform is an afternoon. The work is everything that makes it survive.

• It runs on the client’s own machine or their own server, where that matters, rather than on ours.
• Reaching it from outside goes through a tunnel rather than an open port, so nothing is sitting on the public internet waiting to be scanned.
• Instructions and knowledge come from the client’s real material, not from a generic prompt.
• Guardrails are written down: what it may touch, what it asks about first, and what it leaves alone.
• Configuration is kept as files with backups and a known good copy, and the recovery procedure is one command.
• The unit file, the config path, the logs, the restart, and the rollback are recorded in one place, so somebody who has never seen the machine can restore service from the notes.

The running cost

An agent is a process that needs somewhere to run and someone to maintain it. The hosting is small, often a few pounds a month, and the model usage is metered, so a busy agent has a real running cost that grows with use.

The larger cost is attention. An agent with write access to a calendar, an inbox, or a set of books needs the same care as any other automation that can change records: a preview before it acts, a clear boundary on what it may touch, and a way to undo a bad run. We write those in at setup rather than after the first incident.

The failure mode to plan for is not a crash. A crashed agent is obvious and someone notices within the hour. The dangerous one is an agent that keeps running while quietly doing the wrong thing, which is why the guardrails and the written record are where the time goes.