Approve, Pause, Override: Running Your AI Workforce From Your Phone

Why Telegram MTProto, Not Just A Webhook

A Telegram Bot API webhook is fine for chat-style updates. It is not fine for command-and-control, because the bot cannot interrupt a person's screen and the message has no native ack semantics. We use MTProto for the approval channel because it gives us inline keyboards bound directly to the pausedExecutions row id, delivery receipts that survive the operator's plane mode, and end-to-end transport that does not route through a third-party push service.

The interaction shape is exactly:

• The operator's phone buzzes. The lock screen shows "Refund $1,247.00 — approve?" with two inline buttons.
• They tap approve. The bot posts a callback that hits our /api/webhooks/telegram route, looks up the row, validates the operator is a member of the workspace, and writes the resume payload.
• The paused workflow gets dequeued by the BullMQ worker and continues from the exact block it stopped on.

Median time from agent pause to workflow resume in this path: under thirty seconds. The previous-generation experience — operator notices the email, opens laptop, signs in, finds the run, clicks approve — was eight to forty-five minutes when it worked at all.

Realtime Is Not A Feature, It Is The Substrate

The reason mobile feels fast is not the UI. It is that the same Socket.IO channel that streams block logs to the desktop canvas also streams them to a phone-shaped layout. There is no separate "mobile API." The execution store on the client subscribes to the same workspace:{id}:execution:{id} room regardless of viewport. Open the same workflow on two devices and you watch the same agent think in parallel.

This is also what makes "pause" and "override" cheap. When an operator hits pause on the phone, the client emits an event, the worker checks the flag at the next block boundary, and the run halts within one block. The undo / override surface is just another write to pausedExecutions with a different resume payload — manually edited tool args, a different LLM response, a hardcoded answer. The workflow does not know it was overridden. It just resumes.

What This Buys You

A concrete scenario: agent processing customer refunds. Policy says anything over $1,000 needs an operator. Without a mobile control plane:

• The agent stops at 2:14 PM.
• The operator is in a one-hour meeting from 2:00 to 3:00.
• They see the email at 3:05, get to their laptop by 3:12, approve at 3:14.
• Sixty minutes of customer-visible delay. SLA bordered or breached.

With AACFlow's mobile control plane:

• The agent stops at 2:14 PM.
• The operator's phone vibrates at 2:14:01 PM. They glance at the watch.
• Two taps. Approved by 2:14:18 PM.
• Eighteen seconds. The customer never noticed there was a human in the loop.

That eighteen-second gap is the entire business case. It is the difference between "AI workforce" being a press release and being a P&L line.

The Operator Goes Where The Work Is

A workforce that needs a desk is a workforce that throttles to the speed of the slowest desk. Build the control plane around where humans actually live — their pocket — and the agents work at the speed of attention, not the speed of office hours.

If your platform's mobile story is "we have a responsive design," it does not have a mobile story. Find one with realtime, Telegram, and push wired into the same pause primitive — or watch your agents wait while your operators commute.