The answer that vanishes at reset

The phrase in-context learning names a behavioural pattern before it names a mechanism. A model receives examples or instructions in its input, then performs differently on a new query without changing its trained parameters. GPT-3 made this pattern widely visible, and controlled studies later showed that transformers trained on synthetic function families can construct useful predictors from prompt examples.[1, 3]

The definition is intentionally modest. It tells us when adaptation occurs, not how. The common hidden assumption is that all learning must be stored in weights. If the weights do not move, the model must merely be retrieving something it already knew. That conclusion treats parameters as the only state a computation can possess.

A transformer also has per-request computational state. Every token changes later activations. Attention keys and values derived from earlier tokens remain available during the forward pass. The residual stream carries transformed information from layer to layer. Depending on the serving architecture, a key-value cache may persist across generated tokens. None of this is a parameter update, but it is still a causal change inside the configured system.

Call the trained parameters θ, the demonstrations D, and the new query x*. In-context prediction can be written without claiming any particular internal algorithm:

This simple notation removes one confusion. A fixed function can still produce different behaviour when its input contains a dataset. A spreadsheet formula does not change when its cells change. A database engine does not retrain when a query changes. Likewise, a transformer can use the prompt as data, instruction, index, temporary codebook, or all four.

The more useful factorisation is experimental rather than ontological:

The frame-solver distinction is the paper’s central proposal. Frame construction answers: What is the task, which features matter, what do the labels mean, and what output form is permitted? Solver execution answers: Given that temporary specification, how should this query be handled?

Research on compact function representations gives this proposal some empirical footing. Causal interventions have identified task-related activation directions in particular language models, and layer-wise masking experiments have found points where some models no longer need direct access to the original examples to continue performing the recognised task.[9, 11] These results do not prove a universal task vector. They do show that “the prompt is still visible” and “the task has been compressed into a usable internal state” are separable hypotheses.

This matters because “learning” usually bundles several operations: extracting regularity, changing an internal state, retaining that change, and transferring it later. In-context learning clearly performs the first two. It may perform the third only within a request, and the fourth only when the relevant state is deliberately carried forward. Temporary adaptation is learning with a deliberately narrow retention boundary.

flowchart TD
  A["The answer that vanishes at reset"] --> B["Three solvers inside one<br/>temporary frame"]
  B --> C["Interventions that separate<br/>the stories"]
  C --> D["Build the prompt as a<br/>controlled state"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#D95545,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Three solvers inside one temporary frame

Suppose the model gives the correct warehouse code. The output alone cannot tell us which computation produced it. We need rival generators that agree on ordinary cases and separate under intervention.

The three most useful rivals are retrieval, task inference, and implicit optimisation. They are not exhaustive, and a real transformer may blend them. Their value is that each makes a different causal commitment.

Retrieval: the answer is near an example

Retrieval is the smallest plausible mechanism. Find the demonstration whose input most resembles the query, then reuse its output or continue its local pattern. Attention makes this computationally natural. Induction heads, studied in small transformers, can detect a repeated pattern and copy the token that followed an earlier occurrence.[15] Higher-order variants can estimate next-token distributions from contextual fragments.

A minimal retrieval rule is:

Retrieval explains why example selection often matters. A semantically close demonstration can provide the right vocabulary, format and local transformation. It also explains a particular failure: one highly similar but wrongly labelled example can dominate several globally consistent examples.

Task inference: the examples identify a latent rule

Task inference treats the prompt as evidence about which rule generated the demonstrations. If the model has learned a distribution over possible tasks, it can update its belief when examples arrive. Xie and colleagues showed how in-context learning can emerge as implicit Bayesian inference in a stylised setting where documents have latent concepts and long-range coherence.[2] Later work explored how closely transformers track Bayesian predictors across multiple function families and where they depart.[14]

Suppose the candidate rules are h1: y=x+1, h2: y=2x+1, and h3: y=5-x. The demonstrations change the posterior probability of each rule:

Task inference is not synonymous with conscious hypothesis testing. It is a functional description of a computation. It predicts robustness to a single local decoy when the remaining evidence strongly supports one global rule. It also predicts systematic failure when the true rule lies outside the learned task family.

Training distribution matters because it determines which task families become easy to recognise. Controlled studies found that bursty sequences, many rare classes and changing item meanings can promote in-context learning, while task diversity can produce a transition from a narrow pretraining prior towards behaviour resembling a more general regression algorithm.[4, 8] These are findings about studied distributions, not a universal recipe for language models.

Implicit optimisation: the prompt supplies a tiny training set

The third route constructs a predictor from the examples. In a linear task, the model might behave as though it estimated a slope and intercept. More generally, it might implement one or more update steps on an internal model encoded in activations.

For squared-error regression, a familiar estimator is:

Transformers can be constructed or trained to emulate gradient descent, ridge regression and related estimators on stylised tasks. Akyürek and colleagues found that trained in-context learners could match several standard linear predictors and encode related quantities in late-layer activations. Von Oswald and colleagues gave a weight construction linking linear self-attention to a gradient step and observed closely matching behaviour in controlled regression models.[6, 7]

Capability to implement an optimiser is not evidence that every pretrained language model uses that optimiser. The construction establishes possibility under specified assumptions. Mechanism claims require interventions on the actual model, task and training regime.

The three routes can also cooperate. Retrieval can supply a relevant local example. Task inference can identify the output convention. An optimiser-like computation can estimate the remaining relation. The frame-solver distinction accommodates such mixtures because it asks two questions in sequence: what temporary problem representation was constructed, and what computations used it?

Interventions that separate the stories

A mechanism claim becomes useful when it tells us which single change should alter behaviour. The following experiments preserve most of the prompt while changing one causal property at a time.

Label experiments also reveal why the phrase “learn from examples” can mislead. In a set of classification and multiple-choice tasks, Min and colleagues found that randomly replacing demonstration labels often barely reduced performance. The examples still communicated the input distribution, label space and sequence format.[5] This does not show that mappings never matter. It shows that a prompt can help by constructing the frame even when it provides weak evidence for the exact decision rule.

The rotation test also sets a boundary on the coordinate metaphor. A prompt may establish a usable frame without making the solver invariant to arbitrary transformations. Frame construction and solver quality are separate. A clear task representation can still feed a brittle procedure.

One prompt can carry four different kinds of evidence

A demonstration is not a single teaching signal. It can identify the task boundary, bind arbitrary labels, reveal a statistical relation, and specify the required output form. Those functions can be separated.

Remove the labels but keep the input examples and formatting. If performance remains above the instruction-only baseline, the prompt may be helping the model recognise the domain or expected response shape. Keep the labels but replace each input with unrelated text. If performance collapses, label exposure alone was insufficient. Preserve the input-output pairs but alter punctuation and order. A large change implicates the interface through which the frame was constructed, not necessarily the abstract task.

This decomposition clarifies an apparent disagreement in the literature. Some experiments found that corrupted demonstration labels barely hurt several classification tasks, suggesting that label space, input distribution and format supplied much of the benefit. Other experiments found that sufficiently large models can learn deliberately flipped or semantically unrelated mappings, especially with more examples.[5, 10, 12] Both can be true. A familiar task may need only recognition and output calibration, while an arbitrary codebook demands binding of a new relation.

Do not ask whether demonstrations matter in general. Ask which informational role each demonstration is serving in this task. The answer determines the correct control. A format control tests interface calibration. A label permutation tests binding. A held-out function tests relation estimation. Context masking after a candidate recognition point tests whether task information has been compressed into a transient state.

Layer-local studies offer one possible route. If early layers require direct access to examples but later layers continue after the examples are masked, the model may have moved from reading the prompt to executing a represented task. That interpretation is strongest when the transition reproduces across paraphrases and when causal restoration recovers performance. It weakens if the effect disappears under a small template change or can be explained by residual token leakage.

Together, these experiments create an identification strategy. No single result proves a mechanism. A pattern across interventions can eliminate weak explanations and identify the next internal measurement.

We can now state a practical prediction. Retrieval should dominate when the query has a close, reliable analogue and the task is familiar. Task inference should dominate when several examples jointly identify one known latent rule. Implicit optimisation becomes more plausible when performance improves smoothly with additional diverse examples, generalises across representation changes, and reacts to noise like an estimator.

Many-shot results strengthen the case for treating context as more than a handful of hints. Across a range of studied tasks, hundreds or thousands of demonstrations produced gains, helped override some pretraining biases, and sometimes approached supervised fine-tuning performance.[12] Yet more context also creates more opportunities for conflict, retrieval failure and spurious regularity. Capacity to absorb examples is not the same as reliability of the inferred frame.

stateDiagram-v2
  [*] --> Claim
  state "The apprentice who forgets at<br/>the doorway" as Claim
  state "Retrieval, the answer is near<br/>an example" as Test
  state "When copying is enough" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Build the prompt as a controlled state

The mechanism question changes engineering practice. A prompt is more than prose placed before a query. It is a temporary program whose examples, labels, ordering and state boundary determine the computation available to the model.

The smallest useful discipline is to version four objects separately:

1. The task contract: the intended relation, output schema, precedence rules and abstention condition.
2. The demonstration set: why each example was selected, which boundary it covers, and which known confound it controls.
3. The state boundary: what persists across turns, what resets, and whether external retrieval or application state contributes.
4. The intervention suite: label remaps, order changes, decoys, counterexamples and out-of-family inputs used before release.

Without this separation, a successful prompt is hard to reproduce. A model update may alter semantic priors. A retriever update may change which examples appear. A longer conversation may introduce a conflicting codebook. The output can move even though the visible instruction is unchanged.

An executable mechanism audit

The laboratory below makes the rival generators explicit. It uses synthetic scalar functions so every assumption is visible. Choose a hidden rule, the number of demonstrations and a query. Then add a near-query decoy, reverse the order, or remove all demonstrations.

The three transparent solvers are intentionally simple. Retrieval copies the nearest output. Task-family inference selects the candidate rule with the lowest median error, making it resistant to one outlier. Ridge optimisation fits a regularised linear predictor. Their disagreement is the lesson.

How to use the result

A positive result is not “one bar is shortest”. It is a reproducible intervention signature. Suppose a black-box model remains stable under order reversal, follows an arbitrary label remap, and resists one close decoy, yet improves with diverse examples. That pattern makes pure retrieval less plausible and justifies tests for task representations or estimator-like computation.

A negative result means the three candidate solvers fail to account for the pattern. That is useful. Add a rival, such as sequential recency weighting, instruction hierarchy, majority vote, kernel regression, or a mixture-of-experts account. The audit is designed to expand rather than force every model into one category.

The laboratory cannot establish an internal transformer mechanism. Behavioural resemblance is underdetermined. To move from a solver-level hypothesis to a mechanism claim, intervene on activations, attention paths or layer access, then show that disruption and restoration track the behavioural signature. Function-vector and task-recognition studies provide examples of this stronger causal direction, though their findings remain model and task specific.[9, 11]

function nearestPrediction(points, queryX) {
  if (!points.length) return 0;
  return points.reduce((best, point) =>
    Math.abs(point.x - queryX) < Math.abs(best.x - queryX)
      ? point : best
  ).y;
}

function inferTaskFamily(points, queryX, rules) {
  if (!points.length) return 0;
  const scored = rules.map(rule => {
    const errors = points
      .map(p => Math.abs(p.y - rule.fn(p.x)))
      .sort((a, b) => a - b);
    return { rule, score: errors[Math.floor(errors.length / 2)] };
  });
  scored.sort((a, b) => a.score - b.score);
  return scored[0].rule.fn(queryX);
}

function ridgePrediction(points, queryX, lambda = 0.2) {
  if (!points.length) return 0;
  const n = points.length;
  const sx = points.reduce((s, p) => s + p.x, 0);
  const sy = points.reduce((s, p) => s + p.y, 0);
  const sxx = points.reduce((s, p) => s + p.x * p.x, 0);
  const sxy = points.reduce((s, p) => s + p.x * p.y, 0);
  const det = (sxx + lambda) * (n + lambda) - sx * sx;
  if (Math.abs(det) < 1e-9) return sy / n;
  const slope = ((n + lambda) * sxy - sx * sy) / det;
  const intercept = ((sxx + lambda) * sy - sx * sxy) / det;
  return slope * queryX + intercept;
}

To test an actual model, generate prompts from the same synthetic tasks and record its predictions under every intervention. Do not tune the prompt after seeing each result. Pre-register the expected signature, include matched controls for token count and formatting, and repeat across random seeds and model versions.

From prompt craft to temporary-state engineering

Prompt engineering often optimises one output. Temporary-state engineering asks whether the system has formed the intended task at all. That shift produces concrete controls.

Choose demonstrations for coverage, contrast and boundary value, not only semantic similarity. A nearest example helps retrieval, but a pair of minimally different examples can identify which feature should govern the decision. Include at least one case that defeats the easiest shortcut. Keep labels balanced unless imbalance is part of the intended rule. Randomise order during evaluation even if production order is fixed.

Separate example retrieval from authority. Retrieved demonstrations are evidence about how to interpret the task, not permission to act. The model should produce a typed proposal. An authoritative application validates the schema, checks permissions, applies deterministic rules where possible, and records the examples and task-contract version that shaped the proposal.

Make resets deliberate. A conversation boundary, cache eviction, tool call or summarisation step can delete or distort the task frame. Conversely, carrying context forward can import obsolete instructions. The state manifest should state which temporary facts survive, for how long, and under whose authority.

Finally, require abstention when the frame is underdetermined. If two codebooks fit the demonstrations equally well, more fluent generation is not a solution. The correct system behaviour is to expose the conflict and request an authoritative distinction.

A release gate for temporary adaptation

A consequential in-context workflow should pass a small release gate before its prompt is treated as a stable capability. Begin with a base-performance check, but do not stop there. Measure the same task under at least three harmless variations, such as paraphrased instructions, order permutations and equivalent output formatting. Large variance means the frame is not yet stable.

Next run a mechanism break test. Add the nearest wrong decoy, invert arbitrary labels, or move to a relation-preserving feature transformation. The chosen test should target the mechanism being claimed. If the system is sold internally as learning a rule, a result consistent only with nearest-example copying is a failed gate even when ordinary accuracy remains high.

Then test scope recognition. Include queries that sit just outside the demonstrated task family. The model should abstain or expose uncertainty rather than smoothly extend a temporary rule into an unsupported region. This is especially important when examples are retrieved automatically, because retrieval can make every query look deceptively familiar.

Finally, verify state and recovery. Reset the conversation, change the model version, remove one demonstration, and replay the same request. Record which changes alter the proposal. A system that cannot explain its dependency on temporary evidence cannot reliably resume after interruption or reproduce a past decision.

The release gate does not demand one universal threshold. It demands a declared claim and a test that could lower confidence in that claim. Passing permits bounded use under the tested task contract. Failing means the prompt remains an exploratory configuration, not a dependable learned capability.