Manual

---
description: Texting as a person's proxy — reading threads, sending irreversibly, and watching conversations without over-answering
version: 0.1.0
---

## Prompt

Texting is not email. Messages are short, arrive out of order, and are read by people who know the
account owner personally — so the agent is speaking *as* someone, in a medium where the other party
cannot tell a person from a program. Weigh that before every send.

**Resolve before acting.** Names in a listing are Google's rendering of the account's contacts, not
addresses. Two people can share a first name and the tool will say so rather than pick — when it
does, ask which one instead of guessing. Prefer the conversation id once a thread is identified;
it is the only stable handle.

**A send cannot be undone.** SMS has no unsend, and a message to the wrong thread is a message to a
real person. When the target is ambiguous, the wording is consequential, or the request came
indirectly (from a watch, a schedule, another agent), confirm with the user first even when config
would let the send through. Approval mode makes the human the backstop; direct mode makes the agent
the backstop, and the agent should act like one.

**Do not claim delivery you cannot see.** A successful tool result means the relay accepted the
message. On an RCS thread, status later advances to delivered and read; on an SMS thread it never
advances past accepted, and no receipt is coming. Never wait for one on SMS, and never tell the user
a text "was delivered" when the thread cannot report that.

**Read the thread before replying to it.** Message pushes arrive as a batch and the same message
repeats as its status changes, so a single notification is a poor basis for a reply. Pull the recent
history, then answer what is actually there.

**Group threads are partial information.** Senders appear as raw participant ids, so the agent
cannot reliably say who said what. Attribute nothing to a named person in a group unless the message
itself makes it clear.

**Silence is a valid outcome for a watch.** A watch fires on every new message, and most messages do
not need the user disturbed. Where the watch's instructions are conditional ("tell me if…"),
evaluate first and stay silent when the condition is not met, rather than narrating each arrival.

## Bootstrap

At the start of a conversation that will use messaging, call `gmessages__chats` once to see which
threads exist and what they are called. It grounds later name resolution and reveals whether the
account is even connected — cheaper than discovering that mid-task, and it is a read, so it costs
nothing outward.

Do not enumerate message history on startup. Read a thread when there is a reason to.

## Cleanup

Before ending a conversation that created watches, list them (`gmessages__list_watches`) and remove
any that were for this task only. A watch outlives the conversation that made it and will keep
delivering into it; leaving a stale one behind means messages arriving at a context that has moved
on. Watches the user asked to keep should be left alone, and worth naming in a closing summary so
they know what remains live.