DEV Community

Cover image for FullAgenticStack WhatsApp-first: RFC-WF-0035
suissAI
suissAI

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0035

#webdev #programming #rfc #opensource

RFC-WF-0035

Multi-Intent Parsing & Sequential Execution (MIPSE)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0003 (CCP), RFC-WF-0005 (CRCD), RFC-WF-0010 (IDS), RFC-WF-0018 (SMCL), RFC-WF-0034 (CSCP), RFC-WF-0022 (HAPF), RFC-WF-0015 (PPGP)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies Multi-Intent Parsing & Sequential Execution (MIPSE) for WhatsApp-first systems. MIPSE defines normative requirements for handling messages that contain multiple intents (e.g., “cancel order 204 and refund it”) by converting them into a sequence of independent command envelopes, each with its own confirmation/approval gates, idempotency behavior, evidence emission, and recovery semantics. MIPSE prevents unsafe “one confirmation approves many effects” behavior and standardizes orchestration of multi-intent operations under conversational constraints.

Index Terms— multi-intent, intent parsing, sequential execution, command batching, confirmations, idempotency, conversational safety.

I. Introduction

Users often issue compound requests in a single WhatsApp message: “cancel and refund”, “update address and reschedule delivery”, “pause subscription and send receipt”. In WhatsApp-first systems, multi-intent is unavoidable—especially with audio STT.

Without formal rules, implementations risk:

  • executing multiple mutations from a single ambiguous “yes”
  • partially executing a compound request with no recovery plan
  • losing audit granularity (what was approved vs inferred)
  • mixing idempotency boundaries (one key for many effects)

MIPSE standardizes the correct approach: split into multiple commands and execute sequentially under governance.

II. Scope

MIPSE specifies:

  • Multi-intent detection and canonicalization requirements
  • Command sequence model and execution ordering
  • Confirmation/approval semantics for sequences
  • Idempotency rules per command in the sequence
  • Evidence requirements for sequence execution
  • Failure handling and recovery options for partial completion
  • Context state interactions (CSCP)

MIPSE does not mandate NLP models; it defines the execution contract once intents are identified.

III. Normative Language

MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are normative.

IV. Definitions

Multi-Intent Message: A single inbound message expressing more than one executable intent.
Command Sequence: An ordered list of command envelopes derived from one message.
Sequence Root: A parent identifier linking commands in the same sequence.
Partial Completion: Some commands executed successfully before a later command fails or is rejected.

V. Design Goals

MIPSE MUST ensure:

  • G1. Safety: each mutating intent has its own confirmation/approval gates.
  • G2. Determinism: stable ordering and consistent sequence semantics.
  • G3. Auditability: evidence can reconstruct the entire sequence and decisions.
  • G4. Recovery: partial completion yields clear recovery/compensation options.
  • G5. Interop: sequences are representable in CRCD/EAS without custom hacks.

VI. Multi-Intent Detection and Canonicalization

A. Detection Requirement

Implementations MUST detect when a message contains multiple intents that map to distinct CRCD commands. Detection MAY be heuristic or model-based.

B. Canonical Split Requirement

When multiple intents exist, the system MUST produce:

  • a sequence_root_id
  • N independent command envelopes (command_id_1..N)
  • a stable order (Section VII)

The system MUST NOT merge multiple intents into one envelope unless CRCD declares an explicit “batch command” with its own schema and governance.

VII. Ordering Rules (Normative)

The sequence order MUST be deterministic. Implementations MUST choose one of:

  • Policy-defined precedence ordering per domain (recommended)
  • Explicit user ordering (when user enumerates steps)
  • Safety-first ordering where destructive/admin/high-impact commands are placed later unless explicitly required earlier

If ordering is ambiguous, the system MUST request clarification (disambiguation template), rather than guessing.

VIII. Confirmation and Approval Semantics

A. Per-Command Confirmation

Each state-mutating command in the sequence MUST require its own confirmation step (CCP), unless explicitly policy-declared safe auto-confirm applies for that command (auditable).

The system MUST NOT accept a single “yes” as confirmation for multiple mutating commands.

B. Batch Confirmation (Allowed Only With Explicit UI)

If the system offers a “confirm all” UX, it MUST:

  • list each command with target and impact preview
  • require explicit per-command acknowledgement OR a structured “approve list” confirmation containing the full list fingerprint
  • bind confirmation to sequence_root_id and each command_id

This feature SHOULD be restricted to privileged operators and governed by policy.

C. Approval (HAPF)

If any command requires approval (S3/R3 or configured S2):

  • approval MUST be per-command, OR
  • quorum approval MUST explicitly enumerate the set of commands approved (sequence fingerprint)
  • denial of one approval MUST not implicitly approve others

IX. Idempotency Rules for Sequences (IDS Alignment)

A. Per-Command Idempotency

Each command in the sequence MUST have its own idempotency_key. Keys MUST NOT be shared across different intents.

B. Sequence Root Tracking

The system MAY store a sequence_idempotency_root for trace grouping, but it MUST NOT be used to dedupe individual commands.

C. Duplicate Delivery Handling

If the original multi-intent message is duplicated (same message id delivered twice), the system MUST:

  • recognize duplicates at the message/context level (CSCP/CAMN), and
  • ensure commands already created/executed are not recreated/re-executed (IDS outcome replay behavior per command)

X. Evidence Requirements (EAS)

Evidence artifacts for each command MUST include (directly or via extensions):

  • sequence_root_id
  • sequence_index (0..N-1)
  • originating message_id

This allows auditors to reconstruct the sequence and verify that each mutation had its own confirmation and authz decisions.

XI. Failure Handling and Recovery

A. Partial Completion Behavior

If command k fails after commands 1..k-1 executed, the system MUST:

  • report partial completion clearly
  • provide recovery options for the failed command (retry/reprocess)
  • provide compensation options where applicable for previously executed commands (RCP), if the user wants to “undo the whole plan”

B. Atomicity Prohibition

The system MUST NOT claim atomic all-or-nothing behavior for arbitrary multi-intent sequences unless it can prove it with transactional boundaries (rare). Default is best-effort sequential with governed recovery.

C. Recovery Suggestions

OoC SHOULD present the sequence view:

  • executed steps
  • failed step and reason
  • next available actions (retry, compensate, cancel remaining)

XII. Context Interaction (CSCP)

When a multi-intent message is detected:

  • context MUST store pending_sequence_root_id
  • context MUST store which command is currently awaiting confirmation
  • “yes/no” replies MUST apply only to the currently pending command, not the whole sequence

XIII. Conformance Requirements

An implementation is MIPSE-compliant if:

  1. it splits multi-intent messages into multiple command envelopes
  2. each mutating command has its own confirmation/approval gates
  3. idempotency is per-command and duplicates do not duplicate effects
  4. evidence links commands to a common sequence_root_id
  5. partial failure yields clear recovery/compensation options

XIV. Security Considerations

Multi-intent is a major safety hazard in conversational systems because it encourages ambiguous approvals. MIPSE prevents privilege escalation via “one yes to many actions” and reduces blast radius by forcing per-command gating and evidence. It also reduces STT ambiguity exploitation by isolating confirmations.

XV. Conclusion

MIPSE makes multi-intent safe and auditable by converting compound messages into governed command sequences. This preserves the WhatsApp-first invariants: canonical envelopes, per-command confirmations, strict idempotency, evidence-backed execution, and recoverable partial failures—without relying on dashboards.

References

[1] RFC-WF-0003, Conversational Command Protocol (CCP).
[2] RFC-WF-0005, Command Registry & Capability Declaration (CRCD).
[3] RFC-WF-0010, Idempotency & Delivery Semantics (IDS).
[4] RFC-WF-0018, State Model & Command Lifecycle (SMCL).
[5] RFC-WF-0034, Conversation State & Context Persistence (CSCP).
[6] RFC-WF-0022, Human-in-the-Loop Profiles & Approval Flows (HAPF).
[7] RFC-WF-0015, Policy Packs & Governance Profiles (PPGP).

Concepts and Technologies

Multi-intent detection, command sequencing, per-command confirmations, sequence root IDs, per-command idempotency, partial completion handling, governed compensations, context-bound confirmations, evidence-linked sequences.

Top comments (0)