A permitting chatbot must remember the resident’s parcel ID across follow-up turns without asking again each message. Where should the application keep that conversation state for reliable FM prompting?
Select an answer to reveal the explanation.
Short Explanation
A permit desk sticky note with the parcel number beats hoping the clerk remembers from yesterday’s hallway chat. DynamoDB (or similar) is that sticky note for the bot—reload parcel context into the next prompt. URLs, embedding weights, and audit logs are not conversation memory.
Full Explanation
Multi-turn permitting chats must retain entities such as a resident’s parcel ID across follow-ups so the foundation model is not forced to re-ask every message. Durable conversation state belongs in an application session store—commonly DynamoDB—that the backend reloads into the prompt or conversation history on each turn. That pattern separates memory from the FM, survives browser refreshes when tied to an authenticated session, and supports audit of what context was shown to the model. Keeping state only in the browser URL hash is fragile, length-limited, and insecure for parcel identifiers; it also fails when the Bedrock request is assembled server-side without that hash. Embedding parcel memory into embedding-model weights confuses session facts with retrieval representations—weights do not store per-resident conversation state. CloudTrail alone records API activity for audit; it does not restore chat context into the next FM invocation. Exam caveat: stems about remembering parcel IDs across turns point to durable session stores rehydrated into prompts, not hashes, embeddings, or audit logs as memory. Operational check: key sessions by authenticated resident or clerk identity, store parcel ID and prior turns with TTL and encryption, inject only needed fields into each Bedrock call, and never treat CloudTrail as the conversation database.