Aviral GargAn AI system can repeatedly solve a task by generating code each time. It can also create a useful program once, retain it and invoke it with new inputs. The second approach turns a sequence of answers into a small library of executable capabilities.
Consider a hypothetical script that compares two structured configuration files. The first request requires deciding how to handle ordering, missing fields and differences that matter. Later requests may need the same behavior on different files. Regenerating the implementation reopens decisions that could instead live in a documented contract.
The reusable part should be separated from the instance. File contents belong in inputs; comparison rules belong in the tool's contract. Paths, credentials and assumptions about one machine should not become invisible defaults. A program that works only on the original example has been saved, but has not yet become a reliable general tool.
This pattern has established prior work. Large Language Models as Tool Makers separates tool making from tool using and describes caching reusable tools behind APIs. Voyager develops a growing library of executable skills in Minecraft. Those settings provide useful ideas; they do not establish savings or reliability for a particular desktop workflow.
Related work includes CREATOR, which studies tool creation alongside reasoning and execution, and LLM Agents Making Agent Tools. The practical question for an application is therefore specific: which repeated operations deserve stable implementations, and how will callers know when those implementations apply?
A small contract can answer much of that question. State the inputs, outputs, side effects, preconditions, dependency versions and failure behavior. Include a normal example and a near miss. A configuration comparator might accept two files with a known schema while rejecting a different schema that happens to look similar.
Discovery then becomes part of correctness. A caller must identify the right tool, select the right version and provide valid arguments. A misleading description can turn a correct implementation into an incorrect workflow. Retrieval should favor a demonstrated match to the contract over a broad similarity between task names.
Promotion into a shared library should be deliberate. One useful script may remain a local helper. Repeated demand, a stable contract and tests covering meaningful variations can justify a maintained tool. Excessive generalization can cost more than it saves, especially when the underlying tasks only appear similar.
Reuse also creates a maintenance obligation. A parser can depend on a format that changes; an adapter can rely on an interface that moves. Record enough version and test information to detect that drift. When a precondition fails, the caller should stop or use a defined repair path rather than silently treating the old tool as applicable. Permission for one invocation also does not authorize every future invocation.
Whether this approach is worthwhile remains a measurement question. Compare repeated generation with retained-tool use on the same tasks. Include creation, review, discovery, invocation, failures, repairs and human supervision. The expected benefit is amortization, but small repetition counts or frequent drift can erase it. No savings follow merely from having a directory of scripts.
A useful next experiment is modest: choose one synthetic task family, retain a narrowly scoped tool and test unfamiliar variants alongside similar tasks it should reject. Measure selection errors and successful results as well as effort. The aim is to move stable reasoning into a maintained contract without hiding the judgment still required at the call site.