Speech acts: requests, reports and commitments in support dialogue

Last updated: 6 Oct 20265 min read

tutorial

The same action words can report an event, request help or promise future work. Classify the utterance function before updating workflow state.

Label the act, not just the subject

“Please roll back the gateway” is a request; “we rolled back the gateway” reports a past action; “I will roll it back” is a proposed commitment. All three mention rollback, so an intent classifier that sees only topic words will collapse them. Record speaker, turn ID, act, target span, tense and source revision. Dialogue state can use the act to update pending tasks without mistaking a report for authorization.

Use preceding turns as evidence

“Yes, do that” depends on an earlier proposal; alone, it has no safe action target. Attach it to a specific antecedent turn and verify who is authorized to approve that action. A customer asking for an account change does not mean the assistant may execute it. If the prior turn is missing or ambiguous, keep the act unresolved. Reference chains help identify “that,” but a resolved pronoun still does not confer permission.

Keep commitment and execution apart

An agent’s promise to investigate is a commitment, not proof that the investigation happened. Track promised action, owner, due condition and later completion evidence as separate records. A bot should never mark a task complete merely because it generated “I’ll check.” If a speaker retracts a commitment, preserve both turns and the retraction relation. Discourse relations can represent correction and contrast without rewriting history.

Evaluate downstream mistakes

Score act labels, target-turn links, unauthorized action attempts, missing commitments and false completion. Include short acknowledgments, reported speech, sarcasm, copied transcripts and overlapping speaker turns. Separate classification quality from workflow safety: a mostly correct model may still trigger a costly action on one wrongly classified report. The commitment audit project stages high-risk acts for review before any external action.

Implementation

def stage_dialogue_act(turn_id, speaker, act, target_turn=None):
    allowed = {"request", "report", "commitment", "approval", "unresolved"}
    if not turn_id or not speaker or act not in allowed:
        raise ValueError("turn, speaker and valid act are required")
    if act == "approval" and not target_turn:
        return {"state": "review", "reason": "approval-target-missing"}
    return {"state": "proposed", "turn_id": turn_id,
            "speaker": speaker, "act": act, "target_turn": target_turn}

assert stage_dialogue_act("turn-47", "agent-82", "report")["act"] == "report"
assert stage_dialogue_act("turn-91", "customer-47", "approval")["state"] == "review"

Performance and operating cost

The staging check is O(1) per turn. Linking a turn to one of h earlier turns can be O(h) without an index, while model inference has its own cost. Human review should focus on acts that can create an external commitment or action. A label is evidence about language use, not authorization from an account system.

Common Mistakes

Treating every action verb as an instruction to execute.
Marking a promised task complete without later evidence.
Accepting “yes” without a uniquely identified prior proposal.
Reporting act accuracy while ignoring unauthorized workflow transitions.