What are feedback-driven memory updates?

Preference drift can be inferred from conversation. Feedback-driven updates start from a clearer signal: the user marked the outcome. A thumbs-down on a suggestion, a star rating on a completed job, a “correct this” control that rewrites a field—these events say the agent’s current memory-backed belief was wrong or incomplete. Personalization research that learns agents from human feedback stresses a loop with memory in the middle: retrieve preferences, act, then integrate post-action feedback so the next retrieve is wiser.

This chapter treats structured feedback as a first-class write trigger into Weaviate Engram, separates weak ratings from strong corrections, shows how to bind feedback to the memories that caused the action, and walks a violin pegbox desk through a dislike that revises standing guidance. The following chapter zooms in on free-text feedback as its own signal shape.

Why is explicit feedback worth a separate write path?

Ordinary chat already flows through Engram’s conversation extraction. Structured feedback deserves its own path because it carries intent the transcript may bury. A user can politely accept a bad suggestion in chat while clicking thumbs-down in the UI. Conversely, a chat vent may not be a durable preference. Feedback events are labeled: positive, negative, rating, field correction, regenerate request. Your application can map those labels to write gates without asking the pipeline to guess salience from tone alone.

The loop looks like this. Before acting, search Engram (bounded profile plus relevant preference topics). Act with that context. After the user rates or corrects, build a small feedback record—what was shown, which memory ids were cited, what the user signaled—and send it to Engram as conversation or pre-extracted content under the same user_id. Transform reconciles against prior preferences. Strong negatives that name a standing rule should update or revoke the active memory that misled the agent.

Skipping the bind step is the usual bug. A thumbs-down with no link to “which suggestion” and “which memories” becomes a vague “user unhappy” note that never fixes retrieval. Feedback without provenance cannot teach. If your UI cannot pass suggestion ids yet, at least pass the rendered proposal text so extraction has something concrete to correct against.

How should different feedback strengths change Engram?

Not every signal deserves the same mutation. A light positive rating can reinforce that the retrieved preferences were adequate—optional, low-priority writes, or simply analytics with no memory mutation. A light negative without detail may trigger a clarification question rather than an immediate delete. A strong correction—“wrong wood,” “never use that cutter geometry”—should create a durable preference memory and supersede the conflicting one. A field-level edit on a saved profile card can patch the bounded UserProfile directly via a write that the pipeline consolidates in place.

Pre-action clarification is part of the same feedback economy. When search returns nothing reliable for a new user, ask before acting, then store the answer as Engram memory. That prevents the confidently wrong first action that only post-action feedback can repair. Feedback-driven design is therefore not only reactive; it budgets questions when memory is empty. Pre-action asks are cheaper than post-action apologies when the wrong pegbox geometry wastes a blank.

Keep organizational SOPs out of feedback mutation. If the user downvotes a policy-compliant refusal, that is a product or policy ticket—not a personalization write that teaches the agent to violate the collection plane.

What application machinery makes feedback updates reliable?

Log the memory ids injected into the prompt for each action. Store them on the feedback event. When integrating, include those ids in the content you send to Engram or use them to target memories.delete / supersede after a confirmed conflict. Prefer topics dedicated to feedback-derived preferences or route into existing preference topics with descriptions that mention corrections. Use group personalization (or your equivalent) and always pass user_id.

Rate-limit automatic writes from spammy button mashing. Require confirmation for destructive revokes when the feedback is ambiguous. Observe run completion so the UI does not claim “saved” while the pipeline is still running. For bounded profile topics, confirm the single memory updated rather than spawning unbounded clones of the same standing rule.

Test with persona-shift scenarios: the agent acts on an old preference, the user downvotes and corrects, the next session must retrieve the new preference. If the old memory still ranks into the prompt, your feedback path did not revoke—it only appended, which is how pollution returns. Make that regression test part of release criteria for any personalization surface that exposes thumbs or ratings.

What does a feedback update look like at a violin pegbox desk?

A luthier assistant suggests pegbox carving geometry for Mira, she thumbs-down, and corrects the rake she wants. Scenario id: violin-pegbox-carving-desk-8.

from weaviate.engram import EngramClient
from weaviate.engram.retrieval import HybridRetrieval

engram = EngramClient()
user_id = "luthier-mira"
group = "personalization"
scenario = "violin-pegbox-carving-desk-8"

# Pre-action: ground in memory
cited = engram.memories.search(
    query="pegbox rake carving geometry preference",
    group=group,
    topics=["carving_preferences", "UserProfile"],
    retrieval=HybridRetrieval(alpha=0.5, limit=4),
    scopes={"user_id": user_id},
)
cited_ids = [m.id for m in cited]

# ... agent proposes a geometry using cited memories ...

# Post-action structured feedback from UI
feedback_event = {
    "type": "thumbs_down",
    "correction": "Too upright. I want a shallower rake on student instruments.",
    "cited_memory_ids": cited_ids,
    "suggestion_id": "sug_pegbox_17",
}

feedback_conversation = [
    {
        "role": "assistant",
        "content": f"Proposed pegbox geometry (suggestion {feedback_event['suggestion_id']}).",
    },
    {
        "role": "user",
        "content": (
            f"Feedback: {feedback_event['type']}. {feedback_event['correction']} "
            f"This corrects memories: {', '.join(feedback_event['cited_memory_ids'])}."
        ),
    },
]

run = engram.memories.add(
    content=feedback_conversation,
    group=group,
    scopes={
        "user_id": user_id,
        "properties": {"scenario": scenario, "source": "structured_feedback"},
    },
)

# Optional hard revoke if a specific outdated preference must leave the active set
# for mid in feedback_event["cited_memory_ids"]:
#     if is_conflict(mid, feedback_event["correction"]):
#         engram.memories.delete(memory_id=mid)

The thumbs-down is not stored as ambient mood. It is a correction tied to suggestion and cited memories, sent through Engram so transform can reconcile carving preferences—and optionally delete the upright-rake note that caused the miss. Next retrieve should prefer the shallower-rake standing guidance. That is feedback-driven memory: explicit signals, provenance, gated writes, visible revocation when needed. The button is only the start; Engram persistence is what makes the lesson survive the next session.

Structured feedback updates Engram when you bind ratings and corrections to the memories that shaped the action, scale write strength to signal strength, and revoke stale preferences instead of only appending. Our next chapter, How does natural-language feedback become a memory signal?, focuses on free-text corrections and comments when there is no thumb control—only words.