What Is Slot Filling? The Named, Typed Boxes a Bot Fills Before It Can Act (2026)

Quick answer: A slot is a labeled box with a type on it. Before a bot can book your table it needs a date, a time and a party size, and each of those is a slot that is either empty or holds a value the bot has accepted. Slot filling is everything that happens to get a value into that box: recognizing it in a sentence the user typed, taking it from a tapped button, inheriting it from earlier in the conversation, or asking a direct question and re-asking when the answer does not parse. The word is a practitioner's word, and the practitioners do not agree on it. Amazon Lex and Rasa call these things slots; Google calls them parameters and calls the process form filling. More usefully, the engines do not behave the same way on the one behavior most guides present as standard, and one of them documents it as unreliable.

A slot is a contract, not a variable

The reason a slot is worth a separate word from "variable" is that a slot carries rules with it. Amazon's Lex documentation lists what you configure per slot, and the list reads less like a storage declaration than like a small specification: a name and description, a slot type that "defines the list of values that a slot can accept," a prompt that is "a question posed to the user to gather information," the number of retries and the wording variation used for each retry, a success response and a failure response, a validation hook, and whether the slot is required at all.

Two of those are worth pulling out, because they are the ones a builder's UI is least likely to put in front of you.

The first is the retry ladder. Lex re-elicits a slot "until it understands a value or until it exceeds the maximum number of retries that you configured," and lets you attach a Lambda function after each attempt to try to resolve messy input into a valid value. Google's form filling has the same shape with a different default: if a required parameter is not provided after a prompt, "the initial prompt will be repeated unless a different behavior is defined in the reprompt handlers," and reprompt handlers exist specifically "to alter the prompt when the end-user fails to provide a value after the initial prompt, and to transition to another page after N failed attempts." A bot that asks the same question in the same words four times is not exhibiting a language problem. It is a bot whose author never wrote the second prompt.

The second is redaction. Dialogflow CX lets you mark a parameter Redact in log, after which "end-user runtime parameter data" is redacted from logs and from Google's internal storage, appearing instead as $parameter-name_redacted. Slots are exactly where card numbers, dates of birth and phone numbers land, so the ability to mark one as sensitive is a real procurement question. It is also one we have never seen a vendor advertise: no review in our catalog of fifteen platforms records a per-slot redaction control, which is an absence from vendor pages rather than a tested negative. Google's page carries its own limitation worth knowing before you rely on it: "At this time, only text user input can be redacted." Our PII handling checklist covers the wider obligation.

The trick every guide teaches is documented as unreliable

Here is the finding that changed how we write about this, and it required correcting three of our own pages.

The standard advice, ours included, is that a bot should ask for one thing but accept everything: "table for four at seven on Friday" ought to fill three slots in a single message so the bot can skip the questions it no longer needs. It is good advice as a design goal. It is not a platform guarantee.

Google's parameters documentation states the limit plainly: "If the end-user provides multiple parameter values in a single conversation turn during form filling, usually only one form parameter is set." Multi-fill happens only when the same parameters are also defined as intent parameters in an intent referenced in the same flow, and even then Google adds the sentence that matters: "This behavior is an optimization of NLU which may or may not occur during a conversation, so this behavior shouldn't be relied on."

The practical version: write the batched-answer case into your test set, run it, and watch what actually lands. Our QA testing protocol covers building that regression set, and the conversation flow simulator is a quick way to see how a matcher scores an ambiguous message before you commit to a design.

Required and optional slots are not mirror images

Both Amazon and Google document the same asymmetry, and it surprises people who expect "optional" to mean "asked for last."

Optional slots are never asked for. Google is explicit: "Optional parameters won't trigger prompts." Amazon says the equivalent, that slots not required for the intent "are not part of the main conversation flow." But both engines will still capture an optional value if the user volunteers it. Amazon's example is a bot with an optional City slot and the utterance What is the sales for April in San Diego?, where the bot fills the optional slot with San Diego.

Where they diverge is how that value is allowed to arrive. On Dialogflow CX, propagation from an intent or session parameter "is the only mechanism to set optional form parameters to values from end-user input," and the same mechanism can also overwrite a required parameter that was already filled. That is a narrow doorway, and because propagation works by matching names, an optional slot on CX that never populates is worth checking for a naming mismatch before you go looking at recognition. Google's parameter names are case insensitive, and the documentation warns that same-named parameters defined in different intents or forms should share an entity type or be renamed.

There is a further wrinkle on Google's engine: required parameters ignore default values entirely. "If a parameter is required, its default value is ignored." A default on a required slot is dead configuration, and it will sit in your agent looking like a safety net that is not there.

Built-in types do the boring work, and some are locale-bound

You do not write a date parser. Lex ships eighteen built-in slot types, which its documentation says "eliminates the need to create enumeration values for commonly used slot data such as date, time, and location." The full roster is AMAZON.AlphaNumeric, AMAZON.City, AMAZON.Confirmation, AMAZON.Country, AMAZON.Currency, AMAZON.Date, AMAZON.Duration, AMAZON.EmailAddress, AMAZON.FirstName, AMAZON.FreeFormInput, AMAZON.LastName, AMAZON.Number, AMAZON.Percentage, AMAZON.PhoneNumber, AMAZON.State, AMAZON.StreetName, AMAZON.Time and AMAZON.UKPostalCode.

Eight of them convert as well as recognize, which is the more useful half of the feature. AMAZON.Confirmation maps the many ways people say yes into a standard Yes, No, Maybe or Don't know value, which is the whole reason a confirmation message can be reliable. AMAZON.Number turns numeric words into digits, AMAZON.PhoneNumber into a numeric string, and date, time, duration, currency and percentage each resolve to a standard format.

One row in that table is worth carrying into a localization conversation. AMAZON.UKPostalCode is listed as supported in English (British) only, while sixteen of the others are marked "All locales" and AMAZON.AlphaNumeric carries no locale entry at all. Read the address-shaped types together and the shape of the assumption shows: city, country, state, street name, and exactly one country-specific postcode. If you are launching in a market whose postal code or national identifier has no built-in type, it becomes a custom slot type you own and maintain.

Beyond scalars, a slot can hold structure. Dialogflow CX documents three value types: scalar, composite (a JSON object with original and resolved fields) and list. The original-versus-resolved split is the useful one to understand, because an entity match usually normalizes what the user said. Google's own example is the word "apples" in user input resolving to "apple" for a fruit entity. If you need to echo back what the customer actually typed rather than what your system decided it meant, that distinction is the difference between a confirmation that sounds attentive and one that sounds like a database. See entity extraction for how the recognition step itself works.

In 2026 the model fills the slot, and the deterministic extractor still wins

The most current change in this area is what happens when a language model is added to a mechanism designed before language models were practical, and Rasa's documentation resolves it in unusual detail.

One caveat before the detail: everything in this section is a Rasa Pro capability, introduced for assistants built with CALM rather than for the open-source NLU pipeline. If you are evaluating Rasa on the strength of what follows, confirm the licensing.

Rasa offers a from_llm slot mapping type, and the documentation states that it "is the default slot mapping type if the mappings are not explicitly defined in the domain file." A slot with no mapping is an LLM-filled slot. The model is also allowed to fill that slot "at any point in the conversation flow, not just at the corresponding collect step," which is the batched, out-of-order behavior everyone wants, delivered by the model rather than by the parser.

The interesting part is the priority order when both mechanisms produce a value. Rasa's published scenario table resolves it consistently in favor of the deterministic path: when the NLU pipeline extracts a value and the model also extracts one, "the NLU based mapping takes higher priority" and the model's value is ignored, including when the NLU value is a correction to an already-filled slot. When a slot was filled by NLU and only the model produces a new value, that value is discarded too, "because the LLM is not allowed to correct NLU-filled slots by default." Opening that door is a deliberate allow_nlu_correction: true on the mapping. A model may fill an empty slot and may correct its own earlier work, but it does not get to overwrite the parser.

Two more details from the same page are worth stealing regardless of what you build on. Rasa recommends ask_before_filling: true on collect steps for slots that can be filled by the same entity, to stop an assistant "greedily filling all the slots with the same entity at the same time, when only one of the slots was requested." A first name and a last name backed by one person entity is the case where that bites. And as of 3.12 the engine supports validation rules written directly on the slot in the domain file, with a rejections list and an optional refill_utter, covering regex, length, type, range, date-format and enumeration checks. Putting the rule on the slot definition rather than in a flow step means it applies everywhere that slot is used, which is a different and stronger guarantee than validating at one collection point.

Nobody sells slot filling, which is the buyer's problem

The term lives in NLU engineering rather than in marketing, so the capability reaches you under a different name depending on who is selling it. The word "slot filling" appears nowhere in our own review corpus of fifteen platforms, which is a reasonable proxy for how rarely vendors use it. Here is the same mechanism under the names you will actually encounter.

Chatbotscape earns affiliate commission on some of the platforms named below. It does not change what we publish. See our affiliate disclosure.

Platform characterizations in the last three rows carry over from our May 2026 reviews; see each review's evidence block for how its individual findings are calibrated, since not every builder surface in that batch was exercised in an authenticated session. The buying question this collapses to is short. Can you store a value mid-conversation, check whether it is already stored before asking again, overwrite it when the customer changes their mind, mark it sensitive so it stays out of logs, and hand the half-filled set to a human on handoff? A platform that cannot do the third one will fail on "actually, make it three," and no amount of model quality repairs that.

Where it breaks

The slot fills with the wrong half of the sentence. A first name and a last name backed by the same entity type both grab the same word. Rasa's ask_before_filling setting is the documented control for the greedy-filling case behind this; on other engines it is a naming and entity-type problem rather than a model problem.

A value arrives that is shaped right and wrong. A date in the past, a party size of nine hundred, an email with no @. Nothing in the type system rejects these, which is why per-slot validation on the turn the value lands is the fix rather than a check at submission.

The optional slot never populates. Usually a name mismatch on a propagation path rather than a recognition failure, because optional slots are not prompted for and therefore have only the one route in.

The bot loops the same question. No second prompt was written, so the engine falls back to repeating the first one. See fallback intent for the wider pattern and what to escalate to.

The values are collected but not remembered. Filling is not tracking. A bot can extract every value correctly and still make the customer start over, which is a dialog state tracking failure sitting downstream of a perfectly healthy slot layer.

Related terms

• Dialog state tracking — what holds the filled slots together across turns, and where "it forgot what I said" actually originates.
• Entity extraction — the recognition step that produces the value a slot then accepts.
• Intent recognition — the sibling task: what the user wants, as opposed to the details they supplied.
• Natural language understanding — the layer both of the above belong to.
• Fallback intent — where a slot goes after the retry ladder runs out.
• Confirmation message — the read-back that turns a filled form into a commitment.

FAQ

What is slot filling in a chatbot?

It is the process of collecting the specific values a task needs into named, typed containers. A booking bot needs a date, a time and a party size; each of those is a slot, and slot filling is everything the engine does to get a value into one, whether by recognizing it in a sentence, taking it from a tapped button, carrying it over from earlier in the session, or asking a direct question and re-asking when the answer does not parse.

What is the difference between slot filling and entity extraction?

Entity extraction is recognition: finding "next Tuesday" in a sentence and resolving it to a date. Slot filling is the surrounding process that decides which slot that date belongs in, whether the slot was already filled, whether the value passes validation, and what to ask next. Extraction produces a value; slot filling decides what happens to it. Many engines let a slot be filled by mechanisms other than extraction, which is why the two are not interchangeable.

Is slot filling the same as dialog state tracking?

No, and the split is useful when you are diagnosing a bot. Slot filling is the collection mechanism for one value at a time. Dialog state tracking is keeping the whole set coherent across turns, including corrections and detours. A bot can fill every slot correctly and still make the customer start over, and that is a tracking failure rather than a filling one.

What is a slot type?

The declaration of what values a slot will accept. Engines ship built-in types for common data so you do not write a date parser: Lex lists eighteen, covering date, time, number, currency, percentage, duration, phone number, email address, city, country, state, street name, a UK postcode, first and last name, alphanumeric strings, a yes/no confirmation type and a free-form catch-all. You define custom types for values specific to your business, such as a service menu or a list of branches. Watch for locale limits: Lex's UK postal code type is documented as English (British) only, while sixteen of the others carry "All locales" and AMAZON.AlphaNumeric carries no locale entry at all.

Can a chatbot fill several slots from one sentence?

Sometimes, and you should not assume it. Google's Dialogflow CX documentation says that when a user provides multiple parameter values in a single turn, "usually only one form parameter is set," that multi-fill occurs only when the same parameters are also intent parameters in an intent referenced in the same flow, and that the behavior "is an optimization of NLU which may or may not occur during a conversation, so this behavior shouldn't be relied on." Design for it, then test it on your platform rather than trusting it.

Do large language models make slot filling obsolete?

They change who fills the slot, not whether you need one. In Rasa Pro, from_llm is the default mapping when none is declared, and the model may fill a slot at any point in the conversation rather than only at the step that asks for it. But Rasa's published priority table has deterministic extraction winning every conflict: an NLU-extracted value beats a model-extracted one, and the model is not allowed to correct an NLU-filled slot unless you explicitly set allow_nlu_correction. The structured, inspectable slot is what makes the model's output checkable, so it survives.

How do I keep sensitive data out of slot logs?

Check whether your platform supports per-slot redaction before you collect anything regulated. Dialogflow CX exposes a Redact in log flag per intent or form parameter, after which the value is redacted from logs and internal storage and shown as $parameter-name_redacted, with the documented limitation that only text input can be redacted at present. No review in our fifteen-platform catalog records an equivalent control on an SMB builder, so on most of them the safe assumption is that you do not have one, and the safe design is not to put regulated data in a slot at all. Our PII handling checklist covers the rest.

Sources

• Amazon Web Services. Slots, Amazon Lex V2 Developer Guide — the built-in versus custom slot type split, the per-slot configuration list (slot info and required flag, slot type, slot prompt with configurable retries and per-retry prompt variation, wait and continue, success and failure capture responses, conditional branching, dialog code hook, input type, audio and DTMF timeouts, text length), the re-elicitation loop until a value is understood or retries are exceeded, the Lambda invocation after each retry attempt, and the behavior of optional slots including the City / "What is the sales for April in San Diego?" example. docs.aws.amazon.com (read 11 August 2026).
• Amazon Web Services. Built-in slot types, Amazon Lex V2 Developer Guide — the eighteen built-in slot types and their descriptions, the statement that built-in types eliminate the need to create enumeration values for commonly used data such as date, time and location, the conversion behavior of AMAZON.Confirmation into a standard Yes/No/Maybe/Don't know format, and the supported-locale column showing AMAZON.UKPostalCode as English (British) only, "All locales" for sixteen of the remainder, and no locale entry at all for AMAZON.AlphaNumeric. docs.aws.amazon.com (read 11 August 2026).
• Google. Parameters, Dialogflow CX documentation (page stamped "Last updated 2026-07-29 UTC" when read) — the definition of a form and of form filling, collection of required parameters in the order defined on the page, the statement that optional parameters won't trigger prompts, the repetition of the initial prompt when no reprompt handler is defined and the purpose of reprompt handlers, the Page.form.parameters[].required semantics and the rule that a required parameter's default value is ignored, the note that multiple values in one turn usually set only one form parameter and that the multi-fill optimization "shouldn't be relied on," parameter propagation as the only route for setting optional form parameters from end-user input, the scalar / composite / list value types with original and resolved fields and the "apples" to "apple" resolution example, case-insensitive parameter naming with the same-name/same-entity-type warning, and parameter redaction with the $parameter-name_redacted log form and the text-input-only limitation. docs.cloud.google.com (read 11 August 2026).
• Rasa. Slots, Rasa Documentation reference (page stamped "Last updated on Jul 24, 2026") — the definition of slots as a key-value store, the text / bool / categorical / float / any / list slot types with categorical case coercion, the from_llm mapping type and the statement that it is the default when mappings are not explicitly defined, the ability of the LLM-based command generator to fill a slot at any point rather than only at the corresponding collect step, the scenario table establishing that NLU-based mappings take higher priority over LLM-extracted values and that the LLM may not correct NLU-filled slots without allow_nlu_correction, the ask_before_filling: true recommendation against greedy filling from a shared entity, and the 3.12 real-time slot validation feature with its rejections and refill_utter properties and the enumerated validation categories. The page presents the LLM-related mappings under CALM and versions them by Rasa Pro release, which is the basis for this entry's note that these are Rasa Pro capabilities. rasa.com (read 11 August 2026).
• Chatbotscape platform reviews: Botpress and Voiceflow (named variables and capture surfaces in developer-grade builders), Manychat (custom user fields typed as string, number, date or boolean) and SendPulse (a flow builder described in terms of custom variables rather than fields). May 2026, mixing vendor-page verification with authenticated sessions; each review's evidence block calibrates its own findings, and the Botpress builder walkthrough in particular is marked docs-signal rather than a paid-account run. We have published no slot-extraction accuracy figures for any of them. The catalog-wide observations in this entry — that "slot filling" appears in no review, and that no review records a per-slot redaction control — were made by searching all fifteen reviews on 11 August 2026.
• Chatbotscape. Multi-turn chatbot forms that don't lose state /academy/multi-turn-form-design, Dialog state tracking /glossary/dialog-state-tracking, and Entity extraction /glossary/entity-extraction — the three pages carrying the unqualified batched-filling guidance corrected in the callout above.
• Ahrefs Keywords Explorer, US and volume-by-country, 11 August 2026 — editorial keyword research informing this entry's scope and its boundary against neighboring pages.
• Chatbotscape evaluation methodology. /methodology (continuously updated).