AWSAWS Certified Generative AI Developer - Professional2026-101.6 Implement prompt engineering strategies and governance for FM interactions
Persist conversations and clarify uncertain intent
Completed by the knowledge check
Learning objective
Store conversation history in DynamoDB and implement intent recognition and clarification workflows with Comprehend or Step Functions.
Core idea
Conversation history, intent recognition, and clarification are separate responsibilities. DynamoDB stores the durable turns and workflow state. Amazon Comprehend can classify text into your trained intent categories. AWS Step Functions coordinates the decision about whether to continue, ask for missing information, or finish with an escalation. A state machine does not recognize language merely because it has a Choice state.
Persist enough information to resume the conversation and explain each routing decision. Do not treat the transcript as an unlimited model prompt or a class label as permission to execute a business action. The application owns the intent taxonomy, confidence policy, missing-information rules, and authorization checks.
How it works
Store turns with an explicit access pattern
Design a DynamoDB partition key that identifies a conversation within its tenant boundary. An application-defined key such as a tenant-and-conversation identifier avoids relying on a client-supplied conversation ID alone. Authorize that identity before reading history. A key naming convention organizes records; it does not enforce tenant isolation by itself.
Use a sort key that orders turn records deterministically, such as a monotonically assigned turn sequence. Store the role, content, turn identifier, creation time, and processing outcome with each turn. Keep workflow metadata distinguishable from message records: pending intent, missing fields, clarification count, and accepted release identity serve different consumers from the transcript.
Read one conversation through Query with a KeyConditionExpression that specifies partition-key equality and, when useful, a sort-key condition. DynamoDB returns results ordered by sort key; ScanIndexForward: false reverses that order. Numeric sort keys order numerically, while string keys order by UTF-8 bytes. If you encode sequence numbers in strings, use a representation whose lexical order matches the intended chronology.
A single Query retrieves at most 1 MB before a filter or projection is applied. A non-null LastEvaluatedKey means the reader must paginate. If you query the most recent turns in descending order, restore chronological order before assembling model messages. A partial page must not silently become the entire conversation. See 1.3.9 for context-window budgeting and preservation of message dependencies.
Write each turn with PutItem using a deterministic turn key. A plain PutItem replaces an existing item with the same primary key. To protect an accepted turn from a retry overwriting it, use ConditionExpression with attribute_not_exists on the partition-key attribute. A failed condition produces ConditionalCheckFailedException; inspect the existing turn and distinguish a duplicate from a conflicting submission instead of blindly retrying the write. This conditional write protects one item, not the entire conversation workflow.
Recognize domain intent with a trained classifier
For a domain taxonomy such as refund_request, delivery_status, and product_advice, train a Comprehend custom classifier and create its endpoint. Call ClassifyDocument with the customer’s text in Text and the endpoint identity in EndpointArn. The endpoint selects the trained classification model; it is not a generic instruction to infer your application’s business categories.
For a multi-class model, Classes contains mutually exclusive class candidates with Name and Score. For a multi-label model, Labels contains categories that need not be mutually exclusive. Choose the training mode according to whether one utterance can legitimately contain several intents. A request to check delivery and cancel an order might need a multi-intent policy rather than an unconditional highest-score winner.
Use reviewed utterances to set the acceptance threshold and any minimum separation between leading candidates. The threshold and margin are your application policy, not a built-in Comprehend intent guarantee. Preserve the classifier endpoint, scores, selected intent, and policy revision with the decision so you can explain why one request proceeded and another needed clarification.
Comprehend’s pre-trained prompt safety classifier is a different model type supported by ClassifyDocument. It returns SAFE_PROMPT and UNSAFE_PROMPT classes for English plain-text prompts. Those labels do not distinguish a refund request from delivery tracking. Do not select the safety classifier when the missing capability is business intent recognition. General entity or sentiment detection likewise does not define your intent taxonomy; see 1.3.10 for enrichment.
Coordinate uncertainty and missing fields
Step Functions receives a structured decision record from classification or another validated recognizer. Include the candidate intent, score, required-field completeness, and clarification count. A Choice state evaluates explicit rules and routes to the appropriate next state. With JSONPath rules, comparisons such as NumericGreaterThanEquals and field checks such as IsPresent can implement the policy. Provide a Default path for unknown or insufficient evidence; without a matching choice or a default, the state machine fails to transition.
Confidence and completeness are separate gates. A high-confidence refund request may still lack an order identifier. A complete set of order fields may accompany an ambiguous request. Ask for the information that resolves the specific uncertainty, then update the state and reevaluate. Define a maximum clarification count as workload policy, and route exhausted conversations to an explicit terminal outcome.
For a durable pause awaiting a reply, Standard Workflows can use supported .waitForTaskToken integrations. Express Workflows support request-response integrations, not the callback pattern. A callback task passes its token to a trusted intermediary; that intermediary resumes the task with SendTaskSuccess or ends it with SendTaskFailure. The principal returning the token must be in the same AWS account.
Do not expose a task token as an ordinary chat identifier. Associate it with the pending conversation in the trusted application layer, authenticate the reply, and ensure it addresses the outstanding question. Configure a task timeout or heartbeat policy rather than relying on the workflow’s maximum lifetime. The documented HeartbeatSeconds mechanism bounds a callback task that otherwise receives no liveness signal. Persist the clarification state so a delayed or duplicate reply cannot be mistaken for a fresh command.
Each reply returns through both gates until the workflow continues or an exhausted conversation finishes with an escalation.
Key distinctions and trade-offs
History versus model context: DynamoDB can retain the durable record while the model receives a selected, bounded context. Retention and token selection solve different problems. For retention, enable Time to Live on the table and store each turn’s expiration as a Number in Unix epoch seconds in the TTL attribute. DynamoDB deletes expired items typically within a few days, so a Query can still return them; filter out expired turns before building model context.
Classification versus orchestration: Comprehend supplies category scores from a trained model. Step Functions executes explicit branching and waiting rules. They can work together; neither replaces the other’s responsibility.
Ambiguity versus missing data: Ambiguity asks what the customer wants. Missing data asks what information the chosen workflow requires. A clarification question should target the condition that prevented continuation.
A synchronous application can handle a brief clarification exchange with persisted state between requests. A Standard Workflow callback is useful when the process must remain durably paused across an external reply. Choose according to the workflow lifetime and coordination need, rather than assuming every chat turn needs a long-running execution.
Architecture / decision scenario
A retailer’s customer says, “The parcel is late; I want my money back.” The service saves the turn under the authorized tenant and conversation key. A custom multi-class Comprehend endpoint returns close scores for delivery status and refund request. The routing policy sends that result to the Step Functions clarification branch rather than choosing the leading score automatically.
The assistant asks whether the customer wants tracking information or a refund. A Standard Workflow callback waits behind the authenticated application, which retains the pending question and token association. The customer chooses refund. The intermediary returns the validated reply with SendTaskSuccess, and the workflow checks completeness through a Choice state.
Because the order identifier is missing, the service asks one targeted follow-up and persists the updated clarification count. After the authorized order is identified, it continues to the refund workflow; if the configured clarification budget is exhausted, it escalates. The transcript remains in DynamoDB, duplicate turn writes encounter the conditional-write boundary, and the model receives only the needed context.
Common exam traps
- Treating a Step Functions
Choicestate as a language classifier. - Using Comprehend prompt-safety labels as business intents.
- Treating the highest class score as sufficient for every action.
- Assuming high intent confidence means all required fields are present.
- Ignoring DynamoDB pagination or reversing recent turns into the wrong model order.
- Overwriting accepted turns with an unconditional
PutItemretry. - Assuming Express supports callback tasks.
What to remember
- Persist authorized, ordered turns and explicit clarification state.
- Use a custom classifier for domain intent and interpret its training mode correctly.
- Route confidence and completeness as separate conditions with a safe default.
- Bound clarification and authenticate callback completion before continuing the workflow.
Knowledge check
A history reader must load every turn of a conversation newer than a checkpoint. It queries in descending sort-key order, and the response includes LastEvaluatedKey. How should it build the model’s message list?
LastEvaluatedKey means the 1 MB page limit cut the result short, so the reader paginates before treating it as complete. Turns read newest-first must then be restored to chronological order before they become model messages.Customers often ask for two things at once, such as tracking a parcel and cancelling another order. Which Comprehend setup lets the router see every intent in one utterance?
LabelsClasses entrySAFE_PROMPT and UNSAFE_PROMPT , and entities do not define an intent taxonomy.A refund-intent score clears the acceptance threshold, but the message carries no order identifier. What should the workflow do?
A workflow must pause durably until an authenticated customer answers a clarification question, which may take hours. Which Step Functions pattern fits?
.waitForTaskToken.waitForTaskTokenChoice state with a Default pathWait state set to a long durationSendTaskSuccess , and a timeout or heartbeat bounds the wait.A turn writer retries PutItem after a timeout, and the original write may already have succeeded. Which write prevents the retry from replacing an accepted turn?
PutItem with the same turn keyPutItem with attribute_not_exists on the partition keyPutItem with a new random turn keyPutItem with ReturnValues set to return the old itemPutItem replaces any item with the same primary key, and a new key would duplicate the turn instead. The condition makes a repeated write fail with ConditionalCheckFailedException , after which the writer inspects the stored turn to tell a duplicate from a conflict.