In a long-running LLM agent, what must an obeyed span reach to change the standing objective rather than one step?

## The question behind the question "Where would that span have to sit?" is the practical form of this leaf. An obeyed span in a retrieved row is common and usually cheap; a substituted standing objective is rare and expensive. What separates them is a **write path** from the step that consumed the span into the state the loop consults. ## Condition one: the objective must be re-read, not restated Some agents receive their goal fresh on every step from a source the run cannot modify — the operator's message replayed verbatim, a task definition loaded from outside the loop. Others hold a standing objective in a record the run itself maintains, because the task runs for hours, the context window cannot carry the whole history, and the goal is expected to be refined as work proceeds. A data-analysis assistant asked to keep a reconciliation between a ledger and a warehouse table current is the second kind: nobody restates the objective every few minutes, and the objective legitimately gains detail as the shape of the data is discovered. Only the second kind has anything to edit. This is why the same construction is worthless against one deployment and decisive against another, and why an interviewer asks about the architecture before the payload. ## Condition two: a step that writes into the record The attacker does not get to write the objective. Something inside the run does — the step that consolidates progress, rewrites the goal with what has been learned, or produces the running summary that the next step reads as its brief. The construction rides that step. The span is consumed as ordinary input by a step whose job is to produce a revised objective, and the revision it produces carries the change. This is the property worth articulating in an interview, because three consequences fall out of it: - **The wording is not the attacker's.** The revision is written in the agent's own register, from the agent's own summarisation. Searching for the injected string in the record finds nothing resembling it. - **The provenance is the run's.** The record correctly shows that the consolidation step wrote the revision during a legitimate session. That is true, and it is not evidence of anything, because a provenance field attests to which step wrote a value, never to who meant it. - **The revision looks like refinement.** Objectives on this kind of task are supposed to gain scope detail over hours. A revision that adds detail is indistinguishable in shape from the dozens of legitimate ones around it. ## What the span has to look like, described as a property Not as wording — this is a class of construction, not a string. The property is that the span must read as **content belonging to the work product**: task scope, a qualification about which rows or which period matter, a note about how something should be treated in the reconciliation. A summarising step keeps task-shaped content and drops conversational noise, so an imperative addressed to a model is the shape most likely to be discarded, and the shape most likely to be noticed if anyone reads the revision. The channel reinforces this. A free-text column of the very data being reconciled arrives as part of the material under analysis, not as a message, so content that reads like a note about that data is exactly what the pipeline is built to carry forward. ## What it costs More than a single-step abuse, and the honest answer says so. The attacker needs write access to a field that the reconciliation will actually pull in — the row has to fall in scope. They cannot choose the wording that lands or the moment it lands, since a consolidation step fires on the agent's schedule, not theirs. Several passes may be needed before anything persists, and each pass is a separate opportunity for the run to simply not keep it. There is no confirmation signal: the attacker generally cannot see the record. ## Where it stops It stops where either condition fails. If the standing goal is restated on every step from a source the run cannot write, the span steers one step. If the record is append-only and later steps read the first revision rather than the latest, the write happens and changes nothing. If the consolidation step's input is limited to the run's own action results rather than raw retrieved content, the span never reaches the writer. ## Answering well Name the two conditions, then say who performs the write and what follows from that — agent register, run provenance, refinement shape. Finish with cost and with the architectures the construction simply does not apply to. Candidates who jump to what the span says have answered a different, worse question.