My father was an economist, which perhaps explains why one of the first toys he brought home for me was an abacus. I suppose he imagined that introducing his young son to numbers at an early age would be the beginning of a wonderful intellectual journey. Personally, I would have preferred a Matchbox car. Fortunately, the abacus had what looked like a lot of little wheels, and I discovered that if I laid it on its side, I could push it around the floor. I don't recall whether my father appreciated this particular application of mathematics, but I was perfectly happy with my new car.
I've been thinking about that abacus lately as we've been working on the next generation of SeerAI's technology. My father saw a mathematical instrument, while I saw something I could drive around the living room floor. Neither of us had changed the object itself, although we had very different ideas about its usefulness. There's probably a broader observation here about the difference between something that exists in the world and the meaning or purpose we assign to it, and I think it's relevant to a problem that has occupied much of my professional life.
We've spent decades building software around particular ways of describing and organizing information. Those systems have become extraordinarily sophisticated, and most were designed to solve legitimate problems. But over time, we've become so accustomed to working within their particular structures that we often mistake those structures for the information itself. We start with the database, the application, or the analytical tool, and then work backward toward whatever it is we're actually trying to understand.
Consider what happens when someone wants to turn a small commercial building into a restaurant. Before investing in architects, contractors, equipment, and a lease, the prospective owner would probably like to know whether the city will allow it, which permits are required, and what might prevent approval. These seem like reasonable questions to ask before committing a substantial amount of money, and the municipality already possesses much of the information needed to answer them.
The building has an address, a location, a zoning classification, a history of permits and inspections, and a collection of regulations that apply to it. The trouble is that these facts live in different systems, maintained by different departments, each with its own terminology and assumptions. The planning department describes the property one way, the tax assessor another, and the fire department has its own view. None is necessarily wrong, and each system may work perfectly well for its intended purpose. The difficulty appears when someone asks a question that requires those different descriptions to be understood together.
Eventually, an answer can be assembled. Someone establishes which zoning provisions apply, another determines whether the proposed use requires additional inspections, and perhaps someone else reconciles a discrepancy between the property records and an earlier permit. Each of these steps involves more than retrieving information. Somebody has had to understand what a record means, how it relates to another record, which rules are relevant, and why a particular interpretation makes sense.
What interests me is what happens to that understanding afterward. Some of it becomes part of the permit application, some finds its way into an internal note or a software workflow, and some remains with the employees who worked on the case. When the next owner wants to renovate the building, expand the restaurant, or open another type of business, a considerable amount of that work may have to be repeated. The records haven't disappeared, but much of what the city learned while interpreting them is surprisingly difficult to reuse.
This is something I've encountered repeatedly, from financial markets to large enterprise systems. Organizations are very good at accumulating information, but considerably less successful at preserving the intellectual work required to make sense of it. And as we begin asking AI to operate across these systems, that distinction becomes increasingly consequential.
Six Words Worth Remembering
We're spending enormous amounts of money developing increasingly sophisticated AI models. We debate reasoning capabilities, context windows, inference costs, and the emergence of autonomous agents. I find much of this progress extraordinary, but I'm not convinced we're giving enough attention to the information these systems are expected to work with. A model may be exceptionally capable at interpreting a question while knowing remarkably little about the particular building, company, asset, or regulation that question concerns.
At SeerAI, we've been thinking about this through six concepts that I believe deserve a more prominent place in the vocabulary of data and AI: Access, Meaning, Definitions, Provenance, Contracts, and Agency. None of these terms is particularly exotic, and that's part of their appeal. They describe requirements that are fairly intuitive once we consider what an intelligent system actually needs to do with information.
Access concerns the ability to use information where it already resides. In our permitting example, the municipality shouldn't necessarily have to copy its property records, geographic information, regulations, and inspection histories into an entirely new database before answering a question about a building. Sometimes moving or consolidating information is appropriate, but it shouldn't be an automatic prerequisite for every new inquiry. There ought to be ways to work across existing systems without continually reconstructing the information infrastructure.
Meaning is the understanding that allows us to recognize what those different systems are describing. The parcel in the geographic database, the property in the tax system, and the building in the permitting application may be related, although they aren't necessarily identical concepts. Establishing those relationships, along with the units, classifications, and other context needed to interpret them, requires some care. Once that work has been done, I see little reason why it should remain confined to the particular application or analyst responsible for the original question.
Definitions take that understanding further by describing the rules and concepts an organization relies upon. What qualifies as a restaurant? When does a renovation constitute a change of use? Which conditions require a fire inspection or additional accessibility measures? These aren't questions that can always be answered with a simple database lookup. They involve definitions that vary by jurisdiction, sometimes conflict, and often change over time. Making those definitions explicit and reusable would seem a sensible improvement over burying them in separate applications and expecting each person or AI agent to discover them independently.
Provenance concerns the evidence behind what we're being told. If an AI system advises our restaurant owner that a particular permit isn't necessary, I'd like to know which regulation supports that conclusion, when it was in force, and whether the system has considered any relevant exceptions. I've written before about the distinction between fluency and provenance, and I think it's one of the more important issues facing enterprise AI. An answer may sound perfectly reasonable while resting on an outdated rule, an incorrectly interpreted record, or a relationship that was never established.
Contracts describe the responsibilities that accompany information when other people or systems begin relying on it. Someone needs to know who maintains a particular source, how current it is, which definitions it follows, what uses are permitted, and what happens when its underlying data changes. In software this is often discussed in terms of data products, but I think the broader concept is quite straightforward. If we're going to reuse information across an organization, we ought to have a shared understanding of what can reasonably be expected from it and who is accountable when those expectations aren't met.
Agency is the point at which these other concepts become particularly important to AI. An agent assisting with a permitting application should be able to discover relevant information, understand the relationships among the records it finds, apply the appropriate definitions, evaluate the evidence, and explain its conclusions. It also needs to operate within the permissions and controls established by the organization, and recognize when the question requires professional judgment or formal approval. Without these foundations, we're asking increasingly sophisticated models to compensate for missing institutional understanding, which strikes me as a rather expensive and unreliable way to proceed.
I don't consider these six ideas to be new discoveries, nor do I think they belong exclusively to any particular technology. What matters is treating them as interconnected parts of the same problem. An organization may have excellent access to information but poor definitions, or carefully maintained definitions without an adequate record of where its assertions originated. When those weaknesses are exposed to AI, the consequences can extend well beyond an inaccurate report, particularly as agents begin making recommendations and initiating actions.
Making the Next Question Easier
Suppose our restaurant owner eventually receives approval and opens for business. During the permitting process, the municipality has resolved questions about the property, established which regulations apply, reconciled records across departments, and documented the reasoning behind several decisions. A considerable amount of intellectual work has gone into reaching that outcome, much of which could be useful well beyond the original application.
Now imagine that a year later someone wants to add outdoor seating, expand the kitchen, or convert part of the building into another use. The new application will have its own requirements, and some of the earlier conclusions may need to be revisited. But there should also be a substantial body of established understanding available to whoever is evaluating it. The property's location, the relationships among its records, the history of previous approvals, and the relevant definitions shouldn't all have to be discovered again.
This is central to what we're building with Geodesic V2. Our aim is to allow information to remain in the systems where it belongs while making the meaning, relationships, definitions, and evidence associated with it available for reuse. There's still work involved in establishing that understanding, and it needs to be reviewed and maintained as circumstances change. But if we're successful, the investment an organization makes in answering one question becomes useful when it encounters the next.
I've become particularly interested in the economic implications of this approach. We generally evaluate enterprise software according to how quickly it performs a task, how much labor it eliminates, or how effectively it answers a question. Those measures matter, but I think we're overlooking another potentially significant source of value: the extent to which solving one problem reduces the effort required to solve another. Organizations have spent decades investing in the expertise needed to interpret their information, and much of that expertise is lost or stranded every time a system is replaced, an employee leaves, or a new application is introduced.
The arrival of AI makes this an even more interesting proposition. We're likely to see rapid changes in models, agents, and the applications built around them, while the underlying things that businesses and governments care about will remain substantially the same. The restaurant may change owners, the building may be renovated, and the zoning rules may be amended, but the accumulated knowledge about those changes should remain available regardless of which software is being used to examine them.
Back to the Abacus
My father probably never imagined that the abacus he brought home would end up being driven around the living room floor. He had a perfectly sensible idea about what it was designed to do, while I had something else in mind. I suppose the lesson is that the usefulness of a thing doesn't necessarily end where its original designer imagined it would.
I think we've made something of the same mistake with enterprise information. We've allowed the systems built to manage it to impose unnecessary limits on how we think about it, even as the questions we're asking become more complex and the technologies available to us become more capable. At SeerAI, we're trying to separate the understanding an organization develops from the particular software that happens to produce or consume it, so that its accumulated knowledge remains useful as those technologies change.
That's why I keep coming back to Access, Meaning, Definitions, Provenance, Contracts, and Agency as a useful vocabulary for thinking about the next generation of data and AI systems. We've become remarkably accomplished at collecting and storing information, and I think it's worth asking whether we can become equally disciplined about preserving what we learn from it. If we can, the hundredth question ought to be considerably easier than the first.