{"slug": "coding-agents-over-telegram-part-3-the-day-to-day-operating-contract", "title": "Coding Agents over Telegram, Part 3: The Day-to-Day Operating Contract", "summary": "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.", "body_md": "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.\n\nKeep 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.\n\nThese are *local control*: the relay acts on them instead of forwarding them. They come from the relay's `AGENTS.md`\n\n(the command table you wrote in Part 2), so the exact phrasings are yours to tune:\n\n| You type | What happens |\n|---|---|\n`status` / `what's in tmux?`\n|\nRelay captures the pane, strips the terminal formatting, and summarizes what the agent is doing right now |\n`send <message>` |\nRelay types `<message>` into the pane and submits it |\n`compact` / `new session`\n|\nRelay sends the agent's compaction / new-session command |\n`interrupt` / `stop it`\n|\nRelay interrupts the running turn (it confirms first) |\n`restart` |\nRelay cleanly exits and relaunches the coding agent, resuming the same session (no confirmation) |\n\n`status`\n\nis 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.\n\nOne caveat to hold onto: `status`\n\nshows 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.\n\n**Which control, when?** Reach for `interrupt`\n\nwhen 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`\n\nonly when the pane or session is genuinely wedged; it resumes the *same* session, so you keep your context. Use `compact`\n\nwhen the conversation is getting long but you want to keep going, and `new session`\n\nto start a fresh, unrelated task.\n\nAnything 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.\n\nTreat 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.\n\n(Need to send a literal control word *to the agent*, say the actual text `status`\n\n? Use `send status`\n\n, which types it into the pane instead of triggering the relay's own `status`\n\n.)\n\nThis is the single thing that confuses everyone on day one, so internalize it now.\n\nWhen the coding agent (inside the pane) asks you something (prints `A / B`\n\noptions, asks `Proceed?`\n\n, or `yes/no`\n\n), your short reply is an answer **for the agent**, and the relay forwards it verbatim. It does **not** act on it itself.\n\nAfter the agent shows options, typing:\n\n`A`\n\n, `B`\n\n, `yes`\n\n, `no`\n\n, `do it`\n\n, `sorry, B`\n\n→ 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`\n\ncould be misread as an instruction to the *relay*, and it might go act on \"option A\" itself instead of passing your choice through.\n\nIf you ever genuinely want the **relay** to make the choice or do something local, address it explicitly: `you pick A`\n\nor `don't send this to the agent, just tell me X`\n\n. Explicit address is the override.\n\nPart 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.\n\nTopics map to agents, and not all agents are equal:\n\nFor 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.\n\nThis is Telegram talking to a shell. The relay enforces guardrails (you encoded the first ones in its `AGENTS.md`\n\n), but you are the first line of defense. The contract:\n\n`main`\n\n/ `dev`\n\n/ 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`\n\nplus your own operator discipline; the series' final piece (the supervisor) makes the judgment automatic and harder to bypass.\n\nWhat this actually feels like, with only your Part 2 setup:\n\n`status`\n\n. The relay summarizes: tests running, two failing.`5`\n\n. It goes to the pane; the agent continues.`status`\n\nagain: the pane reports the tests green. You ask the agent to open a `restart`\n\nand 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`\n\n. But the loop above already works today.\n\nYou're set if you can still tick the Part 2 readiness gate:\n\n`status`\n\nin your topic.`@mention`\n\nrequired.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.\n\nThat'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.", "url": "https://wpnews.pro/news/coding-agents-over-telegram-part-3-the-day-to-day-operating-contract", "canonical_source": "https://dev.to/jerilk/coding-agents-over-telegram-part-3-the-day-to-day-operating-contract-i1a", "published_at": "2026-06-13 19:44:08+00:00", "updated_at": "2026-06-13 20:14:46.895934+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "artificial-intelligence", "large-language-models", "ai-products"], "entities": ["Telegram", "tmux"], "alternates": {"html": "https://wpnews.pro/news/coding-agents-over-telegram-part-3-the-day-to-day-operating-contract", "markdown": "https://wpnews.pro/news/coding-agents-over-telegram-part-3-the-day-to-day-operating-contract.md", "text": "https://wpnews.pro/news/coding-agents-over-telegram-part-3-the-day-to-day-operating-contract.txt", "jsonld": "https://wpnews.pro/news/coding-agents-over-telegram-part-3-the-day-to-day-operating-contract.jsonld"}}