# Inbox And Replies

<!-- BEGIN GENERATED: guide-map -->
## Guide map

Read only the section needed for the next decision. Line ranges are exact
for this generated runtime target.

| Section | What it covers | Lines |
| --- | --- | --- |
| [Purpose](#purpose) | Scope, ownership, and the central operating question. | 29-37 |
| [Use This When](#use-this-when) | Tasks and conditions that belong in this guide. | 38-42 |
| [Do Not Use This For](#do-not-use-this-for) | Boundaries and the correct routes for excluded work. | 43-52 |
| [Mental Model](#mental-model) | Concepts and state boundaries needed for correct operation. | 53-66 |
| [Choose A Path](#choose-a-path) | Decision hierarchy for selecting the right capability or provider. | 67-73 |
| [Primary SDK Paths](#primary-sdk-paths) | Operating guidance and contracts for this section. | 74-84 |
| [Supporting References](#supporting-references) | Capability, provider, policy, and runtime guides for this outcome. | 85-94 |
| [Preflight](#preflight) | State, authority, inputs, and readiness to verify before execution. | 95-111 |
| [Risk And Side Effects](#risk-and-side-effects) | Effects, approvals, cost, privacy, and retry boundaries. | 112-123 |
| [Canonical Operating Pattern](#canonical-operating-pattern) | The normal end-to-end execution sequence. | 124-134 |
| [Data Contracts](#data-contracts) | Required identities, fields, evidence, handles, and durable shapes. | 135-149 |
| [Verification](#verification) | Evidence required before reporting success. | 150-158 |
| [Troubleshooting](#troubleshooting) | Failure diagnosis and corrective routes. | 159-169 |
| [Related References](#related-references) | Adjacent boundaries and when to cross them. | 170-178 |
<!-- END GENERATED: guide-map -->

Inspect, triage, classify, and reply to email or LinkedIn conversations.

## Purpose

Inbox And Replies owns conversation truth from thread inspection through an
approved response. It helps determine what happened, what the latest message
means, whether a reply is needed, and which exact draft may be sent.

It keeps observation, interpretation, drafting, and delivery separate so a
classification mistake cannot silently become an external reply.

## Use This When

Use this guide for unread replies, thread inspection, classifications, reply
drafts, or an explicit response. Campaign creation is a separate outcome.

## Do Not Use This For

| Task | Owning Reference |
| --- | --- |
| Designing or activating a new outbound campaign | `outbound-campaigns.md` |
| Connecting mailbox capacity | `mailboxes.md` |
| Contact or company research outside the conversation | The matching search or enrichment outcome guide |
| Slack notification rules and delivery analysis | `notifications.md` |
| LinkedIn connection requests or public posts outside an existing reply context | `linkedin-outreach.md` |

## Mental Model

Treat a reply as a stateful decision chain:

1. Observation captures the complete relevant thread and current participants.
2. Classification records what the latest inbound message means and the
   evidence for that interpretation.
3. Drafting proposes a response under the sender's objective and constraints.
4. Approval establishes clear intent for the exact rendered message.
5. Delivery records the external effect and resulting thread state.

Threads can change between draft and send. Re-read current state immediately
before an external reply, especially after a delay or handoff.

## Choose A Path

1. Read the complete relevant thread before classifying or drafting.
2. Keep observation, classification, draft, and send as separate stages.
3. Require clear intent before an external reply.
4. Preserve conversation, message, sender, and delivery receipts.

## Primary SDK Paths

<!-- BEGIN GENERATED: primary-sdk-paths -->
| Primary function | Choose it when | Required inputs | Returns | Exact contract |
| --- | --- | --- | --- | --- |
| `vf.inbox.groups` | Use to list and triage conversation groups before opening a specific thread. | None | `inbox_groups` | [`inbox.md`](inbox.md) · installed SDK: `verbiflow/inbox.py:40-142` |
| `vf.inbox.group` | Use to inspect one conversation group's current participants, state, and summary. | `conversation_group_id` | `inbox_group_detail` | [`inbox.md`](inbox.md) · installed SDK: `verbiflow/inbox.py:214-249` |
| `vf.inbox.group_messages` | Use to page the exact messages and pending replies for a selected conversation group. | `conversation_group_id` | `inbox_messages` | [`inbox.md`](inbox.md) · installed SDK: `verbiflow/inbox.py:251-301` |
| `vf.inbox.send_reply` | Use only after the user confirms the exact real reply to send in the selected conversation. | `body_text`, `conversation_thread_id` | `inbox_reply_accepted` | [`inbox.md`](inbox.md) · installed SDK: `verbiflow/inbox.py:495-575` |
<!-- END GENERATED: primary-sdk-paths -->

## Supporting References

Open only the child that resolves the next material decision.

| Reference | Use it for | Kind |
| --- | --- | --- |
| [`inbox.md`](inbox.md) | Email reply inspection, triage, thread state, and explicit reply sends. | capability |
| [`linkedin.md`](linkedin.md) | LinkedIn reads, search, activity, conversations, messages, connections, and posts. | provider |
| [`safety.md`](safety.md) | Approval, confirmation, side-effect, purchase, and external-communication boundaries. | policy |

## Preflight

Before classifying or replying, establish:

- the channel, organization, sender account, conversation identity, and
  participants;
- the complete relevant message history, latest inbound message, timestamps,
  and unread state;
- campaign, contact, or account context that materially changes the response;
- the desired outcome and whether the user asked for triage, a draft, or an
  actual reply;
- any promises, legal/commercial constraints, attachments, or prior opt-out;
- whether another actor or automation has already responded.

If conversation identity or current state is ambiguous, stop before drafting a
message that could be sent to the wrong recipient.

## Risk And Side Effects

| Stage | Risk And Boundary |
| --- | --- |
| Read and inspect thread | Read-only, but conversation content may be sensitive. Keep output bounded. |
| Classify or draft | Local or draft work. Preserve uncertainty and do not mark delivery. |
| Save classification or draft | Reversible platform write. Verify conversation and message identity. |
| Send reply | External communication. Require clear intent for the exact recipient and rendered content. |

Sending may succeed even when the provider response is lost. Never retry an
ambiguous reply without reconciling the thread or delivery receipt.

## Canonical Operating Pattern

1. Resolve the canonical conversation and sender identity.
2. Read enough history to understand the latest inbound message in context.
3. Classify the message and state confidence, evidence, and uncertainty.
4. Decide whether no action, escalation, a draft, or a reply is appropriate.
5. Draft from the current thread and render the exact recipient-facing text.
6. Re-read the latest thread state before sending.
7. Send only when clearly requested, preserve the delivery receipt, and verify
   the resulting conversation state.

## Data Contracts

Preserve:

| Record | Required Meaning |
| --- | --- |
| Conversation | Stable channel-specific thread identity, organization, sender account, participants, and latest state. |
| Message | Stable message identity, direction, sender, recipients, timestamp, content, and attachment references. |
| Classification | Label or disposition, reason, confidence, evidence message, and review state. |
| Draft | Exact rendered text, intended sender and recipients, source conversation, and revision identity. |
| Delivery | Provider operation or message identity, attempted content revision, status, timestamp, and sanitized failure detail. |

Do not join conversations by display name or subject alone. Preserve provider
and platform thread identifiers through every stage.

## Verification

Verify thread identity, latest state, recipient, final rendered text, approval
boundary, and delivery receipt.

After a send, inspect the thread or official status surface to confirm the
message appears once under the intended sender. A successful draft or
classification is not delivery proof.

## Troubleshooting

| Symptom | Likely Cause | What To Do |
| --- | --- | --- |
| Classification contradicts earlier messages | Only the latest snippet was read | Load the complete relevant thread and classify again. |
| Draft targets the wrong person | Participant or thread identity was inferred from display text | Resolve canonical conversation, sender, and recipient identifiers. |
| Reply duplicates an existing response | Thread changed after drafting or an earlier send was ambiguous | Re-read current messages and delivery receipts before retrying. |
| Provider reports success but UI is stale | Delivery and sync are separate states | Inspect the official delivery status and then refresh thread state. |
| No reply should be sent | Opt-out, terminal disposition, or escalation condition applies | Record the disposition and stop at triage. |
| Draft lacks account context | Relevant campaign or CRM evidence was not joined | Retrieve only the missing context, then revise without inventing facts. |

## Related References

| If You Are Doing This | Read Next |
| --- | --- |
| Email thread inspection and explicit replies | `inbox.md` |
| LinkedIn conversations and messages | `linkedin.md` |
| Approval and external-effect boundaries | `safety.md` |
| Writing a grounded response | `copywriting.md` |
| Launching a new campaign instead | `outbound-campaigns.md` |
