{"slug": "a-customer-request-is-not-a-booking-designing-memory-for-ai-assistants", "title": "A Customer Request Is Not a Booking: Designing Memory for AI Assistants", "summary": "A worked scheduling example for customer-facing AI assistants argues that memory should store an unresolved request record rather than a booking, because a customer asking \"Could we do Friday morning instead?\" has changed a preference but not created an appointment. The design separates the assistant's request record from the scheduling service's booking record, which holds the actual appointment identifier, time, status and customer, and requires different evidence for each transition: requested to offered needs a specific available slot returned by the scheduling service, offered to accepted needs an unambiguous customer response, and accepted to booked needs the booking service to return its identifier. The piece cites LangChain's memory documentation distinguishing conversation-scoped state from information retained across sessions, and notes the rules are proposed for this workflow rather than universal scheduling semantics.", "body_md": "“Could we do Friday morning instead?” is enough to change a customer’s preference. It is not enough to put Friday on the calendar. An assistant can quote that message perfectly and still send the wrong reminder if its memory stores only “Friday appointment.”\n\n*Written with AI assistance.*\n\nA small-business owner on Reddit described losing track of client context across email, WhatsApp, notes and spreadsheets [1]. Another discussion asked how to automate customer messages without sounding robotic [2]. Together, they suggest a useful design problem: retrieving the conversation helps, but the next reply also needs to distinguish a request from a commitment.\n\nHere is a worked scheduling example for people building customer-facing assistants. The useful output is a record of the unresolved decision, a rule for changing it, and a set of cases to test before sending reminders.\n\nSuppose a customer asks about Thursday afternoon. A teammate offers Thursday at 3. The customer then asks about Friday morning, and the teammate replies, “I’ll check.” No appointment has been booked.\n\nA summary such as “Customer discussed a Thursday appointment, then moved to Friday” introduces a change that never happened. The customer asked to change the proposed time. Nobody confirmed a replacement.\n\nFor this example, assume the customer is authenticated and the business can read its own scheduling system. Those assumptions remove identity verification from the walkthrough; they do not make the transcript authoritative about availability.\n\nThe assistant’s next step is to check Friday availability. If there is a slot, it can offer that specific time. If the calendar cannot be read, a scheduling teammate needs to take over. A reminder is premature in both cases.\n\nLangChain’s memory documentation distinguishes conversation-scoped state from information retained across sessions [3]. That storage distinction is useful, but either kind of memory still needs to preserve what a statement actually establishes.\n\nFor the example, a small request record could contain:\n\n“Friday morning” should stay unresolved until the date and timezone are established. Converting it silently into a timestamp makes a precise-looking error harder to spot.\n\nThe booking record belongs to the scheduling service. It contains the actual appointment identifier, time, status and customer. The assistant may keep a reference to it, but a sentence in memory cannot create it.\n\nThis separation also handles a harder case. If Thursday had already been booked, the Friday request would create a pending reschedule alongside the existing booking. It would not cancel Thursday automatically. The team needs an explicit rule for what remains reserved while a change is pending.\n\nAn LLM can propose an interpretation of a message: M12 appears to replace M08’s preferred day. Store that proposal with its source so it can be inspected. Application logic should validate the customer scope, request identity and allowed transition before accepting the update.\n\nUse different evidence for different transitions:\n\n**Requested → offered:** the scheduling service returns a specific available slot, and the application records the offer sent to the customer. An availability lookup alone does not mean an offer was sent.\n\n**Offered → accepted:** a customer response refers unambiguously to that offer. If two times were offered and the reply is “yes,” ask which time. Do not make the model’s confidence score stand in for the missing choice.\n\n**Accepted → booked:** the booking service successfully creates the reservation and returns its identifier. Customer acceptance alone does not establish that the write succeeded.\n\nThese are proposed rules for this workflow, not universal scheduling semantics. A business using temporary holds would need another state, with an expiry time and rules for releasing it.\n\nThe application should reject unsupported transitions even if the model asks for them. The model can help interpret an exchange; it should not be able to mark a slot booked by writing a new summary.\n\nThe original Thursday offer remains useful history. It should not remain the current offer for R17 after the customer requests a different day. Preserve the source message and mark its relationship to the newer request rather than deleting the exchange.\n\nA queued reminder creates another problem. It may have been composed before the latest customer message arrived. Attach the request version used to prepare it. Before dispatch, compare that version with the current request record and read the relevant booking again. If either changed, discard the prepared message and reconsider the task.\n\nA version check is only as good as the events already processed. If the message channel has received a cancellation that the request updater has not yet consumed, the record may still look current. The send step therefore needs a defined boundary: process received customer events before evaluating a pending message, and serialize those operations for the request where practical.\n\nEven then, a customer can change their mind after a reminder leaves the system. The objective is to prevent sending against changes already received, not to promise perfect synchronization with every future message.\n\nAvailability also needs protection at booking time. Two customers can accept the same apparently free slot. Enforce capacity in the booking service’s transaction rather than relying on a previous lookup. Database constraints can enforce relevant invariants; PostgreSQL, for example, documents exclusion constraints for restrictions involving overlapping values [4]. The exact constraint depends on whether the resource permits one appointment or several.\n\nRun each fixture through the same path used to prepare and dispatch a message. Inspect the service calls as well as the prose: a careful-sounding reply does not excuse an unauthorized booking write. Repeat the cases with paraphrased customer messages to test interpretation separately from the fixed workflow rules.\n\nThese tests cover a narrow scheduling contract. They do not establish general assistant reliability, extraction accuracy across languages, or production performance. They do make one requirement observable: the assistant must preserve the difference between what the customer asked for and what the business has actually committed to.\n\nFor a small team, this can start as a shared record with a human owner. Automating it becomes easier once “requested,” “accepted” and “booked” have meanings the team can point to — and evidence the system can check.\n\n[1] [Small-business discussion about keeping track of five clients](https://www.reddit.com/r/smallbusiness/comments/1wamvi9/just_got_to_5_clients_and_now_im_already_losing/).\n\n[2] [Discussion about automating customer messages naturally](https://www.reddit.com/r/automation/comments/1wrp1io/has_anyone_found_a_good_way_to_automate_customer/).\n\n[3] [LangChain documentation: Memory overview](https://docs.langchain.com/oss/python/concepts/memory).\n\n[4] [PostgreSQL documentation: Constraints](https://www.postgresql.org/docs/current/ddl-constraints.html).\n\n[A Customer Request Is Not a Booking: Designing Memory for AI Assistants](https://pub.towardsai.net/a-customer-request-is-not-a-booking-designing-memory-for-ai-assistants-b5e938cce832) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/a-customer-request-is-not-a-booking-designing-memory-for-ai-assistants", "canonical_source": "https://pub.towardsai.net/a-customer-request-is-not-a-booking-designing-memory-for-ai-assistants-b5e938cce832?source=rss----98111c9905da---4", "published_at": "2026-09-30 12:01:02+00:00", "updated_at": "2026-09-30 12:16:43.595611+00:00", "lang": "en", "topics": ["ai-agents", "artificial-intelligence", "large-language-models"], "entities": ["LangChain", "Reddit"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-customer-request-is-not-a-booking-designing-memory-for-ai-assistants", "markdown": "https://wpnews.pro/news/a-customer-request-is-not-a-booking-designing-memory-for-ai-assistants.md", "text": "https://wpnews.pro/news/a-customer-request-is-not-a-booking-designing-memory-for-ai-assistants.txt", "jsonld": "https://wpnews.pro/news/a-customer-request-is-not-a-booking-designing-memory-for-ai-assistants.jsonld"}}