01
Hard boundary
Automation cannot create permission
A workflow engine can schedule a review or prepare context, but it cannot make an unauthorized message acceptable. The full LinkedIn account surface remains decision-gated because lawful access and provider authorization are unresolved. DewEngine will not implement bulk auto-messaging, access-control bypass, reverse engineering, anti-detection, or human-mimicry tactics. A product plan must survive if LinkedIn actions remain unavailable.
- Tie every proposed action to an approved sender and purpose
- Treat the provider gate as a release dependency, not an engineering workaround
02
Workflow states
Separate draft, approval, dispatch, and outcome
A message begins as customer-owned content with a recipient reference, conversation context, and intended sender. Approval makes it eligible; it does not prove dispatch. A durable command records the decision before a provider attempt, then distinguishes acknowledged, rejected, throttled, and indeterminate results. This state model prevents a timeout from being reported as success or blindly retried into a duplicate message.
- Persist the approval actor and content version
- Never turn an unknown provider outcome into automatic resend
03
Recipient context
Check relationship and conversation state at action time
A previously prepared message can become inappropriate when the recipient replies, declines, changes role, or is contacted by a colleague. The execution gate should re-read suppression, ownership, recent conversation, relationship state, and account health immediately before dispatch. A CRM sequence is advisory; the connected account and current policy determine whether an action may proceed.
- Cancel stale queue items after a reply or manual intervention
- Show the exact account that would perform the action
04
Pacing
Use conservative budgets, not behavioral camouflage
Provider feedback, explicit limits, account status, and customer policy should reduce or stop work at the relevant scope. Budgets belong per account and sensitive action, with a global kill switch and an audit trail. Random delays intended to imitate a person are not a compliance control. Safe pacing is transparent, deterministic enough to explain, and subordinate to provider rules and user approval.
- Stop on restriction, challenge, or authorization loss
- Expose remaining product budget without claiming a provider quota
05
Conversation loop
Route replies back to accountable people
A messaging product is incomplete if it optimizes sends but loses responses. Inbound observations would need account-scoped deduplication, conversation association, unread ownership, and a clear handoff to the CRM or ATS. A reply should pause incompatible scheduled actions. Automated classification may assist triage, but it must preserve the original message, confidence, and a human correction path.
- Make reply ownership and response deadline explicit
- Keep raw personal content out of unnecessary logs and metrics
06
Release proof
Test restraint as carefully as sending
A credible acceptance suite covers duplicate approval, changed drafts, concurrent workers, timeout after provider dispatch, rejected recipients, throttling, expired sessions, account restriction, reply cancellation, tenant isolation, deletion, and the kill switch. It also requires qualified legal review, provider or partner authorization where needed, consented real-account conformance, and clear customer disclosures. Until then, the architecture is educational research only.
- Prove that suppression wins every race
- Prove that one approval cannot produce two provider actions