Turning an idea into a working tool

Tools and work — 04

After solving a task, we encounter another of the same kind. The data changes, but part of the operation stays the same.

Noticing this similarity is easy. Determining which part of the solution we can reuse is harder.

A correct answer on one occasion is not yet a tool. To become one, it needs clear inputs, outputs, and conditions of use.

This is where a2’s starting question lies:

Can we turn a successful solution into a skill that can be tested and reused on other tasks?

Bringing the idea down to a small task

This question could be kept very broad. We could imagine an agent that uses different tools, learns from its history, and takes on every kind of work.

The current focus in a2 is narrower: data transformation.

Normalising records, matching data from two sources, separating conflicts, and selecting required fields. These tasks may look small, but they provide concrete ground for examining the tool’s behaviour.

Consider a hypothetical example. Two files record the same products in different forms. One uses product codes, the other supplier codes. Some fields are empty, and some values disagree.

We might begin with “merge these files.” Producing the right result, however, requires clearer rules: which field determines a match? What happens to unmatched records? How should conflicting values be shown?

As these questions are answered, the idea becomes an executable task.

Is an output that looks correct enough?

The first solution may produce tidy JSON. Fields are in place, and the file is readable.

The result can still be wrong. A record may have been omitted, two different products merged, or one conflicting value silently selected.

That is why a2 separates checking the output format from verifying the task result.

When an independently specified expected output exists, the generated result can be compared with it. Without that basis, the report identifies the check as schema-only. This is not presented as semantic verification of the task.

The same distinction extends to history records. An invalid output should not be stored as a successful solution.

Reuse should begin with a solution verified under specific conditions, rather than an operation that merely appears complete.

From a solution to a candidate skill

When a task is solved correctly, an executable candidate skill can be generated from that solution.

This transition differs from storing the answer. The aim is to obtain a component that performs the same operation on new inputs.

In a2’s data-learning path, the candidate is checked externally against three new verification tasks before it is persisted. Expected verification answers are not given to the model conversation.

If the candidate passes, it is stored with its contract version, provenance, code hash, and verification fingerprints.

We therefore retain more than “this code worked.” We also retain the conditions and checks under which it became usable.

Passing a few examples does not prove correctness for every possible input. The stored skill’s scope does not automatically extend beyond the examples and contract that verified it.

Does reuse mean better work?

Producing a skill and being able to invoke it is an important step. Its contribution to the work must also be measured separately.

In a2’s comparison setup, the same tasks are handled under five conditions: no history, successful solution examples added as context, human-written skills, learned skills, and unrelated skills.

Learned skills are frozen during evaluation. This avoids measuring a tool that changes while the test is running.

Alongside quality, the records capture latency, model and tool calls, actual skill use, and observed token consumption. The cost of producing the skill is kept separate too.

The bounded live learning work recorded in the sources produced skills that passed independent checks in four data-transformation families. The small, incomplete comparisons, however, showed no efficiency advantage.

This result makes an important distinction visible: producing a usable component and having it improve the whole workflow are separate questions.

A tool may return the right output while the agent calls it unnecessarily or combines it incorrectly with other components. Accepting one component is therefore insufficient to accept the completed task.

Where a tool should not be used

In the previous essay, we discussed evaluating the relationships that make a recalled record valid. Reusing a skill encounters a similar boundary.

Is a skill that worked correctly before compatible with the rules of the new task?

If the matching rule has changed or a different transformation is required, silently using the old skill can produce the wrong result. Contract compatibility is therefore checked explicitly in a2.

Building a multi-step plan from existing skills is another area of work. One component’s output may become the next component’s input, but the conditions of that composition and its final result require separate verification.

Saying that no plan can be produced for unsupported work is part of this behaviour too. A working tool should distinguish work within its capabilities from work outside its current scope.

A working component and a finished tool

a2 remains a development alpha.

The offline demo shows verification and reuse of human-written skills on different inputs. It should not be treated as an experiment demonstrating model learning.

Live learning records form another line of evidence. Complete multi-seed evaluations and validation on real user data are still needed.

At this point, it is difficult to see the transformation from idea to tool as a single moment of completion. Each stage opens another question:

Is the solution correct? Does the skill derived from it work on new inputs? Which rules is it compatible with? Does reuse improve the whole task?

The work taking shape in a2 is to pursue these questions without conflating them.

When we can run a solution again, we have a component. As we establish when to use it, how to test it, and when to stop it, that component becomes a tool.

---

Source note — 15 October 2026: This article draws on a2’s README, architecture, evaluation documents, and dated development records. The product-files example is hypothetical. No new model call or evaluation run was made for this article; it reports bounded results already recorded in the sources.

a2 project page · Does memory store records or relationships?