Remote Control Over Messaging
An owner-authenticated, approval-gated way to drive a running Ambient Desktop from a messaging app — check status, change settings, and run work without sitting at the window. Telegram is the first supported provider; the gateway is built to add more.
Drive Ambient from a chat app
Ambient Desktop is a workstation you normally sit in front of. Remote Control lets you reach a running instance from a messaging app instead — ask for status, flip a setting, kick off or approve work — so you can keep something moving while you are away from the machine.
This is a Developer Preview. It is not a server daemon: the desktop app still has to be running on your machine, and the window stays open. What it removes is the need to be *at* the window. Every remote action is owner-authenticated and, for anything that changes state, approval-gated — the same review posture Ambient uses everywhere else.
How a remote command flows
A message does not run directly. It travels through the same preview-then-approve path the agent uses for any consequential action, with an owner check at the front.
Owner authentication
Each remote binding is tied to a specific owner account on the provider. Messages from anyone else are not treated as commands, so a stray chat cannot drive your machine.
Preview
An incoming command is parsed and previewed first — Ambient shows what it would do and flags any blockers — before anything is applied.
Approval
Commands that change state are approval-gated. You confirm from chat (for example, approve request 1) and only then does the action apply. Read-only status and navigation do not need approval.
Apply and relay
The approved command runs against the live runtime, and the result — status, queued events, or the outcome — is relayed back to you in the same conversation.
Telegram today, more providers next
The gateway is designed as a provider-agnostic surface so new messaging apps can be added behind the same owner-auth and approval model. Only Telegram is wired end-to-end right now; everything else is honest about being ahead of the implementation.
Telegram
The one fully wired provider. A local bridge connects to Telegram with your own API credentials, an owner handoff binds your account, and Ambient polls for your commands. Status reads, settings changes, project/chat/workflow actions, and approvals all work through it.
Signal
Scaffolding and a contract exist, but the provider is intentionally disabled — it reports as unavailable and bindings are refused — until a reviewed local-bridge adapter lands. Ambient can plan the work, but cannot operate Signal yet.
More messaging apps
The goal is to support many providers (WhatsApp, Matrix, and others) through the same gateway. Each one needs a reviewed adapter for owner auth, inbound delivery, and replies before it is offered.
What you can do remotely
Ambient keeps an internal ledger of which actions are ready for remote use, which are partial, and which are still planned — so the agent never promises a remote capability it cannot actually perform. Today the ready set covers the common operating loop:
- Read status and navigate — runtime status, projects, chats, workflow agents, and pending approvals, all without the window.
- Change supported settings — voice, speech input, generated-media playback, search routing, and chat mode, thinking level, and planner finalization.
- Run work — create and switch projects, create chats, and create, run, compile, approve, retry, resume, or cancel workflow agents.
- Handle approvals — review and approve or deny pending permission prompts, and revoke active grants, from chat.
Setup at a glance
Telegram setup is owner-driven and deliberately explicit. Ambient provides an activation plan and walks the steps rather than flipping a single switch.
Bring your own Telegram credentials
The local bridge connects to Telegram using your own Telegram API credentials. They stay on your machine; Ambient runs the bridge as a local process.
Bind your owner account
An owner handoff links the conversation to your account so Ambient knows which sender to trust as the owner.
Start polling with a freshness mark
Ambient polls the owner chat for commands. Activation passes a freshness timestamp so old unread messages from before setup are treated as stale instead of being replayed as commands.
Boundaries and current limits
Honest scope, in the spirit of a Developer Preview:
- The desktop app must be running — this is remote control of a live instance, not a headless server you can SSH into.
- Telegram is the only working provider; Signal is planned and other providers are on the roadmap.
- Only a subset of settings are remotely writable today; provider selection, appearance, API keys, and some others are read-only or not yet exposed.
- Polling freshness depends on activation passing the timestamp correctly; this is handled by the activation plan but is worth knowing when debugging.
- Every state-changing command is approval-gated by design, so remote operation is interactive, not fully unattended.
FAQ
Can Ambient run on a headless server with no display?
Not in this preview. Remote Control assumes the desktop app is running on your machine with its window open. It removes the need to interact with the window, not the need for the app to be running.
Can someone else message the bot and control my machine?
No. Commands are owner-authenticated against a specific provider account, and state-changing actions require your approval from chat. Messages from non-owners are not treated as commands.
Is Signal supported?
Not yet. The provider is scaffolded but intentionally disabled and reports as unavailable. Ambient can plan reviewed Signal support, but cannot operate it today.
Do remote commands skip the usual approvals?
No. Remote commands flow through the same preview-then-approve path as in-app actions. Read-only status is free; anything that changes state is gated.