The Agent Run Becomes the Playbook
Arun Malik's arXiv paper on progressive crystallization argues that recurring agent work should stop being rerun as probabilistic exploration and start being promoted into tested, deterministic playbooks.
The Paper
The paper is Progressive Crystallization: Turning Agent Exploration into Deterministic, Lower-Cost Workflows in Production, arXiv:2607.07052 [cs.SE]. The arXiv record lists Arun Malik as the author, with submission on July 8, 2026 and cross-listings in cs.AI, cs.DC, cs.ET, and cs.MA. The arXiv record describes a conference-style manuscript, and the PDF metadata reports four pages.
The topic is not a new chatbot benchmark. It is an operations lifecycle for agents already doing repeated work. The paper asks what happens after an agent has handled the same class of incident many times. Should the organization keep paying for fresh model inference, fresh stochastic investigation, and fresh uncertainty every time, or should the successful trace become a governed workflow?
That puts the paper next to workplace-agent outcome evaluation, agent action receipts, workflow logs, and operational envelopes. Its useful phrase is progressive crystallization: agent exploration becomes discovery, not permanent execution.
Discovery Is Not Execution
The paper's core complaint is economic and epistemic. A live agent can investigate a novel incident by reading system state, calling tools, reasoning through a path, and taking bounded actions. But if the same incident recurs, a pure agent loop rediscovering that path is wasteful. It spends tokens again, introduces run-to-run variation again, and leaves operators comparing similar but not identical traces.
Malik's proposal is to treat successful traces as raw material. Once a run has been verified, the system extracts the ordered tool calls, branch conditions, input and output schemas, tool-dependency graph, instance-specific parameters such as device IDs and timestamps, and explicit human-approval gates. The result is a reusable playbook class rather than a transcript trophy.
Three Playbooks
The paper defines three execution types. Type 3 is agent-orchestrated: sub-agents reason inside a bounded scope, read operations can be autonomous, and write operations use deterministic checkpoints and human-in-the-loop gates. Type 2 is hybrid: the steps are structured, but specific stages still call an LLM for interpretation, classification, or summarization. Type 1 is deterministic: pre-coded logic, conditionals, typed API calls, no runtime LLM tokens, and full reproducibility.
The token economics are explicit. A Type 3 run is described as roughly 10,000 to 50,000 tokens. Type 2 is about 1,000 to 5,000 tokens. Type 1 uses zero tokens and completes in milliseconds. The point is not only cheaper runtime. It is that autonomy becomes attached to a proven playbook and action type, not to a model brand.
The Promotion Rule
Promotion is evidence-gated. The default Type 3 to Type 2 transition requires at least 10 successful runs, zero safety violations, at least 90 percent of runs producing the same action sequence, all generated acceptance tests passing, and no human override in the recent window. The Type 2 to Type 1 transition requires at least 50 successful hybrid runs, 99 percent LLM classification consistency, deterministic-rule coverage of observed input variation, a full regression suite passing without the LLM, and human review of the deterministic logic.
The paper also makes crystallization reversible. A promoted playbook is demoted on execution failure, safety violation, or acceptance-test regression. The production example is concrete: a firmware update changed command output, a deterministic parser failed, the system demoted the playbook to hybrid so an LLM could handle the changed format, and clean executions later allowed promotion again.
The Production Claim
The production evaluation is a single-domain operational report, not a controlled randomized study. The paper says the lifecycle was deployed in a cloud network operations platform handling tens of thousands of incidents per month. Over eight months, deterministic Type 1 executions rose from zero to about 45 percent, with roughly 30 percent hybrid and 25 percent still agent-orchestrated. Per-incident agent cost fell by more than 70 percent while incident volume roughly doubled.
The paper also reports that the platform resolved over 90 percent of common incident categories autonomously, reduced mean time to resolution from hours to minutes, and kept false-positive remediation below 5 percent with no customer-visible impact. Those are paper-reported production observations. Their governance value is strongest when read as a claim about trace discipline, promotion gates, and demotion paths, not as a universal proof that agents should automate operations broadly.
Limits and Governance
The limitations are material. The results come from one organization and one operational domain. The economics depend on recurring patterns; highly novel environments will keep more work at Type 3. The acceptance tests generated from traces can be too weak if a pattern is under-observed. Sparse logs limit what can be extracted. The economic figures are platform-level observations across one maturity path.
Still, the governance lesson is sharp. Model capability should not grant blanket autonomy. A workflow earns autonomy by accumulating a record: repeated success, stable action sequence, safety history, regression tests, schema validation, human review, and demotion conditions. The agent does not become trusted in general. A specific class of work becomes cheaper and more deterministic because the evidence says it can.
The Receipt
A crystallized-playbook receipt should name the originating agent run, incident class, tool-call sequence, branch conditions, schemas, dependency graph, parameterization rules, human-approval gates, Type 3 and Type 2 run counts, safety violations, override history, action-sequence stability, generated acceptance tests, regression suite, LLM classification consistency, deterministic-rule coverage, reviewer signoff, deployment date, demotion triggers, demotion events, cost change, latency change, false-positive remediation rate, and post-change replay results.
The Spiralist reading is simple: the agent run is not the product. The auditable playbook is.
Sources
- Arun Malik, Progressive Crystallization: Turning Agent Exploration into Deterministic, Lower-Cost Workflows in Production, arXiv:2607.07052 [cs.SE], submitted July 8, 2026.
- arXiv experimental HTML for Progressive Crystallization, checked for taxonomy, lifecycle stages, promotion criteria, economic model, safety argument, production evaluation, and limitations.
- arXiv API record for arXiv:2607.07052, checked for title, author, categories, submission date, and version metadata.
- arXiv PDF for Progressive Crystallization, checked as the PDF source and for PDF metadata.
- DOI resolver for 10.48550/arXiv.2607.07052, checked as the arXiv DOI route.