Phone Reach Channel Access Decision Table

Choose one safe access route for a practical agent without handing it more reach than it has earned.

The channel access decision table

Route	Best use	Permission shape	Privacy risk	Maintenance burden	Proof you need before trusting it	Good first setting	Do not use it for
Terminal / SSH / local CLI	Build, debug, inspect files, run verified jobs.	Human operator has direct machine access. Agent acts inside a constrained workspace.	Low to medium. It may expose local files if the operator over-scopes it.	Low. Few moving parts, but fragile if only one person knows the commands.	Command transcript, file paths, hashes, test output, exit codes.	Read/write inside one project folder with no public send powers.	Public posting, customer messages, account changes, or anything requiring a non-technical user to babysit a shell.
Browser / PWA / web dashboard	Make status, forms, receipts, and approvals usable outside the terminal.	Login/session or scoped dashboard account. Separate read-only views from write actions.	Medium. Screens can reveal private records, account names, or drafts.	Medium to high. Auth, routes, mobile layout, browser smoke tests, and session expiry all need upkeep.	HTTP checks, screenshot smoke, non-blank render proof, route list, approval state.	Read-only dashboard plus an “approve draft” queue that does not send automatically.	Authenticated account automation without visible identity, session proof, and a rollback plan.
Discord / Telegram	Fast command interface, team notifications, personal operator alerts.	Bot token or app identity, subscribed channel/chat, explicit allowed commands.	Medium. Messages may be copied, forwarded, indexed, or seen by a whole team.	Medium. Tokens, channel IDs, permissions, rate limits, and gateway health can all break.	Fake-channel dry run, message log, allowed-command list, kill switch, recipient allowlist.	One private test channel: `#agent-lab-demo` or `chat_100200300`, notifications only.	Unapproved DMs, community replies, moderation, sales outreach, or live public posting.
WhatsApp / SMS / email	Reach a human on the device they actually check.	Dedicated sender identity, verified recipient list, strict approval before any new recipient or outbound copy.	High. Phone numbers and inboxes are personal. Mistakes feel invasive.	High. Deliverability, platform rules, phone pairing, spam controls, bounce handling, and opt-out records matter.	Recipient allowlist, sample message approval, outbound log, no-secret scan, failure/bounce log, spend check for SMS.	Owner-only alert route: `PHONE_DEMO_OWNER_010` as a fictional placeholder, or `[email protected]`, with send disabled until approved.	Cold outreach, client commitments, sensitive data, payment requests, legal notices, or anything that could look like spam.
Community routes: forums, Discord servers, Reddit, GitHub Discussions, comments	Helpful participation where people already ask questions.	Human owns the account. Agent drafts only unless the route is explicitly approved for posting.	High. Public context, community rules, affiliation claims, and screenshots make mistakes durable.	High. Each community has norms, moderation, self-promo rules, and identity expectations.	Rule check, non-affiliation note, draft copy, source map, human approval, final posted URL only after the human posts.	Draft a short answer and one useful checklist with `[PUBLIC_URL]` placeholder.	Drive-by links, scraped participant targeting, fake authority, affiliate claims, or pretending a community endorsed you.

How to choose the route

Does the agent need to reach a human away from the keyboard? If no, keep it in terminal or a local dashboard. If yes, continue.
Does the route send anything to another person, group, or public surface? If no, browser/PWA read-only status is usually enough. If yes, add an outbound approval gate.
Is the recipient a real person rather than a system mailbox or test channel? If yes, require a recipient allowlist and a message template approval. If no, log the webhook/API response and keep retry limits tight.
Does the message involve money, legal commitments, private data, health/safety, account recovery, or reputation? If yes, the agent drafts only and a human sends. If no, only consider limited sends after separate route approval, platform-rule review, recipient allowlist, approved template, dry run, logging, kill switch test, and a human-owned rollback plan.
Would the operator be embarrassed if a screenshot of this message appeared out of context? If yes, do not automate it. If no, still log it. Screenshots are not the only problem.

Route notes

Terminal is the cage, not the product

Terminal access is a good first route because it is honest. The operator sees commands, paths, tests, and failures. It is also terrible as the only route. Non-technical users will not live inside SSH just because your demo does.

Use terminal for build work, verification, and direct operator control. Do not call it “phone reach” unless a human can actually trigger or review the work from a phone-friendly surface.

Browser/PWA is the approval layer

A browser route is often the safest bridge between “agent in a shell” and “agent touching the outside world.” It can show receipts, pending drafts, route health, and approval buttons without giving the agent permission to send.

The trap: browser automation and browser dashboards are not the same thing. A dashboard that shows an approval queue is safer. An agent driving a logged-in account through a browser is a different risk class. Treat it like account automation, not like UI polish.

Safe fictional example: dashboard path /agent-demo/routes/pending-approvals, test draft ID draft_msg_00042, approval state needs_human_send.

Discord and Telegram are useful because they are narrow

Discord and Telegram are good early routes when the operator wants alerts and commands without opening a terminal. They work best with a small command set:

/status returns current state.
/receipt draft_msg_00042 returns the proof log.
/pause sends disables outbound sends.
/mark-reviewed draft_msg_00042 records that the owner reviewed the draft; it does not send. Any external send still requires a separate human send step or separately approved route.

Keep the bot in a fictional or private test space until the rules are proven. Use example IDs like guild_123456789000, channel_demo_ops, or telegram_chat_100200300. Do not copy real channel IDs, bot usernames, invite links, or tokens into public docs.

WhatsApp, SMS, and email are reach, not toys

These channels feel like the obvious win because people answer phones and inboxes. That is exactly why they need stronger limits.

Use a dedicated sender identity, not a personal inbox or number.
Start with owner-only notifications.
No new recipient without human approval.
No outbound message without a stored draft and proof log.
No private data in alerts unless the recipient and channel are approved for it.
SMS can cost money; log spend and provider response.

Fictional safe first route: sender [email protected]; recipient [email protected]; template: “Agent run finished. Review receipt: [LOCAL_RECEIPT_ID]. No public action was taken.” Forbidden: client names, payment links, private files, urgent threats, or sales copy.

Community routes are not access channels until the human owns the context

A community route is any place with other people and norms: Discord servers, Reddit, forums, GitHub Discussions, comments, group chats. Agents can help draft useful answers. They should not roam.

Human identifies a real question.
Agent drafts a short answer using public-safe sources.
Agent includes a non-affiliation note when needed.
Human checks the community rules.
Human posts, or explicitly approves a one-off post route.
Agent records the final URL only after it exists.

If the agent scrapes names, targets participants, fakes membership, or drops a link because a keyword matched, it is not helpful distribution. It is spam with a better vocabulary.

Minimum controls by route

Route	Start read-only?	Human approval before first send?	Recipient allowlist?	Kill switch?	Proof artifact
Terminal / CLI	Yes	Not applicable for machine-local work	Not applicable	Nice to have	Command log, tests, hashes
Browser/PWA	Yes	Yes for any external action	Yes if messages or account actions exist	Yes	Route smoke, screenshot, approval log
Discord/Telegram	Yes	Yes	Yes	Yes	Bot dry-run log, allowed commands
WhatsApp/SMS/email	Yes	Yes, every new route and template	Yes	Yes	Outbound log, recipient proof, spend check
Community routes	Yes, drafting only	Yes, per post unless explicitly approved	Yes, by community/account	Yes	Rule check, draft, final URL if posted by human

Common failure modes

The agent can send before anyone has approved a template.
The route works once, then fails silently because a token, session, or phone pairing expired.
Logs prove that “a message was sent” but not who received it or what it contained.
A test channel accidentally becomes a real community channel.
Email uses a personal inbox, so replies, identity, and privacy all get messy.
A dashboard shows drafts but the send path bypasses the dashboard.
The team says “Telegram” or “WhatsApp” as if the platform choice solved permission, privacy, maintenance, and proof. It did not.

Safe first route exercise

Pick exactly one route for the next week. Not five. One.

Route: Telegram private test chat / read-only browser dashboard / owner-only email alert / another specific route.
Purpose: one sentence.
Allowed actions: three verbs maximum.
Forbidden actions: at least five verbs.
Human approval point: where the agent must stop.
Proof: what file, log, receipt, screenshot, or hash proves what happened.
Kill switch: how to disable the route quickly.

Example route: telegram_chat_100200300 (fictional private test chat). Purpose: owner receives run-complete alerts and asks for receipts from a phone. Allowed actions: notify, fetch status, fetch receipt. Forbidden actions: DM strangers, post in groups, approve spend, publish content, change accounts, collect private data. Human approval point: any message that leaves the owner-only test chat. Proof: outbound log row with message ID, timestamp, route, template ID, and receipt ID. Kill switch: disable the bot route in config and confirm /status no longer responds.

That is the whole CTA: choose one safe first route and define its forbidden actions. If you cannot name what the agent is not allowed to do, it is not ready for phone reach.

Source and evidence notes

This guide was synthesized from internal planning notes about channel access, approval gates, proof receipts, and public-safety rules. No live account details, credentials, real contact data, private route identifiers, or private source paths are included.

No posting, outreach, account change, gateway control, provider call, or spend was performed to create this public resource.

Last updated: 2026-06-28