For most of my career, the consumer of a data product was a person. They read the documentation, asked questions in chat, and filled the gaps with judgment. That era is ending. The fastest-growing consumer of the data products I build is software: artificial intelligence (AI) agents and language models that read your data the way a person would, minus the judgment. I work on this full time, designing data products where AI systems are first-class consumers. Here is a practical look at what changes when the reader of your documentation is a machine.
The Wiki Test
A human consumer resolves ambiguity by asking. An agent resolves ambiguity by inventing. When a person cannot tell which of your three date columns is canonical, they message the team. When an agent cannot tell, it picks one, confidently, and builds on the choice. The gap that used to surface as a question now surfaces as a wrong answer downstream, delivered with perfect fluency.
So the bar moves. I hold data products to the same standard I hold specifications: a competent agent should be able to use the product with zero human clarification. If your dataset only works because a knowledgeable person is nearby, it is not agent-ready. It is a person with extra steps.
Four Upgrades That Make Data Agent-Ready
| Upgrade | From | To |
|---|---|---|
| Contracts | Prose that describes the dataset | A binding schema with quality rules and an availability target |
| Precision | Column names a human can guess at | Every field defined, with units, currencies, and time zones stated |
| Quality | A person eyeballing a dashboard | Validators and checks that run on every load and fail loudly |
| Provenance | Tribal knowledge of where data came from | Every field traces to a definition and a source |
First, write contracts, not descriptions. A data contract states the schema, the types, the allowed values, the quality rules, and an availability target, a service level agreement (SLA). Prose describes a dataset. A contract binds it, and a contract can be validated automatically, which prose never can.
Second, get to field-level precision. An agent will not intuit that a column named px holds a price, or that your timestamps are New York time except in the one table where they are not. Name things fully. Define every field. State units, currencies, and time zones explicitly. Every hour spent here is repaid on every query any agent ever runs.
Third, make quality machine-verifiable. If quality means a person eyeballing a dashboard each morning, every agent inherits the gap between what that person checks and what they miss. Schema validators, quality rules that run on every load, and checks that fail loudly turn quality from a habit into a property of the system.
Fourth, keep provenance. Every field should trace to a definition and a source. When an agent's answer gets challenged, and it will, lineage is the difference between an audit and an argument.
Robots Are Just Strict Humans
Here is the part I find funny. Nothing on that list is exotic. Contracts, precise definitions, automated quality, lineage: this is exactly what human consumers of data have been asking for since the beginning. We just never fully delivered, because humans compensate. They ask around, they guess well, they carry context in their heads. Agents do not compensate, so the discipline finally has to be real.
Designing for robots, it turns out, is just designing for humans with the excuses removed. If you want to start on Monday: pick one dataset that matters, write one contract for it, and wire up one validator that enforces it. Your agents will work better immediately. So will your people.
This is the first post in a new track on data and agent tooling built to go deeper than a field report, working templates, checklists, and scripts you can actually run. Free for now while the track grows; the deepest installments become a paid tier later.