What agents can — and can't — do

Pidge exists so agents can reach you — which is exactly why most of its machinery is about what they can’t do. None of this is honor-system: each limit below is structural, enforced by the server or the app, and verified on real devices. The short version: agents propose, you decide, and the plumbing can’t be talked out of that.

Lock-screen banners only ever carry safe buttons — Done, Yes/No, Snooze, a reply field. Anything dangerous or custom lives only behind the app’s detail screen, with a confirmation alert (cancelling sends nothing), and Face ID for the actions the agent marks as gated. The Face ID tap reaches the agent as your decision on that exact question — never as a stray command it can reinterpret. The safe-button list is mirrored byte-for-byte between the app and the server, so an agent can’t smuggle a custom action into a banner.

An agent can’t turn its own volume up

You set a per-channel ceiling — how loud that agent may ever get. An over-ceiling send still arrives (nothing is silently dropped), but visibly downgraded, and the agent is told why — never silently louder. An urgent that cries wolf gets its channel capped; abuse is structural, not a promise. And your delivery settings — profiles, ceilings, quiet hours — are writable only from your side: agents can read them, and leave advisory notes for each other, but nothing an agent writes can change how anything is delivered.

You always know who spoke

Every signed send wears a stable persona — same session, same name; new session, new name. Tap it and the identity sheet shows the agent’s label, how it was launched, its role, and its seal — with the honest caption that this proves which execution spoke, not what it remembers. When a new session takes over a conversation, a visible handoff marker (“new session took over: from → to”) appears in the thread — you’re never silently switched. And attribution is never authorization: personas identify, they don’t grant power.

Nothing is answered twice, nothing is lost

One question, one answer: your response closes the notification, and only snooze or a reschedule bring it back — an agent can’t keep a question open to ask again. In the other direction, if the agent is offline your messages queue durably on the server and are handed over when it returns — delivered at least once, deduplicated on the agent side, so a crash mid-task means a retry, never a loss. Once handled, the message carries a receipt: who processed it and a summary of what they did.

Keys rotate on every re-connect

Connecting an agent uses a single-use claim code that expires in 15 minutes — never the key itself. Exchanging it mints a fresh channel key in the same atomic step, and the previous key stops authenticating instantly: re-claiming from the app is how a leaked or forgotten key dies. A used code is indistinguishable from a fake one, so old chat logs can’t be swept for live credentials. Full detail in the security model.

What the server can — and can’t — read

Messages are encrypted in transit, and Pidge doesn’t read, train on, or sell content. Want protection against the server itself? Flip on per-channel end-to-end encryption: titles, bodies, your replies and messages travel as ciphertext the server can’t open. The sealing is per-field and honestly documented — what the server needs for routing (action ids, timestamps, urgency) stays readable by design, and the manifest lists exactly which is which instead of claiming the server is blind to everything. Don’t trust the app’s key generator either? Bring your own key.