Chatbot with per-session memory

Memory isolation starts outside the model. The chat backend creates the session id, usually tied to the browser session or a logged-in guest, and sends it on every POST to the Langflow run endpoint. Chat Input stores the turn under that id and Message History retrieves only that id's messages, so the agent's context is scoped to one conversation. I never let the session id come from free text or a default value, and I add a check that rejects runs without one. I also load-test with many parallel sessions, because Playground testing with one session hides sharing bugs. Finally, personal details like phone numbers go to the reservations system, and chat history has a retention limit so old conversations are purged.

The website sends the message to our chat backend. The backend assigns or reuses a session id tied to the browser session or logged-in guest, then calls POST /api/v1/run/<flow-id> with the message and session_id. Chat Input stores the turn under that session. Message History loads recent turns for the same session, and the Prompt component adds the host instructions. The Agent combines all three and either asks a follow-up or calls a tool: Check availability to find slots, or Create booking after explicit confirmation. Chat Output returns the reply to the backend, which shows it to the guest. Every run is traced to Langfuse or LangSmith with the session id so we can review each conversation.

The session id is the only key that separates one guest's memory from another's, so it has to be trusted. If the browser could send any value, someone could guess or reuse another guest's id and read their party size, name or phone number through the history. The backend issues an unguessable id, binds it to a secure cookie or the logged-in account, and only ever passes that id to Langflow. Langflow also should not be reachable directly from the public internet, so the backend stays the single place where session identity is decided and checked.

I use several layers. The prompt forbids confirming anything without a successful Create booking result. The Create booking tool returns either a booking reference from the reservations system or an explicit error, never a vague success. The agent may only say confirmed when it has that reference. Because prompts are not guarantees, I add a backend check: before showing a confirmation, the backend verifies that the reference in the reply matches one returned by the tool in that run, or looks it up in the reservations system. If it doesn't match, the backend replaces the message with a safe fallback and logs the trace.

A timeout means the outcome is unknown, not failed. The booking might exist. The tool should not report success, and the bot must not say confirmed. Because the request carries an idempotency key, the tool can safely retry with the same key. If the booking was made, the reservations system returns the existing reference instead of creating a second one. If retries still fail, the bot tells the guest honestly that it could not confirm the booking yet and offers another option, such as calling the restaurant. The trace is flagged so staff can reconcile it later.

Availability changes minute by minute as other guests book or cancel, and a schedule pasted into the prompt is stale the moment the flow runs. A tool-mode custom component that queries the reservations system returns the live state, and the agent only decides when to call it and how to phrase the result. The prompt explicitly says never to claim a table is free without a fresh tool result, even if history mentions it. This also keeps the prompt short and moves business logic, like table combinations and opening hours, into tested Python code. When availability is wrong, I can see the exact tool input and output in the trace, which is far easier to debug than a model reasoning over a long text block.

Three layers. First, a confirmation step: the agent must read back date, time, party size and name, and the guest must say yes before the Create booking tool is allowed. The prompt states this, and the tool itself can require a confirmed flag. Second, idempotency: the tool sends a key derived from the session id and the booking details, so a retry after a timeout returns the existing booking rather than making a new one. Third, the reply only shows a booking reference returned by the reservations system, never one the model invents. I track 'confirmed in chat but missing in system' and duplicates as zero-tolerance metrics, and I review traces for any run where the booking tool was called without a confirmation turn.

The key must stay the same when the same confirmed request is retried, and change when the guest makes a genuinely new request. A good approach is to create it when the guest confirms a specific read-back, for example from the session id plus a hash of date, time, party size and contact. A retry of that confirmation reuses the key. A changed time produces a new key. The key should be produced in the tool code, not chosen by the model, so the model can't accidentally vary it. The reservations system must store keys and return the original result for repeats.

Both may see the slot as free in Check availability, because that is only a snapshot. The reservations system is the source of truth and must enforce capacity atomically when Create booking writes, using a transaction, row lock or conditional insert. One request succeeds and gets a reference. The other gets a clear error such as slot unavailable. The agent then tells the second guest the table was just taken, calls Check availability again and offers alternatives. The chatbot never holds or assumes inventory itself, which keeps consistency inside the system built to manage it.

Enough to keep the booking details the guest already gave, but not so many that cost, latency and confusion grow. A reservation chat is usually short, so a modest recent window works for most conversations. Too few turns and the bot forgets the party size or name and asks again. Too many and the prompt gets long, slower and more expensive, and old changed details can confuse the model. If conversations run long, I would keep a short window plus a structured summary of the collected booking fields, so key facts survive without loading every turn.

The prompt tells the agent to follow host rules, but I assume prompt injection can sometimes work, so the real protection sits outside the model. The model cannot create a reference; only Create booking can, and only the reservations system decides whether a booking exists. The backend checks that any confirmation matches a real tool result. Tools validate their inputs, such as dates, party size limits and contact format, so the model can't push bad data. The agent only has the two tools it needs, so injected text has little power. Odd answers show up in traces for review.

Collect only what the booking needs: name, contact, date, time and party size. Message history is stored per session with access limited to the backend and the flow. Set a retention period and delete or anonymise old chats. Traces in Langfuse or LangSmith also contain message text, so I would mask or redact phone numbers and emails before sending them where possible, restrict access to the tracing project, and pick a hosting region that meets India's DPDP Act obligations. The privacy notice should tell guests the chat is stored and used to make the reservation.

Message history is stored in Langflow's database keyed by session id, not in a single worker's memory. That matters because it keeps workers mostly stateless: any instance can serve any turn as long as they share the same database. For production I would use a proper database such as PostgreSQL rather than the default local one, run several Langflow instances behind a load balancer and scale them horizontally. The database then becomes the shared dependency to monitor, with indexes on session id, backups and a retention job to keep the history table from growing forever.

It depends on the error, which is why the tool should return clear error types. If the slot is unavailable, the bot apologises, checks availability again and offers alternatives. If input is invalid, like a party too large for online booking, it explains and suggests calling the restaurant. If the system is down or the result is unknown, it must not claim success; it says it couldn't complete the booking right now and offers to try again or contact staff. Raw technical errors should never be shown to the guest, but they should be visible in the trace.

Langflow should not be exposed directly to the public. Only the chat backend calls it, over a private network or with TLS, using a Langflow API key kept in a secret store. The backend authenticates guests, issues session ids, rate limits and validates input before calling the flow. Credentials for the reservations system live in the tool configuration or environment, never in the prompt. I'd restrict who can edit flows in the Langflow UI, since changing a flow changes production behaviour, and keep the Langflow version patched because it runs Python code from components.

An agent handles natural conversation well: guests give details in any order, change their minds, ask about dietary needs, or say something vague like next Friday around 8. A form handles that poorly. The trade-off is less predictability. So I'd keep the agent for conversation but put the risky parts in deterministic code: tools validate inputs, the reservations system enforces capacity, idempotency prevents duplicates, and the backend verifies confirmations. If traces show the agent struggling, a hybrid works well: tracking required fields explicitly and letting the model only fill gaps.

Never let the reply be the only evidence. The Create booking tool's result is recorded in the run and visible in the trace. The backend can compare any reference-like string in the reply with the reference actually returned by the tool in that run, or confirm it with the reservations system before display. If there is no match, it suppresses the confirmation and shows a safe message. Using a distinctive reference format makes detection easy. In review, traces where the reply contains a reference but no successful tool call are a critical alert.

I would start from the business: number of restaurants, expected reservation chats per day, average turns per chat and the peak hour share, often around evenings and weekends. That gives peak flow runs per minute. Each run costs one or more model calls plus possible tool calls, so I'd measure average latency and tokens per run in the Playground and in a load test. From that I size Langflow workers, model rate limits and the reservations API capacity. I'd then validate the estimates with load testing and adjust from real traces after launch rather than trusting guesses.

It adds one turn, but it prevents the most costly mistakes. Language models can mishear or mix up details, like 7 versus 7:30, 4 people versus 14, or today versus tomorrow. A wrong booking costs the restaurant a table and the guest a bad evening. Reading back date, time, party size and contact, then waiting for an explicit yes, gives the guest a chance to correct errors and gives us a clear consent point before writing to the reservations system. It also makes the trace easy to audit: you can see exactly what the guest agreed to.

First in the Playground, with scripted conversations: simple bookings, changed minds, fully booked slots, ambiguous dates, injection attempts and tool errors. I would point the tools at a test or sandbox reservations system. Then I'd build a set of test conversations and run them through the API with different session ids, checking that no session sees another's details and that no reply says confirmed without a booking reference. I'd also test concurrency with parallel sessions booking the same slot. Traces in Langfuse or LangSmith help review failures. Only after that would I release gradually.

It should return structured data, not prose: the requested date and party size, a list of available slots with times, and maybe area or table type, plus a clear status such as available, none, or error with a reason. Structured results let the agent present real options without inventing times, and make it obvious when nothing is free. A clear error lets the agent say it couldn't check rather than guess. Keeping the output small also saves tokens. Tool descriptions and input fields should be precise so the agent calls it with valid arguments.

The model needs to know the current date and the restaurant's time zone, so I would pass them into the prompt on every run rather than relying on the model's sense of time. For an Indian restaurant that is usually IST, but a chain abroad would differ. The agent resolves tomorrow into an absolute date and includes it in the read-back, such as Saturday 14 March at 8 pm, so the guest can catch mistakes. The tools accept only absolute dates and times in a fixed format and validate them, rejecting past dates or slots outside opening hours.

Per session, I'd check the full sequence: the input, the history loaded, the prompt, model calls, tool calls with arguments and results, and the final reply. Key things to watch: confirmations without a successful Create booking, Create booking called without a prior read-back and yes, repeated tool calls or loops, tool errors and timeouts, slow runs, high token use and odd answers. Because traces carry the session id, a guest complaint can be traced to the exact conversation. I'd also tag outcomes like booked, abandoned or failed to track quality over time.

I'd treat the flow as code. Export the flow definition and keep it in version control, review changes, and test them against the saved set of conversations in a staging Langflow instance with a sandbox reservations system. Then deploy to production, ideally sending a small share of traffic to the new version first, and compare outcomes in traces before switching fully. Keep the previous flow available for quick rollback. Tweaks on the API call can override settings for experiments without copying the whole flow, but structural changes should go through the same review.

Add Cancel booking and Modify booking tools as custom components in tool mode, but with stronger identity checks, because these act on an existing booking. The guest must prove ownership, for example a booking reference plus the phone number, or a one-time code, or simply being logged in. The tool verifies that against the reservations system rather than trusting the model. The same rules apply: read back the change, wait for explicit confirmation, use an idempotency key, and only report success when the system returns it. Prompt instructions are updated to describe when to use each tool.

At the backend, rate limit per IP, per session and per account, and add bot protection on the chat widget if needed. Limit message length to control cost. In the tools, enforce business rules: maximum party size online, a cap on bookings per contact per day, and validated phone or email, perhaps with an OTP for confirmation. Reservations staff can flag no-shows. Traces and metrics help spot unusual patterns like many sessions from one source. Spending limits on the model provider protect against runaway cost.

Set a limit on agent iterations so a confused run stops instead of calling tools repeatedly. Make tool descriptions clear and outputs unambiguous, because loops usually come from the model not understanding a result. Return explicit statuses like none available so the agent moves on to alternatives. Set timeouts on tool calls. At the backend, set an overall request timeout and show a friendly fallback if it is hit. Monitor tool calls per run and tokens per run in traces, and alert when they rise, which often signals a prompt or tool change gone wrong.

The simplest safe rule is to keep the current session id for the rest of that conversation and link it to the account in the backend after login, so history continues and nothing from other sessions is pulled in. If you want logged-in guests to resume chats across devices, the backend maps the account to its session ids and chooses which to reuse. What I'd avoid is merging histories automatically, because a shared device could mix two people's details. Booking ownership should be tied to the verified account or contact, not only the chat session.

Pass the restaurant identity from the backend on every run, for example through tweaks or as an input, and have the tools use it so availability and bookings go to the correct restaurant's reservations system. The prompt can include restaurant name, hours and policies loaded per tenant. Session ids must be unique across all restaurants so memory never crosses tenants. The tools should take the restaurant id from trusted backend input rather than from the model, so a guest can't trick the agent into booking at another restaurant. Traces should be tagged by restaurant for per-tenant review.

Because history is keyed by session id, the backend must know which sessions belong to that guest, through the account or the linked contact details. We delete message history for those sessions in Langflow's database and remove or anonymise matching traces in Langfuse or LangSmith, which store copies of message text. The booking record in the reservations system may have its own retention rules, since the restaurant may need it for the reservation itself, and that should be explained in the privacy notice. A scheduled retention job should also clear old sessions automatically.

If other AI clients need to make reservations, for example a voice assistant or an internal staff copilot that supports MCP, Langflow can expose the flow as an MCP tool rather than us building a separate integration. The same safeguards still apply because the tools and reservations system enforce them. I'd be careful about session handling and authentication, since MCP clients must still supply a proper session or identity, and I'd only expose flows intended for that audience. For the public website alone, the normal backend-to-API path is simpler.

First find where the time goes using traces: model calls, tool calls or history loading. Then reduce work: trim history to a sensible window, keep the prompt short, and make tool outputs compact. Use a faster model if quality holds up in tests. Speed up the reservations API or cache read-only data like opening hours, though not availability for final booking. Avoid needless extra agent iterations through clearer tool descriptions. On the website, show a typing indicator and stream the reply if the backend supports it, so the wait feels shorter.

For a live chat, the run API fits better: the backend calls POST /api/v1/run/<flow-id> with the message and session_id and waits for the reply to show the guest. Webhooks suit event-driven triggers where another system pushes data in, such as a messaging platform sending an incoming message or the reservations system notifying about a cancellation. If we later connected a channel that delivers messages by webhook, we'd still need to map its user or conversation id to a stable session id so memory stays separate.

1. APOST /api/v1/chat/<session-id>
2. BPUT /api/v1/run/<flow-id>
3. CPOST /api/v1/run/<flow-id>Correct answer
4. DGET /api/v1/flows/<flow-id>

Why: Langflow flows are run through POST /api/v1/run/<flow-id>, with the message and session_id in the request.

1. AThe language model
2. BThe guest typing it in the chat
3. CThe chat backend, tied to the browser session or logged-in guestCorrect answer
4. DA random value generated fresh on every message

Why: The backend issues and reuses a trusted session id so memory stays tied to one conversation and cannot be spoofed.

1. AAfter every Check availability call
2. BAs soon as a free slot is found
3. COnly after the guest explicitly confirms the read-back detailsCorrect answer
4. DWhenever the guest mentions a date

Why: The workflow requires an explicit confirmation of read-back details before any booking is written.

1. ATell the guest the table is booked
2. BTreat the result as unknown and retry with the same idempotency keyCorrect answer
3. CRetry with a new idempotency key
4. DCreate a booking directly in the database

Why: A timeout may hide a successful write; retrying with the same key returns the existing booking instead of duplicating it.

1. AThe session id passed on each run and used by Message HistoryCorrect answer
2. BA higher model temperature
3. CStoring history inside the Prompt component
4. DA different flow per guest

Why: Message history in Langflow is keyed by session id, so passing a unique session id per conversation scopes memory to that guest.

1. AMessage History
2. BThe reservations systemCorrect answer
3. CThe Langfuse trace
4. DThe agent's last reply

Why: Only the reservations system actually holds bookings; the bot may confirm only what it returns.

1. AIn the Chat Output component
2. BIn the prompt instructions
3. CAtomically in the reservations system on writeCorrect answer
4. DIn Message History

Why: Capacity must be enforced by the system of record with a transaction or conditional write; availability checks are only snapshots.

1. ABy switching them to tool mode and connecting them to the agentCorrect answer
2. BBy adding them to Message History
3. CBy exporting the flow as JSON
4. DBy placing them in the Prompt

Why: The Agent takes tools such as components switched to tool mode, other flows or MCP tools.

1. AA friendly sentence for the guest
2. BStructured results such as slots and a clear statusCorrect answer
3. CThe full restaurant schedule for the year
4. DNothing, it only logs

Why: Structured results let the agent offer real options and recognise none-available or error cases without guessing.

1. APrompts only apply to the first turn
2. BPrompts are ignored by agents
3. CModels can still err or be manipulated, so code checks are neededCorrect answer
4. DPrompts cannot mention bookings

Why: Instructions guide behaviour but are not guarantees; tools, the reservations system and backend checks enforce correctness.

1. AA timestamp of each retry
2. BChosen by the model each time
3. CStable for retries of the same confirmed request, new for a changed requestCorrect answer
4. DThe guest's phone number alone

Why: Retries must repeat the key to avoid duplicates, while genuinely different bookings need different keys.

1. AThe tracing integration
2. BThe guest
3. CThe language model
4. DThe Create booking tool code or backendCorrect answer

Why: Deterministic code keeps the key consistent; leaving it to the model risks accidental variation.

1. AMessage History
2. BChat Input
3. CPromptCorrect answer
4. DChat Output

Why: The Prompt component carries the host-style rules, such as never stating availability without the tool.

1. AEnd the chat silently
2. BSay booked anyway
3. CExplain it was just taken, re-check availability and offer alternativesCorrect answer
4. DRetry the same booking endlessly

Why: Availability is a snapshot; the honest recovery is to recheck and offer real alternatives.

1. ABackend verification that any confirmation matches a real booking resultCorrect answer
2. BUsing a bigger model
3. CHiding the chat history
4. DA longer prompt

Why: Checks outside the model hold even when the model is manipulated.

1. ABy raising the context window
2. BBy pasting the schedule into Chat Output
3. CBy connecting a component switched to tool mode to the Agent's toolsCorrect answer
4. DBy adding a webhook to the Prompt

Why: The Agent component takes tools, such as components switched to tool mode, other flows or MCP tools, and calls them as needed.

1. ARestart Langflow with new environment variables
2. BDuplicate the flow on the canvas
3. CPass tweaks in the POST /api/v1/run/<flow-id> requestCorrect answer
4. DEdit the Message History component

Why: Tweaks in the run API override component settings per request, so one flow can serve several branches.

1. AIn the Prompt component
2. BIn the browser only
3. CIn the model provider
4. DIn Langflow's shared database keyed by session idCorrect answer

Why: Message history is stored against the session id in the database, keeping workers mostly stateless and horizontally scalable.

1. AThe tracing tool's storage
2. BA local file database on each instance
3. CA shared database such as PostgreSQLCorrect answer
4. DNo database, keep memory in RAM

Why: Instances must share history; a single shared production database like PostgreSQL supports that.

1. ABetter recall but higher cost, latency and possible confusionCorrect answer
2. BLower cost and faster replies
3. CIt leaks other sessions
4. DIt disables tools

Why: Longer history keeps details but makes prompts longer, slower and pricier, and stale details can confuse the model.

1. AAsk the reservations system to parse it
2. BBook for the next available 8 pm anytime
3. CGuess from the model's training data
4. DUse the current date and restaurant time zone passed in, and read back the absolute dateCorrect answer

Why: Providing current date and time zone lets the agent resolve an absolute date, which the read-back then lets the guest verify.

1. AWrites the booking
2. BReturns the reply to the backend for displayCorrect answer
3. CStores the guest's credit card
4. DChecks availability

Why: Chat Output returns the reply, such as a booking reference, alternatives or a follow-up, to the backend.

1. AIt is required to call tools
2. BIt encrypts the messages
3. CIt speeds up the model
4. DIt lets failed bookings and odd answers be reviewed per conversationCorrect answer

Why: Tagging traces by session ties each run to a specific guest conversation for debugging and audits.

1. AIn the website's JavaScript
2. BIn the Prompt text
3. CIn Message History
4. DIn tool configuration or environment secretsCorrect answer

Why: Secrets belong in secure configuration, never in text the model or browser can see.

1. AYes, it is simpler
2. BNo, the backend should call it with an API key and enforce auth and rate limitsCorrect answer
3. CYes, with the API key in the page
4. DOnly for logged-in users

Why: Exposing Langflow and its key to browsers lets anyone spoof sessions or run the flow freely.

1. ADisable tracing completely forever
2. BRedact or mask PII where possible, restrict access and set retentionCorrect answer
3. CShare traces publicly for transparency
4. DStore traces in the prompt

Why: Minimising and protecting personal data in traces keeps debugging possible while respecting privacy obligations like the DPDP Act.

1. AA larger prompt
2. BRemoving Chat Output
3. CA maximum iteration limit plus tool timeoutsCorrect answer
4. DMore history

Why: Iteration caps and timeouts stop runaway runs and control cost and latency.

1. ACancelling an existing bookingCorrect answer
2. BAsking for party size
3. CShowing opening hours
4. DChecking availability

Why: Cancel acts on someone's existing reservation, so ownership must be verified by the tool, not the model.

1. AEdit the database directly
2. BPass tweaks in the run API requestCorrect answer
3. CChange Message History
4. DCreate a new session id

Why: Tweaks override component settings per API call without duplicating the flow.

1. ATrusted backend input passed on each runCorrect answer
2. BThe model's guess
3. CThe tracing tool
4. DWhatever the guest says in chat

Why: Taking tenant identity from the backend prevents a guest from steering bookings to another restaurant.

1. ATo store chat memory
2. BTo let other MCP clients, such as an assistant, use the booking flow as a toolCorrect answer
3. CTo replace the reservations database
4. DTo speed up the website

Why: Langflow can expose flows as tools to MCP clients, enabling reuse by other AI clients.

1. AAs YAML files
2. BAs SQL views
3. CAs Python classes with inputs and outputsCorrect answer
4. DAs prompt templates only

Why: Langflow custom components are Python classes defining inputs and outputs.

1. AThe tracing dashboard
2. BThe model provider's console
3. CProduction with real guests
4. DThe Playground with a sandbox reservations systemCorrect answer

Why: The Playground lets you test flows interactively, and a sandbox avoids creating real bookings.