Agent workflows
Keep a Gmail Agent's Reply in the Right Conversation
Separate Gmail thread IDs, message IDs and MIME reply headers. Build a draft-first reply workflow that preserves conversation context without silently expanding recipients.
A reply is more than matching the subject
Imagine an assistant asked to reply to a supplier's delivery update. Two conversations use the subject “October shipment.” One involves purchasing; the other includes a customer. Searching by subject and picking the first result could produce a perfectly written answer in the wrong conversation.
A useful email skill must identify which message the user meant before composing. It must also distinguish replying to that sender from replying to everyone in the conversation. Neither a matching title nor a plausible salutation resolves those choices.
This guide is for developers connecting an agent to Gmail and operators reviewing its drafts. The proposed workflow uses a draft as the handoff artifact, not as permission to send.
Methodology: follow identities through the operation
We reviewed Google's official threading, draft and sending documentation on October 3, 2026. We compared what identifies a conversation, what identifies a stored object and what describes reply ancestry inside the message. We did not connect a test mailbox, send email or measure delivery behavior.
The implementation recommendations below are an editorial design, not an assertion that an existing OpenAgentSkill listing implements them. Our earlier approval binding guide covers consent for exact content and recipients. Here the narrower question is whether the approved reply is attached to the intended conversation.
Keep four identifiers separate
Use explicit field names in the application's record:
| Field | Purpose in the proposed workflow |
|---|---|
| Gmail thread ID | Identify the selected conversation in the connected mailbox |
| Gmail message ID | Retrieve the particular stored message chosen as the parent |
| MIME Message-ID header | Identify the parent within email reply headers |
| Gmail draft ID | Locate the unsent draft being reviewed |
Do not copy the Gmail message resource ID into the MIME reply header just because both names contain “message.” Capture the actual parent headers instead.
Google's thread guide specifies three threading conditions: supply the target threadId, set compliant References and In-Reply-To headers, and match the Subject headers. Treat these as distinct checks. A conversation identifier alone is not the complete threading request.
Our recommended record also includes the connected account identity. This prevents an application from accidentally treating a saved conversation reference as portable across mailboxes. Preserve the original identifiers privately; do not expose a mailbox's contents in public logs.
Choose the parent before drafting
Retrieve the selected conversation and show enough context to establish intent: the parent sender, subject, date and a short relevant excerpt. If the user's request could refer to two messages, ask which one. Do not silently substitute the newest message when the user selected an earlier one.
Next, decide the recipient policy. “Reply” and “reply all” should be distinct operations in the agent's tool contract. Build the proposed To and Cc fields from the selected message and the intended operation, then show actual addresses for review. An address found inside quoted text is not a new recipient instruction.
For the fictional shipment example, a draft preview should say which supplier message it answers and whether purchasing colleagues remain copied. The preview should not force the user to infer this from a long conversation transcript.
If a new message arrives while the agent is composing, flag it as additional context. The application can ask whether the answer should change rather than automatically moving the reply to a different parent.
Preserve a draft without mistaking it for a sent message
Google's draft lifecycle documentation distinguishes the stable draft container ID from its underlying message ID, which changes when the content is replaced. Sending removes the draft and creates a sent message with a new ID.
Consequently, our proposed application tracks the draft ID for editing and a separate content revision for approval. A stable draft ID does not mean the reviewed body is still identical. If a person changes the draft in Gmail, retrieve it again before an authorized send and compare the approved fields.
Record the result of sending as a new operation outcome, not as an update saying the old draft message became the final message. This keeps support diagnostics understandable when someone asks which exact reply was sent.
Encode the approved message, then verify the result
The sending guide describes direct message sending and sending from drafts. Both use a MIME message represented through base64URL encoding in the raw field. Use a mail library for MIME construction rather than concatenating untrusted text into headers.
In our recommended workflow, the executor accepts only an approved draft revision. It checks the sender, recipients, subject, body, attachments and reply ancestry before dispatch. An instruction hidden in an incoming email cannot authorize a send or alter that approval record.
After the API returns, retain the returned message reference and verify the resulting thread association where the integration exposes it. Report “sent through Gmail” only from observed evidence; do not claim the recipient read it. If the request times out, investigate the uncertain outcome before creating another reply.
A small fixture matrix before production
Use a controlled mailbox and non-sensitive content. These are proposed checks, not results from an executed test:
- Two threads share a subject: selecting one must not reply to the other.
- A conversation contains three messages: choosing the middle message must preserve that parent decision.
- A draft is edited after preview: the prior approval must not silently cover changed content.
- A reply includes an extra Cc address: the review must show that changed destination.
- A send has an uncertain response: recovery must not automatically create a second message.
For each check, retain the selected parent reference, intended recipient set, draft revision and observed result. Avoid retaining full message bodies where a limited audit record is sufficient.
Limitations and skill selection
Correct Gmail threading does not guarantee that every recipient's email client displays the same grouping. It also does not provide delivery confirmation, authorization or duplicate-send prevention by itself.
When reviewing email automation candidates in the skills directory, ask whether they expose the parent message and the actual draft for inspection. A tool that only accepts a subject and generated body may be convenient, but it leaves important context decisions outside the visible contract.
The practical acceptance criterion is not “the agent wrote a convincing reply.” It is “the agent prepared the intended answer to the intended message, for the intended people, and preserved enough evidence to check what happened.”