What Changes for the User? Performance, Control, and Project-Scale Work
Beyond the Chat Window · Article 8 of 8
The previous article argued that modern LLM products increasingly operate through machinery that the chat window only partially exposes: files, plans, tools, persistent workspaces, context management, checkpoints, memory, and subagents. The method developed in this series gives the human a way to enter that machinery more deeply. Instead of interacting only through prompts while the system independently decides how to preserve and transform the work, the user can participate in the persistent representation on which later model operations depend.
That raises a question about performance, but the question is easy to formulate too weakly. If persistent state is described merely as better memory, the method sounds like a more elaborate notebook. If the question is whether putting an argument into JSON makes the base model intrinsically smarter, the answer is obviously no. The stronger claim developed across this series is that the method changes the computational form of the project. Work that would otherwise exist as a mixture of conversation history, drafts, implicit assumptions, and human recollection becomes a system of addressable objects and relations. Some of those objects are straightforward: articles, claims, sections, decisions, artifacts, statuses. Others are qualitative and interpretive: a reader's likely prior belief, the warrant that licenses an inferential move, the rhetorical function of a section, the relation between one conclusion and another.
The LLM makes it possible to operate in that mixed domain. It supplies semantic judgment where the objects cannot be reduced to rigid types or exact rules. The external schema, graph, protocol, and execution state supply something different: identity, persistence, topology, versioning, and procedures. The result is not simply that the system remembers the project. Human and model gain a persistent substrate they can jointly manipulate.
The project was represented, not merely remembered
Article 1 distinguished canonical project state from conversational history. Articles 2 through 5 then added transition semantics, resumable execution, progressive formalization, explicit dependencies, and provenance. Those results matter here because they describe a representational change, not just a storage choice.
I did not begin the first five articles by writing detailed outlines and then asking the model to produce five essays. After describing the underlying idea, I asked the system to create a schema for the series and a protocol for modifying that schema. The next important instruction reframed the articles as epistemic transformations:
“We have to establish our objectives for each post, the likely initial state of readers, and the moves that the article has to make in order for the justified beliefs of the audience to include the conclusions of the articles.”
That instruction did not specify every rhetorical move. It declared a kind of structure the project should contain. Each article should have an initial reader state, a target justified-belief state, and a sequence of inferential transformations connecting the two. The model instantiated those structures across the article objects. When I later asked the system to “formalize all five posts in one step of increasing granularity,” the instruction again operated on an existing class of objects. The model iterated over each article's argument state and generated premises, warrants, objections, examples, section functions, and explicit belief transitions.
The final artifact is prose, but prose was not the primary working representation for much of the project. The project existed as an abstract system that could eventually be materialized as prose. A transcript could preserve the sentence “Article 3 needs to convince the reader that a user-level task can exceed the scale of a single inference.” The structured project could represent post_3, its target belief, the earlier beliefs it depends on, the argument moves that establish the target, the examples assigned to those moves, and the later articles that depend on its conclusion.
Once those things have stable identities, they become operationally addressable. They can be queried, extended, compared, invalidated, traversed, or regenerated. That is the stronger distinction from ordinary chat: not whether the information is present somewhere, but whether it exists as part of a representation on which the workflow can operate. A sufficiently long conversation may contain nearly everything the model needs semantically, but the model must repeatedly infer which passage represents the current rule, which sentence refers to which conceptual object, which earlier conclusion a later section depends on, and whether a new decision invalidates something downstream. In this workflow, some of those interpretations were made, committed to state, and reused. The representation was not a perfect formalization of meaning; it was formal enough to support procedures that would otherwise require repeated semantic reconstruction.
Nine prompts and the leverage of procedure
The scale of the human interaction makes that difference unusually visible. By my recollection, the sequence that established, formalized, corrected, and ultimately produced the first five articles took place over roughly half an hour during my drive home from work. The underlying idea was not invented in that half hour. It had already been substantially developed before the workflow began. What was compressed was the intermediate labor of turning that idea into a large, structured, internally related writing project.
The canonical project history records roughly nine substantive human interventions from initialization through the accepted five-article publication. They can be sketched as procedural prompt templates:
4. Initialize the project state. Given this developed idea, create a schema representing the five-article project and a protocol governing how the schema should be modified to produce publishable articles. 5. Formalize the epistemic objective. For each article, represent the reader's likely initial beliefs, the justified beliefs the article should establish, and the inferential moves required to get from one state to the other. 6. Increase granularity recursively. Iterate across all article objects and expand each argument into finer structures: premises, warrants, objections, examples, section functions, and belief transitions. 7. Turn the representation into an execution plan. Starting from the existing state, design and execute successive passes that increase granularity until prose becomes the appropriate representation, while maintaining checkpoints and resumability. 8. Correct a governing relation. Remove an artificial restriction on how many earlier results a later article may inherit; make inheritance depend on the actual inferential requirements of the article. 9. Promote the project itself into the example. Treat the production of this series as the central worked example and propagate that requirement through every article according to the methodological aspect it explains. 10. Repair the composition architecture. Preserve the useful argument state but insert a separate
composition layer so prose is synthesized from structured reasoning rather than mechanically serialized from it. 11. Add adversarial editorial governance. At paragraph level, require two independent revision proposals
and a strict editor that accepts, rejects, synthesizes, or remands them under explicit criteria. 12. Resume from the correct checkpoint. Retain the trustworthy upstream state, discard defective
downstream artifacts, and rerun the pipeline under the revised protocol.
The number matters only if we understand what kind of input those prompts represented. They were not nine chunks of article copy, and they were not nine rounds of line editing. Most of them specified operations over persistent state. One prompt operated over five article objects at once. Another caused every article to acquire a reader-state trajectory. Another recursively expanded all argument moves into finer structures. Another changed the allowable topology of the cross-article argument graph. Another replaced a downstream transformation procedure while preserving the upstream intellectual state.
The human interventions were therefore sparse relative to the number of durable objects and relations generated underneath them. That asymmetry is one of the method's most important performance characteristics. I would call it generative leverage: the amount of coherent project structure one meaningful human instruction can cause the system to construct because the instruction operates over a formalized set of objects rather than a single piece of prose.
The distinction also prevents the wrong conclusion from being drawn from the “half an hour” observation. This was not five thoughtful articles generated from almost no intellectual input. The conceptual substance existed before the workflow began. The method compressed a different category of labor: decomposing the idea into article objectives, applying a common rhetorical model across those articles, elaborating those models into arguments, recording dependencies, coordinating execution, and eventually materializing prose. In a chat-interface-only workflow, much of that intermediate structure would remain implicit or would have to be negotiated article by article. Here, the user could define an operation once and have the model apply it recursively over the persistent project model.
Revision becomes dependency-aware recomputation
The same architecture produces leverage when the project changes. In a conventional writing workflow, revision is normally described at the level of text: change a sentence, rewrite a paragraph, move a section. Even in a sophisticated chat workflow, the interaction is usually local. The user points to an output and asks the model to revise it. If that change has implications elsewhere, the model may notice them, the user may identify them, or a later pass may rediscover them from context.
A stateful workflow can treat revision as an upstream data mutation rather than a downstream text edit. If a sentence expresses a canonical claim and the user changes the meaning of that claim, the primary operation can be “mutate the claim object.” The prose is a derivative artifact of that object. Once the claim has stable identity and explicit relations, the system can determine what depends on it before rewriting anything.
Conceptually, the operation is:
canonical idea changes -> traverse dependency graph -> identify affected objects -> classify required action -> recompute affected semantic structures -> validate -> rematerialize derivative artifacts
The graph does not write the new prose. It determines where consequences may exist. The protocol can classify those consequences. Some dependents may be unaffected after review. Some may require a line revision. Some may require recomposition of a section. Some may invalidate a downstream conclusion and force a larger argument change. The LLM performs the semantic work required by each class of revision.
That is revision leverage: one human correction can propagate through all represented dependents of the governing object under a defined procedure.
The current Article 8 is itself a concrete example. In the previous version, one paragraph claimed that the major project changes “would all have been possible in ordinary chat,” with the main difference being how they were represented and remembered. The problem was not merely that the sentence was badly phrased. It exposed a defect in Article 8's argument model. The article nominally depended on Articles 1 through 7, but its performance argument had inherited those results too weakly. It emphasized persistence and recovery while neglecting the stronger earlier results about object identity, recursive formalization, graph relations, and procedural operations over qualitative state.
Correcting the article therefore began upstream. The incoming dependencies to Article 8 were strengthened. Its target justified beliefs were rewritten. New argument moves were added. The composition map was rebuilt. The article was drafted again, passed through competing paragraph-level revision proposals, adjudicated by a strict editor, and reread as a continuous sequence before it became authoritative prose. A local textual objection revealed a structural defect, so the workflow changed the state from which the text was derived and recomputed the artifact.
In a mature implementation, the connection can be even more explicit. Suppose a prose paragraph preserves provenance back to claim_17, argument_move_5, and target_belief_3. The user says, “This sentence is wrong; what I actually mean is X.” The system can decide whether the correction is stylistic or semantic. If it changes the governing claim, it can propose a mutation to claim_17, enumerate the downstream dependents, and execute the required review or regeneration according to protocol.
The prose remains a natural human control surface, but the edit can be lifted into the data model. This is fundamentally different from asking a model to reread a long conversation and “make sure everything else is consistent.” A capable model may infer many of the same consequences, but repeated semantic rediscovery is not the same operation as dependency traversal over committed relations. In a chat-interface-only method, there is no persistent affected set to enumerate, no exact graph to traverse, no checkpointed state transition to validate, and no formal distinction between dependents that require recomputation and those that do not.
Ordinary chat can discuss the same semantic relationships. What it cannot provide by itself is the same durable relational substrate with procedural propagation semantics.
A hybrid formal-semantic workspace
The graph cannot determine everything that revision requires, because the most consequential project relations are not purely formal. Does one premise genuinely support another claim? Is a reader-state assumption still plausible after an argument changes? Does a new paragraph satisfy the rhetorical function assigned to it? Should a recurring concept become a new type, a relation, or merely an annotation? Those are interpretive questions.
The method works because two kinds of machinery cooperate. The formal layer preserves identity and topology. It can say that claim_17 supports belief_4, that post_8 depends on B5, that an artifact derives from a particular composition state, or that a changed node has seven downstream dependents. Once committed, those relations can be traversed exactly.
The LLM supplies the semantic judgments required to create and revise that structure. It determines, provisionally and revisably, what the reader probably believes, whether a claim really supports another, how a changed idea should alter an argument, and what revised prose should say. The model's inference remains probabilistic. The operations performed over the committed representation can be deterministic.
This division is why the schema can contain qualitative objects without pretending that rhetoric has been reduced to mathematics. The schema declares object types and relations. The model constructs and interprets instances of those types. The protocol governs legal mutations. The graph makes selected dependencies explicit enough to analyze. The manifest makes execution state explicit enough to resume.
Article 4 called this progressive formalization. The ontology does not have to be known in advance. A semantic distinction can emerge during work, become a provisional field, and later become a stable type or edge if it proves operationally useful. Formalization is not a one-time conversion from ambiguity to rigid structure; it is an evolving interface between semantic inference and procedural control.
That hybrid division of labor makes both kinds of leverage possible. The formal system tells the model what set of objects to operate over and where a change must be considered. The model determines what the operation means in each semantic context.
Performance as intervention leverage
Once generative and revision leverage are visible, project-scale performance looks different. A single-response benchmark asks whether the model produced a good answer. That remains important, but it does not capture what the user experiences when a project lasts for hours or days, accumulates many related artifacts, changes direction, and repeatedly returns control to the human.
For this kind of work, one useful question is: How much coherent, governable project-level change can one meaningful human intervention produce?
Generative leverage asks how much structured work one procedural instruction can cause the system to create. Revision leverage asks how far one correction can propagate through represented dependencies without forcing the user to rediscover and restate every consequence manually. Structural reach asks what kinds of operations the workflow can perform at all: iterating over every article to construct a reader-state trajectory, adding a semantic distinction across relevant objects, traversing downstream dependencies when one claim changes, or rebuilding derivative artifacts without rewriting unrelated upstream work.
Other dimensions support those central forms of leverage. Continuity asks whether governing state survives across turns and sessions. Recoverability asks whether execution can resume from a known checkpoint. Inspectability asks whether the user can see the representation the system is relying on. Artifact scale asks whether coherent work can exceed the bounds of any one inference. Cognitive offloading asks how much project architecture the human can move out of working memory without surrendering control over it.
The user experience changes because the human can intervene at different depths. Sometimes the right move is conversational: “make this clearer.” Sometimes it is a state mutation: “this claim is wrong.” Sometimes it is a protocol change: “later articles may inherit as many earlier results as their argument requires.” Sometimes it is schema evolution: “we need a relation representing this recurring dependency.”
That range of interventions is one reason the method is especially relevant to capable users. A modern agent harness may already maintain plans, files, memories, and checkpoints internally. The user can stay at the chat surface and let the product decide how those hidden structures evolve. This workflow exposes selected parts of the persistent substrate so the human can govern them directly.
The significance of that range is not that the human should govern every object or supervise every operation. It is that the project now has a persistent structure in which human intent can be expressed at the level where it actually matters. Sometimes that level is a sentence. Sometimes it is a claim, a dependency, a protocol rule, or an object type. The model can continue to perform the semantic work of interpretation and generation, while the user can decide which parts of the resulting structure should become durable and govern what happens next.
That is where the eight articles in this series converge. Article 1 separated project state from conversational history. Article 2 added rules for legal state transition. Article 3 showed how persistent execution breaks the coupling between one task and one completion. Article 4 allowed the representation itself to evolve as the work revealed new distinctions. Article 5 made selected relations explicit enough for graph analysis and provenance. Article 6 reconstructed how a user can build the workflow from ordinary conversation. Article 7 showed that the most capable LLM systems already depend on stateful machinery beneath the chat surface, and that a capable user can move deeper into that machinery instead of leaving every persistent decision to the provider.
Article 8 adds the practical consequence. The method changes the leverage of human intervention. During construction, a small number of procedural instructions can generate and govern a much larger formal project state. During revision, a change to a governing idea can be propagated through represented dependencies instead of being rediscovered manually across a corpus of prose. In both directions, the human is operating on the project model rather than only on its latest textual manifestation.
The first five articles make that leverage unusually concrete. The underlying idea already existed, but by my recollection the interaction that established, formalized, corrected, and ultimately produced the original five-article system took roughly half an hour and about nine substantive prompts. Those prompts did not contain five articles' worth of copy. They defined operations over persistent classes of objects: initialize the schema, construct reader-state trajectories, recursively increase granularity, change a governing relation, alter the composition procedure, add editorial rules, and resume from the appropriate checkpoint. The substantial work between those interventions was performed by the system over the formalized state.
That is the larger proposition behind this series. A language model is unusually capable of reasoning over qualitative, ambiguous, partially formalizable material. A schema, protocol, graph, and persistent execution state can give that reasoning durable identity and procedural structure. When those two capabilities are combined, the project stops being only a conversation that the model remembers. It becomes a shared formal-semantic workspace that human and model can construct, inspect, revise, traverse, and resume together.
The chat window can remain the control surface. It no longer has to be the project itself.