An a2 working record
To understand whether a data workflow is reusable, we need to look at the second file.
A solution that works on the first file may be tailored only to its details. When the records change, what stays constant becomes clearer.
That is why a2’s presentation demo has two separate days.
The scenario is small: find which customer codes in a CRM list have counterparts in ERP. Both systems are assumed to use the same unique code. The data and companies are synthetic.
Rules first
The first skill prepares the CRM fields. code becomes id; name becomes label. Leading and trailing whitespace is removed from the name.
The second skill matches the prepared records against the ERP list by customer code. Matching records enter the result list. CRM records with no counterpart are kept separately with the code missing_match.
Accounts found only in ERP do not enter this task’s matched-customer list; their count is reported separately.
This choice matters. We are not implementing every possible meaning of “reconcile two files”. We are running a comparison in a specified direction under a specified rule.
The two-day record
The release package’s run summary contains these results:
| Record | Day one | Day two |
|---|---|---|
| CRM records | 6 | 7 |
| Matched records | 4 | 5 |
| Unmatched CRM records | 2 | 2 |
| ERP-only accounts | 1 | 1 |
| Model calls | 0 | 0 |
Each day’s result was compared against an independent expected answer. The code hashes of the skills used are identical too.
I do not read this table as a speed or learning comparison. I read it as a limited record of the same rules being executed with the same skill versions on two sets of data.
A small detail: 0007
One customer code in the demo is 0007.
Although it looks numeric, here it is an identifier. Its leading zeros are preserved. Turning it into 7 would be a change not permitted by the task contract.
Matching is exact and case-sensitive. Similar-looking names are not used to infer that records belong to the same customer. Empty or duplicate codes are rejected.
These may look like small details. Yet a data workflow’s reliability often depends on precisely these points: the system knows which transformation to perform and leaves no ambiguity about which it will not perform.
Where to look after the result
The demo produces more than a summary screen. Plans, matched records, issue lists and execution records can also be inspected. The HTML report makes them easier to read together.
After installation, the demo can be run with:
python -m a2.customer_demo --output runs/customer-demo --compact
Choose a new output directory for another run.
The question answered by this example is narrow: can we use the same two skills on a new file and check the result against a separate reference?
Real use will add other questions. Do the source systems actually share the same identifier? Have the rules changed? Who will handle the records set aside for review?
The second file is the beginning of reuse. Checking that the meaning of the work has not changed remains an ongoing responsibility.
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 · a2’s first technical preview · A task’s journey through a2 · Why does a plan refuse to run?
This connects to
Examines a2’s 0.1.0a1 technical preview and the limited evidence in its release package.
Makes the announcement’s reuse idea concrete through two days of demo records.
Connects the data-task journey with the published synthetic CRM/ERP example.
Moves from the two-day demo to the separate refusal check after skill state changes.