Mastering Your Coding Agent Workflow with Telegram Relay Commands

Building a seamless workflow between Telegram and a coding agent requires clear rules. After setting up the relay in Part 2, the next step is mastering its operating contract. This guide simplifies the small set of relay commands, addresses the common day-one confusion, and highlights the critical boundaries you must respect to avoid costly mistakes.

The Relay’s Core Command Set

The relay acts as a courier between your Telegram messages and the coding agent running in a tmux pane. Most of your input travels directly to the agent, but a handful of words trigger local actions instead. These commands are defined in the relay’s AGENTS.md file, so you can customize their phrasing to match your preferences.

• status or what's in tmux? – The relay captures the current pane, strips terminal formatting, and provides a concise summary of the agent’s activity.
• send – The relay types the specified text directly into the pane and submits it as an instruction to the agent.
• compact or new session – The relay executes the agent’s compaction or session-reset command.
• interrupt or stop it – The relay halts the agent’s current action after confirming your request.
• restart – The relay cleanly terminates and restarts the coding agent, resuming the same session without losing context.

The status command is the most frequently used. Until Part 4 introduces automatic progress checks, it’s your primary tool for checking in on the agent’s progress. However, remember that status reflects the agent’s claimed state—not a verified outcome. Always treat its output as a starting point for further validation.

When to Use Each Command

• Use interrupt to halt an incorrect or risky action mid-execution. This command stops the current turn but preserves the session for quick redirection.
• Reserve restart for situations where the pane or session is unresponsive. It reloads the agent while retaining its context.
• Opt for compact when the conversation grows lengthy but you want to continue efficiently.
• Choose new session to initiate a fresh, unrelated task from scratch.

Most of your interactions will flow directly to the coding agent. For example, phrased instructions like "Add a retry to the upload client and run the tests" are forwarded verbatim. Precision in your prompts accelerates the agent’s understanding and reduces back-and-forth.

If you need to send a literal control word to the agent—such as the text status—prefix it with send to bypass the relay’s interpretation. For instance, typing send status types the word directly into the pane instead of triggering the relay’s status command.

The Day-One Pitfall: Option Replies Belong to the Agent

One rule trips up beginners more than any other: when the coding agent presents options or asks for confirmation (e.g., A / B or Proceed?), your reply is an answer for the agent and is forwarded directly to the pane.

This means typing:

• A, B, yes, no, or any other short response will reach the agent as its choice—not as a relay command.

The confusion arises when a bare A might be misinterpreted as a command to the relay itself. For example, if the agent asks, "Continue with option A?", typing A sends it to the agent’s prompt, not the relay’s command processor. To override this behavior and address the relay directly, use explicit phrasing like you pick A or don’t send this to the agent.

Part 4 introduces a deterministic router to eliminate ambiguity entirely. For now, internalizing this rule prevents critical errors in your workflow.

Agent Capabilities and Security Boundaries

Not all agents operate under the same constraints. The relay agent you configured in Part 2 is pinned to a single tmux pane, limiting its scope to interacting with that specific agent. Crucially, the relay does not act as a security boundary—it constrains its own actions, not the agent’s permissions within the pane. The coding agent retains all the permissions granted to its local environment.

Later, you’ll work with an ops agent that operates across the entire system. This agent handles sensitive tasks like credential refreshes and lacks the pane boundary restriction. The topic you’re using determines the agent’s capabilities, so always verify which agent you’re addressing before issuing commands.

The Non-Negotiable Safety Rules

When bridging Telegram to a shell, the relay enforces basic guardrails—but you remain the ultimate safeguard. Follow these hard limits to avoid irreversible mistakes:

• Production and staging environments are off-limits. Never instruct the agent to apply, delete, edit, patch, scale, or restart anything in these environments. Your role is to inspect and debug only.
• Shared branches must stay human-controlled. Feature and bugfix branches are safe, but main, dev, or GitOps branches require manual approval before merging. A change to a GitOps branch is a deployment.
• Shared infrastructure demands human oversight. Gateways, API gateways, and systems used by other teams cannot be modified without explicit approval.
• Never paste secrets into a relay session. Sensitive data should be handled through secure channels outside the relay’s workflow.

By internalizing these rules, you transform a powerful but potentially risky setup into a reliable, efficient system. The next step is automating progress checks in Part 4, which will further reduce manual monitoring and streamline your workflow.