TL;DR for operators Fofadiya and Tiwari propose a context-management system for long-running LLM interactions that does more than summarize old conversations.1 It scores historical turns by relevance, recency, dialogue dependency, and coherence, then applies a three-level policy: retain high-value turns verbatim, summarize medium-value turns, and remove low-value history when the context budget requires it. ...
TL;DR for operators Conversation history helps emotion recognition, but this paper shows that having the whole conversation available is not the same as extracting the affective signal that persists across it. Using the same frozen RoBERTa utterance representations, a structured atmosphere prior scores 71.29 versus 67.86 on IEMOCAP and 69.22 versus 63.63 on MELD; it also improves EmoryNLP and DailyDialog. AtmosERC then reuses that prior inside a lightweight classifier, while a prompt-level variant converts it into a textual cue for LLMs. The lightweight model leads reported baselines on three of four datasets, and the LLM cue improves all three tested general-purpose LLMs on both evaluated datasets. ...
TL;DR for operators A conversational system can hear the user’s words correctly and still miss that the exchange has broken down. A glance, facial change, posture shift, or gesture may signal that the other person did not understand and needs clarification. The study tests whether adding those visible behaviors to text and audio improves recognition of these breakdown signals, known as Other-Initiated Repair (OIR). It does in both evaluated corpora. On a performance measure that gives each repair class equal weight (macro-F1), adding the visual branch improves both OIR detection and repair-type classification over the text-plus-audio baseline.1 ...
TL;DR for operators Small models are not necessarily as incapable as their standard evaluations make them look. On bounded tasks, the wrong training and scoring interface can conceal useful capability. A correct retraction is not necessarily a successful recovery. Users may accept the correction while losing confidence in the agent that created the problem. The two papers imply a full-stack rule: train the system through the interface that matches the decision, then repair errors through the agent that owns the relationship. Backend specialization and frontend continuity are compatible. An expert model can verify the correction, but the original user-facing agent should acknowledge and communicate it. Evaluation should measure both sides of reliability: whether the system gets the decision right and what happens to user trust when it does not. The model is not the whole system AI deployment discussions still have an unfortunate habit of treating model capability as if it were a fluid stored inside a parameter tank. Larger tank, more intelligence. Smaller tank, less intelligence. Procurement can then proceed by comparing benchmark columns and invoices. ...
The meeting-room test AI still fails Meeting rooms are unforgiving places for intelligence. A person can know the topic, understand the slides, recognize every face around the table, and still be a terrible participant. Speak too early, and they interrupt. Speak too late, and the moment has passed. Say something factually relevant but socially tone-deaf, and the room quietly deducts points. No spreadsheet records this. Everyone notices anyway. ...
Customer support has a familiar failure mode: the first answer sounds polished, the second answer sounds patient, the third answer sounds as if the system has quietly forgotten what problem it is solving. The user is still there. The emotional state has changed. The unresolved issue has shifted. The model, meanwhile, keeps producing individually acceptable replies, like a waiter bringing one beautifully plated dish at a time to the wrong table. ...
Battery. At 5 p.m., the grid wants help. The evening peak is approaching, the aggregator needs 3 kW of flexibility between 17:00 and 19:00, and one household in the portfolio looks promising. In the old demand-response world, this might become a price alert, an app notification, or a silent automated command. The household either complies, ignores it, or discovers later that the “smart” system has made a decision that feels less smart when dinner, laundry, or comfort is involved. ...
Affective Inertia: Teaching LLM Agents to Remember Who They Are A chatbot does not need to forget your name to become strange. Sometimes the stranger failure is tonal. The assistant is patient for ten turns, defensive on the eleventh, apologetic on the twelfth, and oddly cheerful on the thirteenth. Nothing in the user’s goal changed. Nothing in the product specification said “please behave like an emotionally unstable intern with excellent grammar.” Yet the agent flips. ...
Voice AI has a very old interface problem wearing very expensive new clothes: it still has to guess whether the user is following. A chatbot can ask, “Was this helpful?” A voice assistant can wait for silence, hesitation, interruption, or a sigh that the microphone may or may not catch. A customer-support bot can count clicks, retries, and abandonment. But none of these signals directly tells the system what is happening inside the user while the conversation unfolds. Is the user overloaded? Bored? Confused? Privately disagreeing with the answer but too polite, tired, or irritated to say so? ...
A customer support bot does not need a soul. Pleasantly, most airlines have not yet advertised one. But it does need to remember what role it is playing. If it gives policy advice, that advice must remain anchored to the policy. If it apologises for an error, the correction should bind future answers. If the company has told users the assistant is a support agent, the assistant cannot conveniently become a speculative travel blogger, a therapist, a lawyer, or a magic refund machine, depending on which prompt arrives next. ...