a2’s first technical preview

Release note — 0.1.0a1

When doing the same task again tomorrow, what can we keep from the previous solution?

Working with data files, we often encounter this question. Records change, but some rules for selecting fields, transforming data and matching sources stay the same. Reusing a solution requires explicit rules, an identifiable implementation and checks on the new result.

I have published a2’s first technical preview, version 0.1.0a1, on GitHub. Source code, installation packages and inspectable demo records are available.

a2 is a small Python agent project built around tool use, shared memory, output validation and reusable skills. Its current focus is data transformation: organizing records, matching sources, separating conflicts and selecting required fields.

What I particularly want to make visible in this release is how the work was done.

Which plan ran? Which skill was used? Which code version was selected? Was the result checked only for format, or also compared against an independently prepared expected answer?

The answers can be inspected alongside the output.

A first encounter: reconciling two files

The presentation demo uses two customer lists arranged as though exported from CRM and ERP systems.

Customer codes in both systems are assumed to identify the same customers. But the lists do not contain the same records. Some customers have matches; others need review.

The demo uses two days of synthetic data. On day one, four of six CRM records match and two are reported separately. On day two, five of seven match and two are again set aside for review.

The same two skills are used on both days: one transforms fields, the other compares customer codes by exact matching. Separate expected answers check the results.

This execution needs no API key and makes no model calls. The demo skills are human-written.

What it demonstrates is a solution prepared under particular rules being run again on new inputs with the same version.

The scope of the technical preview

I see this release as a shareable starting point for trying the approach.

The demo does not use real customer data. It establishes no live CRM or ERP connection. It does not perform approximate name matching or resolve different customer identities automatically.

Generating skills with a model is a separate line of evidence. An earlier bounded live run produced four skill families that passed independent checks. That result does not show a general efficiency advantage for learned skills; broader comparisons remain necessary.

The GitHub CI run for the release commit completed successfully. This is a result from the recorded software checks; it does not replace a real-user pilot or learning and efficiency evaluation.

After this first preview, I want to encounter the rules of an actual task.

How much effort do setup and checking take? What interventions remain on repeated runs? Can we catch wrong matches? When the file changes, is the same solution still appropriate?

I am sharing a2 at a stage where these questions can be asked about concrete work.

---

Source note — 18 October 2026: This text draws on the 0.1.0a1 release documents and existing demo records. Demo data is synthetic and skills are human-written. No new demo, model call or evaluation was run for this essay.

Source code · Release and downloads · Demo guide · Download HTML report · Download demo evidence · GitHub CI

Connections: a2 · Turning an idea into a working tool · When should an agent stop? · The same task, a different file tomorrow · Why does a plan refuse to run?