<?xml version='1.0' encoding='UTF-8'?>
<symptom xmlns="urn:adm:1" id="S003" version="1" status="draft" evidence="unvalidated" updated="2026-10-26" title="Sudden performance degradation">
  <summary>An agent shows an abrupt, observable decline relative to its own recent performance on comparable work.</summary>
  <observations>
    <observation id="performance-drop">
      <p>Across a bounded transition, performance worsens on a named measure relative to a recorded earlier baseline: for example, more errors on comparable tasks, missed constraints, reduced completion, or greater time or cost for the same accepted result.</p>
    </observation>
  </observations>
  <how-to-recognize-it>
    <p>Specify the measure and comparison before attributing the decline. Identify the last adequate and first degraded work, and compare task difficulty, available information, acceptance criteria, tools, and environment. A change in style or a general impression of reduced intelligence is a lead to investigate, not enough to establish a performance drop.</p>
    <p>Use repeated comparable tasks when available. For a single session, identify concrete before-and-after behavior under the same relevant constraints and retain uncertainty about ordinary variation. Describe how abrupt the change was in turns, time, or releases; there is no universal effect-size or time threshold in this draft.</p>
    <p>The observable decline can be real even when its cause is unknown. Changes to model, effort, instructions, harness, context, or service conditions are possible explanations, not part of the symptom definition. <ref target="S006">Lost task constraints</ref> and <ref target="S002">Doom looping</ref> may describe particular ways the decline manifests.</p>
  </how-to-recognize-it>
  <benign-lookalikes>
    <lookalike id="harder-work">
      <p>Later tasks require different skills or greater complexity, so the earlier success rate is not a comparable baseline.</p>
    </lookalike>
    <lookalike id="changed-standard">
      <p>The user changes acceptance criteria or requests faster, shorter, or cheaper work and observes the resulting tradeoff.</p>
    </lookalike>
    <lookalike id="isolated-miss">
      <p>One stochastic failure follows a small number of successes without enough evidence of a sustained or repeatable shift.</p>
    </lookalike>
  </benign-lookalikes>
  <what-to-record>
    <p>Record the baseline and later tasks or trace segments, explicit performance measures, errors and outcomes, transition interval, and sample sizes. Preserve model/client versions, effort settings, prompts, tool availability, context transitions, service incidents, and environmental differences. Keep perceived change, measured change, and proposed cause distinct.</p>
  </what-to-record>
  <examples>
    <example id="abrupt-omissions" kind="synthetic">
      <p>Synthetic example: an agent correctly processes six records using the same explicit four-field rule, then omits two required fields on each of the next six comparable records after a session transition. The omissions establish a local decline; the transition alone does not establish its cause.</p>
    </example>
    <example id="quality-postmortem" kind="observed">
      <p>Reported investigation: <a href="https://www.anthropic.com/research/april-23-postmortem">Anthropic’s April 23, 2026 postmortem</a> attributes quality complaints to separate effort, context-management, and system-prompt changes. One bug repeatedly dropped prior thinking after an idle session resumed. These confirmed product incidents do not explain an unrelated episode automatically.</p>
    </example>
    <example id="different-task" kind="synthetic">
      <p>Synthetic comparison: an agent succeeds at five typo fixes and then fails a distributed-systems redesign. The change in task difficulty prevents using that sequence alone as evidence of sudden degradation.</p>
    </example>
  </examples>
</symptom>
