Coding Agents over Telegram, Part 3: The Day-to-Day Operating Contract

A developer details the operating contract for a Telegram-based coding agent relay, defining local control commands like status, interrupt, and compact that the relay handles directly, while all other input is forwarded to the agent. The post explains the single routing rule that confuses new users: when the agent asks a question, the user's reply goes straight to the agent, not the relay. It also warns against sending certain unsafe inputs and emphasizes precise prompting for effective agent interaction.

You finished Part 2, so you have a topic where you type a message and a coding agent answers and drives a pane. This post is the operating contract: the small vocabulary the relay understands, the one routing rule that confuses everyone the first day, and because this is a phone wired to a shell the short list of things you must never send. It's a contract, not a tutorial; read it once and you'll drive the thing confidently. Keep the mental model from Part 1 in front of you: you are talking through a relay agent to a coding agent in a tmux pane. The relay is a courier. Most of what you type is forwarded straight to the pane; a handful of words are handled by the relay itself. These are local control : the relay acts on them instead of forwarding them. They come from the relay's AGENTS.md the command table you wrote in Part 2 , so the exact phrasings are yours to tune: | You type | What happens | |---|---| status / what's in tmux? | Relay captures the pane, strips the terminal formatting, and summarizes what the agent is doing right now | send <message | Relay types <message into the pane and submits it | compact / new session | Relay sends the agent's compaction / new-session command | interrupt / stop it | Relay interrupts the running turn it confirms first | restart | Relay cleanly exits and relaunches the coding agent, resuming the same session no confirmation | status is the one you'll lean on most. Until you add the automatic monitors in Part 4, status is how you check in : there are no progress pings yet, so you ask. One caveat to hold onto: status shows you what's on the pane right now ; it's a snapshot, not proof. It can report that the agent claims the tests passed; it can't tell you they actually did. Treating that claim as something to verify rather than trust is exactly what Part 5 is about. Which control, when? Reach for interrupt when the agent is doing the wrong thing or about to take an unsafe step: you want to stop this turn and redirect. Reach for restart only when the pane or session is genuinely wedged; it resumes the same session, so you keep your context. Use compact when the conversation is getting long but you want to keep going, and new session to start a fresh, unrelated task. Anything that isn't one of those control words is forwarded verbatim into the pane. "Add a retry to the upload client and run the tests" isn't a command the relay interprets; it's an instruction for the coding agent, so the relay just types it in and lets the agent work. That's the default, and it's most of what you do. Treat that first message like a good ticket: name the repo and branch, the change you want, the test expectation, and any constraint. The agent acts on what you give it, so a precise prompt beats a chatty one. Need to send a literal control word to the agent , say the actual text status ? Use send status , which types it into the pane instead of triggering the relay's own status . This is the single thing that confuses everyone on day one, so internalize it now. When the coding agent inside the pane asks you something prints A / B options, asks Proceed? , or yes/no , your short reply is an answer for the agent , and the relay forwards it verbatim. It does not act on it itself. After the agent shows options, typing: A , B , yes , no , do it , sorry, B → goes straight to the pane as your choice.That's what you want: you're answering the coding agent's question, not issuing a new command to the relay. The reason this needs stating is the failure mode it prevents: without this rule, a bare A could be misread as an instruction to the relay , and it might go act on "option A" itself instead of passing your choice through. If you ever genuinely want the relay to make the choice or do something local, address it explicitly: you pick A or don't send this to the agent, just tell me X . Explicit address is the override. Part 4 hardens this with a deterministic router so the classification is instant and never guesses. In your Part 2 setup it's handled by the relay's own instructions, which is enough as long as you remember the rule above. Topics map to agents, and not all agents are equal: For pre-work you have exactly one relay and one pane. Just be aware that "which topic am I in?" determines "how much can this agent do?" That's a habit worth forming before you add an ops topic. This is Telegram talking to a shell. The relay enforces guardrails you encoded the first ones in its AGENTS.md , but you are the first line of defense. The contract: main / dev / GitOps branches are human-merge-only. A merge to a GitOps branch If the relay refuses an instruction or asks you to confirm, don't fight it; that's the contract working. Right now that contract is the explicit rails in your agent's AGENTS.md plus your own operator discipline; the series' final piece the supervisor makes the judgment automatic and harder to bypass. What this actually feels like, with only your Part 2 setup: status . The relay summarizes: tests running, two failing. 5 . It goes to the pane; the agent continues. status again: the pane reports the tests green. You ask the agent to open a restart and it came back on the same session.No terminal, no SSH, the whole loop from your phone. In Part 4 you'll add monitors that push progress and a final summary automatically, so you stop having to poll with status . But the loop above already works today. You're set if you can still tick the Part 2 readiness gate: status in your topic. @mention required.Bring a redacted screenshot of that working loop as your "I'm ready" artifact. If you're blocked, send your symptom plus Node/pnpm versions and the last few redacted gateway log lines so it's sorted before we're in the room. That's the end of the pre-work. In the live session we go beyond a single courier: Part 4 makes agents genuinely capable loadable skills, tool servers, per-topic memory, and the monitors that notify you automatically , and Part 5 is the payoff: the skeptical supervisor that audits an agent's evidence and blocks the confident-but-wrong answer before it reaches you.