Keep working while model decisions arrive
Subsecond interpretation belongs inside a continuing interaction. How to preserve useful work when the document, question or goal changes before an answer arrives.
Ask a design tool to widen a button. Before the answer arrives, change the heading. The button edit should still be useful. Now imagine resizing that same button yourself—or narrowing the container around it. The arriving answer has a different relationship to the work.
A responsive interface needs more than a fast model. It needs to know what the decision examined, what has changed, and whether applying the result would still mean what the person asked for. That is how interpretation can become part of ongoing work instead of a reason to stop working.
Our instrument, canvas, browser agent and application-review prototypes expose different parts of this problem. Their public interactions replay tested examples. The illustration and general adapter below are proposed designs, distinguished from the narrower protections already implemented.
A decision has a context, not just a destination
An edit might write one button while reading much more: its label, the neighboring objects, available space and the person’s instruction. Keeping the destination unchanged is insufficient if the reason for the edit has changed.
That matters when dividing work into small tasks. A task supplied with the whole document has a potential dependency on the whole document. We cannot infer that another paragraph was irrelevant merely because the returned action names one object. A smaller task with explicit inputs can make independence easier to establish.
Deterministic illustration. No model request or timing measurement.
The last case is easy to miss. A check limited to the button’s revision would accept the proposal even though its containing layout changed. The application needs to preserve the read dependencies of a decision as well as the objects it will write.
Separate interpretation from permission to apply it
A useful request envelope can carry:
- Meaning: the instruction, task and tool revision.
- Subject: stable object, source or company identifiers.
- Context: the exact values supplied to the task and their revisions.
- Authority: which operation may be applied and under what current conditions.
The model returns a permitted interpretation. The application checks whether that interpretation can still act on the current state.
capture context → interpret → proposed action
↓
validate current dependencies
↓
apply all changes together
Kung and Robinson’s On Optimistic Methods for Concurrency Control separates reading and tentative work from validation and a possible write. Its database setting differs from model-assisted editing, but the separation is useful: work can proceed before it earns permission to change shared state. The paper also explains why validation and the final write need an indivisible boundary. A successful check followed by an unprotected delay leaves room for another writer to intervene.
For an HTTP-backed editor, If-Match can make an update conditional on the resource’s current strong entity tag. The server evaluates the condition before applying the method; a failed condition can produce 412 Precondition Failed. A client-side check alone cannot supply the same boundary when other clients can write.
JSON Patch’s test operation provides a more explicit way to express conditions inside a patch. For example, a proposed adapter could test both revisions before replacing the width:
[
{ "op": "test", "path": "/button/revision", "value": 12 },
{ "op": "test", "path": "/container/revision", "value": 6 },
{ "op": "replace", "path": "/button/width", "value": 300 },
{ "op": "replace", "path": "/button/revision", "value": 13 }
]
HTTP PATCH requires atomic application: the server applies the complete patch or none of it. A local implementation would need to provide that property itself. A patch format is not a transaction engine, and validating the schema does not prove that the model chose a good edit.
Preserve the work whose meaning has not changed
Discarding everything on every update makes an interface correct by making it unnecessarily slow. Reusing everything makes it fast by treating changed meaning as irrelevant. A dependency graph gives a more useful unit of reconsideration.
Consider a proposed review workspace with two branches:
- A payment branch reads invoices and the proposition “customers pay for recurring use.”
- An independence branch reads service logs and the proposition “customers complete the workflow without founder help.”
A new service log should reopen the independence branch and any conclusion that combines both branches. The invoice interpretation can remain available if its inputs, question and task revision are unchanged. A new definition of “recurring” reaches a different part of the graph.
This is a design for selective reuse, not a claim that our current graph runtime maintains a cache across changing requests. The present runtime executes one validated request snapshot against one exact tool version; nodes receive their declared predecessors. It returns a declarative action. An application consuming that action remains responsible for current-state checks and any external write.
The important product change is specific: new evidence can revise the relevant part of a continuing inquiry while leaving settled material available. The reader does not have to restart the entire investigation to ask a better question.
Different activities need different continuity rules
The prototypes currently use several narrower strategies:
- Instrument: a recorded plan belongs to an exact native patch, history and protected-control context. Context-changing controls are disabled while it is pending. Playback and matched audition have their own continuity; the sound can keep playing.
- Canvas: each spoken operation belongs to an exact responsive document, edit history and protected-content state. The controller checks that context before applying the complete plan. The qualified replay preserves those same before-and-after identities. Reusing a proposal across unrelated edits would require a further dependency rule.
- Browser agent: catalog, inventory, reservation and cart checks join exact identities before the next action. In the recorded journey, the spoken size correction begins while the medium reservation is still being interpreted. Normal progress on the same goal and product can continue; the controller reconciles the completed reservation before checking large stock and preparing its replacement. That narrow compatibility rule does not admit an arbitrary changed goal.
- Application review: saved findings belong to an exact company dossier, task version and cited passages. Changing a cohort filter uses those findings without relabeling them. A changed dossier would need fresh analysis; the current workspace does not infer which old findings remain valid.
These choices preserve different things: a sound, an edit order, a journey or a question. A universal “latest response wins” rule would erase those distinctions. An older result can still be useful for the question it actually answered.
Let a person change direction without losing authorship
Suppose a lighting designer asks for a slower transition, then protects one lamp before the proposal arrives. A useful tool could keep the old proposal available for comparison while declining to apply it under the new protection rule. The designer can request another proposal, rather than have the application silently weaken the protection or reinterpret the original command.
The browser example makes the external-effect problem visible. Ignoring a reservation response does not undo the reservation. Its controller establishes what happened, cancels the medium reservation through the controlled service, then checks the large variant afresh. Stopping local waiting and reversing an external effect are different operations. Extending that behavior to another service requires its own rules for cancellation, inventory and conflicting updates.
For a proposed interface, the response to changed context should be concrete:
- Preserve the person’s newer work.
- Identify the particular dependency that changed.
- Keep an old observation available where it remains meaningful.
- Offer a new decision only for the part that needs reconsideration.
This is another reason to develop a model and its tool together. The task defines which distinctions matter; the tool defines which state those distinctions may change. Examples must exercise both the intended decision and the moment at which it becomes usable.
Subsecond decisions make fine-grained interaction practical. Preserving their meaning lets people use that speed while continuing to edit, listen, navigate and investigate. The resulting interface can respond to a person’s next move without making their previous work disposable.