Pi Workspaces Turn Telegram Into a Gateway for Always-On AI Agents
Alejandro’s tutorial shows how to run specialized Pi assistants on an always-on machine and reach them through Telegram using his open-source `pi-gateway`. Each assistant runs from its own workspace, with its own instructions, tools and model; the gateway uses a local SQLite database to route messages to persistent Pi sessions. The demonstration covers a personal assistant and a research agent, while scheduled automations and support for other messaging platforms remain proposed extensions.
An always-on agent is a workspace you can reach by message
Alejandro AO pairs Pi with a Telegram gateway. The aim is to make specialized assistants available from a phone while running on an always-on machine the user controls. That machine can be a VPS, a desktop left on at home, or a DGX Spark; the demonstration uses a VPS. Models can be chosen separately for each assistant, including models accessed through OpenRouter.
The key design choice is that each agent is a directory, not just a bot name or a model preset. In the example, pa-assistant and researcher sit under an agents directory. Each can have its own AGENTS.md instructions, tools, and skills. Pi runs the agent in that directory, so the workspace supplies the context and capabilities the agent uses.
The personal assistant’s instructions define it as a Google Workspace helper and set operating constraints. The visible AGENTS.md tells it to check whether the gws command-line tool is available and authenticated, and to consult command-specific help rather than guessing syntax. It says to prefer read-only lookups for email, calendar, contacts, and Drive; include time zones when showing dates; and ask for explicit confirmation before sending email or changing events or files. It also cautions the assistant not to claim an action succeeded without a successful tool result.
In a test through Tau, Alejandro asks for recent unread emails. The assistant returns a short list of ten recent unread messages, gives dates in UTC, and says it has not marked anything as read. The exchange shows how the workspace instructions and Google Workspace tools inform a practical request.
Alejandro describes the structure as a way to build agents for different jobs: give each one the capabilities it needs, then define its role and operating rules in its own context. His personal assistant has Google Workspace access and web-research skills; his separate research agent has research-oriented tools and a different system prompt. These are examples rather than a fixed set of built-in roles.
Skills add capabilities, but they depend on the right tools
The personal assistant’s workspace includes skills for searching and reading the web, including Firecrawl search, scrape, and parse. Alejandro also installs Google Workspace CLI skills into the project so they are available to that specific agent. He selects capabilities for calendar and agenda access, Drive, and email. The setup screen shows a larger catalogue of skills, and a subsequent screen displays security-risk assessments for several installed Google Workspace skills.
The skills are not a substitute for the underlying tool: Alejandro says the Google Workspace CLI must also be installed for the related skills to work. Installation and authentication are separate prerequisites, and he does not walk through setting up or authenticating the CLI here. Without those steps, the assistant cannot use the Google Workspace capabilities shown.
He uses Tau for the terminal demonstration and describes it as a Python port of Pi that he uses for coding. He also notes that the agent can be opened in Pi. When the project folder is opened, the harness asks whether to trust it, explaining that trust allows it to load settings and resources, install missing project packages, and execute extensions. The prompt makes clear that a project setup can include executable resources as well as written instructions.
Alejandro’s diagram sketches other possible workspaces—for research, social work, and general use—but these are examples, not agents demonstrated in the tutorial. The practical distinction is that the files and installed skills in a workspace determine what Pi has available when it runs that agent.
The gateway keeps chat sessions attached to the right workspace
A gateway makes agents reachable without opening an SSH session or manually connecting to Pi each time. Alejandro’s gateway runs as a background process on the always-on machine and listens for messages from a platform. The version he demonstrates supports Telegram. He mentions WhatsApp, email, and Slack as possible platforms, but says adding them would be future work.
The routing model connects Telegram to a gateway, Pi sessions, and a local SQLite database on the host. When a Telegram message arrives, the gateway associates it with an agent and a Pi session. Alejandro illustrates the identifier as tele:pa-agent:uuid: it encodes the message source, the agent name, and the session ID. That mapping is stored in SQLite. If no matching session exists, the gateway creates one; subsequent messages for that conversation route to the corresponding Pi session in the agent’s directory. Since Pi runs in that directory, the session uses the instructions, tools, and skills configured for that agent.
A /new command starts a fresh session and creates a separate entry, leaving the existing conversation’s routing distinct. The Telegram bot also exposes commands to list and switch sessions, set a model, abort an execution, clear Pi or its conversation history, and resume a response. These controls provide ways to manage the conversation from Telegram rather than returning to the host machine.
Alejandro says Hermes Agent and OpenClaw helped inspire the gateway pattern. He sees their appeal not only in integrations, but in being able to reach an assistant through familiar messaging platforms. In his words:
They are sort of your personal assistant that you can talk to from any platform that you would usually use to talk to your actual human assistants.
His pi-gateway project applies that idea to Pi with a background process, Telegram connectivity, and persistent sessions. He describes his implementation as minimalist and says it took him 34 commits to reach the version shown.
Setup binds a Telegram bot to an agent and restricts who can use it
The installation requires SSH access to the always-on machine. Alejandro installs pi-gateway with uv tool install pi-gateway, then runs pi-gateway init from the personal assistant’s directory. The initializer asks for a Telegram bot token, the Pi working directory, a model, a thinking level, and an instance name.
To get a token, he creates a bot through Telegram’s BotFather using /newbot, chooses a display name and a unique username ending in bot, then pastes the token into the setup prompt. The token gives the gateway the credentials it needs to connect to that bot. He also configures the gateway to accept messages only from his Telegram user ID. In the demonstration he retrieves that ID from a Telegram user-info bot. This allowlist is the access-control step: it determines which Telegram user is permitted to contact the assistant.
For the personal assistant, he keeps the default directory pointing to pa-assistant, preserving the instructions and Google Workspace configuration already in that workspace. He chooses openrouter/stealth/space-bunny-alpha as the model and names the gateway instance bunny. After setup, he starts the instance and checks that it is running. The gateway provides status and instance commands for confirming what is active.
Once the Telegram bot is started, Alejandro asks what it can do. The reply identifies it as a personal assistant running through Pi and describes its Google Workspace abilities: Gmail triage and summaries, drafting, sending, and forwarding messages, calendar agenda and event operations, Drive file lookup and upload, and contact lookup. The workspace instructions also specify confirmation before consequential changes.
Separate bots can use different workspaces and models
Alejandro sets up a second bot for research in the researcher directory. He gives it a distinct Telegram username and instance name, restricts access to his user ID, and chooses openrouter/moonshotai/kimi-k3 rather than the personal assistant’s Space Bunny model. He says the research agent has Firecrawl and can receive additional plugins and tools later.
The first attempt to message the new bot produces no working reply because the gateway instance has not been started. After starting it, he resends the question; the gateway connects and Pi begins processing. Initialization configures an instance, but the instance must also be running before the bot can handle messages.
The two bots therefore differ in both the workspace Pi uses and the model selected for the gateway instance. Alejandro describes each agent as having its own “computer”—a workspace where it can create and write files or conduct research. The personal assistant’s email lookup and the research bot’s startup show those separate configurations being connected to Telegram.
Automations and other platforms remain proposed extensions
The current demonstration connects Telegram to persistent Pi sessions; it does not include scheduled automations or other messaging platforms. Alejandro says he would like to add routines such as having the personal assistant review and summarize email each morning, and similar routines for research.
He also suggests adding tools through MCP or custom Pi tools, and adapting the gateway to platforms such as WhatsApp. That would require working out how the platform connects to the gateway; he points to Hermes and OpenClaw as open-source projects that could offer inspiration. These are extensions to explore, not features he demonstrates. The working setup shown is Telegram routing messages to specialized Pi workspaces through pi-gateway and a local SQLite database.