Feedback loop

A context feedback loop links what an agent received to what happened afterward. It can distinguish useful, wrong, stale, and missing context and provide evidence for later retrieval or policy changes. The exact customer-visible feedback contract is evolving and is not part of the frozen public caller-memory REST trio.

The intended record

A useful feedback event needs:

• the tenant and stable context-read identifier;
• the task or interaction it informed;
• a bounded verdict such as helpful, wrong, stale, or missing;
• an optional correction with source evidence;
• safe timestamps and producer identity;
• no unnecessary transcript, secret, or personal data.

The record should say what was observed. It should not let a single click silently rewrite a durable fact or policy.

Why feedback is not automatic learning

“Helpful” may correlate with a good outcome without causing it. “Wrong” may identify stale context, a bad entity mapping, or an agent that ignored correct context. A robust system preserves the event, tests counter-hypotheses, and changes retrieval only through a measured and reversible process.

Future calibration, fact-supersession proposals, and salience tuning therefore require separate mechanisms and gates. They are not implied by collecting feedback.

How to evaluate the evolving MCP path

Inspect the deployed tools/list, identify the exact feedback tool and schema if present, and prove one controlled lifecycle: create or observe a test interaction, request context, submit a verdict, and inspect the resulting state. If any step is unobservable, record it as unproven rather than inferring success from a tool response.

The caller-memory REST lifecycle uses a later read to verify calls/end; it does not expose a separate feedback endpoint.

Continue with MCP server, Salience and Beacon (design stage), and Production readiness.