Skip to main content
All Posts
AI AgentsBuild in PublicHermesAutomation

How a Client Set Up Her Own AI Agent From One Link

One version of this onboarding had the client text me her server password and wait. That was the wrong product. Here's the design I replaced it with: four steps, a browser terminal, and a setup skill that installs the agent's memory.

Joe BlasSeptember 19, 20269 min read

A client I'll call V has her own AI agent. It runs 24/7 on a server she owns, and she texts it from Telegram like a friend who never sleeps. She has never opened a terminal app or an SSH client. The command builder in her guide means her bot token goes straight into her own server, and the guide no longer asks her to text me a password or a token. She set the whole thing up herself from one link — which is the part that took me three tries to get right.

$90

Her cost for the year

21 min

Her side of setup, as designed

4

Steps she does

The Versions I Got Wrong First

My first attempt was a DIY doc: pick a VPS, paste an install command, choose a model, start the gateway. Fine if you're me. Not a product for someone who has never seen a terminal prompt.

So I wrote a second version — the concierge one. She'd buy the server, create a Telegram bot, and then text me four things: server IP, root password, bot token, user ID. I'd SSH in, wire it up, and text her back when it was live. That felt helpful. It was actually the worst of both worlds: she still had to gather credentials she didn't understand, send them over chat, and then wait on me. I'd made myself a required dependency and called it service.

The question that killed that version was my own, reading it back: why do I still have to do step three — is this not a plug-and-play setup? If any step needs me to manually touch a client's server, that's a step to design away, not a step to perform faster.

The rule I took from it: if the handoff requires the client to send me a secret, the handoff is the product defect. Not the client, not the tooling — the handoff.

What She Actually Does

This is the version that went out in July, and everything on her side happens in a browser and Telegram — two apps she already had open. What she works from is a single-page guide I build and host for each client: their own checkout link, their own copy-paste blocks, nothing generic. It isn't a public page — it's the deliverable, and building it is the entire remaining job. After I send it, I'm out of the flow.

Step 1 — buy the server (~10 min)
She opens a pre-configured Hostinger checkout link from her guide. The cart already has the Hermes agent template set to auto-deploy via Docker, a 12-month KVM 1 plan, and the “Ready to use AI” credit bundle pre-checked so there's no separate AI account to create. She picks the server location closest to her and pays.
Step 2 — make the bot (~5 min)
In Telegram she messages @BotFather, sends /newbot, names it, and gets a bot token back. Then @userinfobot gives her a numeric user ID.
Step 3 — paste one command (~3 min)
The guide has a small command builder: she types the bot token and user ID into two fields, and the page generates a curl command with those values as environment variables. She opens Hostinger's web terminal — a terminal inside a browser tab, no SSH client — and pastes it. The installer is built to finish in two or three minutes and print SETUP COMPLETE. Her own run, on August 4, predates a fix I made to it on August 8 — more on that below.
Step 4 — give it a memory (~3 min)
The agent is alive but blank. The guide's last step has her paste one prompt into Telegram telling the agent to fetch its setup skill and run it. The skill has the agent install its own memory system, write its own identity file, and restart its own gateway.
Step 3 is the whole trick, and the detail that makes it work is that the command builder is plain client-side JavaScript — it reads the two fields, checks their shape, and pastes them into a string. The builder makes no network call at all: the token she types into it goes nowhere but her own server — not through a chat log, an inbox, or anything of mine.

The Unlock: A Terminal Inside a Browser Tab

Every version of this that required a real SSH client died on contact with a real person. Installing PuTTY or opening Terminal.app, managing keys, remembering an IP — each one is a place where a non-technical client stops and texts you instead. Hostinger's dashboard has a “Web terminal” button that opens a shell in the browser, already authenticated. That single button is the difference between a guide someone finishes and a guide someone abandons. Design the onboarding around it, not around SSH.

How the Memory Layer Works

The memory layer the setup is designed to install is MemPalace, and it uses an actual spatial metaphor — the people and projects the agent hears about become wings, topics inside them become rooms, and each verbatim thing it's told lands in a drawer. Nothing is summarized on the way in, and it is designed to run on the same server as the agent, with no API key.

One dated caveat. Her first run, on August 4, used an installer with a bug that stopped the script at the memory step; I fixed it on August 8. I haven't confirmed that the fixed installer has been re-run on her server, so I can't tell you her agent's memory works — only how it's built to. Here's the shape of it:

loading memory map…

What I Did Anyway

Here's the honest footnote to all that self-service engineering: for her first run, I got on FaceTime and stayed on the call anyway. It was my first time doing this whole handoff fully remote, and it was genuinely fun watching it come together with her on the line.

It took a couple of hours — longer than the tidy version of this story would suggest — because after her command finished I got into the server through the Hostinger panel and checked it over before telling her it was live.

Let me be exact about that, because it's the part that could read as a contradiction. What the command builder guarantees is narrow and specific: the bot token she types into it never passes through a chat or an inbox of mine on its way to her server. Her guide no longer asks her to text me her server password or bot token either (it did, until October 2026), but that does not mean nobody ever had administrative access to that box — on the first run, I did, through the panel, with her sitting on the call. A claim like “zero credentials” is only worth making if you're willing to say exactly where its edges are.

A script printing SETUP COMPLETE is not the same as an agent that works. Before I tell anyone their assistant is live, I check that the bot actually answers and that the gateway is still up a few minutes later. I'd rather be slow than have someone's first message land in a bot that isn't really listening.

What It Actually Costs

It all comes through one checkout: about $84 for twelve months of the KVM 1 plan, $5.99 for the starter AI credits, and a domain thrown in free for the first year — roughly $90 for a full year of an always-on assistant.

When those starter credits run out, the upgrade path is Ollama Cloud at $20/month. I want to be precise about that because I've seen it described as free, including once in my own notes. There is a free tier, but it has very limited usage, and $20/month is the number to plan around.

That's her infrastructure bill, not my invoice. What I charge to build and support one of these is a separate conversation, quoted per project.

The Pitfalls That Actually Bite

Most of what I know about this process is a list of things that went wrong once. The ones worth passing on:

  • Enable systemd linger before starting the gateway. Without it, a user service dies the moment the session disconnects — so the agent works perfectly during setup and goes silent afterward.
  • Have them message the bot before it's wired up. Telegram requires at least one message from a user before a bot may message them. Skip it and the agent's first reply fails silently, which looks exactly like a broken install.
  • A Telegram user ID is not a phone number or a username. It's a numeric ID from @userinfobot. Expect to redirect people here at least once.
  • Never set a default-drop firewall policy on a remote VPS unless the rule allowing your own SSH access has already landed. Locking yourself out of a client's server is a memorable way to learn this.
  • Run the agent as its own user, not root. The install handles it; the temptation to skip it on “just a small VPS” is how small VPSes become incidents.
  • Yes, it's a piped install command — and that's the point. Normally “paste this into your terminal” is how people get burned. It works here because the script is served over HTTPS from a domain I control and wrote, and because the alternative was worse: the only way to avoid the paste was to have her send me her credentials instead. One of those two risks travels through a chat log. The other doesn't.

The thing I keep relearning: the engineering that makes this feel simple is almost entirely about removing myself from it. If you want one of these for your own team — an agent on a server you own, memory that stays yours, and a setup someone non-technical can actually finish — that's what I set up as an agent of your own.

Joe cleaning his hot tub in San Diego while his AI agents handle business operations

Joe's Tech Solutions — AI strategy and deployment for businesses ready to move.

About the Author

Joe Blas

Generative AI Full-Stack Developer based in San Diego and founder of Joe's Tech Solutions LLC. He builds AI-powered applications and private AI systems for businesses that want to own their intelligence stack — not rent it.

An agent of your own

Want One of These for Your Team?

This is the pipeline I used for a client — an agent on a server you control, memory that stays yours, and a handoff simple enough for someone who's never opened a terminal.