A Conversational Turn With a Durable Memory

DeskcommCRM’s AI turn is designed to answer a narrow but consequential question: how can a model respond to a customer without becoming the only place where that customer’s state exists? This chapter follows the current engine from a durable job to its opening context, knowledge lookup, explicit send, forced checkpoint, and handoff to operational work. The reader should come away able to separate ephemeral model context from durable product state—and to see why that separation is the foundation of continuity.

A language model is naturally good at producing a next response from the text it can see. It is not, by itself, a reliable database, queue, permission system, or record of what happened after a process is restarted. DeskcommCRM treats the model call as one stage in a larger turn. The runtime decides what the model may see, how it may speak, what must be checked before a message leaves, and what must be written down before the turn is complete.

The opening context is assembled from durable facts

Each job begins a fresh model session. That choice avoids a dangerous kind of hidden state: an in-memory agent that seems to remember a customer only while one process remains alive. A worker can restart, a deployment can replace a container, or a retry can run on another process. If the conversation depends on the old process’s memory, continuity has already failed even if the next model call is technically successful.

A fresh session does not mean an amnesiac agent. It means that memory is reconstructed from sources that the CRM can own and inspect. The opening context can include the published agent configuration and playbook, the person’s contact record, the current conversation, recent messages, the lead’s funnel state, durable notes, and the last linked order or other relevant business object. These inputs answer different questions. The contact identifies the person as far as the organization knows them. The conversation supplies the immediate exchange. The lead state says what business demand is currently open. A note carries a durable fact that should survive the conversation window. A linked order gives the model a concrete transaction rather than an invented reference.

That distinction matters when the customer asks a question that sounds simple but depends on history. “Where is my order?” is not answered well by a generic policy paragraph. The agent may need the conversation’s latest message, the contact’s relationship to the organization, the order linked to the active demand, the pipeline vocabulary used by that business, and a relevant piece of policy or catalog knowledge. Conversely, a model should not receive every table column merely because it exists. Context has a purpose and a budget; excess internal state can increase cost, latency, and leakage without improving the answer.

The boundaries between these inputs also prevent a subtle category error. A recent message is evidence of what the customer is asking now; it is not automatically a durable preference. A lead stage is the organization’s current operational state; it is not proof that the customer used that word. A note can preserve a fact across many turns; it should not silently become a new instruction that overrides a current message. The engine’s job is to assemble these sources with their different meanings intact. That is why a compact, well-scoped context can be more useful than a much larger transcript: it tells the model which facts are current, which are durable, and which are retrieved evidence rather than conclusions.

The knowledge layer adds controlled recall.