Skip to content

ADR-056: Record "why" requests as a behavioral trust signal

Status: Accepted Date: 2026-05-13 Context: During live testing of SKILL.md v3.0.0 on May 13, 2026, a colleague observed that a user choosing to ask "why" after a recommendation is itself a meaningful data point. If the headline alone was sufficient and trusted, the user wouldn't need to ask. If they ask, they're either uncertain about the recommendation, curious about the reasoning, or calibrating how much to rely on the agent. All three are trust-relevant. The question is whether we can measure this.

Decision

Record whether the user asked "why" on each profile read. When the agent calls sync.get_recent_decisions and passes the read_id from the preceding get_profile call, the server marks why_requested = true on that row in agent_profile_reads. This links the follow-up behavior (asking "why") back to the specific read, enabling future analysis of whether "why" requests correlate with feedback ratings, decision domains, or profile richness.

Implementation: - agent_profile_reads.why_requested BOOLEAN DEFAULT false (migration 094) - sync.get_recent_decisions accepts optional read_id (uuid) parameter - Server marks why_requested = true on the agent_profile_reads row matching that read_id when it arrives - SKILL.md v3.2 instructs the agent to pass read_id from get_profile when calling get_recent_decisions

Rationale

Asking "why" is active engagement, not passive consumption. A user who trusts the headline acts on it without asking. A user who asks "why" is doing something deliberate - testing the reasoning, building trust incrementally, or checking whether the profile actually informed the call. Over time, the presence or absence of "why" requests tells us something about the user's trust state with the agent.

The signal is implicit and low-friction. No survey, no prompt, no explicit trust rating. The user's behavior (asking or not asking) is the measurement. This is the same class of signal as click-through rates or scroll depth - users reveal preferences by what they do, not what they say.

It connects to the delegation-trust thesis. The core bet on Sync is that users who trust the agent will start to delegate rather than approve-everything. The path from approval-fatigue to delegation probably runs through "why" questions: ask why → understand the reasoning → trust the next recommendation without asking. Measuring where users are in that progression helps us understand whether SKILL.md iterations are moving the needle.

Low implementation cost, long-run value. The data is worthless today and potentially very useful in six months. The cost of adding the column and the parameter is trivial. The cost of not having it is that we can never answer the question retroactively.

The read_id linkage is already the right join. agent_profile_reads logs every profile call with a read_id. Feedback already joins back to a read_id. Adding why_requested to that same row means a single join (reads → feedback) exposes the full picture: did they ask why, and did they find it useful?

Alternatives Considered

  • Log "why" as a separate row in a new table: More flexible but introduces a join. The profile read is already the natural unit - one recommendation, one read, one optional "why." Adding a column to the existing row keeps the model clean.

  • Log "why" in agent_response_feedback: Wrong table - feedback is about the quality of the response, "why" is about the user's engagement with the reasoning. Mixing them makes both signals harder to interpret.

  • Infer "why" from tool-call sequence in logs: Possible in theory (get_recent_decisions fired after get_profile = "why" happened), but requires parsing unstructured logs and is fragile if the call ordering changes. Explicit read_id passing is more reliable.

  • Don't track this at all: The signal has no immediate use. But the cost is near-zero and the retrospective value is high. ADR-047 Deferred discipline applies when the cost is high; here the cost is trivial.

Discussion

The core principle: behavioral signals are more reliable than stated preferences. When users say they trust the agent (in surveys or interviews), that is subject to social desirability bias. When they ask "why," they're revealing something real about their current trust state. The fact that asking is low-cost (one word) means the bar for doing it is low, so even a small signal is meaningful.

One open question: is "not asking why" trust, or is it indifference? A user who got a headline and immediately closed the chat might be very trusting or might not care. The submit_feedback call disambiguates somewhat - a user who thumbs-up a recommendation without asking "why" is the clearest trust signal. Combining why_requested = false with rating = up is the gold standard.

This connects to ADR-047's Deferred discipline and the broader instrumentation principle: collect the signal before you know what question you'll ask of it.

Consequences

  • agent_profile_reads gains why_requested BOOLEAN DEFAULT false — migration 094. Existing rows default to false (correct — we don't know whether past reads had "why" requested).
  • sync.get_recent_decisions gains optional read_id parameter — the agent passes the read_id from the preceding get_profile call; the server marks why_requested = true on that row.
  • SKILL.md v3.2 — tool description for get_recent_decisions updated to instruct passing read_id.
  • Future analysis: SELECT why_requested, rating, AVG(rating='up') FROM agent_profile_reads JOIN agent_response_feedback ON ... will surface the correlation once volume accumulates.
  • No behavior change for users — the "why" flow is identical from the user's perspective. This is pure instrumentation.

Key files: - migrations/094_why_requested_signal.sql - schema change - src/lib/agent/mcp.ts - sync.get_recent_decisions tool definition + handler updated - src/lib/agent/load-profile.ts - markWhyRequested utility added - public/agent-skill/SKILL.md - v3.2, get_recent_decisions description updated