Regenerating a draft, end to end
Regenerating discards the draft text and nothing else. The thread, its mailbox, the person, the guidance and the memory all survive, and the second attempt is written against the thread as it stands now — including messages that arrived after the first draft. If nothing has changed and nothing new has been said, expect a similar answer rather than a better one.
The flow, stage by stage#
- Trigger — a person rejects a draft or asks for another attempt.
- User event — a request from the Needs You queue or from the conversation itself.
- Authentication and workspace resolution — the thread and its draft are read inside the session's workspace; a draft id from a browser cannot reach another workspace's row.
- Ingest — nothing arrives from outside; the input is the thread as it currently stands.
- Canonical record — the previous draft is discarded, and the rejection, where there was one, is recorded against the thread.
- Classification and reasoning — the reply is written again over the current messages, which may now include mail the first attempt never saw.
- Knowledge, memory and rules — knowledge, memory at four tiers and any guidance on the thread are supplied again, under the same budgets.
- Autonomy and approval — unchanged. A regenerated draft is held exactly as the first was; regenerating is not approving.
- Action through a provider — none. Nothing is sent, and the recipient sees nothing at any point.
- Result — a new draft in the same place, waiting on the same decision.
- Relationship, timeline and memory — the customer's timeline is untouched; no message existed to record.
- Audit, usage and Needs You — the attempt is metered as model work, the rejection is in the decision log, and the item stays in the queue.
Discarded, kept, and newly supplied#
| Element | Regeneration |
|---|---|
| The previous draft's wording | Discarded |
| Your edits to that draft | Discarded with it — edit and regenerate are alternatives, not steps |
| The thread and its history | Kept, and now includes anything that arrived since |
| The mailbox the reply will leave from | Kept — it was decided when the thread was created |
| The person and the company | Kept, including any correction made in between |
| Guidance recorded on the thread | Kept and supplied again |
| Memory at workspace, channel, endpoint and contact | Kept and supplied again |
| The approval state | Kept — a held draft is replaced by another held draft |
The second row is the trap. Editing changes the words that will be sent; regenerating replaces the words with a fresh attempt. Doing both means losing the edit, so decide which you want before you press anything — edit when the draft is nearly right, regenerate when the thread has moved on.
What the second attempt is told#
- The newer messages. This is the material difference. A draft written before the customer's follow-up arrived is answering an older question; regenerating is how the newer one gets answered.
- Whatever you wrote as guidance. Guidance on the thread is the supported way to say *shorter*, *do not quote the price*, *acknowledge the delay* — and it is read on every attempt, not only the next one.
- Memory at four tiers, narrowest first, so a contact-level instruction outranks a workspace-level habit.
- Grounding from Knowledge, under a fixed budget. A regeneration does not widen that budget, so an answer missing a fact needs the fact added, not another attempt.
What it is not told is that you disliked the first draft, beyond the fact of the rejection. If the reason is something Connect should apply in future, it has to be written down — as guidance for this thread, or as memory for this contact. A rejection on its own is a decision about one message.
When regenerating is the wrong move#
- The draft is nearly right
- Edit it. Your edit is what gets sent, and Connect does not write over it.
- It is wrong for the same reason twice
- The input is wrong, not the attempt. Add guidance, correct the memory, or supply the missing knowledge, then regenerate once.
- The facts are missing
- Grounding comes from Knowledge under a budget. Another attempt with the same sources produces the same gap.
- The wrong person is attached
- Fix the thread's person first. Everything written after a wrong match inherits it.
- It is held rather than bad
- A draft that is not appearing for approval may be in a mode that never asks. Read the mailbox's autonomy setting before rewriting anything.
Approving what comes back#
Read the new draft against the newest message on the thread, not against the previous draft.
Result You are judging whether it answers what was actually asked, which is the question the customer will apply.
Edit if it is close.
Result The edited text is sent unchanged; there is no further rewriting between your edit and the provider.
Approve.
Result The send runs through the same boundary a person's own send uses, and the result is recorded with the provider's acknowledgement. Until that arrives the state is *uncertain* rather than *sent*.
Questions#
Does regenerating lose my edits?
Yes. A regeneration replaces the draft, and anything typed into the previous one goes with it. Edit when the draft is nearly right; regenerate when the thread has moved on and the draft is answering an older message.
Why did the second attempt say almost the same thing?
Because it was given almost the same input. The material change between attempts is newer messages, new guidance, corrected memory or added knowledge. Without one of those, the second attempt is a rephrasing.
Does the customer see anything while a draft is regenerated?
Nothing at all. No provider has been handed a message at any point, so there is no delivery attempt and nothing in your sent folder — which also means a held draft is not a slow reply, it is no reply.