Ask a stranger to grab you lunch. Tell them "get me something I'd like," and walk away. You'll get something. Maybe it's fine. Maybe it's a ham sandwich and you're vegetarian.
Ask a good friend the same thing, and they'll ask a follow-up question or two. Better odds.
Ask your spouse, or the friend you've eaten a hundred meals with, and they don't even have to ask. They already know you hate tomatoes, love spicy food, and will not, under any circumstances, eat mushrooms. They nail it, every time, without thinking hard about it.
Here's the thing that's easy to miss: the stranger and your spouse could be equally intelligent. Same IQ, same taste in restaurants, same ability to read a menu. The only variable that changed was context. Intelligence without context is just a guess wearing a confident face.
AI is no different. Give a model a hard problem and no context, and you get the stranger's lunch order: something, delivered confidently, that misses what actually matters.
So what does that mean for the electrical grid?
Right now, most grid operations run on a fragmented view of the world. Customers, meters, DERs, real-time grid status, SCADA. Each one lives in its own system, speaking its own language, updating on its own schedule. Nothing talks to anything else natively.
A human can stitch it together by hand. Utilities have smart, capable people who do exactly that every day. But it's slow, and it's expensive, and the practical result is that the proactive questions never get asked. Not because nobody's smart enough to ask them, but because the cost of getting an answer is too high to justify asking in the first place. Nobody spins up a cross-system data pull just to check a hunch.
That's the real cost of fragmentation. It's not that hard questions go unanswered. It's that most of them go unasked.
AI hits the identical wall
Here's the uncomfortable truth nobody selling "AI for energy" wants to say out loud: bolting a language model onto a fragmented data environment doesn't fix the fragmentation. It just gives the fragmentation better vocabulary.
An AI model dropped into that same environment can't connect a customer to the transformer up the street, because nothing ever told it they were connected. It certainly can't dispatch a home battery when it detects a voltage drop nearby, because it has no idea the battery exists, let alone that it's sitting three hundred feet from the problem.
Come back to lunch for a second. This is the model showing up as the stranger, not the spouse. It isn't that the model is too dumb to order the right thing. It's that nobody ever gave it the hundred shared meals' worth of context it would need to know what "the right thing" even is. Same intelligence, no context, confident guess.
I want to be careful here, because it's easy for this to sound like shade at specific vendors, and that's not the point. This isn't about anyone being incompetent or dishonest. Most of the industry genuinely doesn't have the connected data to work with yet. That's a real, structural gap, not a character flaw. The point isn't "they're lying about their AI." It's that the AI can't be as good as advertised until the underlying context problem gets solved, and that's true no matter how good the model is.
What "having context" actually requires
To get the most out of both your people and your AI tools, you need a shared, connected, and (this part matters more than it sounds like it should) live picture of everything happening on the grid.
That means:
- Distribution grid topology: substation, feeder, transformer, meter, all mapped and connected. (There's more wiring detail in reality, like switches, reclosers, and span lengths, and we map all of that too, but this is the piece that matters for the story below.)
- Meters of every kind: consumption and generation, residential, commercial, and industrial.
- DERs layered on top: batteries, solar inverters, EVs, connected into that same topology, not sitting in a separate system nobody cross-references.
None of that is AI. I want to say that plainly, because it's the whole point: this is unglamorous data-unification work. Topology mapping. Meter ingestion. DER registration. It's the stuff that doesn't make a good demo. It's also most of what we spent the first few years of Texture doing. We invested heavily, up front, in modeling the underlying infrastructure and building data models designed to produce a virtual twin of the entire grid and every one of its connectivity points. That's the boring foundation everything else stands on, and skipping it is exactly how you end up with a chatbot that's confidently wrong.
One piece of that prerequisite work that's easy to underestimate: most utility Meter Data Management Systems are built to store a meter ID and its interval reads, and not much else. Where that meter physically sits, whose it is, and how it connects into the grid typically live in other systems entirely, if they're recorded accurately at all. Location and topology sit in GIS, customer and account in CIS, and the meter-to-transformer mapping in particular is a notoriously incomplete piece of data across the industry, which is why utilities run entire projects just to reconstruct it. So someone has to stitch all of those relationships together before any of the spatial analysis below is even possible, and that someone usually spends a very long time pulling their hair out over cross-linkages that should have existed from day one. We did that mapping work up front. It's why it's now trivial to look at a map and see exactly what's happening anywhere in the grid, in real time, instead of reverse-engineering it after the fact.
And it has to be live, not batch. The industry's whole trajectory (monthly billing reconciliation, then AMI 1.0, then AMI 2.0) has been "make the batch job faster." Never "make it not a batch job." A snapshot from last month can't inform a decision that needs to happen in the next five minutes, and a lot of grid decisions need to happen in the next five minutes. This is a big part of what makes Texture the AI-native operating system for the grid: you can't be AI-native if you don't have all this information, and you can't be AI-native if it isn't real-time either.
"We'll look at the results in 90 days"
We've written about this before, but it's worth a quick callback because it's the clearest illustration of what "not real-time" actually costs.
At a conference, a utility executive proudly announced they'd captured demand response data and, ninety days later, found some great insights. The room applauded. My team nearly choked on our coffee. This is an industry where battery dispatch happens in milliseconds and wholesale prices change every five minutes, and someone was getting a standing ovation for a 90-day turnaround. That's not lightning speed. That's bragging about your dial-up modem at a fiber-optic convention. (Full rant here if you want the whole thing.)
The reason that happens isn't incompetence. It's architecture. Dump AMI telemetry into a warehouse with no connective tissue, and the only way to get an answer is a data analyst with query access, digging by hand, weeks or months after the fact. With a connected, real-time picture, you know the answer as the event happens, exactly how much energy moved and where it went, not via a query someone runs a quarter later.
The before-and-after, made concrete
Here's what this looks like with a real customer, on a real problem.
We work with Vermont Electric Cooperative (VEC), a member-owned utility serving about 45,000 meters across northern Vermont, with roughly 30,000 transformers in their territory. Utilities need to know when a transformer is heading toward overload. The problem: transformers themselves generally aren't individually sensored. Putting a physical sensor on 30,000 of them isn't happening. The economics don't work.
Without context: a transformer somewhere in VEC's territory is quietly climbing toward overload. Nobody's watching it directly, because there's nothing to watch. No sensor, and checking manually means pulling meter data for everyone downstream, one system at a time. Nobody does that proactively. It's too slow and too expensive to justify on a hunch. So the problem doesn't surface until the transformer actually fails, and by then it's not a small problem. A single transformer can feed dozens or even hundreds of homes and businesses, so a failure means an outage across that whole pocket of the grid at once: freezers thawing, medical devices losing power, heat cutting out in a Vermont winter, a truck roll to a fault nobody saw coming, and a switchboard lighting up with calls. What could have been a scheduled, proactive fix becomes an emergency.
With context: the topology is already mapped (substation, feeder, transformer, meter, all connected) and years of interval meter data are already flowing through the platform as time-series. Aggregate the meters downstream of a given transformer, and you can infer its loading without ever touching a physical sensor. You can see the trend climbing toward capacity continuously, not discover it after the fact, and act before it ever becomes an outage, whether that means dispatching a DER response to relieve the load or scheduling a proactive fix.
Say it again with feeling: none of that is AI. It's topology plus data, correctly connected. But it's exactly the context an AI model needs before it can reason usefully about the grid at all. Without it, even the best model has nothing real to reason over. It's back to guessing at your lunch order.
The point
Remember the opening. Most companies telling you they'll use AI to fix your grid problems will not do it, not because they're bad actors, but because they're the stranger, not the spouse. They don't have a hundred meals' worth of context on your grid. They have a model and a slide deck.
This isn't throwing shade. You need the right context to make AI actually useful, and most of the industry simply doesn't have it yet. That's a real gap, not a moral failing. But next time someone tells you they "use AI" for grid operations, ask them how the data situation looks underneath it. The honest answer, for most of the industry today, is "not great."
We spent the unglamorous years getting the data right first. That's the boring part nobody puts on a conference slide. It's also the only part that makes any of the exciting part real.
