# Change how Connect writes

Three separate controls decide how a reply reads, and picking the wrong one is why an edit appears to do nothing. Behaviour text on the Connect Rules screen owns register and length. The mailbox owns the signature. Knowledge owns the facts a reply is grounded in. Memory and thread guidance override any of them for one channel, one mailbox or one person.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/maya-rules, #/mailboxes, #/knowledge, #/inbox
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/change-what-connect-says/

## Which control owns what

| What you want to change | Where it lives | Scope |
|---|---|---|
| How formal or warm a reply sounds | Behaviour text on Connect Rules | The whole workspace unless a narrower rule overrides |
| How long a reply runs | Behaviour text on Connect Rules | The whole workspace |
| The sign-off block at the foot | The mailbox's own signature | One mailbox |
| What a reply is allowed to assert | Knowledge, and the facts derived from it | The whole workspace |
| Wording for one customer only | A memory row at the contact tier | One person |
| Wording on one thread only | Guidance on that thread | One conversation |
| Whether a reply is sent at all | Autonomy | Contact, endpoint, channel or workspace |

> **Note** A price, an SLA or a warranty is not a tone problem. Connect refuses to improvise commercial terms that Knowledge does not support and escalates instead — the refusal is the designed behaviour. If replies keep stopping at the same commercial question, the fix is a Knowledge source, not a friendlier instruction.

## Making the change

1. Find one recent reply that reads wrongly and write down, in a sentence, what is wrong with it. "Too long" and "too stiff" are different edits and pull in different directions.
   - Result: You have a description you can check the next reply against, which is the only way to tell an improvement from a change.
2. Edit the behaviour text on the Connect Rules screen. Say what you want, not what you dislike: a direction to be direct and finish under six lines outperforms a prohibition on rambling.
   - Result: The direction becomes part of what the model is given for every draft on that channel from the next one onwards.
3. Set the mailbox signature separately, on the mailbox itself. Each mailbox has its own, alongside its own role and its own autonomy.
   - Result: Replies sent from that mailbox carry that sign-off. A support address and a sales address do not have to share one.
4. If the problem was a wrong claim rather than a wrong tone, add the correct statement to Knowledge instead.
   - Result: Answers are grounded in it, and the same question stops producing the same wrong sentence.
5. Let one real thread produce a draft, and read it before approving.
   - Result: This is the verification step. Nothing is proved by the settings screen; it is proved by the next draft.

## When an edit looks like it did nothing

**A narrower rule is winning** — Memory resolves workspace, then channel, then endpoint, then contact, with the narrowest applying. A contact-tier note saying "always formal with this person" beats the workspace's new instruction, correctly.
**You are reading an old draft** — A draft written before the change is not rewritten by the change. Regenerating gives the model the current instructions; editing the held text does not.
**The instruction asks for something the channel cannot do** — Length directions that make sense in mail do not transfer to a phone call, where the reply is spoken and the controls live in the Voice Lab.
**The instruction is a preference rather than a direction** — "Be more professional" is not actionable. "Open with the answer, no greeting longer than one line, never apologise twice" is.
**The signature was edited on the wrong mailbox** — Signatures are per mailbox. A workspace with several is a workspace where this is easy to do.

## Keeping the change honest

Changes to behaviour text affect every future draft on the channel, which makes them cheap to make and easy to over-make. Two habits keep it manageable. Change one thing at a time, because two simultaneous edits cannot be attributed when the next reply improves. And prefer the narrowest control that solves the problem: if one account needs careful wording, a contact-tier memory row is a better answer than making the whole workspace cautious.

The decision log records what was decided and under which rule, so a reply you disliked can be traced back to the instruction that produced it instead of guessed at. That trail is also how you find the old instruction that is quietly still in force and fighting the new one.

## Questions

### Can I set a different tone for each mailbox?

Yes, through memory at the endpoint tier — an endpoint is one mailbox or one phone number. That is the tier between the channel and the individual contact, and it is the right place for "support replies stay plainer than sales replies".

### Does editing a held draft teach Connect anything?

No. Your edit is what gets sent, and it is not read back as a lesson. If the edit represents a rule rather than a one-off, write it down as guidance on the thread or as a memory row, or the next draft repeats the original.

### Why do replies stop short of answering a pricing question?

Because Connect will not invent commercial terms. Where Knowledge does not support a price, an SLA or a warranty, the question is escalated to a person rather than answered plausibly. Supplying the term in Knowledge is what changes the behaviour.

## Related

- [Knowledge in Connect](https://connectbyjbrh.com/docs/knowledge/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Mailbox signatures](https://connectbyjbrh.com/docs/email/mailbox-signature/)
- [Giving guidance on a thread](https://connectbyjbrh.com/docs/email/guidance/)
- [Write a standing instruction that works](https://connectbyjbrh.com/docs/how-to/write-a-standing-instruction/)
- [Why a sales agent should refuse to answer](https://connectbyjbrh.com/research/safe-refusals-in-sales/)

## What this page is based on

- docs-source/sources/GENERAL.md §6 — memory tiers and resolution order
- docs-source/sources/CHANNELS.md §1 — mailbox roles, signatures and autonomy
- docs-source/sources/CHANNELS.md §6 — `safe_sales` and refusals
- Connect capability registry (docs-source/facts.py)