An AI Agent That Fixes Itself From Your Phone

GitHub repo: iam-Akshat/self-patch-bot.

I wanted an AI assistant I could keep building from my phone. Not just use but extend and fix while lying on the couch. No laptop.

The problem with most AI setups is they’re static. You deploy them and if you want to change anything you’re back at your desk. I wanted something I could have a conversation with and say “hey add this feature” and it would just do it.

So I built that.

Why pi

pi’s RPC mode was perfect for this. Each Telegram chat gets its own pi subprocess, so the mental model stays really simple: one chat, one agent, one session dir. I just send prompts in as JSON over stdin and read events back over stdout. That means I do not have to build my own agent loop or session store, and I can still hang custom tools off it through extensions.

The nice part is that pi already gives you the right shape for this kind of thing. It feels a bit like wiring a small process together instead of building a whole framework around it.

The architecture

Five files, just over a thousand lines total.

src/bot.ts          — grammy handlers, voice transcription, startup
src/chat-session.ts — per-chat streaming state, Telegram edit throttling
src/pi-session.ts   — spawns and talks to the pi subprocess
extensions/ask-user.ts    — inline keyboard tool for the agent
extensions/patch-self.ts  — the self-patch tool

When a message comes in grammy routes it to a ChatSession. That session owns a PiSession which is just a thin wrapper around the pi subprocess. Prompts go in over stdin, events come back over stdout, and the bot streams the response back to Telegram by editing a placeholder message every 750ms to stay under rate limits. Voice messages get transcribed via the Gemini Files API before hitting pi. Session history lives on a Fly volume so it survives restarts.

The main thing I wanted was no hidden magic. bot.ts handles Telegram events, chat-session.ts handles streaming and message updates, and pi-session.ts only knows how to spawn and talk to pi. That separation makes the whole thing easier to reason about when you are changing it from your phone.

What it can do

Right now I mainly use it as a personal finance bot for myself, but the nice part is that the setup stays small enough that I can steal ideas from other agents and drop them in without dragging a bunch of bloat along with it.

If I want a new tool or workflow, I can usually wire it up pretty fast and keep the whole thing lean. That is the whole vibe here. Build just enough, keep it useful, and keep it easy to improve later.

The self-patch tool

This is the whole point. When the agent edits a source file it calls restart_bot with a short summary of what changed. The extension writes that summary to /data/restart-context.json then sends SIGUSR1 to the bot process.

process.once("SIGUSR1", () => {
  shutdown();
  process.exit(1); // non-zero → Fly auto-restarts
});

Fly sees a non-zero exit and restarts the machine. On the next boot the bot reads the summary file, deletes it so it doesn’t fire again, and feeds it back to the agent as a system message. The agent then sends the user a confirmation. Edit, restart, confirmation — about 10 seconds end to end.

The intuition is pretty straightforward: the agent does not need direct access to the Telegram bot runtime. It only needs a small bridge into the host process. That bridge is the restart tool, and it is enough to let the agent patch itself safely without turning the whole app into a giant mess.

The agent knows its own file structure, where things live, and how the restart cycle works. So you genuinely just tell it what you want and it handles the rest.

Does it work

Yeah. I’ve shipped features to this bot from my phone while it was running. That felt genuinely weird in a good way.

Is it production ready — no. Is it the most fun I’ve had building something in a while — yes. The foundation is solid enough to keep building on and that was the whole point.