Build message state around the native Instagram thread

Messaging scope must come from approved access

Direct-message behavior depends on the eligible account, provider interface, application review, permissions, conversation state, and customer purpose. DewEngine has not cleared that combination. This design research refuses scraping and provider-rule evasion; anti-detection is rejected as a substitute for missing access. A released contract must identify which threads, participants, history, content types, reply actions, and events the authorized product actually exposes, leaving every other surface unavailable.

Anchor messages to account and thread identity

Each conversation needs a DewEngine public ID, connected account, native thread reference, participants as observed, timestamps, and synchronization state. Handles and display names can help a user recognize context but should not determine routing. Group or request-like states, if supported by the chosen product, need explicit provider extensions. A customer CRM link can decorate the thread without changing who owns the account or which native conversation receives a reply.

Preserve direction, reply context, edits, and gaps

A message model should distinguish inbound and outbound observations, provider creation time, edit or deletion evidence, content type, attachments, reactions where authorized, and native reply relationships. Webhook repetition must not create duplicates. Missing history should be represented as partial coverage rather than an empty authoritative transcript. Raw payloads can support adapter diagnostics under strict custody, but they should not leak into customer webhooks, application logs, or search by default.

Validate capability again immediately before reply

The application supplies the chosen account, thread, content, purpose, approval, and idempotency key. Admission checks permissions and policy, while a worker rechecks account health, thread eligibility, suppression, and provider pacing after acquiring the job. Acknowledgement is not identical to recipient delivery or reading. When an outcome is ambiguous, the command remains indeterminate until an authorized reconciliation can establish what happened.

Use replies as control signals, not just content

A verified inbound observation can update the product interface, stop pending automation, or reopen a human task. Event processing must retain workspace and account identity, validate origin, deduplicate immutable observation IDs, and tolerate delayed order. A notification may require a follow-up authorized read before it becomes canonical state. Unsupported event types and known gaps should be published so silence is never interpreted automatically as no response.

Exercise conversation failures with consented accounts

A release requires approved messaging access, eligible account fixtures, bounded history, participant and thread identity tests, every advertised content type, permission loss, message requests where relevant, throttling, ambiguous sends, duplicate callbacks, reply-driven suppression, reconnect, retention, deletion, and incident shutdown. Support tools must reveal command state without exposing unnecessary private content. Until those tests pass, this guide remains non-callable architecture.

• Document whether each event is authoritative, partial, or only a change hint
• Return unsupported content and thread states before attempting provider dispatch