Data Déjà Vu

Why do we keep solving the same problems?

I suspect everyone has had the experience of calling customer service, explaining a problem in considerable detail, and then being transferred to someone else who asks you to explain the whole thing again.

What I find particularly irritating is that every new person begins by asking for my name. Didn't the previous person just tell me they were transferring me to someone better qualified to help? Presumably they told that person something about why I was calling. And aren't they looking at a computer screen with my name on it? I can only imagine what else they might be looking at.

There's a ticket number, a customer history, perhaps even a transcript of everything I've said. Somewhere, a computer has dutifully recorded every detail of my increasingly unpleasant afternoon. Yet the next person still needs me to reconstruct the problem and quite often begins by asking me to perform the same troubleshooting steps I've already completed twice.

I suppose I shouldn't be surprised. Having spent much of my career working with enterprise data, I've seen essentially the same thing happen inside some of the world's most sophisticated organizations. Someone asks a question, and an entire process begins to unfold, much of which looks remarkably similar to what happened the last time somebody asked something remotely related.

An analyst goes off to find the data, figure out what it means, reconcile the inconsistencies, build a spreadsheet, and produce an answer. Perhaps someone remembers that another analyst did something similar six months ago. Better still, there's an old spreadsheet they can use. Except that spreadsheet was built to answer a different question. It contains assumptions nobody remembers making, formulas nobody wants to touch, and information that may no longer be current. So we adapt it, retrieve some additional data, and repeat much of the original work.

I call this data déjà vu. We've been here before, and we're remarkably comfortable doing it all again. The strange thing is how much intellectual work disappears into this process. Someone figured out which records refer to the same facility, which definitions apply, how different sources relate, and why a particular interpretation makes sense. That understanding is valuable, but it tends to remain buried in the spreadsheet, the application, or the mind of the analyst who built it.

Most enterprise software remembers what you did. Very little of it preserves enough of why you did it to help you do something different next time.

Now consider what happens when we introduce AI. An agent might complete the entire exercise in minutes instead of days, which is certainly useful. But if it has to rediscover those relationships, definitions, and assumptions every time someone asks a new question, we've made the old process faster without addressing why we keep repeating it. And if the agent simply begins with the previous spreadsheet, it may inherit assumptions that made sense for the original question but have little relevance to the new one.

At SeerAI, we're developing Geodesic around the idea that the understanding established while answering a question should remain available afterward. Where the information lives, what it means, how it relates to other information, which rules apply, and what evidence supports a conclusion should become reusable knowledge. The next question may require different assumptions, newer information, or an entirely different approach, but we ought to be able to build on what we've already learned without being constrained by the structure of the previous answer.

There's an interesting economic implication here. We generally measure the value of software by how quickly it answers a question or completes a task. But suppose every question also leaves the organization better equipped to answer the next one. The relationships established, the definitions clarified, and the evidence assembled become useful to other people, applications, and AI agents, even when they're working on something quite different from the original problem.

I've often said that the hundredth question should be easier than the first, but lately I've come to think that doesn't go far enough. The hundredth question should be a question you couldn't reasonably have asked before. As an organization's understanding accumulates, it becomes possible to recognize relationships that weren't previously apparent and explore possibilities that would once have required weeks of preparation. That's a considerably more interesting opportunity than simply making our existing processes faster.

We've spent decades teaching computers to remember what we did. Perhaps it's time we became equally serious about preserving what we learned, so we can finally stop starting over. And maybe, just maybe, the next customer service representative will already know my name.