---
name: synthesis-agent-correspondence
description: "Compose and send honest agent correspondence on Slack, email and other channels: principal-direct, assistant and bot lanes, the voice axis, review depth, personas, disclosure signatures and send gates. Use for sending on a principal's behalf, message signatures, persona registries or agent voice."
license: "Apache-2.0"
depends_on: []
metadata:
  author: "Rajiv Pant"
  version: "4.1.0"
  source_repo: "github.com/synthesisengineering/synthesis-skills"
  source_type: "public"
  format: v5
---

# Agent Correspondence

How an agent drafts and sends correspondence for a principal honestly: which lane a message belongs in, who narrates it, what its signature discloses, and the gates it passes before it leaves.

> **Disclosure should answer the one question the recipient actually cares about: whose words are these? Everything else — how the sausage was made, what approval workflow ran — is internal governance, not disclosure.**

## Binding rules

1. **Every message sits in one lane.** Principal-direct carries no marker; the assistant lane (the principal's words, the agent's hands) carries one authorship signature; the bot lane (the principal's direction, the agent's words) carries the persona's own signature.
2. **The assistant lane requires exact-text ownership.** Words the principal has not made their own go in the bot lane: no signature can honestly say both "these are my words" and "I did not review these words."
3. **The archetype binds the narrator.** An assistant persona writes in the principal's first person; a bot persona says "I" for itself and names the principal in the third person, early. One narrator per message.
4. **Sincerity classes route up.** Appreciation, kudos, condolences and relationship messages need the principal's voice: would it sound right coming from a staff assistant? If not, route up.
5. **Hard content limits at `standing_direction` and deeper:** never opinions, commitments, sensitive relationships or criticism. Add limits; never subtract these.
6. **When in doubt, claim less.** Approval doubt routes toward more review; authorship doubt routes to the bot lane. A false assistant-lane signature cannot be walked back.
7. **Personas live in a private registry.** Branding is absolute, and a persona's emoji never appears on another persona's message.
8. **Channel disclosure is a fact, not a preference.** Verify each channel's current behavior; Slack stamps agent-performed sends whatever the signature says.
9. **Signature links render natively per channel,** as the section below sets out.
10. **Pass the three gates.** Read the whole thread and prior correspondence before composing; load the voice and anti-slop rules before drafting; re-read the live thread and re-verify every claim at send time. The verdict is send, revise or withdraw.
11. **Get the exact call approved, then verify it.** Load `synthesis-message-guard` for construction and the principal's approval of the exact call, and read the draft or sent message back through the transport after an approved draft or send.
12. **Call people by the name they go by.** In prose and greetings, use a person's preferred name where one is known: from the principal's preferred-names map, then a chat display name that differs from their real name, then the name they sign or use in their own messages. With none known, use the name they use in their own messages. Mention syntax stays what the platform requires.

## Contents

- [references/lanes-and-voice.md](references/lanes-and-voice.md): the core principle, the three lanes, the voice axis and bot-voice composition rules, and review depth with its content limits and routing rules. Read it before choosing a lane or writing in a persona's voice.
- [references/gates-and-sending.md](references/gates-and-sending.md): channel disclosure, the three gates in full, email construction and verification, related skills. Read it before composing a reply and again at send time.
- [references/personas-and-adoption.md](references/personas-and-adoption.md): the persona registry schema, archetype binding with example signatures, adoption steps, and migration from v1 and v2. Read it when configuring personas or writing a signature.
- [references/persona-registry.example.yaml](references/persona-registry.example.yaml): a commented registry template. Read it when creating a registry.
- [references/preferred-names.md](references/preferred-names.md): where a preferred name comes from, what stays as the platform requires, keeping the principal's map, the editor pass and the send guard's name check. Read it before greeting or naming anyone in a draft.
- [references/coverage-map.md](references/coverage-map.md): where each part of the 3.1.2 text now lives.
- [references/preserved.md](references/preserved.md): sentences replaced in 4.0.1 because they named send-guard machinery v5 removed, verbatim. Read only to review the change.
- Signature links render natively per channel: below.

## Signature links render natively per channel (v3.1.0)

The persona's name in a signature is a **named hyperlink on every channel that can
render one**. A visible URL is the last-resort fallback for channels that genuinely
cannot — never a stylistic choice, because the raw-URL form costs exactly the
recipients the signature exists to serve.

Link capability is a per-channel fact, verified against the actual send path like
disclosure behavior above:

- **Slack** renders `<https://example.com/|Name>` mrkdwn as a true link.
- **Email renders HTML, never markdown.** `[Name](url)` in an email body is
  literal text to every mail client. The signature (and therefore the whole body)
  must go out as an HTML part — `<a href="https://example.com/">Name</a>` — via
  whatever the send tool exposes (an html body format, or a dedicated html-body
  parameter). When the tool takes both a plain and an html part, the html part
  carries the anchor and the plain part carries the fallback form. A plain-text
  body is not a softer version of the same signature: the receiving client
  auto-links the raw URL and may wrap it in a tracking redirect, so the recipient
  sees neither the clean name-link nor the clean URL. (Observed live: a
  markdown-authored signature reached Gmail as plain text and displayed as the
  name followed by a provider-redirect URL in parentheses.)
- **Rich editors** (docs, wikis) take the platform's native link on the name.
- **Channels with no rich text on the send path** (for example Google Chat
  messages sent with user credentials, where named-link markup is app-only) use
  the plain fallback: `Name (example.com)` — short and readable as text, chosen
  for how it reads, not for auto-linking.

Markdown link syntax remains the *notation* for drafts, approval prompts, and
review surfaces; the wire format is the channel's own. Converting notation to the
channel form is part of staging the send, and a compose gate should treat
markdown reaching an email body as a defect, not a fallback.

**The send path is part of the channel (v3.1.1).** Two tools for the same
mailbox can store different bytes: a tool that takes structured fields and lets
the provider compose the message server-side may rewrite your hrefs (observed
live: Gmail's composer wrapping every link in an expiring `google.com/url`
redirect at ingestion), while a tool that submits raw MIME stores the bytes you
built. When both exist, prefer the byte-faithful path — and verify a path once
by reading the stored message back in raw form before trusting it with real
correspondence. A link that looks right in the client can still be wrapped
underneath; only the stored bytes settle it.