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.

The words the relay handles directly

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:

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.

Everything else goes to the agent

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.)

The one gotcha: option replies belong to the agent

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.

Know which agent you're talking to

Topics map to agents, and not all agents are equal:

• A relay agent (what you built in Part 2) is pinned to one pane: by itself it can only nudge that agent, read the pane, and restart it, nothing more. But be clear-eyed: the relay is not a security boundary. The coding agent in that pane can still do whatever its own local permissions allow; the pin constrains the relay, not the agent's reach, which is why the rules below matter.
• An ops agent (covered later) is not pinned. It runs commands across the whole box and owns sensitive jobs like credential refreshes. It is far more powerful, and you treat its topic with more care precisely because there's no pane boundary containing it.

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.

What you must never type

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:

• Production and staging are read-only. Never ask the agent to apply, delete, edit, patch, scale, or restart anything in prod or staging. Inspect and debug only.
• No pushes or merges to shared branches. Feature and bugfix branches are fine; main / dev / GitOps branches are human-merge-only. A merge to a GitOps branch is a deploy.
• Shared infrastructure needs a human. Gateways, API gateways, and anything used by other teams: no mutations without explicit human approval.
• Never paste secrets into a relay topic. Credentials are an ops-agent concern, and even there they go in via a guarded path and are never echoed or relayed. A relay topic is the wrong place, full stop.

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.

A day in the life

What this actually feels like, with only your Part 2 setup:

1. From the queue at a coffee shop, you open the topic and type a task: "In the upload service, add exponential backoff to the S3 client and run the unit tests." The relay forwards it; the agent starts.
2. A few minutes later you type status. The relay summarizes: tests running, two failing.
3. The agent asks whether to bump the retry ceiling to 5 or 10. You reply 5. It goes to the pane; the agent continues.
4. You type status again: the pane reports the tests green. You ask the agent to open a feature branch and push, and it does.
5. It got wedged once on a stale process; you typed 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.

Before the session

You're set if you can still tick the Part 2 readiness gate:

1. The bot replies to status in your topic.
2. A real instruction reaches the pane and the agent acts on it.
3. Routing is correct (your agent handled your topic).
4. The group is locked down: allowlist, your ID only, no @mention required.
5. You can drive the loop above end to end.

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.