A task’s journey through a2

At the workbench — 10

A task often begins with a short sentence: “Clean up this data.”

But that sentence contains decisions not yet made. Which fields will stay? Which will be renamed? Will whitespace be trimmed? If a record appears twice, should both copies be preserved?

I want to consider a task’s journey through a2 by breaking these decisions into small, traceable parts.

For this, I will use a simple transformation from the project’s example files. A task with two records and no real user data.

From a request to an explicit rule

Each record in the sample input has a code, a name and a field that will not be used:

{
  "code": "A1",
  "name": "  First item  ",
  "ignored": "discard"
}

The requested transformation is small: code becomes id, and name becomes label. Leading and trailing whitespace in the name is removed. Other fields are excluded from the output.

But the rule does not end there. Preserving every record and producing no issue records in this example are also part of the contract.

These details narrow the space left open by “clean up”. They specify which changes may be made and which should not be made.

The first important piece is this contract, before the data itself.

Taking in the input

A task can be rejected before it reaches a model.

In a2’s data path, local input must have the expected structure. Duplicate JSON keys and invalid numeric values are not accepted. Input size is also bounded.

These checks do not resolve the meaning of the task. They answer a more basic question: do we have data we can read unambiguously?

Silently accepting a field name written twice in the same object, for instance, can obscure which value is being used before the transformation even begins.

Accepting input is therefore a step in the work too. A file’s existence does not mean it is ready to process.

Which path will do the work?

Not every task follows the same path in a2.

If a previously verified skill has an exactly matching contract for this transformation, data apply can execute it directly. No model call is made on this path.

Matching here is narrower than two tasks resembling one another. The transformation family, saved contract and contract version are considered together. If no suitable skill exists or selection is ambiguous, the run stops with a report. It does not automatically fall back to a model to try another solution.

Solving with a model and learning a new skill are separate paths.

This distinction makes the execution easier to understand. Did we reuse an existing piece, generate a new solution, or prepare a reusable skill candidate?

Even if the resulting files look similar, the grounds and costs of these paths differ.

Encountering the output

The expected transformation of the first sample record is:

{
  "id": "A1",
  "label": "First item"
}

The second record is transformed by the same rules. The complete output contains rows for the transformed records and issues for problems.

There are two separate examinations here.

First, whether the output has the expected structure. Second, whether it agrees with an independently prepared expected result.

In a2’s example files, the expected answer is kept separately. The model solving the task is not given the reference answer. Checking happens externally against the generated result.

Since every record must be preserved in this example, comparison also preserves the counts of duplicate records. An orderly-looking output should not conceal a missing record.

When no expected result is supplied, the report indicates a schema-only check. Reading such a report requires attention to the verification scope behind its “success” status.

Connecting one task to another

We might want the transformed records to be matched against another file afterwards.

This is now a larger task than the single-skill example. Which input of the second step receives the first step’s output must be defined explicitly.

a2’s data pipeline path executes sequential plans prepared by the caller. The previous step’s rows or issues can be passed to specified inputs. No implicit field transformation takes place in that connection.

If a step fails, downstream steps do not execute. If an intermediate result contains issues, their routing into the next step must also be explicit. Passing issues onward does not by itself establish that their meaning is preserved; the result needs a separate check.

It is also possible to ask a model for a proposed plan. Producing a proposal and executing it are separate operations, however. A proposed plan is not confirmation that the goal will be solved correctly.

This adds another decision point to the task’s journey: have these pieces actually been joined in a way that does the requested work?

The record left at the end

I do not consider transformed data alone sufficient at the end.

Which skill was used? What check was performed? Did the run complete, produce an invalid result, or stop at a limit?

a2’s reports carry traces of these questions according to the execution path. Direct reuse records the selected skill and verification scope; multi-step execution records completed steps and the code hashes of the skills used.

Learning a new skill has its own verification path too. Producing the right answer on one task does not show that the same operation will work on other inputs.

What we can conclude from this two-record example is limited as well. We can show its explicit contract and a checkable expected answer. We cannot infer general efficiency or broad correctness in real work from it.

The journey I want to follow in a2 is this: a request becomes a rule, an appropriate execution path is selected, the output is checked, and a readable record remains.

So that, when the next task arrives, we can return to the earlier file and ask:

What exactly did we achieve here, and under what conditions can we trust it again?

---

Source note — 15 October 2026: This essay draws on a2’s bundled example inputs and expected results, and its existing data, reuse, planning and sequential-execution code. The two-record transformation is a teaching example from the project, not real user work. Subsequent matching is an extension illustrating the flow. No new model call or evaluation run was conducted for this essay.

a2 project page · Previous essay: When should an agent stop?