Is a speech act limited to spoken language?

No. Written messages can ask, promise, warn, and perform other communicative actions.

Are speech acts and dialogue acts always identical?

The terms overlap, but dialogue-act schemes often include interactional functions such as grounding and turn management.

Can one sentence contain several acts?

Yes. A message can provide information and ask a question, or apologize while making a request.

AI Glossary / Graphs and symbolic AI / Intermediate

Speech act

Definition

A speech act is an action performed through an utterance, such as asking, informing, requesting, promising, or apologizing. The concept focuses on what a speaker or writer is doing with language, not only on the sentence's literal content. In AI, recognizing speech acts helps a dialogue system interpret the function of a message and choose an appropriate response.

What it means

The same topic can appear in different communicative actions. A message can ask whether a booking exists, request that one be created, or report that one has been created. Treating all three as statements about bookings misses the difference in what the conversation requires next.
Grammatical form offers clues but does not settle the interpretation. A question about ability can function as a polite request in context. Speech acts also occur in writing, including chat and email. The word speech does not restrict the concept to sound recordings or spoken-language recognition.

How it works

A system considers the utterance together with the conversation, participants, and task context. It can identify a likely act type and represent its content, such as a request involving a particular object or an answer filling a requested information slot.
Dialogue-act annotations often combine speech-act information with interactional functions such as acknowledgment and clarification. Their labels depend on the task and annotation scheme. A system should therefore distinguish its operational label set from a universal theory of human intention. Recognizing a likely request also remains separate from deciding whether the system can and should carry it out.

Three practical examples

A scheduling assistant can distinguish a question about availability from a request to create an appointment.
A customer-service analysis can identify complaints, information requests, and acknowledgments to study how a conversation progresses.
A robot interface can distinguish a report that a container is open from a request to open it, even when both mention the same container.

Think of it this way

Think of words as moves in a cooperative game: one move asks for information, another supplies it, and another accepts a proposal. Understanding the vocabulary alone does not reveal which move occurred. The analogy is limited because ordinary conversation has ambiguity, multiple simultaneous purposes, and social context that cannot always be reduced to a fixed set of game rules.

Worked example

Consider an original dialogue about a hypothetical booking system. In context one, an evaluator asks, Can this system reserve a meeting room? The intended act is a capability question. A suitable answer describes whether that function is supported; creating a booking would not answer the question correctly.
In context two, a user has identified Room Cedar and a time, then says, Can you reserve it for three o'clock? In that context, the utterance can function as an indirect request. The system still needs to resolve the date, duration, and reference to it before determining the next operational step.
Suppose the system responds, Do you mean Room Cedar tomorrow from three until four? This is a clarification or confirmation-seeking act. The user's reply, Yes, that room and time, confirms the proposed details in this stated dialogue. It does not mean that the booking has already succeeded.
Only after a separate successful booking operation could the system accurately report that the room is reserved. An utterance promising to try, an acknowledgment of the request, and a report of completion correspond to different conversational and operational states.
For an annotation exercise, label those four turns as REQUEST, CLARIFY, CONFIRM, and INFORM-COMPLETION under a deliberately simplified scheme. These labels are chosen for the exercise; another annotation framework might divide or name them differently. The worked result is the preserved sequence of meanings, not a universal tagset or a numerical claim about model accuracy.

Illustrative case study

In a fictional service-desk pilot, a bot responds to a message about a delayed delivery by repeating tracking information. A reviewer observes that the customer was asking for an explanation and expressing dissatisfaction, not merely requesting the latest status.
The team adds conversation examples that separate topic from communicative function and allows more than one relevant label where the scheme supports it. This case illustrates a design review, not a claim that speech-act recognition can read private intentions or that the revised bot achieved a measured satisfaction increase.

Common misconceptions and mistakes

Do not assume that a question mark always signals a request for factual information. Do not assume that identifying a command establishes authority to execute it. Language understanding and action policy are related but distinct responsibilities.
An acknowledgment such as okay can indicate that a message was heard without proving agreement with every implication. A single utterance can perform several functions, and context may leave the interpretation uncertain. Finally, a statement that an action happened is not itself evidence that the underlying operation succeeded.

Business use

Speech-act analysis can improve how teams specify conversational workflows and review failure cases. It encourages a distinction between detecting a subject, understanding the requested interaction, and recording actual task progress.
For evaluation, include messages with similar wording but different contexts. Check whether the system confuses requests with capability questions, promises with completed actions, or acknowledgments with confirmations. These distinctions often matter more to a usable conversation than recognizing a topic correctly while choosing the wrong next step.

Check your understanding

A system says, I will attempt to upload the file. Does that utterance establish that the upload succeeded?

Answer: No. It expresses an intended future action or commitment to attempt it. A later completion report should be grounded in the operation's actual result.

Related terms

Dialogue act
Pragmatics
Grounding
Clarification
Natural language understanding
Intent recognition
Conversation state
Indirect speech act

Learn next

Next, write three messages about the same document: one asking whether editing is supported, one requesting a specific edit, and one reporting that the edit is complete. Identify the evidence each interpretation needs. Then create a reply that acknowledges receipt without falsely implying that the requested edit has already happened.

Sources

AIMA original glossary sentences, speech act: https://raw.githubusercontent.com/aimacode/aima-glossary/master/sentences.txt Jurafsky and Martin, archived Chatbots and Dialogue Systems chapter: https://web.stanford.edu/~jurafsky/slp3/old_sep21/24.pdf Stolcke and colleagues, Dialogue Act Modeling for Automatic Tagging and Recognition of Conversational Speech: https://arxiv.org/abs/cs/0006023

Previous: Speculative multithreading Next: Speech analytics