Building the Workflow: A Reconstruction of This Series
Beyond the Chat Window · Article 6 of 8
The first five articles described a method for extending an LLM beyond the conversational surface: represent the project in persistent structured state, govern changes with a protocol, make execution resumable, allow the schema to evolve, and use explicit relations and provenance when the work becomes complex enough to justify them. Those ideas can sound like the architecture of a software system that must be designed before anyone can use it. That was not how this series was built.
It began in an ordinary chat, and the decisive initialization instruction was not a specification for an agent framework. It was a request to take a project that had already been discussed conversationally and externalize it:
“Plan a five-part blog series about this method. Let’s also use the method. So now that you know what our task is and the content is, create a schema that we can use to write the blog posts, and a protocol for modifying the schema in order to achieve our goal of five well-written, publishable blog posts…”
That instruction established the method in practice. The conversation already contained the subject matter: persistent state, a schema, a mutation protocol, resumable execution, adaptive types, graph analysis, and provenance. The next move was not to keep elaborating those ideas in chat. It was to create a durable representation of the project and a set of rules for changing that representation. The initial files were simple: a project-state JSON document, a protocol document, and a human-readable series plan. Everything that came later grew from those objects.
That is the first practical lesson. You do not need to design the final ontology before you begin. You need enough formal state to stop making the transcript carry the whole project.
Start by externalizing the project you already have
A minimal persistent-state workflow begins with two questions: what must survive beyond the current turn, and what rules should govern changes to it? In this project, the first schema answered the first question by recording the series goal, audience, working terminology, five article objects, dependencies, open questions, execution status, and publication requirements. The protocol answered the second by defining how state could be read, mutated, validated, persisted, and used to generate derivative artifacts.
A useful starting directory can be almost embarrassingly small:
project/ state.json protocol.md artifacts/
The state file is the current model of the work. The protocol says how that model may change. The artifacts directory contains prose, code, reports, or other outputs derived from the state. You can add a manifest when execution becomes multi-stage, a change log when structural revisions matter, and explicit provenance when you need to trace how an output was produced. Those are later layers, not prerequisites.
The key is to make the state operational rather than decorative. If state.json says that Article 3 depends on Articles 1 and 2, later operations should actually read that dependency. If a terminology object changes, affected articles should be identified from the state. If an article is marked publication_ready, the protocol should define conditions that make that status valid. Otherwise the file is only a note written in JSON.
This distinction is why the first two files matter more than their format. You could use YAML, a database, or a directory of smaller objects. What matters is that the representation becomes the authoritative place where the project currently exists and that subsequent operations consult it rather than reconstructing the project from conversational history.
For a new project, an initialization prompt can therefore be straightforward:
Create a persistent project state for this task and store it in a machine-readable file. Represent the goal, important objects, decisions, constraints, dependencies, unresolved questions, and execution status. Then create a separate protocol that defines how the state may be changed, validated, and persisted. Treat the files as canonical for future work and the chat as the interface through which I modify them.
That is enough to begin. The rest of the method should be earned by the work: new object types, relations, manifests, graphs, and helper agents should appear because the project has developed a problem that they solve, not because a mature architecture is being copied ceremonially.
Increase formalization only when the project reveals a need
The initial schema for this series did not contain a complete theory of article composition. It could not have, because we had not yet discovered what kind of representation would be useful. The next important prompt changed the project by changing what the articles were supposed to accomplish:
“Let’s treat this like an instructive argument. 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 introduced a new kind of state. The articles were no longer represented mainly as topics and titles. Each acquired a reader model, a set of target justified beliefs, and a path of inferential moves that would have to be made for the reader to reach them. This was not merely a better outline. It changed what could be checked. A post could now fail structurally if one of its target conclusions lacked a supporting path or if a later article assumed a result that an earlier article had never established.
Once the epistemic model existed, the next prompt deliberately increased granularity again, not because finer structure was intrinsically desirable but because the project was ready to make its argumentative dependencies explicit:
“The next useful move is to formalize all five posts in one step of increasing granularity. You can do this in one pass.”
The state expanded to represent section-level premises, warrants, objections, examples, rhetorical functions, and belief transitions. At the same time, the five posts were connected in a series argument graph. The graph did not replace the articles. It represented the dependencies among the results the articles were supposed to establish.
This sequence is worth noticing because it reverses a common implementation instinct. Instead of designing a rich schema first and hoping the project will fit it, the project began with a small schema and promoted distinctions into formal state only after they became useful. The user supplied conceptual pressure; the model supplied a proposed formal representation; the protocol made the resulting structure durable.
A practical rule follows: when you notice yourself repeatedly expressing the same distinction in natural language, ask whether that distinction should become a field, object type, relation, or invariant. If it will be queried, propagated, validated, or reused, formalizing it is usually worthwhile. If it will only be mentioned once, leave it in prose.
This is also why stable identifiers matter sooner than elaborate types. If a claim, section, source, or decision has an ID, you can add new relations to it later without rebuilding the project. Stable identity makes progressive formalization possible.
Turn the state into an execution, not just a representation
A structured project can still sit idle. The next transition in this workflow was from representing the work to orchestrating it. The prompt was explicit:
“You’ve seen how I orchestrated the first pass. Plan and implement an orchestration of the remaining passes. You should iteratively increase the granularity of descriptions until prose, or until a prose step is appropriate. Then you should write the prose for each article.”
That request introduced an execution manifest and a sequence of passes. The project now knew not only what the articles were but where the workflow was in producing them. The early passes moved from article-level objectives to section arguments and then to more detailed content objects. Later passes were responsible for prose drafting, article revision, series-level continuity, typesetting, and verification.
At this point the distinction among three files becomes useful:
state.json What the project is. protocol.md What changes are allowed and how they are committed. manifest.json Where execution currently is.
Those roles can be combined in a small project, but separating them clarifies failure recovery. If a process stops after drafting Article 2, the manifest should say that Article 2 is complete and Article 3 is next. The state should still contain the project model. The protocol should still say what counts as a valid commit. Resuming does not require replaying the entire conversation to infer where the process stopped.
The workflow was tested repeatedly by interruption. One interruption came when I imposed an unnecessary rule on the series: I said later articles would inherit “one precise result” from the previous article. The user stopped the process and corrected the assumption:
“I never constrained the number of precise results that should be used from the previous article. That should be determined by the necessity of the moves within the article.”
The correction was not handled by adding a sentence to the chat and hoping it would remain salient. The continuity rule in the state and protocol was changed. Later articles could inherit any number of earlier results required by their own arguments, from any earlier article. The execution then continued under the corrected rule.
A later interruption introduced a more substantial requirement, one that changed how every article would demonstrate its own claims:
“A great example of the method is this article itself… The content that the reader is reading was itself generated using this method.”
That changed every article. The production of the series itself became the central worked example. Again, the project did not restart. A new central_demonstration object was added to the state, post-specific requirements were propagated, and the existing argument objects were retained where they remained valid.
These episodes illustrate the practical purpose of persistent state better than a polished success story would. Project-scale work changes. Users notice mistaken assumptions, add requirements late, or redirect the purpose of an artifact. The method is useful because those interventions can become explicit state transitions rather than diffuse conversational corrections.
Do not formalize straight through to sentences
The first five articles also exposed a boundary condition that is useful when implementing the method. More structure is not always better.
The original orchestration progressively decomposed the argument until it reached paragraph-role objects: setup, claim, mechanism, example, qualification, synthesis. That looked like a natural continuation of the method. It was also too close to the final prose. The initial drafts inherited the granularity of the schema and became choppy: many short paragraphs, isolated declarative sentences, and visible outline cadence.
The important lesson is not that the persistent-state method failed. The state had represented the argument effectively. The mistake was assuming that the next useful representation after a detailed argument graph was a finer argument graph. Rhetorical composition is not serialization.
The protocol was therefore extended with a separate prose-composition layer. Instead of mapping argument objects directly to paragraphs, a Composition Orchestrator groups multiple objects into larger rhetorical movements. Helper roles analyze architecture, reader continuity, development, redundancy, and line-level prose. Paragraphs are created because a movement in the argument requires them, not because a database object needs a textual container.
The editorial layer was made deliberately adversarial. One revision agent attacks excess, repetition, and looseness. Another attacks underdevelopment, abruptness, missing warrants, and outline-like prose. A strict editor compares their paragraph-level proposals with the original, then keeps the original, accepts one proposal, synthesizes them, or remands the problem to the composition layer if the defect is structural.
That addition suggests another practical rule: formalize the task until the representation supports the next operation, then stop. If the next operation is inherently rhetorical, visual, or aesthetic, introduce a transformation layer appropriate to that kind of artifact rather than continuing to subdivide semantic state.
A minimum viable implementation
The full workflow used for this series now includes schemas, graphs, manifests, composition maps, revision agents, editorial records, provenance, and publication QA. A new user should not copy all of that at initialization. The reusable core is much smaller.
Start with a persistent workspace that the model can read and write. Ask it to create a canonical state file and a protocol. Put the current objective, constraints, decisions, important objects, open questions, and statuses in the state. Tell the model that durable changes must be written back to that file. Then work normally through chat, but whenever the project changes materially, require the change to be reflected in state.
Add a manifest when the task becomes long enough that “what is complete and what is next?” should not depend on conversational memory. Add stable object IDs when revisions begin to propagate among parts of the project. Add explicit relations when dependency questions become useful. Add provenance when you care about how a derivative object came to exist. Add helper agents only when independent contexts, parallel work, or deliberately conflicting review roles justify the cost.
A compact initialization package might look like this:
project/ state.json protocol.md manifest.json # optional until execution becomes multi-stage artifacts/ revisions/ # optional until formal review matters
Then give the model an operating contract such as:
Before substantial work, read the canonical state and the protocol. For any durable change, update state before relying on the change in later work. When a task is multi-stage, record progress in the manifest and commit units only after their artifacts and metadata are persisted. Extend the schema when a recurring distinction becomes operationally useful, but do not create formal structure merely for completeness. Generate final artifacts from the current state rather than reconstructing the project from chat history.
The method becomes more powerful as the model gains file access, code execution, graph analysis, search, and long-running task support, but none of those changes the basic pattern. The human uses conversation to express intent. The model interprets that intent against durable state. The state changes. Execution proceeds from the new state.
The result is not a chatbot with a bigger prompt. It is a project whose semantic and execution state can survive beyond any particular prompt.
That raises the practical question behind the next article. Modern LLM products increasingly have their own persistent workspaces, tools, memory systems, plans, context compaction, subagents, and long-running execution. In other words, the strongest agentic systems are already doing versions of this underneath the chat surface. If the provider can manage that state for you, why expose it at all?
The answer is that there are two different ways to benefit from a stateful agent system. You can remain at the conversational surface and let the harness decide how your project is represented internally. Or, when the service gives you enough access, you can place your own schema, protocol, and intent inside the stateful loop and take direct control of parts of the machinery the agent would otherwise manage on your behalf.