An arXiv preprint published on 10 July 2026 suggests that workflows driven by large language models—such as sequences of tool usage, data retrieval, and human-in-the-loop approvals—ought to be viewed as durable, examinable knowledge entities instead of temporary execution logs [S1]. The authors' primary contribution is making a clear conceptual separation between deterministic calculations and judgments made by LLMs. If this separation proves useful, it may transform the way engineers debug, restart, and review automated agent systems. The open question is whether a theoretical framework lacking any implementation, performance benchmarks, or formal mathematical semantics can truly influence real-world development practices.

The problem: workflows that forget

To accomplish meaningful tasks, applications using LLMs depend more and more on structured workflows that involve tool usage, information retrieval, conditional branching, saving progress, and human verification [S1]. Current systems for managing workflows already address numerous execution-related issues [S1]. However, the researchers point out a common flaw in these platforms: after a workflow finishes, the only things left behind are the final result and perhaps a log file. The actual workflow—comprising its setup, records of intermediate LLM judgments, saved contexts, and links between steps—disappears.

This is important because tasks using LLMs over long horizons fail in particular, aggravating ways. Another arXiv preprint called ADEMA recognizes this same pattern from an alternative viewpoint: knowledge states drift across rounds, intermediate commitments remain unspoken, and interruptions break the chain of evolving evidence [P4]. When an automated agent pipeline fails midway through a multi-stage task, developers usually lack a straightforward method to examine the model's reasoning at the seventh step, restart from the sixth step, or review why the fourth step yielded an incorrect result.

The distinction that does the work

The main idea introduced by the preprint is a fundamental conceptual split. According to the paper, any action within an LLM-driven workflow falls into one of two categories:

  • Derive — calculations performed deterministically on the current state. This includes pure functions, database queries, math operations, and text formatting. Given the same input, the output is always identical.
  • Infer — judgments made by an LLM that are governed by a specified context and a set of capabilities controlled by the executor [S1].

The second category carries significant weight. "Infer" goes beyond simply having a model produce text; it refers to LLM decisions restricted by two factors: a declared context (the information the model is permitted to access) and a capability policy (the actions the model is allowed to take). This separation allows developers to examine any workflow step and determine if it was a calculation or a judgment—and if it was a judgment, to see the exact limitations placed upon it.

Here, the paper draws inspiration from Lisp. The strength of Lisp lies in homoiconicity, meaning code and data share the same structure, enabling programs to examine and modify themselves. The researchers adopt this concept metaphorically, utilizing symbolic forms, object identity, and a concept they term "live-image thinking" as conceptual tools rather than actual features to be built [S1]. This proposed framework is not built on Lisp. Rather, it suggests that workflows should exist as primary entities within their own environment, capable of being inspected just like Lisp code.

The knowledge substrate

Under the suggested framework, five categories of elements are transformed into durable knowledge entities within a collective "knowledge substrate" [S1]:

  • Workflow setups — the blueprint
  • Workflow executions — a particular occurrence
  • Records of inferences — every LLM decision, along with its specified context
  • Saved contexts — the information available to the model at every stage
  • Links of dependency — the relationships between different steps

The authors state that this yields an initial theoretical framework for semantic persistence [S1]. In this view, workflows do more than just generate outputs and logs; they themselves become knowledge entities that can be examined, restarted, and evaluated.

What it means

The paper advocates for a straightforward but easily overlooked idea: stop discarding AI workflows after they run. Currently, when an LLM agent executes a ten-step pipeline—fetching documents, creating a summary, querying an API, composing an email, waiting for a person to approve it, and sending it—the workflow itself vanishes. You receive the final email. You might receive a log file. But you cannot readily halt the process at the fifth step, examine the exact context the model utilized, modify its allowed capabilities, and then continue.

The semantic persistence suggested in this preprint would turn every step into a lasting entity. Developers could jump back to any LLM judgment, view the context that was declared, verify if it was a deterministic derive or an LLM infer, and grasp precisely why the pipeline generated its specific output. For engineers constructing agent systems—where dependability is the main obstacle—this shifts the system from an opaque black box into a transparent glass box.

The separation between derive and infer acts as the foundational support. By cleanly dividing deterministic steps from those mediated by LLMs, developers can replay the deterministic ones without cost (since they are pure functions) and only re-run the LLM judgments when the context shifts. This approach leads to less expensive inference, improved debugging, and a route toward auditability that existing workflow platforms do not provide.

What it means for business

For a small AI consultancy managing agent pipelines for clients, the practical deficiency highlighted by this paper is both real and recognizable. When a client inquires, "why did the agent send that email?" the response today is frequently a shrug accompanied by a log file. A framework that ensures every inference step is examinable—with its declared context and capability policy included—transforms that question from a difficult forensic investigation into a simple database query.

For a local agency automating the processing of documents, the ability to resume workflows is crucial. Should a workflow fail at the eighth step out of twelve, semantic persistence allows developers to avoid starting from scratch. They can restart from the most recent checkpoint, keeping all previous inference records untouched. Current workflow orchestration tools like OpenBMB's WorkflowLLM [P5] already manage execution orchestration; the contribution of this preprint is the conceptual layer above that—elevating the semantic content of the workflow to a primary entity.

For industries with heavy compliance requirements—such as legal, finance, and healthcare—the promise of reviewability is the most notable aspect. If every LLM judgment within a workflow exists as a durable entity with its declared context attached, organizations possess an audit trail that effectively explains its own reasoning. This is not a tangible product. It is a design philosophy, and it is one that regulators would appreciate.

However, none of this is currently available. The preprint offers a theoretical framework, not an installable system.

What we don't know yet

The preprint openly acknowledges its boundaries. Formal transition semantics—the mathematical rules dictating how a workflow progresses from one state to another—are left for future research [S1]. It lacks an implementation, an executable program, performance benchmarks, and user evaluations [S1]. Furthermore, the authors' assertions regarding trends in LLM workflows are made without supporting data citations [S1].

The wider research landscape prompts additional inquiries. ADEMA [P4] addresses the drift of knowledge states in long-horizon LLM tasks from an architectural viewpoint. The Malaclyde/semantic-memory repository [P3] provides an implementation of persistent memory using TypeScript and Python. It remains unknown whether the theoretical model suggested in this preprint can be put into practice alongside or integrated on top of these existing projects.

The next tangible milestone to monitor is whether the authors publish a paper on formal semantics or release a reference implementation. Until that happens, this framework remains a design philosophy worth comprehending—and a conceptual split (derive versus infer) worth incorporating into your own mental models—but it is not a system ready for deployment.

If this breakdown provided something useful for you, subscribe for more plain-English analysis of AI research that actually matters.

Sources

More from Not A Tech Guy

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.