I "Hired" an AI Employee That Lives in My Telegram

Picture this: you're out somewhere, you pull out your phone and text someone — "process that batch of images," "add a small feature to the site," "remind me to check the numbers at 9 tomorrow." A while later, the work is done and the results land right back in your chat.

That "someone" isn't a person. It's an AI running around the clock on a Mac mini at my place. I named it Arin. This post is about how I turned an ordinary AI coding assistant into a 24/7 "AI employee" that lives in Telegram — and the potholes I hit along the way.

The big idea: AI is the brain, the chat app is just the mouth and ears

The whole architecture fits in one sentence:

Claude is the brain, Telegram is just I/O, and memory lives in files — sessions are temporary, memory is permanent.

It breaks down into three pieces:

1. An always-on computer. I use a Mac mini, set to never sleep, with the gateway running as a system service (starts on boot, auto-restarts if it crashes).
2. A message gateway. Telegram on my phone sends a message → the gateway receives it → hands it to the AI on the computer to execute → sends the results (text, images, files) back to my phone.
3. Memory that lives in files. Every project has its own memory.md, todo.md, and progress.md. The AI reads them before starting work and writes to them when done. Even if the session restarts or the whole program reboots, its knowledge of the project survives.

That third piece is the soul of the system. People assume "making an AI remember things" requires some deep technology. The humblest possible solution — have it write things down in files — works. Next time it starts work, it reads its own notes, exactly like a human employee doing a handover.

What it actually does day to day

• Casual task dispatch: I just send natural language — "draw me an image of X," "fix the bug on this page." It figures out which project the task belongs to, runs it in the background, and sends the output back.
• Multiple projects in parallel: each project has isolated memory, so nothing bleeds across. There's also an "auto-dispatch" mode — an AI acts as a router, decides which existing project a new task belongs to, and switches over automatically.
• Scheduled jobs: things like "fetch the data every day at 09:00" run on time and push results to my phone.
• Status checks: I can ask what it's working on, see the task queue, even check how much my AI usage cost this month.

The hard part: trusting it to act on its own

Letting an AI perform real operations while you're not watching — deleting files, changing code, deploying — makes trust the core problem. I ended up with four permission tiers, like driving modes on a car:

• Strict: every write operation needs my approval on the phone.
• Normal (default): only dangerous operations (deletes, deploys, system commands) come to me.
• Smart: dangerous operations first go to a second AI "judge" that evaluates them in the context of the task — if it deems them safe, they're auto-approved and I get a "🤖 auto-approved" notification; only uncertain cases come to me.
• Hands-off: fully automatic, reserved for trusted batch work.

And when it does ask, it's not a bare YES/NO. There are three options: 1 = just this once; 2 = allow this category for the rest of the session; 0 = cancel. Categories approved with "2" are remembered, so the same kind of operation stops nagging me.

One design choice improved the experience more than anything else: non-blocking approvals. When it hits a step that needs sign-off, it doesn't sit and wait — it skips the step, finishes everything else that doesn't depend on it, then tells me "2 operations are waiting for your approval." I reply "continue," and it goes back and fills in the skipped parts. The AI's time is cheap; human attention is the expensive resource. Never let the machine idle waiting for a person.

The three most expensive lessons

The concepts are easy. The tuition gets paid in the details. Here are the three that stuck with me.

Lesson one: a casual "ok" almost approved every dangerous operation

In an early version, whenever the approval queue wasn't empty, any affirmative reply from me — "ok," "sure," "sounds good" — was interpreted as "approve everything." Imagine a file-deletion operation sitting in that queue while I say "ok" in passing about something else entirely.

The fix was to tighten the trigger words hard: only explicit, unambiguous words like "continue" or "approve" release the queue; casual acknowledgments never count. The lesson: for confirmations that gate dangerous operations, make the user type two extra characters rather than doing "clever" intent guessing.

Lesson two: the logs printed my secret key in plain text

One day I was reading the logs and noticed the HTTP library was printing full request URLs at INFO level — and a Telegram bot's API URL contains the bot's secret token in plain text. Which means the key to fully controlling my bot was just lying there in a log file.

The fix was one line: raise the network library's log level to WARNING. The lesson was much bigger: any system wired to external services deserves a pass through its own logs to see what's actually being printed. Most leaks aren't breaches — they're things you printed yourself.

Lesson three: I let the AI upgrade itself, and it killed itself

Arin has a very cool trick: I can text "add feature X to Arin," and it edits its own code. But the change only takes effect after a service restart — and the restart command kills the current process, which is the very process running that task. The task dies mid-flight and the results never come back. An ouroboros.

The solution was to split the responsibilities: the AI only edits code, runs the automated tests, and reports back — the restart is always done by me, manually (or in a follow-up message, by which point it's no longer inside the original task). The lesson: in a self-modifying system, "making the change" and "activating the change" must be two separate steps — otherwise every upgrade is a suicide mission.

What I learned

• The core of an "AI employee" isn't chat. It's three things: memory + permissions + async. Memory gives it continuity, permissions let you loosen your grip, async stops it from wasting your attention.
• The humblest memory scheme — writing files — is surprisingly sufficient, and it's human-readable and editable at any time.
• Trust is designed, not wished for. Tiered permissions, revocability, and audit trails — you need all three.

These days I leave the house with just my phone; the little box at home is my second self. Honestly, after two weeks of this, going back to "you must be sitting at the computer to get anything done" is no longer an option.