Build once, call many: turning AI-generated scripts into reusable tools

The configuration comparison is finished. Then another pair of files arrives. Generating the program again means reviewing the same decisions again: which fields matter, whether order matters and what to reject.

The useful thing to keep is the decision boundary. For a configuration comparator, that means a defined input format and a rule for which differences count. A new pair of files should change the inputs, not reopen settled comparison rules.

For that comparator, make three outcomes explicit: unchanged, changed or rejected input. Suppose version 1 accepts a JSON object containing a Boolean enabled field. Comparing false with true yields a change. A file containing "enabled": "false" is rejected: interpreting a string as a Boolean would silently change the contract. Saving the program is useful only if the next caller can distinguish a real result from an input it should never have accepted.

Separate the reusable logic from each input. 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. Measure savings and reliability in the workflow where the tool will run.

CREATOR and LLM Agents Making Agent Tools also study creating tools for reasoning and execution. Which decisions stay fixed across the inputs your application receives?

Give the next caller a small contract it can use without reading the implementation:

Inputs: two version-1 objects with Boolean enabled fields
Outcomes: unchanged, changed, or rejected input
Accepted change: false → true
Rejected near miss: "false" instead of false
Recheck: dependencies, current inputs and side-effect permission

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.

Keep a script local until it needs a shared contract. 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.

A simple cost model exposes when reuse pays. Let g be the average cost of generating and reviewing each accepted solution, b the initial cost of building a reusable tool, r the average cost per accepted result of selecting and invoking it, and m its maintenance over the comparison period. For n equivalent accepted results, compare n × g with b + n × r + m. If g > r, reuse is cheaper only when n > (b + m) / (g − r). Include failures and supervision in each cost.

Reuse operates at several layers. In its July 2026 engineering account, OpenAI describes reducing repeated agent-loop work through bounded tool output, discoverable tools and cacheable prompt prefixes. Executable reuse preserves program logic; prompt caching reuses model-input computation; transport optimization reduces what must be sent. Measure each separately.

The surrounding workflow can still change. Anthropic’s March 2026 experiments removed context resets and later sprint decomposition as its models improved, while evaluation continued to catch broken application interactions. Keep the comparator’s accepted and rejected cases; reconsider orchestration that no longer earns its cost.

A stable command can call a changing API or read changing data. Its next invocation still needs current inputs, compatible dependencies and permission for any side effect. The lasting artifact is a usable contract, with enough evidence to recognize when it stops applying.

Keep the reasoning that repeats. Recheck the conditions that change. Promote this comparator when callers can select it, supply valid inputs and recognize rejection without reopening its implementation.