Building a Multi Agent Workflow Telegram to Slack Relay With a Cloud Android Phone

Wiring a multi agent workflow telegram to slack pipeline lets an on-call engineer or operations lead send a short command in Telegram, delegate a live mobile app inspection to an isolated cloud Android phone, and publish a structured status card into a team Slack channel. Most tutorials that connect Telegram to Slack stop at a trivial text forwarder: a webhook receives a string in one chat app and reposts the exact same string in another. Real operational workflows are rarely that simple. When a growth, logistics, or marketplace ops team needs to verify regional in-app promo pricing, check live delivery or rideshare wait times, or inspect a smart-facility controller that only ships as an Android or iOS binary, standard HTTP webhook glue hits a brick wall.

To bridge that gap without maintaining brittle reverse-engineered mobile scrapers, you can equip your orchestrator agent with Airtap, which provides a real Android phone inside an isolated cloud container (or connects to a spare physical Android phone via Autopilot) that developer agents can drive through a lightweight skill file. Your ingress bot handles the Telegram command, your orchestrator delegates the screen-level mobile task to the Android runtime, and your egress worker formats the structured output into Slack Block Kit.

This tutorial walks through the four-node relay architecture, webhook deduplication and security headers, delegating mobile UI checks via the skill specification, formatting Slack Block Kit cards, and handling session expiration or human-in-the-loop escalations. API details below are verified against official Telegram Bot API and Slack Developer documentation as of October 2026.

Why a multi agent workflow telegram to slack relay needs a real Android runtime

In a typical operations setup, Telegram serves as the fast, mobile-first command trigger for founders or on-call responders who are away from their desks, while Slack serves as the persistent system of record where the wider engineering or operations team tracks incident timelines and price audits. A multi agent workflow telegram to slack architecture becomes much more useful when the middle of the pipeline can inspect software that has no public web API.

Consider three everyday ops checks that fail inside a standard headless browser worker:

• Verifying app-only retail and delivery pricing. Regional delivery apps, pharmacy loyalty wallets, and travel platforms frequently display different prices or promo banners inside their native mobile apps than on their public websites.
• Checking live local supply and wait times. Mobility, courier, and booking apps lock real-time ETA maps behind mutual TLS (mTLS) and Google Play Integrity attestation, blocking raw Python requests or headless Chromium scripts.
• Inspecting mobile-bound hardware and IoT controls. Many smart thermostats, access locks, and building sensors only expose their status dashboards inside a companion Android app.

Splitting the relay into four single-responsibility nodes keeps your codebase modular:

1. Node 1 (Telegram Ingress Webhook): Validates the incoming operator command, checks the sender allowlist, deduplicates the update_id, and returns HTTP 200 OK in under 500 milliseconds.
2. Node 2 (Orchestrator Agent): Parses the user's intent, loads the mobile execution skill, and dispatches a bounded, read-only mobile inspection task with a strict JSON return schema.
3. Node 3 (Cloud Android Runtime): Opens the genuine Android application inside an isolated container, reads the live screen and accessibility tree, and extracts the requested metrics.
4. Node 4 (Slack Block Kit Egress): Converts the structured JSON telemetry into an actionable Slack card posted to #ops-mobile-checks.

Step 1: Verify and deduplicate incoming Telegram Bot webhook commands

The biggest operational trap when connecting a chat webhook to a real UI agent is webhook timeout retry storms. Under the official Telegram Bot API setWebhook specification, Telegram expects your HTTPS endpoint to acknowledge incoming Update payloads promptly, and it will re-deliver the same update_id if your server hangs for 45 seconds waiting for an Android app to launch and render.

Always verify the X-Telegram-Bot-Api-Secret-Token header, check update_id against a short-lived cache or Redis set, acknowledge the request immediately, and push the agent job to an asynchronous background worker:

import express from "express";

const seenUpdates = new Set<number>();
const ALLOWED_USER_IDS = new Set([10492819, 29481022]);
const app = express();
app.use(express.json());

app.post("/webhooks/telegram", (req, res) => {
  const secret = req.header("X-Telegram-Bot-Api-Secret-Token");
  if (secret !== process.env.TELEGRAM_WEBHOOK_SECRET) {
    return res.status(401).json({ error: "unauthorized" });
  }

  const update = req.body;
  if (!update?.update_id || seenUpdates.has(update.update_id)) {
    return res.status(200).json({ ok: true, deduped: true });
  }
  seenUpdates.add(update.update_id);

  const msg = update.message;
  if (!msg?.text || !ALLOWED_USER_IDS.has(msg.from?.id)) {
    return res.status(200).json({ ok: true, ignored: true });
  }

  res.status(200).json({ ok: true, queued: true });
  void runMultiAgentRelay(msg.chat.id, msg.from.username, msg.text);
});

By returning 200 OK before calling runMultiAgentRelay, your pipeline guarantees that a 40-second mobile screen check will never trigger three duplicate runs.

Step 2: Equip your orchestrator agent with the cloud Android skill

Instead of writing custom Appium scripts or brittle coordinate macros for every mobile app you want to inspect, your orchestrator agent (such as Claude Code, Codex, OpenClaw, or a custom agent loop) can load Airtap's public skill definition directly.

On your agent runner host, fetch the skill specification so your orchestrator knows how to dispatch tasks to your cloud Android phone (or to a spare physical Android phone connected via Autopilot):

curl -sL https://airtap.ai/skill.md

When the orchestrator delegates a task to the mobile execution layer, instruct it to enforce two rules: keep the operation strictly read-only unless a human explicitly confirms a state change, and return a deterministic JSON object so your downstream Slack formatter never has to regex-parse conversational prose.

Here is an example task prompt template that the orchestrator passes to the mobile worker when an operator sends /check_ride SFO_Terminal_G in Telegram:

{
  "task_type": "mobile_ui_inspection",
  "read_only": true,
  "instruction": "Open Uber and Lyft on the signed-in Android phone. Check live pickup ETAs and standard fares from 500 Howard St, San Francisco to SFO International Terminal G. Do not tap Book or confirm any ride.",
  "response_schema": {
    "status": "OK | NEEDS_TAKE_CONTROL | ERROR",
    "app_checked": "Uber & Lyft",
    "uber_quote": "$42.50 (4 min ETA)",
    "lyft_quote": "$46.10 (6 min ETA)",
    "requires_human_action": false,
    "take_control_reason": null
  }
}

Because the cloud Android phone runs inside its own isolated container with the real apps installed, the agent reads the live screen state naturally without triggering API gateway blocks.

Step 3: Post structured results or escalation alerts to Slack Block Kit

Once the mobile worker returns its structured JSON payload, the final node in your multi agent workflow telegram to slack pipeline formats the result for your team channel. According to the Slack Incoming Webhooks documentation, every webhook POST should include both a top-level text string (used for mobile push notifications and screen readers) and a rich blocks array built with the Slack Block Kit framework.

async function postToSlack(operator: string, command: string, result: any) {
  const statusEmoji = result.status === "OK" ? "🟢" : "🟠";
  const payload = {
    text: `[${result.status}] Mobile check completed for ${command}`,
    blocks: [
      {
        type: "header",
        text: {
          type: "plain_text",
          text: `${statusEmoji} Mobile App Check: ${result.app_checked}`
        }
      },
      {
        type: "section",
        fields: [
          { type: "mrkdwn", text: `*Triggered By:*\n@${operator} (via Telegram)` },
          { type: "mrkdwn", text: `*Status:*\n\`${result.status}\`` },
          { type: "mrkdwn", text: `*Primary Quote:*\n${result.uber_quote || "N/A"}` },
          { type: "mrkdwn", text: `*Secondary Quote:*\n${result.lyft_quote || "N/A"}` }
        ]
      },
      {
        type: "context",
        elements: [
          {
            type: "mrkdwn",
            text: `Command: \`${command}\` · Executed on isolated Android container`
          }
        ]
      }
    ]
  };

  await fetch(process.env.SLACK_WEBHOOK_URL!, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload)
  });
}

When result.status is OK, the team channel gets a clean four-field summary card within seconds of the mobile check finishing.

Handling mobile session expirations, retries, and Take Control handoffs

Real mobile apps occasionally throw curveballs that headless scripts cannot solve on their own: a 30-day login token expires, a two-factor verification prompt appears, or an operator asks the agent to prepare a booking that requires payment confirmation.

Under Airtap's security model, password fields are cryptographically blocked from agent reading, and your credentials are never stored by or visible to the AI. Instead of pasting passwords into Telegram or Slack env vars, your relay should route authentication and payment gates through a Take Control handoff, where the operator taps a link to interact with the cloud phone screen directly, completes sign-in, and lets the agent resume.

Here is how to map each failure mode across your multi agent workflow telegram to slack pipeline:

Failure or Escalation Scenario	What Happens on the Android Runtime	Orchestrator Retry Policy	Slack & Telegram Notification Behavior
Telegram Webhook Timeout (>10s)	Task continues running normally on the Android phone	Deduplicate by update_id; do not spawn a second Android task	ACK 200 OK immediately on ingress before starting the agent loop
App Session Expired / Login Prompt	Agent detects sign-in screen; password fields are blocked from reading	0 automated retries; pause task and emit NEEDS_TAKE_CONTROL	Post orange alert card in Slack and reply in Telegram with Take Control handoff notice
2FA Code or Passkey Challenge	Security prompt blocks navigation to target screen	Pause execution for up to 10 minutes awaiting human input	Notify triggering operator in Telegram to enter the 2FA code directly via Take Control
Checkout / Payment Confirmation Gate	Agent reaches final review screen with price and terms	Never auto-submit payment; hold state for explicit human confirmation	Send quote summary to Slack and Telegram; require operator approval before confirming
Transient App Modal or Promo Popup	Promo banner overlays the main navigation bar	Up to 1 screen-level dismissal retry by the UI agent	Log dismissal in context block; only alert Slack if screen remains blocked after retry

Production checklist before deploying your relay

Before moving your Telegram-to-Android-to-Slack relay from a local test script to an always-on team bot, verify four operational guardrails:

1. Lock down your Telegram sender allowlist. A Telegram bot username is publicly discoverable. Checking X-Telegram-Bot-Api-Secret-Token only proves the request came from Telegram's servers, not that the sender is on your team. Always filter against an explicit allowlist of numeric Telegram from.id values.
2. Choose the right Android device target for the job. For 90% of team checks, Airtap's cloud Android phone (which sets up in about 60 seconds inside an isolated per-user container) is the cleanest choice because it supports live screen view in the web dashboard and wipes sessions cleanly on logout. If a task requires an app bound to a local office Wi-Fi network or physical SIM card, connect a spare Android phone via Autopilot (noting that live screen streaming in the web dashboard is currently supported only for the cloud phone).
3. Keep routine checks read-only by default. Separate inspection commands (like /check_price or /check_eta) from action commands so no automated schedule or fat-fingered chat message can accidentally complete a purchase without a human confirmation step.
4. Mind your daily usage rhythm. Airtap is free to start, with a daily soft usage cap, making it straightforward to prototype your multi-agent relay and run recurring team checks without provisioning custom emulator clusters.