How Superintelligence Works | Agent Email Threading

Did you know that two emails with the same subject do not necessarily belong to the same conversation? An AI agent preparing a parent reply, teacher follow-up or school notice can accidentally attach its answer to the wrong thread if it relies only on the words after Re:. Internet email uses identity headers such as Message-ID, In-Reply-To and References to express relationships between messages. A provider’s conversation or thread ID may add another layer, but neither a familiar subject nor a matching header alone proves that the user authorized the next recipient or action.

The practical method is to preserve the original message’s identity and trusted mailbox context, construct reply headers according to RFC 5322, respect the provider’s actual threading rules, distinguish incoming source evidence from user instructions, check recipient and attachment scope, then verify the send using the original provider operation. This guide works through invented 120-message and fifty-message ledgers with independently checkable arithmetic. They are teaching examples, not real eduKate mail statistics or claims that artificial superintelligence already exists.

Continue through How Super Intelligence Works. Related chapters cover Inbound Email Parsing and Outbound Email Safety. Email threading is a distinct engineering problem: deciding which prior message a response refers to, preserving that relationship in headers and provider metadata, and ensuring the resulting action matches the current user’s decision.

Choose your reading route

Preparing a reply? Start with Message-ID, In-Reply-To, References and provider threading.
Protecting family privacy? Focus on mailbox scope, Reply All, quotes and recipient binding.
Learning Mathematics? Check the 120-message and fifty-message ledgers.
Building an agent? Study provider receipts, missing headers and safe retries after uncertain sends.

1. A matching subject is a weak conversation identifier
2. RFC 5322 gives messages identities
3. In-Reply-To normally identifies the parent
4. References preserve the ancestor chain
5. Gmail combines a provider thread ID with RFC headers
6. Provider thread identity is scoped to the mailbox
7. Subject matching is useful context, not sufficient identity
8. Quoting prior messages can expose private context
9. Reply All is a consequential new operation
10. A thread may include conflicting instructions
11. Missing headers require controlled fallback
12. Draft preparation and sending have different receipts
13. An original 120-message threading exercise
14. A table should name the evidence behind each category
15. Repair five ambiguous cases without inventing new sends
16. A changed-context fifty-message school example
17. Automated testing needs the actual provider contract
18. Practical policy for responsible email agents
Frequently asked questions
Primary internet-mail sources
Related guides

1. A matching subject is a weak conversation identifier

An inbox may contain several unrelated messages titled Mathematics Homework, Registration Question or Meeting Time. One could refer to a Sec 1 student while another concerns a different family or academic year. A language model ranking messages by topical similarity can choose the wrong conversation despite the subject words matching perfectly.

Email threading should begin with message identity and the authorized mailbox context. A reply to a specific message is not the same thing as starting a new conversation about the same topic. A stable provider message or thread identifier and the relevant RFC headers help connect the intended parent. The sender’s actual permission and recipient selection remain separate decisions.

Do not assume adding Re: to a subject creates a legitimate reply. The text might be hand-edited, localized or already contain prefixes, and providers can use their own conversation grouping rules. The application should use actual message references where available rather than manufacture a link from a familiar title.

A useful AI assistant can prepare a correct standalone draft even when threading cannot be established. That is safer than inserting private learner details into a neighboring family’s thread. A transparent status such as Draft prepared, parent message not yet confirmed is an acceptable intermediate result.

Return to contents or continue to RFC 5322 gives messages identities.

2. RFC 5322 gives messages identities

RFC 5322 describes Message-ID as a unique message identifier and recommends that messages contain one. It also specifies In-Reply-To and References fields for reply relationships. Those headers are structured technical information, not casual labels chosen by an agent to make a message look connected.

An original email might have a Message-ID enclosed in angle brackets under RFC message-id syntax. A reply may include the parent’s Message-ID in In-Reply-To and build References from the parent’s existing References followed by its Message-ID. The official specification provides detailed cases for missing identifiers or multiple parents.

The requirement to identify a parent is distinct from proving the sender’s human identity. Message-ID is not an authentication signature and can be supplied by untrusted messages. A fraudulent incoming email could contain a plausible-looking reference. Account trust, current authorization and any required provider verification remain separate.

Treat malformed or missing IDs honestly. Some messages arrive without the recommended header, and providers can still display them as conversations under their own rules. A conservative agent should preserve source evidence and not invent a supposedly official identifier merely to force a thread link.

Return to contents or continue to In-Reply-To normally identifies the parent.

3. In-Reply-To normally identifies the parent

For a straightforward one-parent reply, RFC 5322 says In-Reply-To contains the Message-ID of the message being answered. The relationship can let clients construct a conversation chain beyond a subject match. The new reply receives its own distinct Message-ID rather than copying the parent’s identity.

An agent should obtain the actual parent identifier from the trusted retrieved message object. It must not select the first email with the same subject when the user referred to a specific dated message. The relevant mailbox account, sender, recipient, date and original content all contribute to resolving the intended parent.

Multiple parent messages are possible under the syntax, but RFC 5322 notes complications and discourages some ambiguous References constructions. A general-purpose model should not improvise a multi-parent thread merely because two messages mention the same task. Qualified clarification or separate replies may be safer.

The header itself does not prove the send took effect. A draft can contain perfectly formed In-Reply-To while no provider message was ever transmitted. Read the mail provider’s actual result and distinguish Draft, Accepted and Verified Sent where the API supports those states.

Return to contents or continue to References preserve the ancestor chain.

4. References preserve the ancestor chain

RFC 5322 describes References as the parent’s References followed by the parent’s Message-ID where available. This can preserve the ancestry of a discussion across replies. A single message ID may point to the immediate parent while the chain helps the client understand the broader conversation.

If a source message’s References chain is truncated, malformed or inconsistent, the agent should not invent missing ancestors as historical facts. A model may suggest a plausible connection based on topic, but the trusted mailbox data determines which identifiers were actually present. Preserve uncertainty where the relationship cannot be established.

Use stable source IDs in the application’s task ledger. A child message created after a reply should link to the intended parent and the authorized thread. If the user later changes which email they want to answer, a previous draft’s references may no longer apply and should be revalidated.

History can include forwarded content or quoted messages that mention unrelated people. Those quotations are not necessarily additional parents for RFC threading, and they do not grant permission to copy the whole history to a new recipient. Keep message ancestry and confidential quote scope as separate checks.

Return to contents or continue to Gmail combines a provider thread ID with RFC headers.

5. Gmail combines a provider thread ID with RFC headers

Google’s Gmail API threading guide says that for adding or sending a message within an existing thread, the requested threadId must be set, References and In-Reply-To must comply with the relevant RFC standard, and Subject headers must match. This is a documented provider-specific contract rather than a guarantee that any email API uses exactly the same rules.

An assistant that knows only Gmail’s threadId should not assume it can omit the reply headers and still obtain the intended result. Conversely, inserting RFC header fields into a draft without specifying the required provider metadata can fail to join the desired Gmail conversation. The application adapter needs the actual platform contract.

The subject condition creates another subtlety. An agent rewriting a subject for clarity might inadvertently cause the provider to treat the message as a new thread, even though its References chain points at the original. The user may want a new conversation, but that decision should be explicit rather than an accident of model wording.

Thread matching is not an authorization rule. A draft could satisfy all three provider requirements while carrying private information to a recipient who was not approved. The protected sending service still verifies the actual destination, attachments, current user permission and operation identity.

Return to contents or continue to Provider thread identity is scoped to the mailbox.

6. Provider thread identity is scoped to the mailbox

A provider’s internal thread identifier should be understood in the context of its account, workspace and API. A numeric or opaque ID from one mailbox is not a universal email identifier that grants another account access. The user-facing assistant should obtain it through the authorized connected mailbox rather than trust a free-form ID pasted into a document.

Some providers group messages heuristically or allow conversations to appear differently across interfaces. A threadId returned by one service is evidence about that service’s grouping, not a universal RFC statement about every other mailbox client’s view. Preserve the actual provider and account identity in the task.

Shared mailboxes introduce additional boundaries. An editor may be authorized to draft a reply but not to send from the principal’s address, or may have access to one folder but not another. The model should never select a more powerful account solely because that account has a similarly titled thread.

Replying to a thread across a changed sender identity may alter what the recipient sees and which reply address is used. These are actual communication decisions. Check From, Reply-To, To and any delegated Send As permission under the provider’s current rules before making an external effect.

Return to contents or continue to Subject matching is useful context, not sufficient identity.

7. Subject matching is useful context, not sufficient identity

The subject helps humans understand a discussion and may be an explicit provider threading condition. Yet many conversations share a generic subject, and a single discussion’s subject can change over time. Use it alongside exact message and provider references, not as a unique key for deciding which parent’s confidential details belong in a reply.

A fictional teacher receives two emails titled Homework Feedback. One belongs to Cedar School and the other to Willow School. If an agent simply chooses the latest subject match, it may prepare a technically coherent response about the wrong pupil. Exact message lineage and current authorized account scope reduce that risk.

Do not treat sender display names as unique either. Two people can share a name, and address fields may be misleading. Authentication and mailbox identity come from the provider and appropriate security systems. The content of an incoming email remains untrusted until the legitimate user decides what to do with it.

When a provider cannot establish the intended thread, a safe draft may be preferable to immediate sending. An agent can ask the authorized user to confirm the parent message or produce a separate new email. The user should not be penalized for the system refusing to invent missing conversation evidence.

Return to contents or continue to Quoting prior messages can expose private context.

8. Quoting prior messages can expose private context

A reply may automatically quote earlier conversation text. That can help the recipient follow the discussion, but can also expose sensitive learner information when another recipient is added or an attachment is forwarded. Thread correctness and privacy minimization must be checked together, especially when an AI agent composes a response from a long conversation.

Build a recipient-bound content approval. The user might authorize a reply to a named teacher without authorizing a Reply All to several parents. A draft’s quoting behavior should reflect that decision. A model’s assumption that everybody already saw the previous thread can be wrong when new recipients were added.

Separate retrieved correspondence from instructions. An earlier message may say ‘please send this to everyone,’ but it is lower-trust source content relative to the current authorized user’s decision. The assistant should not treat quoted text as a new direct command to expand distribution.

Review attachments too. A thread may contain an older marked assignment that the agent does not need to reattach. A safe reply can summarize the requested facts without distributing all historical files. This improves readability while reducing the chance of sending confidential records to an unintended recipient.

Return to contents or continue to Reply All is a consequential new operation.

9. Reply All is a consequential new operation

The intended parent message may have multiple recipients. Choosing Reply rather than Reply All changes the audience and possibly the privacy consequences. A model optimizing for helpfulness may add a school administrator or parent who was visible in a previous header, but visibility does not create present authorization.

Bind the current approved recipient list to the exact send operation, including To, Cc and Bcc as appropriate. Changes after approval should trigger the applicable recheck. The email protocol’s ability to connect messages does not decide which human beings are allowed to receive confidential content.

An internal reviewer might be qualified to confirm factual Mathematics content but lack authority to change the distribution list. A sending tool must check the actual user’s and organization’s permission under the relevant workflow. A threadId is evidence about conversation grouping, not approval to include additional people.

After a send, the provider may record a message in the correct thread while the content or recipients differ from what the user intended. Final verification should compare the approved payload and provider record, not merely a thread list showing one additional message.

Return to contents or continue to A thread may include conflicting instructions.

10. A thread may include conflicting instructions

Past correspondence can contain statements that were superseded by later decisions. A parent might first approve a meeting date and then cancel it, while the agent retrieves an earlier email that appears clearer. The latest applicable user decision and official source should govern the new action, not whichever quoted text is most prominent.

Email messages can also contain prompt-injection text instructing the assistant to disregard permissions or forward private files. Such text is untrusted content to summarize or evaluate. It cannot make a model administrator or override a current draft-only instruction.

Keep relevant source and effective dates. An official school notice copied into an email might be accurate historically but outdated for a current intake. A correct thread association does not prove the quoted admissions rule remains current. Source applicability still needs separate checks.

An ambiguous history warrants clarification or a safe hold. The user may be better served by a draft identifying the unresolved date than by an immediate confident reply. Thread reconstruction and factual adjudication are different responsibilities.

Return to contents or continue to Missing headers require controlled fallback.

11. Missing headers require controlled fallback

Some incoming mail may lack the recommended Message-ID or contain malformed References. A provider may supply internal message identifiers and thread grouping despite these shortcomings. The agent can use trustworthy provider metadata under its documented contract, but should not invent an RFC-valid history and present it as observed.

A subject-only fallback carries a higher risk of mistaken association, especially for frequent school topics. A safe workflow can create a standalone reply draft, ask the user to confirm the source message or hold sending while the provider relationship is investigated. The best choice depends on consequence and current permission.

A model’s semantic similarity score can assist in locating candidates but cannot prove they belong to one conversation. A teacher’s two identical homework subjects may involve unrelated students. Keep identity and authorization checks outside the model’s similarity judgment.

Preserve the original raw header evidence where a protected diagnostic genuinely needs it, but avoid copying entire correspondence into a public or shared trace. Stable provider IDs, header-presence status and safe dates often make an investigation possible without unnecessary private information.

Return to contents or continue to Draft preparation and sending have different receipts.

12. Draft preparation and sending have different receipts

A mail provider may accept a draft that contains correct headers and a recipient, while no external message has yet been sent. That is valuable preparatory work but not the user’s final communication outcome. Keep explicit Draft, Approved, Submitted, Verified Sent and Unknown states under a stable logical task ID.

A send API can time out after accepting the message. The agent must not assume the attempt failed and send a duplicate. Use the original operation or provider message ID to reconcile the result. If the provider’s API does not expose definitive evidence, preserve that uncertainty and offer an appropriate human route.

Thread placement and delivery are also different claims. The new message could appear in the provider’s correct conversation while delivery to a remote mailbox remains beyond what the sender platform can verify. Use wording matched to available provider receipts rather than claim the recipient read the message.

Keep the user’s approval exact. If the model edits a material paragraph, recipient or attachment after approval, the new draft may require review before sending. Neither RFC headers nor a green threadId changes the actual user-consent boundary.

Return to contents or continue to An original 120-message threading exercise.

13. An original 120-message threading exercise

Build a fictional Cedar Correspondence Desk test with 120 proposed reply operations. Seventy have their intended parent and provider conversation correctly identified and lead to verified permitted outcomes. Eighteen are held because required identity evidence is ambiguous. Fourteen are blocked when subject-only similarity points at the wrong conversation. Ten have a wrong-recipient or expanded Reply All request appropriately refused. Eight have unknown provider send outcomes.

The exclusive categories total 70 + 18 + 14 + 10 + 8 = 120. Verified permitted results are 70 ÷ 120 ≈ 58.33%; ambiguous association is 15%; blocked subject-only false pairing is about 11.67%; recipient refusals are about 8.33%; unknown effects are about 6.67%. These are deliberately selected teaching cases, not an actual email accuracy or security rate.

A dashboard treating the fifty nonverified cases as failures of the language model would hide correct privacy protection. Refusing to associate a subject-only match with another family is desired behavior. On the other hand, the eight unknown sends cannot be counted as successes merely to improve the result. Their actual provider operations need reconciliation.

The denominator here is proposed reply operations, not received email messages or distinct families. One long thread can generate multiple legitimate replies, and one uncertain send can lead to several provider attempts. Stable task IDs keep user outcomes separate from transport and troubleshooting activity.

Return to contents or continue to A table should name the evidence behind each category.

14. A table should name the evidence behind each category

A useful disposition table gives the chosen parent Message-ID, provider thread ID where applicable, approved recipient scope and final provider result. A correctly associated reply requires more than an identical subject; it must match the intended source message under the actual mailbox and task contract.

Ambiguous cases may need qualified user confirmation, while wrong-recipient cases require a corrected approved target. Unknown sends need the original provider operation inspected. These next actions are not interchangeable, so a general Send Again button can create serious mistakes.

Privacy-aware logs should store opaque operation and provider IDs rather than full family correspondence when possible. A qualified user may inspect the actual source message through their connected mailbox. Debugging does not need to create a second unrestricted archive of every pupil’s private email.

Keep timestamp semantics precise. An email received on one day can be answered later, and a provider thread grouping can change independently of the historical message header. Report what was observed at the relevant cutoff rather than pretending the application always had the final answer.

Return to contents or continue to Repair five ambiguous cases without inventing new sends.

15. Repair five ambiguous cases without inventing new sends

Suppose five of eighteen ambiguous thread associations are resolved through trusted provider and user evidence, and their drafts are then correctly approved and sent once. Verified results rise from seventy to seventy-five, while ambiguous associations fall from eighteen to thirteen. Other categories stay fourteen subject-only blocks, ten recipient refusals and eight unknown sends.

Verify 75 + 13 + 14 + 10 + 8 = 120. Verified share becomes 75 ÷ 120 = 62.5%. That is a later snapshot of the same invented operations, not five new parents or a universal improvement in email reliability.

A correct association does not authorize sending automatically. The exercise assumes the five operations also gained valid current approval and actual provider completion evidence. Without those facts, they would remain Draft or Awaiting Authorization despite knowing the parent message.

Preserve the old report alongside the new one. The original ambiguous status was truthful at its cutoff; later evidence resolved it. Changing past records to say the association was always known would obscure the reason the agent safely held the message.

Return to contents or continue to A changed-context fifty-message school example.

16. A changed-context fifty-message school example

Transfer the method to fifty fictional school messages: thirty have verified correct thread association and authorized result, eight require clarification, six are blocked due to subject-only false matches, four are denied for changed recipients and two have uncertain send outcomes. Their sum is 30 + 8 + 6 + 4 + 2 = 50.

Verified share is 60%, clarification 16%, blocked false matches 12%, recipient denials 8% and unknown sends 4%. These percentages teach how to distinguish the categories; they are not measured school-support statistics or proof of one email provider’s behavior.

Now two families separately email the school with the subject Secondary Mathematics. The agent must not treat them as one thread because their words match. Trusted message ancestry and mailbox context identify the intended parent, while account permissions prevent mixing private learner information.

Finally, a send times out after a provider may have accepted it. The assistant should inspect that original message ID or provider operation before sending another. A correct thread association is still not evidence that a second external send would be safe.

Return to contents or continue to Automated testing needs the actual provider contract.

17. Automated testing needs the actual provider contract

Create synthetic mail objects with distinct Message-IDs, correct References chains, missing headers and identical subjects across tenants. Verify which source message a proposed reply actually references. A test should fail if the agent selects another family’s thread even when its drafted words are grammatically correct.

Include a provider-specific Gmail case with a valid threadId but missing or mismatched reply headers. The documented Gmail threading requirements should be checked as one contract, not inferred from RFC syntax alone. Then include a legitimate correctly configured reply as a positive control.

Test recipient changes and Reply All separately. A subject or thread reference can be correct while the actual destination is unauthorized. The protected service must reject the send before external effect. A model’s apology after sending to the wrong person is not a passing security test.

Test an ambiguous provider acknowledgement as well. Inspect whether the underlying message was submitted once and suppress duplicate retries. The correct oracle is the simulated or actual trusted mailbox state, not the agent’s generated statement that it thinks the send worked.

Return to contents or continue to Practical policy for responsible email agents.

18. Practical policy for responsible email agents

Begin with one authorized mailbox and a narrow capability such as Prepare Reply. Retrieve the original message object, preserve provider ID, Message-ID and relevant References, then construct the draft under the actual provider contract. Keep current recipient and content approval distinct from technical threading.

Before sending, show the user the actual To, Cc, Bcc, subject and any quoted or attached confidential material. A Reply All change or different parent message may require renewed confirmation. The agent should not silently expand an audience because the conversation looks collaborative.

On send, persist the original operation identity and check the provider result. An unavailable provider or ambiguous timeout should lead to a bounded recovery path, not a fresh new send by default. If necessary, a protected human review can settle the recipient and content before further action.

The durable lesson is that an email thread is a relationship established through actual message identity and provider rules, not a word-processing convention. Reliable AI correspondence respects ancestry, current permission and externally verified effects, helping teachers and families receive the right information without accidental cross-conversation disclosure.

Return to contents.

19. A thread can be correctly linked but wrong for the task

Suppose a parent asks an agent to answer the latest question about next term’s Mathematics group. A previous message in the same thread contains last year’s session schedule. The reply headers can be fully correct while the response’s factual content remains stale. Thread association establishes conversational lineage, not which source revision currently governs the question.

Check the actual latest user request, relevant source date and official issuer before drafting a material claim. A reply may legitimately quote an earlier historical decision while explaining a newer policy. The model should not infer that the last quoted timetable is current simply because it appeared in a correctly threaded email.

After a content correction, verify that the recipient and actual parent message are still the intended ones. The new text might change a deadline or an offer’s scope, requiring fresh human review even though the RFC headers remain unchanged.