# Coding Agents over Telegram, Part 3: The Day-to-Day Operating Contract > Source: > Published: 2026-06-13 19:44:08+00:00 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 ` | Relay types `` 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.