Skip to content

ADR-055: Sync agent skill surfaces only profile-derived content - situational reasoning is user-initiated

Status: Accepted Date: 2026-05-13 Context: During live testing of SKILL.md v3.0.0 on May 13, 2026 (three Bucket B questions: job offer, case study vs integration, quiet team member), a consistent pattern emerged: the "why" expansion ended with a flip condition in all three cases, and all three flip conditions were situational common-sense advice rather than content derived from the user's Sync profile. Examples: "if Beacon has a near-term inflection" (obvious given the runway framing), "if you have a warm pipeline" (obvious given the question), "if you are the cause of the silence" (standard interpersonal advice any advisor would give). The v3.0.0 instruction said "name the key unknown that would change the recommendation" without specifying that the unknown must come from the profile.

At a glance

What it decides: The agent's "why" expansion surfaces only content the Sync profile actually knows — flip conditions appear only when the profile holds a relevant calibration, persuadability, or context signal. Generic situational advice is left for the user to raise as a follow-up.

  • Core rule — if it could appear in a no-Sync agent's answer with the same personal_context, it doesn't belong inside the Sync skill layer; general reasoning is the base model's job.
  • Why it matters — mixing situational advice into the "why" causes misattribution (users credit it to Sync), which corrodes trust in the parts that are profile-derived (3-of-3 flips were generic in the first test).
  • Alternatives rejected — moving flips into the headline, labeling situational content ("not from your profile"), and dropping flips entirely; profile-derived flips earn their place because only the profile can produce them.
  • Consequence — "why" expansions without a profile flip end cleanly after the anchor + feedback prompt; revisit if profile-derived flips never appear across a larger sample.

Decision

The "why" expansion surfaces only content derived from the user's Sync profile. Flip conditions are included only when the profile contains a directly relevant calibration signal, persuadability pattern, or context rule. If no profile-derived flip exists, the "why" ends after the scenario anchor and feedback prompt. Situational variables are for the user to raise as follow-ups ("when would this change?") - the agent answers when asked, but does not pre-emptively surface them unprompted.

Rationale

The "why"'s contract is profile reasoning, not general consulting advice. When a user asks "why," they are asking why the Sync profile points toward this recommendation. A situational flip condition ("if you are the cause") answers a different question - what to check before acting - and is outside the scope of what "why" is answering. It belongs in a follow-up exchange, not pre-emptively in the profile reasoning layer.

Misattribution risk. When situational advice appears in the "why" alongside profile-derived content, users naturally attribute all of it to the profile. This creates false trust - the user believes Sync "knew" something it didn't. If users later notice that flip conditions are always generic (three for three in the first test session), it undermines trust in the parts that ARE profile-derived. Keeping the "why" pure prevents this.

Labeling doesn't solve it. An alternative considered was labeling situational content ("one note not from your profile:"). This is honest but breaks the voice, invites the user to question everything else in the response, and implicitly admits the "why" is mixing signal types. Cleaner to remove the content entirely.

Users can ask. A user uncertain about what would change the recommendation will naturally ask: "when would this change?" or "what if X?" The agent answers. That is a normal conversational follow-up, not a design failure. The user who acts immediately on the headline doesn't need the flip surfaced at all.

General reasoning belongs to the base model, not the skill layer. The Sync skill's job is to contribute what the base model cannot: insight from the user's actual decision history. Situational advice any thoughtful advisor would give is already part of Opus 4.7's baseline capability. Surfacing it inside the skill layer falsely credits it to Sync.

Alternatives Considered

  • Move situational flips to the headline as qualifiers ("Reach out - unless you think you're the cause, in which case name it directly"): Rejected. The headline's job is one thing: give the recommendation. Adding qualifiers to find a home for Tier 2 content trades headline clarity for completeness. The user who needs the qualifier can ask.

  • Label situational content explicitly ("One situational note, not from your profile:"): Rejected. Breaks the voice, invites skepticism about all other content, and is an awkward admission that the "why" is mixing signal types. Cleaner to remove than to label.

  • Keep as-is (always include a flip condition): Rejected. Three for three in the first live test confirms the pattern is structural, not incidental. The instruction "name the key unknown" will always produce a situational variable when no profile-derived flip exists - the model defaults to the most obvious situational consideration. No amount of testing will change this without changing the instruction.

  • Cap the "why" at pattern + anchor, no flip at all: Considered. Simpler and avoids the question entirely. Rejected in favor of allowing profile-derived flips because those are genuinely high-value - a persuadability note or calibration signal that warns the user about their own blind spot is exactly the kind of content only the profile can produce, and it earns its place.

Discussion

The core principle surfaced here: Sync only tells the user what their profile actually knows. This applies beyond flip conditions. It should be the governing rule for any future content that gets added to the "why" expansion - if it could appear in a response from a no-Sync agent with the same personal_context, it doesn't belong inside the Sync skill layer.

This connects to the delegation-trust thesis (see project memory: project_agent_skill_delegation_trust_thesis.md). The trust case rests on the user recognizing that Sync-augmented recommendations are grounded in their actual decision history. If generic advice is mixed in, the trust case weakens - users can't distinguish what Sync contributed and what the base model would have said anyway. Keeping the layers clean is what makes the comparison legible.

The "user-initiated flip" pattern also fits the concise-first design principle from ADR-047's Outcome section: short answer, "why" on demand, reasoning on demand. Situational considerations are a third layer - they go behind a third trigger, not front-loaded.

Consequences

  • "Why" expansions without a profile-derived flip condition end after the scenario anchor + feedback prompt. This is intentional - a clean ending is better than padding with generic advice.
  • Users who want situational reasoning ask a follow-up. The agent answers. No change to how the agent handles follow-up questions.
  • The "why" word count drops on questions where no profile-derived flip exists. This is a secondary benefit - aligns with Cici's token-cost concern (May 9, 2026).
  • The misattribution risk is structurally removed rather than managed through labeling.
  • Future "why" content additions should be evaluated against the same principle: does this come from the profile, or is it Tier 2 reasoning the base model would produce anyway? If Tier 2, it does not belong in the "why."
  • Revisit if profile-derived flips never appear across a larger test sample. If the profile rarely contains relevant calibration signals or persuadability patterns, the flip condition instruction becomes effectively a no-op and could be removed entirely.

Key files: - public/agent-skill/SKILL.md - v3.1.0, flip condition instruction updated