Short answer: Casual mid-conversation corrections carry extractable lessons and deserve their own feedback category, not only a vague unhappy note.
Phrases like filter by genre instead of name are actionable instructions. Capture with the prior task context so the lesson is unambiguous. Not every remark that sounds like feedback should be stored. Engram can store natural-language feedback as a distinct, reusable signal for later turns.
The previous chapter looked at how a system reacts to feedback once it’s already been captured, updating a memory to reflect what was learned. This chapter looks a step earlier, at the feedback itself, specifically the kind that arrives as an ordinary sentence typed in the middle of a conversation, and why that plain, unstructured wording is actually a genuinely rich signal worth extracting deliberately rather than treating as just another passing remark.
Why Does a Person’s Casual Correction in the Middle of a Conversation Actually Count as a Meaningful Signal Rather Than Just Conversational Noise?
When someone tells an assistant “that’s not quite right, I meant the version from last quarter” or “you should have filtered by category instead of searching by name,” they’re not making idle conversation, they’re directly identifying a gap between what the system did and what it should have done. This kind of correction carries genuine, specific information about how the system’s behavior needs to change, and treating it as ordinary conversational content to be answered and then discarded throws away exactly the kind of signal a system most needs in order to actually improve.
What Makes Natural-Language Feedback Harder to Capture Correctly Than a Simple Structured Rating or Thumbs-Up Signal?
A structured rating arrives already labeled, a number or a binary signal that’s trivial to store and act on directly. Natural-language feedback arrives as free-form prose, mixed in with everything else being said in the conversation, meaning a system first has to recognize that a given sentence actually constitutes feedback at all, distinguishing it from an ordinary question or a neutral statement, before it can even begin extracting what specifically needs to change. This recognition step is exactly the kind of judgment a rigid, rule-based extraction system struggles with, but a language-model-powered extraction pipeline can generally handle well, since understanding that a sentence is functioning as a correction is itself a language-understanding task.
Why Does Feedback Deserve Its Own Distinct Category Rather Than Simply Being Extracted Into Whatever General Topic Already Covers the Subject Matter?
A sentence describing what a user prefers and a sentence describing that the system got something wrong carry genuinely different functions, even when they’re about the same underlying subject. The first tells a system a fact about the world or the user, the second tells a system something about its own past behavior that specifically needs correcting. Extracting both into the same undifferentiated category loses this distinction, making it harder later to specifically search for “what have I gotten wrong before” separately from “what do I generally know,” a separation that turns out to matter considerably once a system is actually trying to learn from its own mistakes deliberately.
How Does a System Actually Turn a Single Piece of Feedback Into Something Concretely Actionable Rather Than Just a Vague Note That Something Went Wrong?
Useful extraction pulls out the specific, concrete lesson embedded in the feedback, not just the fact that a correction happened. “You should filter on genre instead of searching by name” contains an actual, reusable instruction about behavior, and extracting that instruction directly, rather than a vaguer summary like “the user was unhappy with the search,” is what actually makes the feedback useful the next time a similar situation arises. This kind of extraction often benefits from combining the feedback itself with whatever context led up to it, the original task and the action that triggered the correction, since the feedback alone can be ambiguous without knowing what it was actually responding to.
Does Every Piece of Natural-Language Feedback Deserve to Be Captured and Acted On, or Does Some of It Genuinely Not Matter?
Not every casual remark that sounds like feedback is actually worth encoding as a lasting behavioral lesson, a one-off preference expressed in a specific, unusual context might not generalize to anything a system should change more broadly. This is exactly why feedback extraction benefits from the same deliberate topic design covered earlier in this knowledge base, a well-written topic description helps a system distinguish feedback that reflects a genuine, generalizable lesson from an offhand comment that happens to be phrased similarly but doesn’t actually warrant a lasting change in behavior.
How Does Weaviate Engram Let a System Capture Natural-Language Feedback as Its Own Distinct, Actionable Memory Signal?
Weaviate Engram’s topic configuration lets a system define a dedicated feedback category, extracting a person’s corrections separately from ordinary factual memory and combining that feedback with the surrounding context needed to make it genuinely actionable. Consider a virtual interior-design assistant helping clients furnish rooms, where a client’s casual correction about style preferences carries a concrete lesson worth remembering for every future recommendation:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
[
{"topic": "task_goal", "content": "Client asked for furniture recommendations for a home office."},
{"topic": "actions_taken", "content": "Assistant recommended a heavy, ornate wooden desk."},
{"topic": "feedback", "content": "That's too traditional for my taste, I prefer minimalist Scandinavian pieces with clean lines."},
],
user_id="client-interiordesign-6604",
)
design_lessons = client.memories.search(
query="What has this client told me about their style preferences in the past?",
user_id="client-interiordesign-6604",
topics=["feedback"],
)
Capturing the client’s correction as its own distinct feedback memory, alongside the original recommendation that prompted it, gives the assistant a concrete, reusable lesson about this specific client’s actual taste, one it can draw on the next time it’s recommending furniture for any room in their home, rather than treating the correction as a passing remark that gets answered once and then forgotten. This is exactly the value capturing natural-language feedback as a distinct signal delivers for a use case like interior design assistance, where a client’s own casual correction, phrased in plain conversational language, actually contains the exact preference information the assistant needs to stop making the same kind of recommendation again.
Natural-language feedback carries a specific, extractable lesson embedded in ordinary conversational wording, and capturing it as its own distinct signal is what lets a system actually learn from a correction rather than simply responding to it once and moving on. Our next chapter, How do you personalize agents without per-user model training?, takes up how this kind of accumulated, per-user learning can shape an agent’s behavior without ever requiring a separate model to be trained for each individual user.