From Telegram to Production: Mobile DevOps with AI Agents

Originally published at getorquesta.com/blog/from-telegram-to-production-mobile-devops-ai-agents

The Problem with Desk-Bound DevOps

Most DevOps workflows assume you're sitting at a computer. You have your terminal, your editor, your CI dashboard. But the best ideas often hit when you're away from your desk—on a walk, at lunch, or in a meeting. For years, the answer was to jot a note and handle it later. That delay kills momentum. We wanted to close that gap: capture the intent immediately, and let the agent do the work. So we built a Telegram bot for Orquesta. Send a prompt from your phone, and your local AI agent turns it into a PR. Here's how we built it, and why mobile-first DevOps is more than a gimmick.

Why Telegram?

We chose Telegram for three reasons: it's fast, it's secure (end-to-end encrypted secret chats), and it has a robust bot API. No need to download another app—most developers already have Telegram on their phone. The bot acts as a thin client: it receives your prompt, authenticates you, and forwards the request to the Orquesta API. The actual work happens on your machine where the Orquesta agent runs.

Building the Bot

The bot is built with Python and the python-telegram-bot library. The core is straightforward: define handlers for commands like /start, /prompt, and /status. Here's a minimal setup:

from telegram.ext import Application, CommandHandler

async def start(update, context):
    user_id = update.effective_user.id
    # Check if user is authenticated; if not, send auth instructions
    if not is_authenticated(user_id):
        await update.message.reply_text("Welcome! Please authenticate by linking your Orquesta account. Send /auth to get a one-time code.")
    else:
        await update.message.reply_text("You're authenticated. Send /prompt <your prompt> to start an agent task.")

async def prompt(update, context):
    user_id = update.effective_user.id
    if not is_authenticated(user_id):
        await update.message.reply_text("Please authenticate first. Send /auth")
        return
    prompt_text = ' '.join(context.args)
    if not prompt_text:
        await update.message.reply_text("Usage: /prompt <prompt>")
        return
    # Forward to Orquesta API
    response = send_to_orquesta(user_id, prompt_text)
    await update.message.reply_text(f"Task created: {response['task_id']}. Agent will start shortly.")

app = Application.builder().token("YOUR_TELEGRAM_BOT_TOKEN").build()
app.add_handler(CommandHandler("start", start))
app.add_handler(CommandHandler("prompt", prompt))
app.run_polling()

The real complexity is authentication. You don't want anyone who finds your bot to trigger deployments. We use a one-time code flow: when a user sends /auth, the bot generates a short-lived code and tells the user to enter it in their Orquesta web settings. The Orquesta backend stores a mapping between the Telegram chat_id and the authenticated Orquesta user. After that, every command from that chat is trusted. We also use Telegram's built-in user ID (which is unique per account) as part of the identity, but we always verify against our own auth service.

Here's a snippet of the auth handler:

async def auth(update, context):
    user_id = update.effective_user.id
    code = generate_one_time_code(user_id)  # stored in DB with expiry
    await update.message.reply_text(f"Your one-time code: {code}. Enter it in Orquesta Settings > Integrations > Telegram.")

Once entered, the Orquesta web app calls back to our backend which marks the chat as authenticated. All future requests from that chat are signed with the user's API token (never exposed to the chat).

From Prompt to Production

When you send /prompt fix the login bug on mobile Safari, here's what happens:

1. The bot forwards the prompt to the Orquesta API as a new task.
2. Orquesta creates a task in the Agent Grid and assigns it to your local agent (if online). If your agent is offline, the task waits until it comes online—you'll get a Telegram message when it starts.
3. The agent runs on your machine using Claude CLI (or any configured LLM). It streams output in real-time. You can watch it in the Agent Grid from your phone's browser, but you don't have to.
4. The agent makes code changes, runs tests, and creates a git commit. If you've enabled quality gates, it can simulate the changes and wait for your approval before pushing to the remote.
5. Once done, the bot sends you a summary in Telegram with a link to the PR.

The key point: the agent is not running on Telegram's servers or in our cloud. It's running on your infrastructure. The phone is just the remote control.

The Mobile DevOps Experience

Mobile-first DevOps isn't about doing everything from your phone; it's about eliminating the "I'll do it later" tax. Let me give a real example. A few weeks ago, I was at a coffee shop without my laptop. I got a Slack alert that a production API was returning intermittent 500s. I opened Telegram, typed /prompt investigate the 500s on /api/orders, likely a race condition in the inventory service, and hit send. The agent on my home office machine picked it up, ran diagnostics, added a mutex, and opened a PR. I reviewed the diff on my phone, approved it, and the agent deployed to staging. By the time I finished my coffee, the fix was live.

That's the power: you're not writing code from a phone keyboard. You're directing an agent that already has full context. Telegram becomes a command line for your AI workforce.

Beyond triggering, you can also receive real-time updates: when an agent starts, when it finishes, when a PR is opened. We use Telegram's inline keyboards to provide quick actions like "Approve" or "Open PR".

Technical Challenges

Building this wasn't trivial. The main issues were:

• Statelessness: Telegram bots don't maintain state between messages. We had to handle multi-step commands (like auth) using a conversation state machine or by storing temporary data with a short TTL.
• Async execution: Agent tasks can take minutes. The bot can't block. We use webhooks and background workers to process commands asynchronously. The /status command returns a link to the live Agent Grid view.
• Security: We enforce rate limiting per user, validate all input, and never send sensitive logs (like API keys) back to Telegram. All agent output is logged in Orquesta, not in the chat.

Why This Matters

The barrier to fixing something shouldn't be your physical location. With AI agents, the bottleneck shifts from "I need to be at my desk" to "I need to know what to ask." Telegram is just one interface; we also have an embeddable widget and a web dashboard. But the mobile aspect is crucial because it aligns with how developers think: in bursts of intent, often away from the keyboard.

The future of DevOps is not typing commands; it's expressing intent. The agent does the mechanical work. Telegram is a natural front-end for that because it's already in your pocket.

Takeaway

Mobile-first DevOps with AI agents is not about replacing your workstation; it's about decoupling intention from execution. The Telegram bot we built for Orquesta is a thin but powerful layer that turns a chat message into a production change. The heavy lifting is done by the agent on your infrastructure, with full audit trail and quality gates. If you're still waiting until you get back to your desk to fix that bug, you're already behind.