When the rules live in application code, only the application can act on them. An agent hits a wall it cannot see — and that wall used to be merely expensive.
Application-centric design starts from screens: what will the user do, what fields does that need, build a database to persist it. Meaning ends up distributed through validation functions, automations and conditionals — a rule written in 2019 by someone who left, encoded in a method nobody reads. The data underneath records what happened without carrying what it means or what is allowed.
Data-centric design inverts the starting question from "what will the user do" to "what is true". Entities and relationships first, then attributes and constraints, and the screens become a projection of that model rather than its cause. The effort curves differ characteristically: application-first is fast to a first screen and slow to scale, because each new surface re-implements meaning; data-first is slower to start and close to free to extend, because the meaning is already there to project from.
This was a defensible trade-off when humans were the only consumers, since a person can read the code, ask a colleague, or absorb the rule by osmosis. An agent cannot. Semantics buried in a validation function are invisible to it — not hard to find, unreachable. It will act confidently on the data it can see while remaining ignorant of the constraint that governs it, and produce output that is structurally valid and organisationally wrong.
That turns an old architectural preference into a current requirement. The phrase worth keeping is rules are rows: if a constraint matters, it should live where anything can read it, not compiled into one consumer. Structure, meaning and rules travelling with the data is what lets a second consumer — a report, a model, an agent — arrive later and behave correctly without re-deriving the business from source code.