A company had two spreadsheets in the same workbook. One was the financial model — monthly, quarterly, annual. The other was the Monday Morning Metrics: a weekly operational dashboard with sales pipeline, warehouse labor, ad spend, and a customer roll-forward. They shared 317 row labels. They also had 260 rows that didn’t overlap at all — the operational layer the financial model was never designed to carry.
The task: read the weekly sheet, load it as a data source, and link it to the financial model wherever the rows matched.
One working session. The AI analyzed the sheet, scoped the work into an epic with five stories, laid out four design decisions with a recommendation on each. The human made the calls: weekly only for v1, link rows by their name rather than a mapping table, park the bigger “unified metric layer” idea on the backlog, build a new reader instead of patching the working one. The AI built it, reconciled the numbers, loaded 73,133 weekly rows, and shipped it live.
That could be the end of the story. A thing got built. It works. Move on.
But then the human said: “Remember this as an ability.”
That’s where it gets interesting. In this system, there’s a deliberate distinction between a memory and an ability. A memory is a thing you should know — a fact, a preference, a lesson. An ability is a thing you can do — code, a how-to document, a registry entry that makes it discoverable. The rule is explicit: don’t store in memory what the code already records.
“Read and ingest an MMM-style weekly sheet from Google Sheets” is a thing you can do. So it was filed as an ability — documented, registered, and listed so that the next company with a similar operational dashboard gets the same reader without rebuilding it from scratch.
This is the difference between shipping a feature and building infrastructure. The feature solves today’s problem. The ability solves the category. One session of work, and the system permanently knows how to do something it couldn’t do yesterday — not because someone remembered to write it down later, but because the act of filing it as a capability was the last step of the work itself.
Most software gets built, used, and forgotten. The script that “worked that one time” rots in a folder somewhere. Quality isn’t just whether the thing runs correctly today. It’s whether the work compounds. Whether the next time is faster because this time was done right.
That’s durability. That’s quality.