Saved, Still Rebuilt: The Search Cost of Reusing AI Workflows

TL;DR for operators

An AI system can save a successful workflow and still spend substantial effort reconstructing how that workflow was originally assembled. Efficient reuse depends on whether the completed procedure is directly available to subsequent planning as a callable operation.

FormCraft proposes a capability architecture in which primitive and composed operations share typed interfaces, retain their formation provenance, and can participate in further compatible composition. Verification determines which operations enter a persistent library.

In a controlled comparison across 12 sequence-processing goals, exposing previously admitted operations directly reduced candidate attempts from 16,570 to 144, a 99.1% reduction. Historical composition expansions fell from 37,300 to zero. Both representations matched the evaluation oracle on tested cases.

For agentic platform teams, the practical opportunity is to reduce repeated planning and synthesis work. The reported figures do not measure wall-clock speedups: stored operations still execute their internal steps, and retrieving capabilities from a growing library introduces costs the experiment does not quantify.

A saved workflow can still be expensive to find

Consider an automation system that has assembled a multi-step procedure and verified its output. Another task subsequently requires the same procedure. The system could invoke the completed operation directly, or it could search through the composition decisions that originally produced it.

Both approaches may eventually execute equivalent operations. Their search requirements can differ substantially.

This problem motivates Hang Lin’s Recursive Formation and First-Class Reuse of Compositional Capabilities¹, which introduces the FormCraft framework.

The paper asks what happens when an acquired operation becomes an independently selectable capability rather than remaining primarily a historical product of program synthesis.

That change requires more than saving executable code. A planner needs a stable interface through which the operation can be selected, supplied with new inputs, and combined with other operations. The system must also preserve enough information to verify and inspect how the capability was formed.

FormCraft treats these requirements as properties of the capability representation itself.

Making composed operations callable without rebuilding them

FormCraft gives primitive and composite capabilities a uniform operational interface. Each capability accepts a concrete input and externally supplied invocation parameters, then produces an output.

The stored representation includes typed input and output contracts, an external-parameter schema, an executable body, and an operational identity. Composite capabilities additionally retain parent references, static wiring information, formation depth, and provenance.

The important design choice is that invocation-specific data remains outside the capability’s formation record. The same operation can therefore be called on new instances without being rebuilt for each invocation.

A composite also becomes eligible to participate in further composition. Under compatible input/output contracts and wiring, combining well-formed capabilities produces another well-formed capability. The paper establishes finite recursive closure under these assumptions (Section 2.4, Proposition 2).

This is a conditional architectural guarantee. It does not imply that arbitrary operations can be combined safely or meaningfully.

The model additionally separates three properties that capability registries may otherwise conflate:

• Operational behavior: what the capability produces for valid inputs and parameters.
• Operational identity: how the system identifies an operation independently of a particular formation history.
• Formation provenance: which parent operations and wiring decisions produced the recorded capability.

Two capabilities may behave equivalently while retaining different provenance. FormCraft’s definition of behavioral equivalence requires agreement over all contract-valid invocations, a stronger condition than passing a finite test suite.

These distinctions allow a planner to use a composite through one public interface while the system retains its internal construction record for inspection.

Importantly, the composite’s internal execution has not disappeared. What disappears from subsequent search is the requirement to reconstruct the historical composition decisions before selecting the operation.

Verification determines which capabilities persist

FormCraft separates forming a valid callable capability from admitting that capability into long-term storage.

A successfully formed operation may already be first-class: it has a uniform interface and can participate in compatible composition. Persistent library membership is a subsequent, verification-controlled decision.

The implementation makes this lifecycle explicit:

1. Formation: construct an executable capability with compatible contracts and recorded provenance.
2. Verification and admission: apply appropriate checks before retaining the capability in the persistent library.
3. Reuse: expose an admitted operation directly to later searches through its public interface.

Verification varies by domain. The implementation includes executable oracles, contract checks, provenance audits, cold-reload checks, cross-language execution comparisons, and independent proof checking where applicable.

The evaluations test different aspects of this lifecycle.

In a propositional microdomain, all five composite capabilities were formed successfully and reused across ten theorem instances. Lean accepted all ten checks, with capability-record hashes and formation provenance preserved (Section 4.3, Table 2). These are independent checks of the tested propositions, not a general proof of correctness for every capability FormCraft can represent.

The sequence-processing study examines persistent acquisition. Seven example-driven Stage I goals added 14 executable capabilities, increasing the store from 12 to 26 records. All seven roots passed cold reload. A subsequent increasing-depth Stage II added 12 executable capabilities across 12 goals, bringing the store to 38 records and reaching a maximum formation level of ten (Section 4.4, Table 3).

The final 38 records comprise 36 executable capabilities and two auxiliary records. The stages use different training and holdout protocols, so their results demonstrate sequential library growth rather than a single homogeneous learning benchmark.

Direct exposure sharply reduces historical search work

The central quantitative experiment compares two ways of presenting previously formed operations to subsequent search.

Under Expanded, search reconstructs the target’s earlier D-level composition chain. Under First-class, the previously admitted target is available directly through its public operation interface.

The study holds the 12 D01–D12 goal definitions, starting snapshot, executable capability pool, oracle, seed, verifier, applicable examples and holdouts, and candidate limit fixed. Both representations match the frozen oracle on evaluated cases.

The search-work measurements differ markedly (Section 4.5, Table 4):

Candidate attempts decline by 99.1%, while verification batches decline by 98.9%.

The reductions arise from changing what search must construct. Instead of rebuilding previously established composition chains, the First-class representation permits direct selection of existing operations and binding of their invocation inputs.

The zero counts for historical expansions and intermediate materializations are particularly informative: those operations disappear from the measured reuse-time search route because the historical formation has already been captured in a callable capability.

They do not imply that the stored composite has become computationally trivial.

The paper also compares FULL and ACTIVE lifecycle views, which expose the same aggregate 366 executable records across the 12 goals and both produce 144 first-class candidate attempts. This additional comparison supports the interpretation that the measured advantage concerns historical-depth handling rather than a narrower exposed capability pool.

Still, the result comes from a fixed experimental family and an intentionally controlled comparison of search representations. It should not be interpreted as a 99.1% reduction in execution latency, total computational cost, or production operating expense.

What agentic platform teams can apply

For an enterprise automation architect, FormCraft suggests treating reusable procedures as managed executable assets with stable contracts, rather than retaining them only as successful planning traces.

A platform encountering recurring workflow patterns could use four architectural responsibilities:

Capability creation. Produce a typed, independently callable operation, keeping task-specific data and parameter values outside its persistent definition.

Admission control. Require domain-appropriate verification before making the operation available for persistent shared reuse.

Provenance management. Preserve parent references, formation details, identities, and verification records so later inspection does not depend on repeating the original synthesis process.

Direct planner exposure. Allow subsequent tasks to select admitted operations through public interfaces and use them as building blocks for compatible higher-level procedures.

This arrangement offers a potential reduction in repeated planning overhead when the same composed operations are needed across multiple tasks.

But the deployment decision should depend on a fuller measurement framework. Platform teams need to measure capability retrieval overhead, search attempts, verification work, internal execution latency, and overall operating cost separately.

For example, direct exposure may reduce synthesis effort substantially while providing little benefit for a workflow whose internal execution dominates total latency. Conversely, repeatedly reconstructing complex procedures may impose meaningful overhead even when executing those procedures is inexpensive.

Library growth introduces another unresolved dimension. The paper does not establish how retrieval, deduplication, or search breadth should behave when thousands of heterogeneous capabilities accumulate. A direct-operation interface does not by itself guarantee efficient selection from an expanding registry.

The boundary of the result

FormCraft contributes a formal representation and an implemented lifecycle for recursively composable capabilities. Its strongest quantitative finding concerns the search work avoided when already admitted composites are directly exposed.

The continuous and discrete prototypes support instance-independent invocation. The Lean experiments test independently checked reuse in a small propositional domain. The sequence experiments demonstrate persistent acquisition and controlled historical-search reduction. These are complementary checks of different architectural properties.

They do not establish universal behavioral correctness, superiority over existing abstraction-discovery methods, or production-scale runtime improvement. Finite oracle checks are also narrower than the paper’s formal definition of behavioral equivalence across all valid inputs.

The broader implication for agentic system design is nevertheless concrete. Retaining a successful workflow and making it directly reusable are separate engineering decisions. FormCraft specifies how a composed operation can retain its executable behavior and formation history while appearing as one selectable capability to future search.

For systems repeatedly assembling procedures they have already acquired, that representation is worth benchmarking. The measured advantage is less historical reconstruction during planning; its economic value depends on whether those avoided searches materially affect end-to-end performance.

Cognaptus: Automate the Present, Incubate the Future.