We hear this often. The younger generations are not capable of performing simple tasks without their phones and computers. The schools no longer teach our children to read and write in cursive. Some joke that this is the best encryption tool available. Things like reading analog clocks, paper maps, memorizing math formulas or poetry are not the skills they possess. When you point it out, people shrug it off as a nuisance. Why do I need to remember all this stuff when my phone can tell me the time, give me directions and solve any math problem that I need? With the help of AI bots, I can write my essays, resumes, cover letters, emails and code. I can generate music, videos and images. I don’t need to know how to do it. There is no reason for that.

My mind goes to 2008 when the movie WALL-E came out. It felt almost grotesque. All these people just floating around the spaceship, well fed and hydrated, with the computer screens right in front of their faces. We said to ourselves, this is not going to happen. We are in control. Are we? Really?

There is a scene in the movie where a woman (I think her name was Mary) is riding a monorail across the deck of the starship called Axiom. She has a holo-screen hovering just a few inches in front of her face. And this is where every passenger on this ship has their screen too. A small robot bumps into her chair by accident and knocks the screen away from her face. As a result, Mary has an unobstructed view of the world surrounding her. Her eyes dilate slowly. She reacts as if she is seeing the world for the first time. She gets out of her chair, looks around and says: “I didn’t know we had a pool!” As I think about it, the people who wrote the screenplay were trying to tell us something 18 years ago. And it was not the chair. I think they were trying to show us cognitive decline. We did not get weaker. We just stopped knowing the shape of the place we are standing in.

Think about a New York City subway car, or an airport gate area, a doctor’s office, or any public place where you can participate in my personal favorite sport, people watching.

I don’t want to be insensitive, but what happened to human eye contact, to a conversation?

What if there was a cyber crash tomorrow? I know it’s a dark thought, but stay with me for a few minutes here.

Massive power grid failure, internet outage, cell services down. The older generation might be able to function, but I fear for younger people.

In my line of work, the engineers are required to obtain certifications. The exam happens in a proctored environment with no reference material. You either have to know how stuff works, or you have to memorize certain things. Sometimes even I question it. Why memorize when I can easily go and look it up on the support website or just ask an AI agent?

But the human brain is like a muscle and it needs to be trained to remain strong and agile. Reading, memorizing, building and creating things, writing in cursive, all of that helps.

This is not a new thought at all. Many people are worried about the consequences of relying on technology too much.

Back in 2011, a study published in Science showed that if people know that some fact is stored on the computer, their brain doesn’t bother to store it “locally.” They just remember where to look.

London cab drivers memorize over twenty-five thousand streets in the city. That part of their brain grew physically larger. Well, this sounds good, but it is not entirely accurate. In technical terms, the gray matter in the hippocampus simply shifted towards the back, which is redistribution, not growth. When they retire, it starts to drift back, but it never fully gets there. And here is the funny part. Working cabbies are worse than the rest of us at learning new visual things. Retired ones are not. So they lost something and got something back at the same time. Use it or lose it, sure. But also use it and lose something else. Give people GPS and the navigation circuitry in their brains works a lot less.

Researchers at MIT put sensor caps on 54 subjects (three groups of 18) and told them to write an essay. One used ChatGPT, one was allowed to use a web search engine, and the last was told to write it without any helper tools.

The results were incredible. The brain-only group scan showed dense and balanced activity. The brain was lit up like a Christmas tree. The group with the search engine showed significantly less activity, and the ChatGPT group showed the weakest activity of all. Then the researchers took the AI away and told that group to write unaided, and their brains stayed quiet. They couldn’t even quote the essays they supposedly just wrote. 83% of them. In fancy terms, this is called cognitive debt. Here is a quote from the Q&A section of the study. It is almost funny.

“Is it safe to say that LLMs are, in essence, making us ‘dumber’? No! Please do not use the words like ‘stupid’, ‘dumb’, ‘brain rot’, ‘harm’, ‘damage’, ‘passivity’, ‘trimming’ and so on. It does a huge disservice to this work, as we did not use this vocabulary in the paper, especially if you are a journalist reporting on it.”

Most recently, in 2025, there was another study published in The Lancet. They studied a group of endoscopists who used AI to assist with spotting precancerous growths in the colon. When AI was taken away, the doctors’ own detection rate fell by six percentage points. Just think. Seasoned specialists made weaker by the tool that was designed to help them.

The prosecution rests!

I could probably end this article here, but that would be a huge disservice to my readers. The prosecution has spoken, now it’s time for the defense lawyers. Right?

Instead of being lazy, I decided to actually read the studies instead of only reading sensationalized summaries. That was a huge mistake on my part because it completely ruined a really good article.

Well, the MIT study is not peer reviewed, and the 2011 study has failed to replicate twice. Even the colon cancer paper, the one I just used as my closing argument, is called “hypothesis-generating” by its own authors, and three studies have since gone looking for that effect and none of them found it. One of those was co-authored by the same senior author, across five thousand colonoscopies.

So I could just stop here and tell you that this is all nonsense. But that would be its own kind of lazy. This is not how we roll in this shire.

Underneath all of it, there are some really cool findings. People who asked AI to explain things to them still had the material a week later. People who asked the AI bot to write it for them lost the gains the moment the tool was taken away.

Same AI tool, different result. It is all about what you asked it to do.

Every generation has run this experiment before. Socrates thought that writing things down would ruin memory. We only know about it because Plato wrote it down. Some guy in Switzerland in the 16th century was worried about the abundance of books. He thought it would be harmful. Then radio, TV, comic books, video games. And, oh my, calculators!! There was a study that showed kids who used calculators alongside traditional instruction improved their pencil and paper math skills.

The tool didn’t replace the teaching, it complemented it.

Let’s go back to our spaceship, the Axiom. I realize now that I used that movie unfairly. At a test screening in 2007, the director found out that half the audience walked out thinking the humans would not survive back on Earth. So he had Pixar build an entire end credits sequence, showing the people and the machines rebuilding the planet together. They wanted to tell the audience it was going to be all right.

And in the movie itself, the whole recovery takes one afternoon. Mary’s screen goes dark and she sees John sitting next to her. The ship captain stands up on his own two feet for the first time in his life. Nobody on that spaceship is broken. They just need a little nudge and they will be just fine.

So I am not going to tell you to get rid of your phone. I still ask the AI to explain things to me, and I am not giving that up. This article would have many more grammar and spelling errors without the help of AI. Those certification exams, in a room with no reference material, are miserable and we complain about them every time, but we also notice that the things we had to memorize are the things we still remember.

Everything in moderation, even moderation itself. Let the machine do the boring part. Keep doing the part you would miss. Read a book once in a while, not on a tablet, a real paper one. Right? Take the wrong turnpike exit on purpose and find your own way back, write something by hand and see how much worse your handwriting has become.

It is nice to know your way around the ship you live on.

And every so often, let something bump your chair.

I appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Let’s investigate a serious crime, shall we? I think it is a crime that not all technical solutions sales teams are successful.

Who are the team members? Different companies use different titles for the roles, but essentially there is a sales person, an AE (account executive) or AM (account manager), and a technical specialist, an SE (sales engineer, systems engineer) or SA (solutions architect). The extended team may also include an FSA (field solutions architect, or domain expert) and a Principal Technology Strategist (or Field CTO).

I don’t think it would be breaking news to say that sales is a team sport. And as in any team sport, trust between team members has to be earned, it is never given. There are different perspectives that team members bring to the table, and everyone is driven by something. It can be money, recognition, status or a title. Once you understand what drives behavior, you can adjust your communication style and the way the information is delivered.

In my opinion, there should not be a hard line division between AE and SE. Beach volleyball comes to mind. You are both barefoot, playing on an uneven sand surface, and you both need to be skilled in serving, spiking the ball, blocking, digging and assisting.

In today’s technology world, selling value no longer means showing a product or solution demo. I think it is the art of storytelling. A good SE can easily become a clinical psychiatrist. We are in the people business, and understanding the people across the table from us, their goals and ambitions, will affect the delivery method of the value message. I wrote before about what makes the A+ SEs. You simply cannot rehearse the same story and repeat it every time to every prospect.

My advice to you is to start with research. There are plenty of tools available to sellers today, Perplexity, Claude, Gemini and others. You can master the prompts and get a good picture of the target customer’s business, needs, and desired outcomes.

Fair warning, be careful. Not everything that comes out of these tools is true and accurate. A few days ago I was preparing for a 30-minute first call with a prospect. I did deep research and created a 19-page document. During the meeting I said, we did our research and based on what we saw, here is what we think you have in the data center. We were on a Zoom video call and he laughed. No, we don’t have any of that here. This should be a red flag to anyone out there. I wrote about this risk in my 4 part series last month.

Let’s move forward. The days of traditional technical discovery are long gone. Business evolved, technology evolved. Active listening is one of the most critical skills that a well-functioning sales team should have. I am not suggesting you should abandon the art and science of technical discovery, though. Through active listening you should always look for clues, and in today’s world you have to learn and hone the skill of identifying the non-verbal ones. Posture, body language, are they looking at their phones and not paying attention?

Never lie or embellish. Always be honest about what the solution can and cannot do. You lie just once and not only do you lose credibility, you also lose the hard-earned trust that took such a long time to establish.

I have already talked about research. But research by itself, in a vacuum, is not going to produce the results you may be looking for. To get better, always work on joint strategy with your AE. They are smart business people and their experience can be invaluable. And as you are doing your research and preparing for the meeting, discuss the strategy with the bigger team too, who is going to say what on the call.

Rehearse your story, your value message and yes, your demo too. Live demos can still crash and burn today, just like 20 years ago. Think of delivering your message, your story, as acting. Own the room, be confident but not cocky. Always keep in mind the process of continuous improvement. Write down your notes, objections and lessons learned, and weave them into your next presentation. Ask your AE or manager for feedback. They will gladly give it to you.

There is a good reason some AEs and SEs refer to their counterparts as “work spouses”. Great SEs and AEs complete each other’s sentences. They become life-long friends. They trust each other.

This level of team performance takes patience and understanding, just like any successful marriage.

If I had to define why SEs even exist, I would probably think of a field in the CRM that is called “technical selling complete”. This is the ultimate goal of the sales process. Not a demo, not a presentation, and not a story.

Learn how your AE thinks, be genuinely interested, invest in the relationship, understand their ambitions and always share the spotlight.

I appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Normally I avoid sounding like marketing and directly promoting Everpure solutions. This time I am going to, and I would rather say that now instead of surprising you later.

What I write is how I learn. There is a saying I remember in Russian, «Кто пишет, тот дважды читает», which turns out to be Latin underneath.

Qui scribit, bis legit. Whoever writes, reads twice.

This is so true. Writing an article like this starts with pages of scribbled notes, research, reading a book that triggers a thought or inspires an idea. As I finish drafting an article, I read it again and again. I change things, research some more and type it again.

When my son was younger and I was helping him understand mathematical concepts, I also realized that as I explained things to him, I understood them better myself. He might disagree.

The reason I keep doing it here in this forum, in public, is that I meet many business leaders, and even technical architects, who are tasked with goals but lack the basic understanding of what all of these things mean. So as I am learning, I want to share in a language people can understand, and help them grasp the concepts they need to do their jobs well.

Last week I was in a meeting where the Everpure Data Intelligence topic came up. I asked everyone in the room if they knew and understood the basic terms used in AI conversations. I was grateful that instead of being quiet, many in the room raised their hands, made eye contact and admitted that they did not fully understand. We took some time and went over the basics to make the rest of the conversation relevant. People in the room were grateful and happy to learn. This is a big deal when you sell value. Active listening and a consultative approach.

Someone suggested I read Nick Bostrom’s Superintelligence. It was published in 2014. Reading the first few chapters and realizing the book was written before the current AI boom, I was impressed with some of his analysis and predictions. This is a very complex technical field, and being able to identify the challenges and potential approaches to solutions 12 years ago is very impressive to me.

Thinking about it, he wrote this book without ever typing a prompt into a chat window. No ChatGPT. No copilots. The most celebrated thing was a computer program that had beaten Garry Kasparov at chess, and IBM’s Watson beating Ken Jennings and Brad Rutter at Jeopardy.

One of the things he is saying is that it is not really AI, it is machine learning. I think this is very true from a technical perspective. We were able to build computers that are able to learn. In order for the machines to learn, they need to be taught. Enormous amounts of data need to be stored somewhere, and the speed of access has to be fast.

He never says the second part out loud. But I kept thinking it in my head as I read.

He picks up Alan Turing’s idea from the 1950s about building a child machine instead of an adult one, a program that “acquires most of its content by learning, rather than having it pre-programmed at the outset”, and notes that this applies whether you are copying a human brain or designing something synthetic.

Science fiction writers in the 20th century thought of artificial intelligence as humans building a machine that resembles a human brain. This is where the “copying a brain” expression comes from. Whole brain emulation involves slicing brain tissue, scanning it with electron microscopes, and reconstructing the network from the images.

Bostrom is talking about what the machine does with what it learns. He says nothing about where the learning material sits, how it gets there, and who decided it was allowed to be there.

Once you notice that, it shows up everywhere in the book.

Later on he looks at it again from a different angle. He defines speed superintelligence as a mind that does what we do, only much faster, and gives the example of an emulation reading a book in just a few seconds. Then he follows the physics and concludes that fast minds needing constant interaction would want to live in machines in the same building, purely to avoid latency. That is data gravity, arrived at in 2014 by reasoning about imaginary digital brains. Dave McCrory had already named the idea in 2010, and I have written before about what it means when the model should travel to the data. Bostrom hit the same wall from the other side and does not seem to have noticed he had found something practical.

Reading Chapter 4, I decided to write this post.

Is it just me, or does this happen to you too? I read something and my mind starts wandering. I find myself skipping entire paragraphs and needing to focus and read them again.

I had to put the book down. Some of the terms he uses I did not even understand, so I kept looking them up. If you are just trying to fall asleep, it takes its toll.

He frames the whole question as a ratio.

Rate of change in intelligence equals optimization power divided by recalcitrance.

His word, not mine. I had to look it up too.

Recalcitrance is his word for how much the system resists being improved. Lower the resistance and the same effort gets better results. So he goes looking for places where the resistance might already be low, and he lands on what he calls a content overhang: “pre-made content (e.g. the internet)” sitting there, becoming available to a system the moment it reaches human parity.

He wrote that as a hypothetical. We ran the experiment. The overhang was real, the models consumed it, and the results were good enough that every organization now wants the same trick performed on data that is not on the internet.

That is where the book stops being prophecy and becomes useful. The public internet came pre-cleaned because somebody decided to publish it. An organization’s data has no such property. Nobody curated the shared drive, nobody labeled the PDFs, and there was no editorial decision behind the fourth copy of the enrollment spreadsheet.

What Machine Learning Actually Unpacks Into

In practice there are six stages. This is the vocabulary part, so I am going to be slow about it. The image below does not match this list exactly. I used this image to explain basic concepts to my team a few weeks back.

Ingestion is first, and it is not as easy as it sounds. The unstructured data, PDFs and images and objects and streams, has to move at multiple gigabytes per second or the pipeline develops backpressure and the results may suffer. Just like plumbing.

Then curation, which means cleaning, deduplicating, normalizing, and ignoring corrupt files nobody has touched in years. And I am talking about doing this across millions of objects. Then classification, where data gets scanned and tagged for what it actually contains: personally identifiable information, intellectual property, the things with risk or legal consequences.

That third stage is the one I would underline for anyone in state or local government, or in higher education.

Classification has to happen before embedding, not after.

Once a chunk of text becomes a vector in an index, you cannot attach a sensitivity label. The label does not come along unless somebody deliberately carried it there. You cannot un-embed someone’s social security number. This is why I keep writing about knowing what your data is before you point a model at it and about discovery and classification as a prerequisite rather than a checkbox.

The last three stages are like geometry.

Embedding runs text through a model that turns concepts into a bunch of floating-point numbers, which is how “refund” ends up sitting near “billing” and “invoice” in a space with a few thousand dimensions.

Indexing writes those vectors into a structure so that finding the closest ones stops being a linear scan of everything and becomes a logarithmic walk. Remember, it is all about statistical probability.

Retrieval measures distance, pulls the closest chunks, and combines them into the prompt before the model sees the question. That last step is Retrieval-Augmented Generation, or RAG, and it is how you can give a model the latest data without doing yet another retraining run.

Six stages, compressed into the word “learning” in the book, which was a completely reasonable thing to do in 2014 when the open question was whether any of it would work at all.

The Machine on the Other End Is Extremely Parallel

Let me geek out and get into the weeds a little. Ask yourself a question. All that “learning” data, where is it going, and what is it feeding?

A CPU has a handful of powerful cores optimized for doing one thing after another quickly.

Back in 1999 NVIDIA introduced the first GPU for video gaming, the GeForce 256. In 2006 NVIDIA introduced CUDA, expanding the GPU from a graphics-only tool into a powerful general-purpose parallel processor used for science and machine learning. When the book was written, GPUs were already available.

A modern GPU has thousands of small cores, plus tensor cores built for one operation: multiply matrix A by matrix B, add C, in reduced precision, constantly. CUDA is the layer that lets the ordinary C++ programming language address that hardware, organizing work into grids, blocks, and warps of thirty-two threads running the same instruction across different sets of data. PyTorch and TensorFlow sit on CUDA. NVIDIA’s NIMs (NVIDIA Inference Microservices) sit on top of that, packaging weights and an optimized runtime into a container you deploy behind an API instead of assembling by hand.

Every layer of that stack exists to do enormous numbers of things at the same time. What feeds it is frequently a legacy storage platform initially designed for running a database doing sequential reads for a small number of users.

That is what AI engineers call GPU starvation. Not a shortage of accelerators, a shortage of anything able to keep them busy. I wrote earlier this year about how power became the constraint everything else organizes around, and the worst version of it is a GPU still drawing full power, producing full heat, occupying rack space, and converting none of that into work.

Somebody Figured This Out Before the Boom Too

In 2018, four years after Bostrom published and four years before ChatGPT, Pure Storage and NVIDIA shipped a joint reference architecture called AIRI. DGX compute nodes connected to first-generation FlashBlade over Arista or Mellanox RDMA network fabrics. The premise was that legacy arrays choke when hundreds of parallel cores demand small, random IO, and that storage therefore has to scale bandwidth and IOPS linearly alongside compute or the investment is wasted.

I remember taking a training back in 2018 and thinking to myself: “Who would ever need this AI stuff?” Nobody outside a fairly small group of really smart people was thinking about AI in 2018.

As time went on, the idea got more specific. FlashBlade//S and //EXA scale capacity, processing, cache, and network throughput together with every blade added, with the design goal of keeping accelerators fed and busy. Everpure Data Intelligence, from the 1touch.io acquisition, handles discovery and classification across hybrid environments and enforces policy before anything gets vectorized. Everpure Data Stream, co-engineered with NVIDIA, automates the run from ingestion through curation to vectorization, so data scientists stop spending two to four months manually building a pipeline before a model reads its first document.

I would strongly suggest you read any vendor’s throughput and utilization numbers, including ours, with the skepticism they deserve. The direction of the architecture is the part I think holds up.

Bostrom’s ratio concept is still useful today. Optimization power is available on a credit card and your competitors have the same card. Recalcitrance is where the difference lives, and in a state agency or a research university, recalcitrance is not the model. It is twenty years of data across file shares, mainframes, databases, SaaS applications, ticketing systems, and backups nobody has opened since the last migration, with no reliable way to say which of the copies is current or which one contains something that should never have left the building.

The data has to live somewhere. Somebody has to know what is in it. Somebody has to get it to the machine fast enough for it to matter, and that turns out to be most of the job.

Appreciate you reading.

Dmitry Gorbatov

© 2026 Dmitry Gorbatov | #dmitrywashere

Let’s start this part with a joke. Shall we?

I felt a bit like Sheldon Cooper in The Big Bang Theory trying to use a literal flowchart algorithm just to make a new friend.

I ran the draft of this article through Substack’s new Pangram scanner — mostly out of plain curiosity after they announced their AI transparency feature on July 21st. The tool took a look at my draft, thought for about 4 seconds, declared it AI-generated, and left me staring at the screen. Here I am, four articles deep into a long series explaining why artificial intelligence behaves the way it does, only for an automated scanner to decide I’m just a chatbot pretending to have a state government IT career.

Pangram itself is and AI agent. It flags text primarily based on two things - predictable word choices, uniform sentence lengths and paragraph structures. It uses statistical probability without understanding. Isn’t this ironic?

It’s funny, sure. But it just confirms the main point of this whole article better than any diagram could. The scanner saw structured arguments, precise technical terms, and consistent formatting, so it mapped those patterns to a machine. It has no idea I spent last thirty some years watching legacy systems evolve. It was just calculating word probabilities.

And that is the exact trap we fall into when trying to make AI work in the real world.

Back in Part 3, I tried to explain the AI language in simple terms. Agents, RAG, embeddings, vector databases, orchestration, guardrails. All those terms matter, but at the end of the day, three practical questions rule everything: what can the machine see, what can it do, and who gets blamed when it screws up?

Even if you manage to answer those three, another question pops up right away. And this one is harder to ignore:

Do we understand the data the system is using?

Ask most IT leaders and they’ll say yes without even thinking. Government agencies run on process. Systems of record, assigned data owners, security frameworks, privacy officers, retention schedules, backup platforms, and auditors. There are architecture diagrams, classification schemes, and formal procedures for almost everything.

Then somebody asks a simple question: “Where does every copy of this citizen’s record live?”

Crickets.

They aren’t asking about the main database. Everyone knows where that sits. The real headache is tracing what happened after real people started doing their daily jobs. Which version was dumped into an Excel sheet three years ago? Which copy was emailed over to an insurance company? Which contractor got a “quick subset” for a pilot project? Which staging database was cloned during a cloud migration and then left behind because someone forgot to delete it?

Which version is current? Which one holds sensitive information? Which one should have been deleted five years ago?

“Know your data” is no longer a strategic principle. It’s more like a scene from CSI.

The Illusion of the Architecture Diagram

Government technology relies on the “systems of record.” Tax engines hold tax data. Benefits portals handle eligibility. Public safety manages criminal records. HR has employee files. Finance tracks the money.

On paper, it’s comforting. Everything sits neatly in its assigned box.

Real life, however, doesn’t care about an architecture diagram.

Data moves because people need to get work done today. Employees run data exports. Analysts build custom models. Developers clone production databases to troubleshoot ‘undocumented features’. Agencies send files back and forth. An intern attaches a spreadsheet to an email because the “approved” request process takes three weeks and the citizen standing right at the counter needs help right now.

Over time, that single source of truth gets surrounded by a massive cluster of copies, drafts, old revisions, extracts, caches, backups, and forgotten project folders.

Official Database ---> Export to Excel ---> Emailed to Team ---> Saved to Desktop --->
---> Forgotten in "Archive_v2"

We need some of those copies. Many are harmless. But some are completely outdated, sitting around holding sensitive details that we forgot even existed.

We like to call this dark data. The name sounds like a sci-fi villain, but the reality is much more simple. Dark data usually lives inside a completely ordinary folder named something like [Archive_Final_UseThisOne] or [Old_DoNotDelete] — file names that have quietly caused more damage over the years than any zero-day attack.

Dark data isn’t hidden by complex encryption; it’s hidden by neglect. Nobody is paying attention to it anymore.

And that’s why it’s so dangerous. An old folder from 2018 might still hold Social Security numbers, tax filings, health records, or plain-text API keys. While your production systems are patched, monitored, and protected, these forgotten folders sit in the dark with open permissions and no oversight.

They are still there simply because cloud storage got cheap enough that keeping everything forever felt safer than making a hard decision about what to delete.

The ROT Problem and the AI Game of Telephone

Have you heard AI folks talking about ROT?

All it stands for is Redundant, Obsolete, and Trivial data.

It sounds dramatic, but the actual risk is clear. Every duplicate is another place where hackers can attack. Every obsolete document increases the odds that a human — or an AI — grabs the wrong facts.

People usually frame ROT as a storage cost issue. But I think, it’s a trust issue.

Imagine an AI bot tasked with pulling the current policy for a state benefits program. It scans the repository and finds four separate documents:

• The currently approved policy.

• An early draft from two years ago.

• A policy that was officially replaced last month.

• A copy modified by an employee, complete with personal notes, saved with a file name that looks more official than the actual master file.

All four documents match the search criteria. Only one is actually correct.

[ Draft Policy (2022) ]
       [ Replaced Policy (2025) ]   --->  AI Engine  --->  Confidently Summarizes
       [ Annotated Copy ]                                  the WRONG Rules
     ★ [ Official Policy (2026) ]

So now, imagine the AI agent pulls a wrong file and runs with it.

That is one of the most frustrating things about modern AI: it doesn’t need to hallucinate to give you a terrible answer. It can follow instructions perfectly, retrieve the exact document it was pointed to, and still produce total nonsense because the source material was obsolete or misleading. And when the response comes back in polished, grammatically correct form, people are not going to question it.

Mainframes, Institutional Memory, and the Context Gap

I hope it doesn’t surprise you that some of state government legacy applications still run on mainframes. These legacy engines handle taxes, licensing, pensions, and public safety — systems that cannot go offline.

The standard complaint is that mainframes are old, but age isn’t the main issue. The real problem is context. The data inside a mainframe is very hard to translate, link to modern apps, or move around without making yet another copy.

Building a modern AI workflow usually means putting together data from a mainframe, a SaaS tool, a cloud repository, and three separate databases. Unifying that mess requires custom translation layers, plus that one OG staff member who remembers that the field STAT-7 actually means something completely different than what the 1994 manual claims. And that person is usually about three months away from retirement.

I used to have a neighbor who worked for IBM for 37 years, mainly because he was the only support guy left who knew a specific mainframe application. When the last customer using it didn’t renew their maintenance contract, he was laid off.

Migrating data to the cloud doesn’t magically fix this either. Moving a database over to AWS doesn’t tell you whether a status code of 3 means Active, Suspended, Deceased, or Pending Review.

Modernization isn’t the same as understanding. Often, it’s just moving a mess from an old basement to a newer, much more expensive basement. And yes, the cloud gets expensive fast — all those egress charges add up... Just ask any government agency CFO.

People survive in these environments using their experience and instinct. They know which database is the true authority, which folder holds junk drafts, and which status codes are legacy quirks. AI doesn’t have instinct — it only has what you feed it.

Where Control Breaks: Shadow Environments and “Fast” AI

Most compliance models look great on paper. Federal Tax Information (FTI) follows IRS Pub 1075. Health data follows HIPAA. Criminal justice details follow CJIS.

The rules are clear enough as long as data stays inside the production system. Everything breaks down the moment data starts migrating.

A tax record doesn’t lose its legal protections because an analyst exported it to a .csv file. Criminal history doesn’t become public domain because it was copied into a dev environment for testing.

This makes non-production environments — dev, test, staging, and sandboxes — much more dangerous than production systems.

Production (Strict Security) -->[ Copy for Testing ]---> Dev Sandbox (Weak Access, Forgotten)

Production systems get the budget, the active monitoring, and the security patches. Sandboxes, on the other hand, are treated like temporary playgrounds. But developers need realistic inputs to build tools. So what happens? Someone clones production data into a dev environment. The project finishes, the team moves on, but that cloned dataset sits there indefinitely with loose access controls and stale credentials.

I wrote about this back in October of last year: A SAP Business Objects reporting server running in the development environment that someone had pointed at the production database back in 2012. Granted, that specific case had nothing to do with AI — the year was 2016, I think — but the underlying habit is exactly the same.

Generative AI projects make this habit much worse because the priority now is speed. Teams launch vector databases, create embeddings, spin up sandboxes, and index file shares just to prove a concept works. Security and privacy reviews are treated like a final checkbox after the demo works.

By the time everyone finishes celebrating a working demo, sensitive data has quietly moved across five new, unmonitored systems.

You Can’t Just Hit “Delete”

There is a dangerous assumption AI project teams make: “If there’s an issue, we’ll just delete the source file later.”

If you were using a basic search index, sure — you might be able to purge a cached file. But if that data was used to fine-tune a model or build embeddings, cleanup isn’t that simple. Models don’t store files like a database folder; they absorb statistical relationships. You can’t just run an UPDATE command to wipe a single person’s history out of a model’s weights.

That’s why production data must be classified, masked, or converted to synthetic data before it ever touches an AI pipeline.

Synthetic data isn’t just junk filler. It mirrors the statistical patterns and structural logic of real data — letting you train and test workflows — without risking actual people’s identities.

An AI workflow needs to know how a benefits application flows. It doesn’t need my real Social Security number to figure that out.

The Real Cost: Public Records and Broken Trust

Let us look at state public records requests to see what poor data management actually costs in practice.

A person files a simple request for documents regarding a municipal project. Finding those files requires digging through agency inboxes, legacy network shares, backup tapes, and folders nobody had touched in a while.

Finding the files is only half the battle, though. People then have to manually review every single page:

• Is this correct?

• Is this a duplicate?

• Is this a draft or the final version?

• Does page 47 contain a plain text SSN?

In states like Massachusetts, tight mandatory deadlines mean agencies have days — not months — to respond. When delays happen, the public assumes the agency is covering something up. In reality, a team of tired people is usually just struggling to figure out if a 2018 PDF was ever officially signed.

From Static Inventories to Knowledge Graphs

Last week I completed technical training on the Everpure Data Intelligence platform. The technology focuses on continuous discovery and contextual mapping across structured and unstructured data — cloud apps, mainframes, and local shares alike.

The tool itself is slick, but the real takeaway was a shift in mindset: data classification can never be a one-time event.

Traditional data inventory projects are static. Agencies pay a lot of money to hire consultants, run scans, generate a report, pat themselves on the back, and archive the findings. That report becomes obsolete the moment an employee creates a new spreadsheet, copies a folder, or spins up a new AI test sandbox. Static tracking fails because our data is dynamic.

We need a continuous, living understanding of our environment. This is where semantic metadata and knowledge graphs enter the picture.

[ Citizen Entity ]
       │
       ├── Linked to ---> [ Federal Tax Record (IRS Pub 1075) ]
       │                        │
       │                  Copied to...
       │                        │
       └── Linked to ---> [ Dev Sandbox Folder ] ---> (!*!) ALERT: Flagged for Masking

Instead of treating every file or database as an isolated island, a knowledge graph maps real-world relationships. It understands that File X contains federal tax info, connects to User Y, was cloned into Staging Area Z, and falls under specific privacy mandates.

With that context layered over your storage, you can automate real governance:

• A production database cloned into a test environment gets automatically masked.

• A vector database trying to index restricted CJIS files gets blocked instantly.

• An obsolete, duplicate policy doc gets flagged for removal before the AI can retrieve it.

Self-Aware Storage

For decades, enterprise storage vendors focused on performance, uptime, and cost. Can it hold the data? Can it read it fast? Can it survive a drive failure?

AI introduces a fundamentally new requirement: does the storage infrastructure actually understand what it is holding?

This isn’t about storage becoming sentient (You may have seen in my article predicting the future of data - The Future of Data Experience). It’s about infrastructure having enough context to recognize that two identical 10GB files require completely different access rules, retention schedules, and security protocols.

Instead of passively storing the data, intelligent storage should actively participate in data governance.

┌──────────────────────────────────────────────────────────┐
│                   SELF-AWARE STORAGE                     │
├────────────────────────────┬─────────────────────────────┤
│   Public PR Documents      │   Federal Tax Records       │
│   • Open Access            │   • Restricted Access       │
│   • Indexed for AI         │   • Masked in Test Apps     │
│   • Standard Retention     │   • Blocked from AI Training│
└────────────────────────────┴─────────────────────────────┘

I want to be clear here: tools don’t replace human oversight. Vendors love to make platform architectures sound like magic spells. A discovery engine can highlight risk, but it can’t write your agency’s policies. A knowledge graph reveals connections, but it can’t replace your privacy officers, legal counsel, or security teams.

Technology simply gives human policy a chance to scale.

The Checklist Before You Launch

While researching and pulling together information for these four posts, I feel like I’ve really grasped where the core bottlenecks lie. At least for now!

AI connects infrastructure, quality, security, and privacy together whether we like it or not.

An AI strategy centered purely on model selection (choosing between OpenAI, Anthropic, or open-source alternatives) misses the point entirely. The model matters far less than the operating framework surrounding your data.

I don’t pretend to know everything, but before launching any major AI initiative, please skip the shiny vendor pitch and ask these operational questions first:

1. Can we dynamically identify where regulated data lives across all systems?

2. Do we know with 100% certainty which copy of a document contains the truth?

3. Are we able to automatically distinguish production data from test data?

4. Can we trace exactly where a dataset originated and everywhere it has moved?

5. Is our AI strictly prevented from retrieving documents outside approved permissions?

6. Can we cite the exact, verified source behind an AI-generated answer?

7. Can we purge obsolete records from the AI’s search path without breaking downstream workflows?

8. Can we reconstruct every step an AI bot took when executing a task?

9. Does the system stop and flag an error when two core source systems contradict each other?

10. Can we clearly explain the output to a person affected by the decision?

You won’t find the answers to those questions on a benchmark leaderboard. And a slick chat interface won’t save you when things go sideways.

Final Thoughts: Trust is the Real Runtime

“Know your data” has become a corporate tagline because you cannot really argue with it. But for too long, many organizations treated it as a vague, long-term goal while managing only their top three production databases.

We simply cannot do things that way any longer.

When a person searches a system, they're after something specific, and they bring their own judgment and instinct. An AI agent doesn't work that way. It crosses system boundaries, puts together data from sources that were never meant to sit next to each other, and then acts on all of it at scale. Which leaves us somewhere uncomfortable: the better we get at teaching machines to find their way around our enterprise environments, the more dangerous it becomes that we're still lost inside them ourselves.

This is where the whole series has been heading:

• Part 1 was about AI-generated information becoming part of the data that future AI systems consume.

• Part 2 looked at the machine behind the language and why statistical prediction is not the same as understanding. Take that, Pangram!

• Part 3 followed the path from an assistant that writes to an agent that acts.

• Part 4 ends with the foundation underneath all of them.

The machine cannot govern data nobody understands. It cannot separate facts from junk.

AI doesn’t just run on compute. It runs on trust. And that trust has to be engineered directly into how you discover, map, and control your data.

That is the line between playing with AI and actually being ready for it.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Subscribe now

Earlier this week I was in Chicago. My hotel was just over half a mile from the office and over 3 days I walked down Monroe Street downtown a dozen times. The weather was nice, the heat wave finally broke. The smoke from the wildfires cleared.

One thing bothered me this whole time - people walking to and from work, making deliveries, getting lunch or coffee. And almost all of them had their phones in their hands. No, I didn’t see any accidents, nothing like that. And I am not making fun of anyone.

I simply started thinking about how things were different in the past. If you asked me thirty years ago what it took to succeed in selling, supporting and delivering advanced technology, I would have given you a predictable list. Know your stuff cold. Prepare better than anyone else in the room. Stay disciplined. Work harder than the engineer sitting next to you.

All this is still true today, but this is not everything.

The experiences that actually stayed with me, the ones that quietly reshaped how I show up in front of people, had almost nothing to do with technology. They came from conference rooms where people were allowed to smoke, long flights across time zones, long silences, dinners where I understood perhaps every fourth word, and customers who taught me that my personal definition of “professional” was only one version of the story.

My world back then was delightfully simple. I believed, as many engineers do, that competence was mostly a matter of information. If you knew the systems inside out and came into the room with enough material, everything else would fall into place.

Then I got to Japan.

Don’t laugh, back then I did have some hair and when I called the support center at the home office, the first question always was: “Do you have holes in your socks?” See, in Japan, you take your shoes off before entering any room. Even if it is just a data center. And if you are still looking at the photo, yes, these are the DEC Alpha servers under the KVM.

It was the mid-1990s, 1996 to be exact. We were introducing a new SMS messaging platform to a major customer in Fukuoka. For the younger readers here, SMS was the beginning of text messaging.

I had spent days preparing for the product validation meeting, building what I considered an exceptional test plan. It lived in a crisp three-ring binder, neatly formatted, printed on an OKI dot-matrix printer, beautifully organized, running somewhere around forty pages. I remember walking into that conference room feeling proud of the work.

The customer received it gracefully. We were in Japan after all. They thanked me, spent a few minutes flipping through the pages, smiled politely, and said something that still makes me smile decades later.

“This is not a test plan.”

A few moments later, they brought out their version and placed seven heavy volumes on the conference table.

Together, those binders probably exceeded the shipping weight of my checked luggage on an Air France flight from Paris to Tokyo.

Sitting there, watching those seven massive binders, I had a choice. I could get defensive. I could explain that nobody in our industry writes test plans like theirs, or tell myself they were creating unnecessary bureaucracy just to make life difficult.

Instead, a little internal voice said, “Slow down.”

I have no clear idea where that impulse came from. This was my first ever trip to Asia. We didn’t have internet to research the culture and how to behave properly. I had a laptop with a dial-up modem and Lotus 1-2-3 Smart Suite for email.

Maybe it was basic respect, or maybe I just realized that arguing with a customer about methodology before understanding their world was a terrible strategy. So I kept quiet and listened.

Over the next few days and nights, I learned what those thousands of pages actually represented. They were not about bureaucracy for the sake of it. They reflected a culture where trust was earned through discipline, repetition, and an almost religious attention to detail. Their expectations were different because in their world, the consequences of a mistake were measured on an entirely different scale. There is nothing worse in Japan than 'losing face'. They tested normal operations, failover scenarios, power loss. Do you know how they tested if the system would survive an earthquake? They just hit the hard drives with a mallet.

When I finally got back and shared the experience, we did not start writing two-thousand-page binders for every account after that, but we did start asking radically better questions.

I must admit, Japanese customers improved the quality of our solutions. By a wide margin.

A few years later I found myself in Thailand, sitting across from the owner of one of Thailand’s largest telecommunications companies (AIS) and a prominent businessman who would later become Prime Minister, Thaksin Shinawatra.

Nothing about that meeting felt like Fukuoka. The rhythm was very different. The way people spoke, the way decisions were weighed, and the subtle ways disagreements were expressed shared no common ground with the conference room in Japan.

Singapore was something else entirely. If Japan taught me patience, Singapore was a masterclass in efficiency. People arrived fully prepared, got straight to the point, and expected you to do the same without fluff. Vietnam had its own distinct cadence. Australia had another.

The strange thing was that the underlying technology barely changed from country to country. The architecture was almost identical. We were still sending and receiving text messages. The products were the exact same boxes. Well, we did upgrade from Informix DB to Oracle 9i on UNIX and were now using DEC AlphaStation 600s. Yet the very same technical explanation could land as deeply reassuring in one room and completely tone-deaf in another.

Eventually, I stopped trying to force people into my framework. I became curious instead. Why did that specific detail trigger concern? Why did this metric matter so much to them, while another team ignored it completely? What was the actual pressure they were under when the conference room doors closed?

That curiosity turned out to be far more useful than any technical certification I ever completed.

It also changed how I view relationships back home, including the long stretches I spent working with government organizations in the United States. We often repeat the phrase “trusted advisor” as if it were a title you unlock after delivering three good projects in a row. We assume trust accumulates like interest in a bank account and just sits there waiting for us.

In my experience, trust does not work like that at all. It has to be re-earned, mostly because people do not stay static.

The customer who bought a solution from you five years ago is rarely the same customer today. Their title might be the same, but their world has changed. They might now be worried about cybersecurity threats, AI, or drastic funding realignments. The young architect who loved diving deep into low-level metrics might now be a director managing organizational politics and digital transformation.

When vendors lose accounts, they often blame the product, the pricing, or an aggressive new startup. But more often than not, the failure is much simpler: the vendor kept selling to the customer as they remembered them, rather than the customer standing in front of them right now. They stopped paying attention. They relied on old familiarity instead of current curiosity.

Real partnership rarely shows up on a QBR deck or a tracking dashboard. You cannot easily measure the business value of staying on a late-night bridge call for three extra hours when you already know your own software is running perfectly, just so the customer does not have to troubleshoot the networking issue by themselves. Nobody logs a line item for answering a weekend call when a customer is panicking about an outage that has nothing to do with your solution.

Those moments are where actual trust is built. They remember who stayed in the room when things got ugly.

Thirty years after that trip to Japan, I don’t remember the exact model numbers of the systems we were validating, nor do I remember the specific test cases in those massive volumes. But I remember the shift that took place in my head when those seven binders were put onto the table.

Respect comes long before influence. Curiosity comes long before credibility. And becoming a trusted partner is not about having all the right answers lined up in advance — it is about never losing the desire to understand what matters to the person sitting across the table today.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Every article here takes a fair amount of research, trial and error, rewriting, editing, and the occasional argument with English grammar. I am not monetizing this. I am just learning in public and sharing what I figure out along the way.

If you find it useful, interesting, or even mildly entertaining, please subscribe and share it with someone else. It costs nothing, and it helps more than you may think.

The least you can do is click the button.

Subscribe now

In Part 1, I wrote about the hall of mirrors created when AI-generated information becomes part of the data that other AI systems consume.

In Part 2, I looked at the machine standing inside that hall. Large language models are remarkable statistical systems, but they do not begin with truth. They generate plausible language based on patterns, context, and the information made available to them.

That led me to a fairly simple conclusion:

AI does not run on data. It runs on trust in that data.

I think the problem is that this conclusion arrives just as government technology leaders are being buried under an entirely new vocabulary.

Somewhere in a state office building, an employee who spent twenty years learning procurement rules, public-records requirements, agency policy, and the difference between seven systems that all claim to contain the official citizen address is now being told to develop an “agentic AI strategy.”

The terminology is not useless. Each term describes something real. But the volume of it creates the impression that government leaders must understand an entirely new branch of computer science before they can make a responsible decision.

The reason I am writing this is to help people understand what authority is being given to the machine, what information the machine can see, and what happens when it is wrong.

Everything else begins there.

Start With the Difference Between Generating and Doing

Most people first encountered modern AI through a chatbot.

You ask it to draft an email, summarize a policy, explain a regulation, or turn meeting notes into something readable. The system produces content, and a human decides what to do with it.

This is generative AI.

The model generates something. It does not necessarily take action in the outside world. It may produce a very convincing letter denying a benefits application, but unless someone or some other system sends that letter, updates the applicant’s status, and closes the case, the model has only created words.

That distinction is important because much of the public conversation now moves casually between generative AI and agentic AI as though they are different subscription levels of the same product.

They are not.

An agent does not merely produce an answer. It is given a goal, access to tools, and some degree of authority to take steps toward completing that goal.

A generative AI system might draft an explanation of why an application is incomplete.

An agentic system might open the case, identify the missing document, search another agency system to determine whether that document already exists, contact the applicant, update the workflow, schedule a reminder, and escalate the case if no response arrives within ten days.

The language model may still sit in the middle of that process, interpreting instructions and deciding what to do next. But the real change is not that the model became smarter.

The real change is that somebody gave it keys.

What Is an AI Agent?

The word “agent” is being used so broadly that it occasionally means little more than “chatbot with ambition.”

A practical definition is simpler.

An AI agent is a system that can examine a situation, decide on a next action, use an available tool, observe the result, and continue until it reaches a goal or encounters a condition requiring human intervention.

The tools may include databases, search systems, email, document repositories, case-management applications, APIs, calendars, or software used to update official records.

Consider a state employee onboarding process.

A normal chatbot can answer questions about benefits, office policy, or required forms.

An agent could verify that the employee’s paperwork is complete, create the appropriate accounts, assign training, request equipment, notify payroll, schedule orientation, and track which steps remain unfinished.

That sounds efficient because it probably is.

It also means the system may need access to identity records, salary information, tax forms, network credentials, background-check status, and internal administrative tools. It must know which actions it is allowed to perform, which actions may require approval, and what to do.

This is why the move from a chatbot to an agent is not merely a feature upgrade.

It is a transfer of authority.

The Five Levels of AI Ambition

There is no single maturity model that everyone follows, which is probably for the best because the industry already has enough diagrams. Still, most government AI projects move through a fairly recognizable progression.

They begin with a system that helps a person write or search. Then they give it access to agency information. After that, they let it complete a small task. Eventually, someone asks whether it can manage an entire workflow. The final step is when the system starts acting before anyone asks it to.

That progression matters because each step adds more than capability. It adds access, authority, and consequences.

Level 1: The Assistant

At the first level, AI helps a person produce something.

It drafts emails and follow-up notes, summarizes meetings, explains technical material, produces boilerplate code, or helps an employee find something buried in a policy manual.

The system has very little authority. A person reviews the output and remains responsible for the decision.

This is where many agencies should begin because the risk is still relatively contained. The AI can be wrong, but the mistake has to pass through a human before it becomes official.

That protection only works when the human actually reads what the system produced. Clicking “Looks good” on the way into another meeting technically counts as review, but not by much.

Level 2: The Context-Aware Assistant

The next step is to connect the model to agency information.

Instead of asking it to answer from whatever it learned during training, the system retrieves relevant policies, manuals, case documents, or program guidelines and gives them to the model before it responds.

This is retrieval-augmented generation, usually shortened to RAG.

The name makes it sound more complicated than it is. The system searches for something relevant, passes that information to the model, and asks the model to answer using what it found.

A public benefits chatbot, for example, might retrieve the current eligibility guidelines for a specific program instead of relying on general information that may have been learned months or years earlier.

This is often described as grounding the model.

Grounding does not mean the model has suddenly developed a relationship with truth. It means the answer is tied to selected source material.

That helps, but only if the system found the right source in the first place. Is the document current? Is it authoritative? Is there another version sitting in a different repository? Is the person asking the question even allowed to see it?

RAG can make AI much more useful. It cannot make disorganized information trustworthy.

Level 3: The Task Automator

At the third level, the system is allowed to do something.

The action is usually limited and happens inside a controlled workflow. The system may route a service ticket, populate fields in an application, classify an incoming document, schedule an inspection, or send a standard notification.

The environment is structured. The choices are restricted. The agent is not wandering through the state network looking for ways to improve government before lunch.

A human may approve the action before it becomes final, or the system may act automatically when predefined conditions are met.

This is where the phrase human-in-the-loop begins appearing.

The phrase sounds reassuring, but it does not tell us how meaningful that human involvement actually is.

A person who reviews the underlying records and understands the decision is genuinely in the loop. A person who receives 600 AI-generated approvals every morning and clicks through them because the queue must be cleared by Friday is also technically in the loop.

The question is not whether a human appears somewhere in the workflow. It is whether that person has enough time, information, and authority to catch a mistake.

Level 4: The Workflow Agent

At the fourth level, the system manages a process that crosses several steps and often several systems.

It remembers what has already happened. It knows that a document was requested, that the citizen responded, that a review is still pending, and that the case must be escalated if nobody acts within a required period.

This is sometimes called a stateful workflow. “Stateful” simply means the system keeps track of where the work stands.

More than one agent may participate. One searches documents. Another checks eligibility. Another drafts communications. Another updates the case-management system.

That is a multi-agent system.

The name may bring to mind a small digital workforce holding status meetings inside the server. In reality, it usually means several software components have been assigned different jobs and pass information between one another.

This can be useful when the responsibilities are clearly separated.

It can also create a very modern form of bureaucratic confusion in which nobody knows which agent made the original mistake, but four other agents have already accepted it as fact.

At this level, context becomes critical. The system must understand not just what a record says, but how that record relates to a person, a case, a policy, an agency, and the action being considered.

A date in a database means almost nothing on its own. It could be an application date, a birth date, a review deadline, or the date an old policy expired.

A name is not enough either. Is John Smith the applicant, the caseworker, the parent, the attorney, or an unrelated resident who happens to share a very common name?

Computers have always struggled with these relationships. Agents make the consequences more immediate because now they can act on their interpretation.

Level 5: The Proactive Agent

At the final level, the system does not wait for a person to begin the workflow.

It watches for a condition, identifies something that requires attention, and starts an action on its own.

A system might detect that a regulatory deadline is approaching, that an eligibility record has changed, that an unusual backlog is developing, or that two administrative rules appear to conflict.

Virginia offered an early example in July 2025 when the state launched an agentic AI regulatory-review pilot. The initiative was designed to help agencies examine regulations and guidance for conflicts with state law, outdated language, unnecessary requirements, and duplication. Delaware launched an AI sandbox initiative that same month to create a controlled environment for testing more advanced AI systems and the governance around them.

These projects matter because they show how quickly the conversation is moving beyond chatbots.

A proactive agent may identify problems that employees did not know to search for. It can monitor more information than any one person and respond much faster.

It can also launch the wrong workflow much faster.

Once a system is allowed to act without being prompted, logging, identity, policy controls, exception handling, and the ability to stop or reverse an action are no longer background features. They are the architecture.

A Few More Terms Before the Acronyms Escape

Once RAG and agents enter the conversation, several other terms usually follow. Most of them sound more mysterious than they really are.

Embeddings

An embedding is a way of turning meaning into numbers.

The system converts a piece of text, an image, or another kind of information into a mathematical representation. Content with similar meaning tends to end up closer together in that mathematical space.

That allows a search system to find related ideas even when the exact words do not match.

A keyword search for “vehicle” may miss a document that only uses “car” or “automobile.” A semantic search may understand that the ideas are related.

This is useful in government, where two agencies can describe the same thing using language created by different committees in different decades.

The limitation is that similarity is not authority. A draft policy may look very similar to the approved one. An expired regulation may resemble its replacement. A record for Robert may be connected to a document containing Bob.

The search may be intelligent and still retrieve the wrong thing.

Vector Databases

A vector database stores those mathematical representations and makes them searchable.

When someone asks a question, the system converts the question into an embedding, looks for nearby information, and passes what it finds to the language model.

It is not necessarily a replacement for the agency’s existing database or document system. It is usually another layer added to help AI find semantically related material.

That additional layer can be useful. It can also create another copy of the data, another access path, another security boundary, and another place where old information quietly survives.

The database may return an answer in milliseconds. The harder question is whether anyone knows what was copied into it six months ago.

Knowledge Graphs

A knowledge graph focuses on relationships.

A normal database may tell us that two records contain the same identification number.

A knowledge graph tries to show what the relationship means. This person submitted this application, belongs to this household, received this benefit, interacted with this agency, and is connected to this case.

The word “graph” does not mean a chart. It refers to a structure made up of entities and the connections between them.

This becomes valuable when an agent needs to understand how information in one system relates to information somewhere else.

It also creates risk when those relationships are wrong, incomplete, or exposed to people who should not see them.

Fine-Tuning

Fine-tuning is additional training applied to an existing model.

An agency might fine-tune a model to recognize a certain document format, classify records, or produce responses in a more consistent style.

That can improve how the model behaves. It does not automatically give the model current agency information.

A model fine-tuned on last year’s policy manual does not know that the policy changed yesterday. For information that changes regularly, retrieval is usually more practical than retraining the model every time something is updated.

Fine-tuning teaches the model how to behave.

Retrieval gives it something current to read.

Inference

Training is the process of building or modifying a model.

Inference is what happens when that model is used.

Every time the model generates an answer, makes a prediction, or classifies something, it is performing inference.

When people say inference should happen near the data, they usually mean the model should process information close to where it is stored instead of forcing the agency to copy everything into a distant external service.

That decision affects data gravity, sovereignty, latency, security, and cost.

Orchestration

Orchestration is the part that coordinates everything.

It decides which model to call, which document repository to search, which tool an agent is allowed to use, when approval is required, how one step passes information to the next, and what happens when something fails.

The model gets most of the attention because it is the part people can see and talk to.

The orchestration layer is often where the real application lives.

It is also where a harmless chatbot begins turning into something capable of changing an official record.

Guardrails

Guardrails are controls intended to limit what the system can do or say.

They may include access restrictions, content filters, approval steps, tool permissions, policy checks, logging, output validation, and rules that prevent certain types of information from leaving an environment.

The word sounds reassuring.

A guardrail on a mountain road works because engineers know where the road ends and the cliff begins. AI systems operate in language, context, policy, and user intent, where the boundary is often much less obvious.

Guardrails are necessary. The existence of the word does not mean the problem has been solved.

The Three Questions Behind All the Jargon

When a vendor, consultant, or internal team presents an AI proposal, government leaders do not need to answer with an equally impressive collection of acronyms.

They can ask three fairly ordinary questions.

What can the system see?

What can the system do?

Who is accountable when it is wrong?

The first question gets to the data architecture. Is the system working with public information, approved agency records, employee email, copied production data, tax information, criminal justice records, health information, or some combination that nobody has fully inventoried?

The second gets to authority. Is the system generating a recommendation, or can it update a record, contact a citizen, approve a transaction, or trigger another workflow?

The third question tells you whether the project was designed for government or merely demonstrated to government.

Accountability cannot be assigned to “the AI.” A model cannot testify at a court hearing, explain why it retrieved an outdated document, accept disciplinary action, or restore a benefit that was denied incorrectly.

A person or an organization still owns the system. Someone approves the data it can use. Someone defines the permissions. Someone decides where a human must remain involved.

And when the system does something nobody expected, someone must be able to reconstruct what happened.

The Agent Is Only as Ready as the Data Beneath It

The current AI conversation often starts with the model.

Which one performs best? Which has the largest context window? Which platform offers the strongest reasoning? Which vendor has the most convincing demonstration?

Those are legitimate questions. They are just not the first ones I would ask.

Before an agency gives an AI model access to a workflow, it needs to know what information exists, where that information lives, whether it is current, what it means, who is allowed to use it, and how records across different systems relate to one another.

Back in March, I wrote about why the public sector reveals the truth about data. State governments operate some of the most complicated data environments in the world. Modern cloud services sit next to decades-old applications, mainframes, departmental databases, email archives, file shares, contractor platforms, backups, test environments, and copies created for projects everyone has since forgotten.

An agent does not clean up that complexity simply by arriving.

It inherits it.

The better an agent becomes at searching across systems and taking action, the more dangerous unknown, duplicated, stale, or exposed information becomes.

We have spent the last several years asking whether AI can understand our questions.

The next question is whether government understands the information being placed in front of it.

Coming in Part 4

Part 4 is where the fun ends and the inventory begins.

I will probably get to it in the next 2 weeks, or tomorrow if the flight gets delayed.

The plan is to close where this whole series has been heading with a fairly blunt question: whether “know your data” can be something a system actually enforces, or whether it stays what it usually is: a sentence a CIO says with great confidence from a conference stage.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

In my last article, The Hall of Mirrors, I wrote about what happens when AI-generated content becomes part of the data that other AI systems consume.

A meeting summary becomes a document. The document gets indexed. Another model retrieves it, summarizes it again, and saves the new version somewhere else. Eventually, the organization has several polished versions of the same event, each one separated a little further from the original conversation, decision, or human memory.

At some point, nobody remembers which version was the source and which version was generated from it.

That was the hall of mirrors.

Since writing it, I have been thinking about the machine standing in the middle of that hall.

We talk about large language models as though there is something inside them reading the prompt, considering the evidence, forming an opinion, and then carefully choosing the right words. The interface encourages this impression.

The machine says “I think.” It apologizes. It reflects. Some models now visibly pause before answering and displaying “Thinking,” which is a particularly effective way of making software look like it has gone into another room to think things over.

Many of us use these systems every day. They can be enormously useful. I also know how easy it is to forget what is actually happening behind magical closed doors.

There is no tiny researcher behind the screen consulting a library, only advanced math running across enormous models trained on staggering amounts of language.

That does not make the technology less impressive. In some ways, it makes it more impressive. We built a machine that predicts language so well that humans instinctively begin treating it as another human.

The problem begins when we confuse the quality of the performance with the nature of the performer.

What the Machine Actually Does

Strip away the friendly interface and a large language model does something surprisingly mechanical.

It receives a sequence of tokens, which are words or fragments of words, and calculates a probability for what token should come next. The model may decide that one word has a 48 percent probability, another has 21 percent, and several others are less likely.

It selects one, adds it to the sequence, and runs the calculation again.

That loop produces everything from a short email to a legal summary, a computer program, a poem, or a confident explanation of a subject the model may not understand nearly as well as the explanation suggests.

The randomness can be adjusted. Settings such as temperature influence whether the machine sounds predictable, creative, strange, or occasionally as though it has been drinking. But none of those settings creates a mind. They change how the machine chooses from its predictions.

This is why the familiar description of an LLM as “autocomplete on steroids” is both useful and unfair.

It is useful because the basic mechanism really is next-token prediction. It is unfair because the scale changes what the mechanism can do so dramatically that the comparison becomes a little like describing a jet engine as a very powerful fan.

Here is what I am really trying to say here.

A model does not begin with a verified understanding of the world and then translate that understanding into language. It learns patterns from language and generates what should plausibly come next.

That difference explains much of what feels magical about AI, and much of what makes it unreliable.

The Improv Actor

There are many “experts” on social media who tell us to create a strong LLM prompt by clearly defining the role the machine should assume when answering, then giving it a task. Tell the model to behave like an executive, an HR performance expert, an engineer, a skeptical customer, or an editor, and its response changes. Give it examples of your writing and it begins to imitate the rhythm. Tell it that it is advising a board of directors and it becomes more formal. Tell it that it is explaining something to a child and suddenly every complex system involves a lemonade stand.

This can feel like persuasion, but it is not. The model has not changed its beliefs because you made a compelling argument. You changed the context, and the context changed the probability distribution.

If I wanted to give you the closest human analogy, it may be improv theater.

You hand the actor a character and a scene. The actor recognizes the pattern and continues it. A good model has seen enough language associated with lawyers, physicians, engineers, historians, salespeople, and mildly irritated customers that it can produce a convincing version of how those people tend to communicate.

Sometimes the performance is excellent, and sometimes it wanders halfway through.

This is also why a persona can improve tone and organization without necessarily improving factual accuracy. The model may sound more like an expert because you asked it to sound like one. That does not mean it suddenly gained the expert’s training, experience, or accountability.

We understand this distinction when watching an actor play a surgeon on television.

Joey Tribbiani played Dr. Drake Ramoray, a neurosurgeon on Days of Our Lives, and at no point did anyone watching Friends think, “He seems convincing. Perhaps he should take a look at my MRI.”

For readers who have followed this blog for a while, this reference will not come as a surprise. I have previously admitted to an undocumented feature in the #dmitrywashere operating system where television and movie lines attach themselves to my brain and then appear in conversations where a normal person might have used an original thought. Joey has already helped me explain MCP. It seems only fair that Dr. Drake Ramoray now gets a small role in artificial intelligence.

This works because we instinctively understand the difference between portraying expertise and actually having it. Joey could wear the white coat, deliver the medical terminology, and look sufficiently serious under studio lighting. None of that gave him the education, experience, or accountability of a real neurosurgeon.

With AI, the boundary feels less obvious because the performance is interactive. The model responds to us, adapts its tone, and appears to remember what we said earlier. The conversation creates continuity, even though much of that continuity comes from feeding the previous conversation back into the model.

The transcript is the memory, and the personality is part of the performance.

More Than a Parrot

The argument becomes more complicated here because describing these systems as parrots does not tell the entire story.

Researchers have found evidence that models develop meaningful internal representations of the things they are predicting. They also found that the model could solve math through internal processes that did not match the polished explanation it later gave to the user.

It suggests that these systems are not simply retrieving memorized phrases or blindly gluing fragments together. The process of predicting the next token at enormous scale appears to force the model to build compressed representations of the world that produced the output language.

If you pause for a minute and really think about it, something genuinely cool is happening inside these systems. Saying “it is just statistics” can become as misleading as saying music is just vibrating air.

But the existence of internal structure does not mean the model understands the world as a human does, or that its reasoning can be trusted in every situation.

That is where the difference between the middle and the edges begins to matter.

Brilliant in the Middle, Fragile at the Edges

Statistically, most business problems live somewhere in the middle of a distribution.

A customer follow-up email resembles millions of other professional emails. A meeting summary resembles millions of other summaries. A Python function for sorting a list resembles code the model has encountered in countless forms. A description of ransomware, cloud migration, or a data center sounds like many descriptions already contained in the training material.

This is the territory where language models are really good.

There is enough statistical support around the question for the model to recognize the shape of the problem and generate an answer that fits inside it.

The middle is broad, valuable, and economically significant. Calling the model unreliable does not mean it is useless. People are also inconsistent, forgetful, and occasionally capable of spending an entire meeting discussing a problem that does not exist. We still let them work. Right?

The issue is what happens when the problem sits near the edge.

The edge may be an unusual customer environment, an uncommon medical condition, a new legal interpretation, an obscure product interaction, a rare failure mode, or a math problem that looks familiar but differs in one important way.

The model may work exceptionally well when the problem, prompt, available tools, and expected output all align. Change the conditions, and reliability may change with them.

That is not how most people understand the word reasoning.

The Reasoning We See

The arrival of reasoning models made our tendency to treat AI as human even stronger. I have a friend who “talks” to AI as if to a professional psychiatrist.

Instead of immediately returning an answer, the model now spends more computation generating intermediate steps. On many difficult tasks, this improves performance. Allowing the model to explore possibilities, correct itself, and use more inference-time compute has produced major gains in mathematics, coding, and structured problem-solving.

The reasoning we see is not necessarily the reasoning the model used.

Humans do this too. We make decisions emotionally, instinctively, or unconsciously and then produce a respectable explanation during the drive home. The difference is that we are increasingly treating AI-generated reasoning as an audit trail when it really is not.

If we follow the chain of thought, it can reveal mistakes and give a reviewer something to inspect. But it should not be treated as a forensic record of what actually happened inside the model.

Why It Hallucinates

The word hallucination makes the behavior sound like an occasional illness, as though the model is normally grounded in reality but sometimes sees something that is not there.

The real explanation is less dramatic.

The machine is doing what it was trained to do.

Language-model training rewards prediction that sounds plausible. It does not attach a verified true-or-false label to every sentence in the training material. When a model encounters a question whose answer is rare, contradictory, or absent, it still makes a prediction of plausible next words.

The machine must produce something unless it was trained to say: “I don’t know.”

We have trained the machine to bluff and then act surprised when it does.

Hallucination can be reduced through better training, retrieval, verification, and evaluation. But it is not simply a loose network cable waiting for an engineer to reconnect it.

Give It Something Real to Read

The most practical response is also the simplest.

Stop asking the model to remember everything. Give it verified information to read.

This is the basic promise behind retrieval-augmented generation, or RAG. Instead of relying entirely on what the model absorbed during training, the system retrieves relevant material from enterprise data and places it into the model’s context.

The model no longer has to recall the customer’s contract, support history, current policy, or product documentation from its weights. It can read the source.

But sometimes retrieval can find the wrong document. The right document may be outdated. Two sources may disagree. Permissions may be missing or overly broad.

RAG cannot make bad data trustworthy, but it can make bad data available faster.

That brings us back to The Hall of Mirrors. The question is not simply whether the organization has data. Every organization has data, often in the same way your garage has tools. Technically yes, although finding the correct one may require moving three boxes, questioning several life choices, and eventually buying another copy.

The important questions are whether the data can be discovered, whether it is current, whether its source is known, whether access is appropriate, and whether the system understands how one record relates to another.

AI does not run on data. It runs on trust in that data.

The Model Is Not What Sets You Apart

The AI industry still encourages companies to describe their strategy in terms of models.

We are adopting Model X. We are building on Model Y. We selected Model Z because it has a larger context window and did very well on a benchmark nobody in the meeting has personally reviewed.

A company can move from one commercial model to another. It can use several at once. It can route easy tasks to a smaller, cheaper model and reserve a larger reasoning model for difficult work. It can download open models or replace them when something better appears.

Think about it - access to a model is not a competitive advantage when competitors can obtain access to the same model with a contract and a credit card.

But… They cannot download your history. They cannot recreate years of customer interactions, product decisions, engineering knowledge, operational exceptions, research, failures, and recoveries simply by upgrading an API subscription.

Even data ownership is not enough. A decade of information scattered across file shares, SaaS applications, databases, email, ticketing systems, old backups, and documents is not automatically an asset that matters most.

It becomes one when the organization can understand it, govern it, connect it, and make it usable without losing control of it.

That is data gravity.

Bring the Machine to the Data

Dave McCrory coined the term data gravity in 2010. I wrote about it a few months ago, in Data Gravity. The idea was simple: as data accumulates, it gains mass. Applications, services, and compute move closer because latency, throughput, cost, and practicality make distance increasingly painful.

AI makes that gravity stronger.

Moving a few documents into a cloud service is easy. Moving petabytes of proprietary, sensitive, constantly changing enterprise data to whichever model happens to be fashionable this quarter is something else entirely.

Copies become stale. Egress becomes expensive. Security boundaries multiply. Sovereignty and compliance questions arrive. The organization starts building new pipelines to move data away from the systems already responsible for protecting it.

At AI scale, the older assumption that data should travel to compute begins to reverse.

I think the model should travel to the data.

This does not mean everything must remain on-premises. It means the architecture should respect where data lives and avoid unnecessary movement, duplication, and loss of control.

The architecture is not centered on a single model. It is centered on the data layer.

What Everpure Is Building

This is where Everpure’s recent announcements become more interesting than another collection of product names.

The company’s move from storage toward an Enterprise Data Cloud strategy only makes sense if you accept that AI’s limiting factor is not simply access to GPUs or models. It is the ability to locate, understand, govern, and feed enterprise data into those systems.

Everpure Data Intelligence, built from the acquisition of 1touch.io, is intended to discover and classify information across structured and unstructured environments. More importantly, it builds context around that information: what the data represents, where sensitive information exists, who should have access to it, and how records across different systems relate to the same person, asset, customer, or event.

At Accelerate, one public demonstration used an anonymized athlete named Shane Falco, which was either a deliberate reference to The Replacements or evidence that somebody in product marketing and I have watched too many of the same movies.

The system found a heart condition buried inside a PDF, connected it to the athlete’s son in another database, and identified that the son had never been screened.

The model was not the interesting part. The connection was.

A language model can generate a polished paragraph about heart conditions. The value appears when the system knows that this PDF refers to this person, that another record refers to his dependent, that the relationship matters, and that access to both records is permitted.

Everpure Data Stream addresses the next part of the problem. Built with NVIDIA components, it packages the steps required to ingest, transform, vectorize, index, retrieve, and generate from enterprise data. Instead of every customer assembling a RAG pipeline from a collection of models, databases, frameworks, scripts, and open-source projects, the product attempts to provide those capabilities as an integrated service.

Everpure says customers commonly spend two to four months building pipelines before AI can read a single document.

That sounds believable to anyone who has watched an enterprise project spend six weeks deciding who owns the service account.

The two products form a logical pair. Data Intelligence determines what the data is, how it relates, whether it is sensitive, and how it should be governed. Data Stream makes approved data usable by AI applications.

The Real Advantage

The industry has become very good at demonstrating fast AI.

Upload documents. Ask a question. Watch the answer appear. Add an agent. Give the agent a friendly name. Put the architecture on a slide with several arrows, because nothing becomes enterprise-ready until the arrows have gradients.

Production means the answer must come from the correct information. The information must be current. Access must be enforced. Sources must be traceable. Sensitive records must not casually appear in the wrong context. Somebody must know what happens when two authoritative systems disagree.

Anyone can stand up fast AI, but trusted AI is different.

I do not believe large language models are merely parrots. They build internal representations. They solve problems through methods their creators may not yet fully understand. They can use tools, inspect their work, and produce results that would be impossible only a few years ago.

I also do not believe there is a little mind inside the machine waiting for us to ask an interesting question.

The truth is more complicated and more useful.

These systems are powerful statistical machines. They are very capable in the broad middle of human language and knowledge. They become stronger when given tools, external verification, and context based on truth. They also remain fragile at the edges, where the data is sparse, the situation is unusual, and plausibility is not enough.

The future will not belong to the company that selected the perfect model in 2026. The advantage will belong to the organization that knows what data it has, understands what that data means, protects it, connects it, and can safely bring whichever model it chooses to that governed context.

Once you see the machine behind the mirror, the model itself starts to look less like the moat and more like the visitor standing at its edge.

Appreciate you reading.

Subscribe now

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Last August, I wrote an article called The Future of Data Experience: From Clunky Gearshifts to Sentient Co-Pilots. I was thinking out loud about where data was going, and somewhere in that thinking I used words like sentient and digital clones.

Even as I wrote those words, I knew they were loaded.

Not because I thought a storage array was going to wake up one morning, ask for a badge, and start attending weekly meetings, although I have attended meetings where that might have improved the conversation. The words were loaded because they pull people into very different versions of the future. Some people hear them and imagine systems becoming more helpful, more autonomous, and less painful to operate. Others immediately go to the movie version of artificial intelligence, where the machines become too smart, humans lose control, and somewhere in the background a giant countdown clock appears for no technical reason whatsoever.

That was not the future I was trying to describe.

I was thinking about a quieter shift. For most of my career, data was something we stored, protected, moved, replicated, restored, analyzed, and occasionally blamed when a dashboard did not say what someone wanted it to say. It was important, but still mostly passive. Humans acted on data. Applications used data. Infrastructure protected data.

That is changing.

Data is no longer just sitting there waiting for a person to ask the right question. It is being classified, summarized, embedded, retrieved, interpreted, and fed into systems that do not simply display information. They recommend. They respond. They write. They route. They open tickets. They draft emails. Increasingly, they act.

That future still feels real to me. Maybe even more real now than it did when I wrote that earlier article.

But lately I have been thinking more about the other side of it.

Not the science fiction side. Not the killer robot side. Not the red-eyed machine standing in the rain while dramatic music plays behind it.

The other side is much less cinematic, which may be why it is easier to miss.

It looks like a reply in a thread, a meeting summary, a dashboard recommendation, a support ticket written from a call transcript.

It looks like a sales email generated from CRM notes.

It looks like a chatbot answer that sounds right because it was trained, tuned, prompted, or reinforced by thousands of other answers that also sounded right.

For decades, when we imagined the machine takeover, we pictured something physical. Drones, lasers, metal, mechanical skeletons, and probably a firewall breach represented on screen by bright green code moving at a speed no human could possibly read. The version we are actually building does not look like that.

It may look like language, or convenience, or just content.

And that may turn out to be the more interesting problem, because the real conflict may not be humans versus machines. It may be the truth versus AI generated “hallucination” noise.

Or, said differently, it may be a hall of mirrors.

The Wrong Fear

The easiest conversation to have is the one about whether machines will replace humans. It gets attention because everyone can understand it, and because it gives us a familiar story. There are workers, tools, companies, customers, winners, losers, and some vague promise that productivity will go up if everyone just stops asking uncomfortable questions.

I do not think it is the whole story.

The more important question may be what happens when machines begin consuming the output of other machines and nobody remembers where the original human truth came from.

That is the part that worries me a lot.

AI can create content. It can write, summarize, translate, classify, code, imitate tone, explain complex topics, draft emails, respond to customers, and produce a decent first version of almost anything. Some of it is impressive. Some of it is average. Some of it is nonsense wearing a nice suit, which, to be fair, has never been exclusive to AI.

The real issue begins after the output is created.

An AI-generated answer becomes a document. The document gets saved. The saved document gets indexed. The indexed document gets retrieved. The retrieved document becomes context for another model, which produces another polished answer. That answer gets emailed, pasted into a slide, attached to a support ticket, summarized in a meeting recap, embedded in a vector database, and eventually treated as part of the organization’s memory.

Nobody set out to create a loop. No one called a meeting and said, “Let’s build a system where machines gradually feed on their own residue until we forget what was originally true.” Although, if someone did call that meeting, I am sure it had a better name and a very attractive architecture diagram.

The loop just happens.

That is why I keep thinking about a simple idea: AI does not run on data. AI runs on trust in that data.

The industry talks about AI as if the model is the center of the universe. Which model are you using? How big is the context window? Which vector database? Which agent framework? Which copilot? Which GPU? Which benchmark?

All of that matters. I am not pretending it does not. But it is not enough. A brilliant model connected to a messy, duplicated, stale, poorly governed data is not intelligence. It is confidence without memory. It is the modern version of “autocomplete”.

That is dangerous because if it is wrong but looks good, is much harder to detect than an obvious error. A bad report used to look like a bad report. A broken spreadsheet had visible signs of distress. Someone would notice the formula error, the missing tab, the number that did not pass the smell test, or the graph that made no sense unless gravity had been quietly deprecated.

AI changes the feel of the error.

The output does not look broken. It looks composed. It does not look uncertain. It sounds helpful. It does not say, “I found a stale document from 2018, mixed it with a meeting recap from 2022, added a policy that no longer applies, and produced a recommendation with the emotional confidence of a senior consultant.”

It just answers.

And humans, being humans, often move on.

The Public Internet Was the Warning Shot

The public internet has already shown us what this looks like at scale.

For years, people complained about content farms, search engine spam, fake reviews, engagement bait, outrage posts, and accounts designed to provoke rather than inform. Then generative AI arrived and made the economics even easier. If attention is the business model, and content is the fuel, then a machine that can generate endless content becomes very attractive.

Platforms reward attention, so content is created to get attention. Automated systems learn what works, so they produce more of it. Other systems scrape it, summarize it, rank it, quote it, index it, and feed it into the next generation of tools. Eventually, the internet starts to feel less like a record of human thought and more like a hall of mirrors with a few humans still wandering around inside, wondering why everything sounds vaguely familiar.

Researchers have a name for this: model collapse — sometimes called “AI inbreeding” or, my personal favorite, model autophagy disorder, which sounds like something a doctor would say just before asking you to sit down. (This took some serious research and reading).

The simple version is that when models are trained too heavily on the output of previous models, they begin to lose touch with the objective truth. Over time, the model may become smoother and less useful at the same time.

We all know about AI hallucination as if the main problem is a machine inventing a fake legal case or giving the wrong answer about a historical fact. Those are real issues, and they can be serious, but at least they are sometimes checkable. The quieter issue is the disappearance of the edges.

And life is mostly edges.

Business is edges. Public sector is edges. Healthcare is edges. Security is edges. The most important cases are almost always the ones that do not fit neatly into the pattern.

If AI systems are trained, tuned, or fed by increasingly synthetic material, they may become very good at repeating the middle and very bad at preserving truth at the edges.

This should really bother you. Not because AI is evil, but because memory matters.

The Enterprise Has Its Own Hall of Mirrors

It is easy to point at the public internet and say, “That is the internet. Of course it is messy.” That is the same internet where people argue with strangers named CryptoEagle1776 under restaurant reviews, so yes, expectations should be managed.

The more uncomfortable question is what happens inside the enterprise, because every company and every public sector agency has its own smaller version of the internet.

It may not look like social media, but it has the same basic ingredients. File shares, SharePoint folders, old PDFs, exported reports, forgotten dashboards, duplicate customer records, ticketing systems, email archives, Teams chats, Slack threads, CRM notes, policy documents, project plans, drafts, final drafts, and final-final-approved drafts that were never actually approved by anyone who remembers the meeting.

Somewhere inside that mess is the thing everyone wants to call the source of truth.

For years, organizations have treated data sprawl as an operational annoyance. Too many copies, too many silos, too many owners, too many systems, and too many places to look. Painful, yes, but familiar. People learned to work around it. They knew who to ask, which folder to avoid, which spreadsheet was the real one, and which dashboard looked official but had not been trusted since the person who built it left the company.

AI changes the stakes because now we are not simply asking people to search the mess. We are asking machines to reason over it. Soon, if not already, we are asking machines to act on it.

That is a very different level of trust.

A human analyst who finds an old document may notice that the logo is outdated, the names are wrong, the project mentioned was cancelled, or the entire strategy belonged to someone who left three years ago. A machine may not notice any of that. It may retrieve the text because the words are semantically close to the question, then present the answer with a level of confidence the source never deserved.

That is the contamination of corporate memory.

I do not mean contamination only in the cybersecurity sense, although that matters too. I mean the quieter contamination that happens when an organization cannot clearly separate current truth from historical context, abandoned strategy, personal opinion, machine-generated summary, and actual system of record.

If everything gets indexed and everything is treated equally, the loudest surviving copy can become the truth. Not the best copy. Not the current copy. Not the governed copy. The loudest one. The one that appears in the most places because it was attached to an email, pasted into a deck, copied into a folder, exported into a data lake, and eventually embedded into a retrieval system.

That is not intelligence. That is lipstick, applied very confidently, to a very old pig.

Garbage In, Gospel Out

One of the reasons this is hard to see is that data no longer sits still.

We still talk about data as if it lives in a place. It is in a database, a file, an object store, a warehouse, a lake, an application, or some other named location that sounds more controlled than it usually is. But modern data behaves less like something sitting in a vault and more like something moving through an assembly line.

A record gets created in one system, copied by another, transformed by a pipeline, classified by a tool, embedded into a vector database, retrieved by a model, summarized in a prompt, turned into an answer, pasted into an email, saved into a customer record, and later retrieved again as context for something else.

The assembly line keeps moving, and the farther away you get from the original source, the harder it becomes to know what you are actually looking at.

If the early part of that chain is polluted, everything downstream gets worse while appearing more polished. That is the part people miss. The language improves. The formatting improves. The summary gets tighter. The recommendation sounds more executive-ready. The bullets line up neatly enough to make everyone feel like the work has been done.

Underneath that polish, the system may be drifting farther from reality.

That is why the old phrase “garbage in, garbage out” does not feel strong enough anymore. AI turns it into something else.

Garbage in, gospel out.

Once the machine says it clearly, people treat it differently. A person who would never fully trust a random paragraph in a dusty folder may trust a clean answer from a chatbot because the answer feels processed. It feels like someone, or something, already did the work.

That is the seduction.

The answer arrives without friction.

And friction, as annoying as it is, has always been part of how humans detect risk.

When you had to open the file, read the source, look at the date, check the author, compare it to another system, ask someone who remembered the project, and then decide whether to trust it, the process was slow. But the slowness forced judgment.

AI removes much of that slowness.

It can be useful. But it is also dangerous.

The Bots Moved Inside the Firewall

The word “bot” still makes people think about the public internet. Fake accounts, spam replies, scrapers, propaganda, comment sections, click farms, and strange social media profiles with no real history and eleven followers.

But the more important bots may be the ones we are willingly bringing inside.

Sales assistants, support agents, meeting note takers, procurement bots, security copilots, HR assistants, code reviewers, customer service agents, knowledge management bots, and ticket summarizers are becoming normal parts of the enterprise workflow. They are not all bad. Many of them are useful. I use these tools. Most of us do. There is nothing noble about manually summarizing a meeting transcript if a machine can get you most of the way there and a human applies judgment to the rest.

The issue is not the tool. The issue is the residue.

Every AI bot creates exhaust. A meeting assistant creates notes. A support bot creates a ticket summary. A sales assistant creates a follow-up email. A code assistant creates comments. A security tool creates explanations. A procurement bot creates recommendations. A customer service agent creates responses.

Some of that output is reviewed. Some of it is not. Some is accurate. Some is close enough. Some is wrong but harmless. Some is wrong in a way that does not become obvious until much later.

The uncomfortable question is where all of that output goes.

If the generated meeting notes become part of the project record, if the ticket summary becomes part of the support history, if the AI-written sales follow-up becomes part of the account timeline, and if all of that eventually gets indexed and retrieved by future systems, then machine output has quietly become part of corporate memory.

At that point, the bot invasion is no longer something happening outside the firewall. It is part of the workflow. It is part of the record. It is part of the memory.

Once that happens, organizations need a way to know what was human-created, what was machine-created, what was reviewed, what was approved, what was inferred, and what was simply generated because a workflow needed something to put in a field.

Without that distinction, corporate memory gets blurry.

Blurry memory is not a good foundation for automation.

Comfortably Wrong

This is where the human part matters most.

I do not think the biggest AI risk is that the machine will be dramatically wrong. This tends to get noticed. If the system invents a customer, reverses a number, or confidently describes a policy that never existed, someone may eventually catch it.

The more common risk is that the machine becomes comfortably wrong.

Humans like comfort. We like validation. We like clean answers. We like tools that reduce cognitive load, especially when we are tired, busy, overcommitted, or buried under more decisions than we can reasonably make in a day.

That is not a character flaw. That is just being human.

AI systems are very good at producing the feeling of resolution. They can make uncertainty feel settled, partial information feel complete, old data feel current, opinion feel like analysis, and a guess feel like institutional knowledge.

That is why trust cannot be a layer bolted on at the end.

Trust has to be part of the architecture.

When Bad Data Governs Real Lives

The stakes get much higher in the public sector.

In commercial environments, bad data can cost money, damage reputation, slow decisions, create bad forecasts, or send teams in the wrong direction. Those are real consequences. I do not want to minimize them.

But in State, Local, and Education environments, data can shape someone’s life.

Eligibility for benefits, student records, public health, criminal justice, housing, taxes, permits, emergency services, child welfare, unemployment, and healthcare access are not abstract workflows. They are human outcomes.

This is the danger in SLED.

Because the output is wrapped in the language of technology, people may treat it as neutral.

Data is rarely neutral. It has a past.

Trust The Data Before You Trust The Answer

This is the part of the conversation where I want to warn you to pay attention.

The future of AI will not be decided only by model size, GPU count, or prompt engineering, although I know we all enjoy pretending that the right prompt is one sentence away from solving all the world’s problems.

The real question is whether organizations can build a trusted data supply chain.

That means knowing what data exists, where it lives, who owns it, who can access it, what it means, whether it is sensitive, whether it is duplicated, whether it is current, whether it was created by a human or generated by a machine, and whether an AI system is allowed to use it or act on it.

This is why the move from application-centric thinking to data primacy matters.

In the old model, applications owned the world. The CRM owned the customer. The ERP owned the transaction. The HR system owned the employee. The ticketing system owned the incident. The learning system owned the student record. Each application had its own rules, its own copy, its own context, and its own version of reality.

That worked when humans were the integration layer.

It breaks down when AI becomes the integration layer.

AI does not simply need access to data. It needs context around data. It needs to understand that two records may refer to the same person, that a document is outdated, that a field contains protected health information, that a policy applies to one department but not another, and that a customer name in one system is connected to a contract in another system and a support history in a third.

Most importantly, it needs to know what it is allowed to know.

That is a data architecture problem.

This is where the conversation around data context and data primacy becomes more than a marketing phrase for me. If data is going to feed AI, agents, bots, automation, analytics, and human decision-making at the same time, then data cannot remain trapped in scattered application silos with inconsistent meaning and uneven governance.

It has to become a governed, intelligent, horizontal layer that systems can use without every application creating its own private version of truth.

I am convinced that human authorization must be in place as a hard gate on sensitive administrative actions.

The Machine Needs a Memory It Can Trust

I still believe in the future I wrote about last year.

I still believe data infrastructure is becoming more autonomous. I still believe the experience of using data will become more fluid, more intelligent, and more invisible. I still believe we are moving toward systems that feel less like tools we operate and more like partners we work with.

But I am less interested now in whether we call those systems sentient, copilots, agents, assistants, or digital clones. The names matter less than the foundation.

A digital clone trained on a messy version of you is not you. A copilot connected to stale data is not a copilot. An agent acting on ungoverned context is not automation. It is risk with a friendly interface.

The future I want is not one where humans do everything manually forever because we are afraid of automation. That would be ridiculous. The old way was not noble. A lot of it was slow, repetitive, fragile, and wasteful. There is nothing heroic about a pivot table.

But the future I want is also not one where we confuse speed with trust, fluency with truth, access with understanding, or automation with accountability.

The machine should be programmed to say, “Here is where the answer came from. Here is why this source is trusted. Here is what I was not allowed to use. Here is what changed recently. Here is where the confidence ends. Here is where a human needs to decide.”

That may not sound as exciting as a robot uprising.

But it is much closer to the real work ahead.

I appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Last night, in Part 1, I wrote that the Everpure Accelerate 2026 opening keynote did not really feel like a storage keynote.

My takeaway from day one was simple:

Everyone wants your data.
The bigger question is who owns the context.

Day two answered a different question.

If day one was about why the Enterprise Data Cloud matters, day two was about how customers are supposed to get there without turning it into another giant transformation project that sounds great on stage or in a boardroom and then dies somewhere between budget approval, staffing constraints, internal politics, and the next urgent outage.

That is why the second keynote mattered.

It was not trying to restart the vision. The vision had already been established. It was about turning that vision into something customers could actually use: a methodology, a blueprint, and a way to connect data architecture to risk reduction, efficiency, agility, modernization, and business outcomes.

And then John Colgrove, Coz, did what Coz does.

He simplified the whole thing.

Not by making it smaller.

By making it clearer.

The phrase that stayed with me from his session was not a technical phrase. It was not Enterprise Data Cloud, Data Primacy, Fusion, data intelligence, or workload mobility, even though all of those ideas were underneath what he was saying.

It was the light switch.

Coz talked about walking into a room at home and turning on the light. You know exactly what is going to happen. It is simple. It is obvious. It works the way you expect it to work.

Then he compared that to walking into a conference room at the office, where five people spend the first few minutes trying to figure out how to turn on the right lights, dim the screen area, wake up the display, connect the laptop, and make the audio work.

Everyone has lived that moment.

It is also a perfect way to explain what Everpure has been trying to do since the beginning.

Make the complicated thing feel like the light switch.

That may sound too simple for enterprise infrastructure, but I think it is exactly the point. The best infrastructure does not feel simple because the problem is simple. It feels simple because somebody did the hard engineering work to hide complexity without hiding control.

That has always been part of the Everpure story.

When Pure Storage first became known in the market, the message was not only flash performance. Performance mattered, of course. But the thing customers really felt was that the experience was different. The arrays were simpler. The upgrades were non-disruptive. The support model was different. Evergreen architecture was different. The idea that you could keep modernizing without the usual forklift pain was different.

Over time, that simplicity moved from one array to more of the environment.

Fusion extended the idea from a single system to a fleet. Policy, placement, automation, workload mobility, service levels, compliance, and lifecycle management started to move from device-by-device thinking toward something broader.

Now, with the Enterprise Data Cloud, Everpure is trying to move that simplicity again.

From array to fleet.

From fleet to data.

From data storage to data management.

That was the thread both Nirav Sheth and Coz pulled through the keynote, and I think it connected day two back to day one in a very useful way. They made it clear that the move from Pure Storage to Everpure is not an abandonment of what got the company here. It is a continuation of the same journey.

That matters because customers are rightfully skeptical when technology companies rebrand or expand their message. They wonder whether the company is moving away from the thing they trusted. They wonder whether the new story is strategy or just vocabulary.

Coz addressed that directly.

We are not abandoning storage infrastructure. We are going to keep building the best storage infrastructure we can. But we are also going higher, because to build better infrastructure, you have to understand more about the data above it.

That is a founder’s version of the message.

Less theater.

More first principles.

If you store data, you want to know what it is. You want to know how it will be accessed. You want to know how often. You want to know what it relates to. You want to know whether there are copies. You want to know whether those copies create risk. You want to know whether the rules are being followed.

The problem, as Coz pointed out, is that nobody really knows the future.

The infrastructure has to be built for agility.

That word gets overused, but in this context it matters.

Agility is the ability to change without breaking everything.

It is the ability to move workloads non-disruptively. It is the ability to rebalance a fleet. It is the ability to modernize hardware without turning it into a migration event. It is the ability to adjust policies as risk changes. It is the ability to bring intelligence to data that already exists instead of forcing the business to start over.

That is where the Enterprise Data Cloud story becomes more practical.

And I personally think the Enterprise Data Cloud Success Blueprint was the clearest example of that.

I liked this part because it moved the conversation away from “look at all these capabilities” and toward “here is why it matters to you” and “what outcomes are you trying to drive?”

That is where a lot of technology conversations go wrong. We get excited about the architecture and forget that customers are not buying architecture for the sake of architecture. They are trying to solve business problems with limited people, limited time, limited budget, and increasing pressure from every direction.

They are dealing with supply chain constraints.

They are being asked to do more with the same team.

They are trying to create VMware optionality without making a reckless move.

They are modernizing applications while still running legacy workloads that cannot just disappear.

They are dealing with cyber risk, ransomware, and minimum viable business recovery.

They are being asked to support AI before the data foundation is ready.

The blueprint framework organized those pressures into three simple categories: risk reduction, efficiency, and agility.

That may seem obvious, but obvious is underrated.

Risk reduction is not just a security feature. It is knowing whether your data is protected, whether your snapshot policies are aligned, whether you can recover the minimum viable business, whether sensitive data is duplicated everywhere, and whether compliance follows the data instead of living in someone’s spreadsheet.

Efficiency is not just a density number. It is energy efficiency, automation, operational scale, fewer manual tasks, fewer migrations, and fewer people spending nights and weekends babysitting infrastructure that should be managing itself.

Agility is not just modernization language. It is VMware optionality, container readiness, AI readiness, cloud flexibility, application mobility, and the freedom to make the next decision without being trapped by the last one.

I think that is a much better way to have the conversation with customers.

Not “Do you want this product?”

But “Which business outcome are you trying to improve, and what is standing in the way?”

The Red Hat and CSX discussion made that practical.

When Eric Grabill from CSX talked about Positive Train Control, sensors along the tracks, safety requirements, and systems where a loss of data can affect train operations, the conversation moved from platform strategy into the real world.

That is where infrastructure earns its keep.

CSX has already moved a large portion of its applications to Kubernetes on OpenShift, but still has legacy VMs remaining. That is the real enterprise pattern. It is not containers or VMs. It is containers and VMs. It is cloud and on-premises. It is modern and legacy. It is AI coming next while everything else still has to run today.

The Red Hat and Portworx conversation made the point that modernization cannot mean creating another disconnected stack. Customers need one operating model across VMs, containers, and eventually AI workloads. They need a practical transition path, not a big bang migration. They need data services that protect the applications, not just compute platforms that can host them.

The St. Elizabeth Healthcare conversation made the same point in a more personal way.

Charles Shepherd talked about joining St. Elizabeth in 1997, starting at the help desk, moving through Novell, GroupWise, backups, storage, and eventually becoming part of the team responsible for systems that support a healthcare environment that never really stops.

What stayed with me was not only the technical story.

It was the laptop on vacation.

Anyone who has worked in infrastructure understands that detail. The laptop that comes with you just in case. The phone you keep checking because maybe something happened. The family event where part of your brain is still in the data center. The trip where you are physically present but operationally on standby.

That is not a feature comparison.

That is a life comparison.

Charles said he recently was able to go to his niece’s graduation and not get called. That sounds small only if you have never been the person who always gets called.

He also talked about more than one hundred hardware upgrades and more than one hundred fifty Purity upgrades without downtime. He talked about moving from older systems to modern ones without the traditional forklift migration pain. He talked about change boards becoming comfortable with upgrades during the day because the process had earned trust.

That is the kind of customer proof that matters.

It shows what the solution that was delivered gives back. It gives back time, trust and confidence.

That connects directly to the light switch idea.

Simplicity is not cosmetic. It is not just a better UI. It is not just fewer clicks. Simplicity changes what people can spend their time on. It changes what teams believe they can safely do.

And it changes whether the infrastructure team is trapped maintaining the past or free to prepare for what comes next.

Coz also said something important about time.

This Enterprise Data Cloud journey is not a one-year story. It is not one product cycle. It is not done because it showed up in an Accelerate keynote. Coz described it as a journey that will take five to ten years, and even then, it will not really be done because the solution will keep improving.

I appreciate that kind of honesty.

So when a founder says this is a long journey, I believe that more than I believe a slide that says “seamless transformation” in large font.

But I also think now is the right time for the journey to become possible.

And Coz reminded us that the best version of this is not complexity with better branding.

The best version is the light switch.

Coz, in the most Coz way possible, reminded everyone that the goal is not to make enterprise infrastructure sound impressive.

The goal is to make the hard things feel obvious.

Like turning on the lights.

I appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Back in February, I wrote that I had never been to Pure//Accelerate.

This year, I still am not in Las Vegas.

I watched the Everpure Accelerate 2026 opening keynote live from my home office, which turned out to be a different kind of vantage point. Not better than being there. Not worse. Just different.

You do not get the hallway energy. You do not get the sponsor booths. You do not get the accidental conversations that happen while looking for coffee (or tea in my case). You do not get to read the room in the same way. You are not surrounded by the noise, the music, the badge lanyards, the customer reactions, or that strange conference feeling where everyone is tired and energized at the same time.

A keynote viewed remotely has to work harder because the production does not carry you in the same way. If the speakers are just reading slides, you feel it immediately. If the story is thin, the distance makes it thinner. If the message is only a collection of announcements, you start checking email.

But if the story is real, the distance does something interesting.

It removes some of the theater.

You are left with the words, the pacing, the ideas, and whether the people on stage actually believe what they are saying.

This morning, the parts that landed with me were not the parts that felt the most polished. They were the parts where the keynote stopped sounding like a keynote and started sounding like people trying to explain a real shift in the industry.

For me, the strongest moments came from Charlie Giancarlo, Chadd Kenney, Shawn Rosemarin, and the NVIDIA conversation. Not because they had the most slides. Not because they had the most numbers. They landed because they are storytellers.

That matters more than we sometimes admit in enterprise technology.

A slide reader can tell you what a product does.

A storyteller can tell you why the product had to exist and why it matters to the customer or partner.

There is a difference.

And this morning, the difference mattered.

Charlie’s most important line came early, and it changed the shape of the keynote. He said he was not going to talk about data storage.

He was going to talk about data.

For a storage company’s major customer event, that is not a small pivot.

It would have been easy for Everpure to spend the morning celebrating the familiar things. Growth. Customer count. Market share. Flash leadership. Subscription run rate. Fusion adoption. Gartner recognition. Net Promoter Score. Performance numbers. Efficiency numbers. All of that was there, and all of that matters.

But the real keynote was not about proving that Everpure is good at storage.

The real keynote was about arguing that storage is no longer the highest-level conversation.

Data is.

That is where the rebrand from Pure Storage to Everpure starts to become more than a name change. A company called Pure Storage can be excellent at arrays, controllers, upgrades, density, performance, and simplicity. A company called Everpure has to earn the right to talk about the enterprise data cloud, and that is a much larger promise.

It is also a much riskier promise.

Because once you move north of storage, you are no longer talking only about where data lives. You are talking about who controls it, who understands it, who governs it, who protects it, and who gets to use it.

That is where Charlie’s message became interesting.

His argument was that the enterprise has spent decades living in an application-centric architecture. ERP had one version of the business. CRM had another. ServiceNow had another. HR systems had another. Analytics platforms copied data out of all of them. Data lakes were built to make sense of the mess. Now AI agents are being asked to reason across that same fragmented landscape.

That is the problem.

Not AI in theory. AI on top of fragmented truth.

We have all seen some version of this. The definition of a customer changes depending on which system you ask. The data in one application does not quite match the data in another. A report is technically correct, but only according to one source. A copy was made for analytics, another for backup, another for a project, another for a data science team, and one more because someone needed it urgently two years ago and nobody knows if it is still being used.

Now imagine asking an AI agent to act on that.

That is where the phrase “Data Primacy” becomes more than keynote language.

From what I understood this morning, Data Primacy is Everpure’s argument that data should no longer be trapped inside applications as a secondary object. The data itself, along with its context, relationships, governance, and sources of truth, has to become primary. Applications still matter. Workflows still matter. SaaS still matters. But the enterprise cannot keep allowing every application to define its own version of reality and then expect AI to make intelligent decisions across the pile.

That is not sustainable.

One of the strongest lines from Charlie was the idea that every vendor wants your data.

Every SaaS vendor wants your data.
Every analytics vendor wants your data.
Every AI vendor wants your data.

But what they really want is not just the data. They want the context.

They want the meaning.

They want to know how a customer in one system relates to a contract in another, a support case in another, an invoice in another, a shipment in another, a security policy in another, and a business outcome somewhere else entirely.

In the AI era, context is the new land grab.

That is the sentence I kept coming back to during the keynote.

Everyone wants your data, but the bigger fight is over who owns the context.

That is why this morning did not feel like just another AI infrastructure pitch. It felt like Everpure trying to move the conversation from managing arrays to managing truth.

That is a big claim. It needs proof. And that is where Chadd Kenney’s part of the keynote mattered.

Chadd is one of those speakers who can make infrastructure feel like an actual story instead of a list of capabilities. That is not easy. Storage features can get very technical very quickly, and if you are not careful, everything turns into a blur of replication, snapshots, policies, performance, controllers, and acronyms.

But Chadd framed the platform in a way that made sense.

First, the unified data plane stores the data. Then the intelligent control plane governs and operates it. Then the universal data intelligence layer helps understand it. Together, those pieces create a different operating model.

That phrase, operating model, is important.

Because the most interesting part of the demo was not just that Fusion can automate tasks. It was that Everpure is trying to change the relationship between people and infrastructure.

The old world asks humans to be perfect by hand.

Log into this array. Check that policy. Fix that snapshot setting. Compare it to the spreadsheet. Make sure the production workloads are covered. Exclude dev and test. Check compliance. Update the retention period. Open the change. Wait for the window. Hope nobody missed one.

We have normalized that kind of work for years.

Then we call it operational discipline.

Sometimes it is. But sometimes it is just human beings being forced to compensate for systems that do not understand intent.

The Fusion demos showed something better. Define the policy once. Attach intent to the workload. Let the control plane detect drift. Let it show violations. Let it recommend a fix. In some cases, let it act. In other cases, keep the human in the loop, but stop making the human do repetitive work that the platform should be able to understand.

The ransomware snapshot example was a perfect illustration. A customer mandate changes retention from fifteen days to thirty days. In many environments, that becomes a manual chase across infrastructure. In the keynote demo, it became a policy problem, a compliance view, a remediation path, and an audit trail.

That is what infrastructure teams actually need.

Not another dashboard that tells them something is broken.

A system that understands what “correct” looks like and helps keep the environment there.

The workload mobility demo made the same point from a performance angle. If the platform can see that a workload is trending toward a service level violation, recommend a better placement, validate the move, and relocate that workload without the application owner noticing, that is not just automation.

That is infrastructure keeping a promise quietly.

And quiet matters.

The best infrastructure usually disappears. Nobody sends a thank-you note because latency did not spike. Nobody opens a champagne bottle because a replication policy worked. Nobody celebrates the outage that did not happen. But those invisible wins are the difference between a team that spends its life firefighting and a team that gets to work on the next thing.

That is why the Active Cluster for File demo also worked. Synchronous replication for file sounds technical, and it is. But the emotional value is simple. When something fails, the business does not want a heroic recovery story. It wants no story at all.

The workload quietly packed its bags and moved.

That line stayed with me because disaster recovery should be boring. Boring is the goal. Boring means the policy worked, the automation worked, the architecture worked, and the humans did not have to assemble on a bridge call at 2 a.m. to save the day.

Then Shawn Rosemarin took the keynote into the AI conversation, and again, the strength was in the framing.

The bottleneck stalling AI is not compute. It is not models. It is not tooling.

It is data.

That is the part of the AI conversation that I think many customers are starting to feel more clearly. For the last few years, the market has been obsessed with models and GPUs. That made sense. There was a lot to understand, and the infrastructure requirements are real. But most customers are not trying to build the next frontier model. They are trying to unlock the intelligence that already exists inside their own business.

Their documents.
Their contracts.
Their transactions.
Their support history.
Their clinical records.
Their policies.
Their engineering files.
Their internal knowledge.
Their institutional memory.

That does not become useful just because someone points a model at it.

It becomes useful when the data is prepared, classified, curated, governed, indexed, vectorized, and delivered with the right context at the right time.

That is why the Everpure Data Stream announcement with NVIDIA mattered. The message was not simply, “We can feed GPUs fast,” although performance absolutely matters. The more important message was that enterprise AI needs a way to make data AI-ready without creating another silo, another copy, another stale version of the truth.

Shawn made the point clearly: other vendors want you to copy your data into their system. But a copy is always behind.

That is such a simple sentence, but it carries a lot of weight.

A copy has to be protected.
A copy has to be governed.
A copy has to be reconciled.
A copy has to be secured.
A copy can drift.

If AI is going to answer questions, automate workflows, make recommendations, or support decisions, stale context is not just inefficient. It is dangerous.

That is where the NVIDIA conversation added credibility. The point was not just that Everpure has a partner logo on a slide. The point was that AI has become a full-stack infrastructure problem. Data has to move efficiently. GPUs cannot sit idle waiting for bytes. Inference needs low latency and quick access to the right information. Agents need context. Networking matters. Storage matters. Hardware matters again.

I liked the line about hardware being cool again.

I liked it because it is funny, but also because it is true.

For years, parts of the industry talked as if infrastructure had become invisible. Cloud abstracted it. SaaS hid it. Software ate the world, and many people acted as if the physical layer was someone else’s problem.

AI ended that illusion.

When customers are investing serious money in GPUs and trying to build real AI capability, storage is not a commodity. Networking is not plumbing. Metadata performance is not trivia. Power is not someone else’s concern. Operational excellence is not optional.

The physical world is back in the strategy conversation.

Maybe it never left. Maybe some people just stopped looking.

That is why the keynote worked for me, even from my home office.

Not because every demo was relevant to every customer. Not because every phrase was perfect. Not because I think one keynote answers every question. That is what the next two days are for.

It worked because the best speakers were not just announcing things. They were connecting the dots.

Charlie explained why the application-centric model is running out of room.

Chadd showed what it looks like when infrastructure starts operating from intent instead of manual heroics.

Shawn connected AI success back to data readiness instead of model worship.

The NVIDIA conversation reminded everyone that AI is not magic. It is infrastructure, data movement, context, governance, and execution.

That is a story.

And in enterprise technology, the story matters because customers are not just buying features. They are buying a way out of the mess they are already in.

The mess is fragmentation.

AI did not create that mess, but AI is making it impossible to ignore.

That may be the real takeaway from day one of Accelerate. The AI era is forcing enterprises to confront the data architecture choices they have been living with for decades. The old model was manageable when humans were the ones reconciling the gaps. It becomes much more dangerous when agents begin acting on top of those gaps at machine speed.

That is why Everpure’s move toward Data Primacy is worth paying attention to.

It is not just a product direction. It is a point of view.

The application should not own the truth.

The copy should not become the truth.

The dashboard should not pretend to be the truth.

The enterprise needs to own its data, understand its context, govern its use, and make it available to applications, analytics, and AI in a way that is coherent and trustworthy.

That is easy to say and very hard to do.

But this morning, for the first time, I felt the full shape of what Everpure is trying to become after the rebrand. Not just a storage company with a new name. Not just a platform company using AI language because everyone has to. But a company trying to move the enterprise conversation north of storage and into the question that will define the next decade:

Who owns the context of your business?

Because everyone wants your data.

The companies that win will be the ones that know what it means.

I appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

If you have been following along for a while, you already know about the “undocumented feature” in the #dmitrywashere operating system. The one where movie and TV show lines attach themselves to my brain and then find their way into conversations where most reasonable people would have said something normal instead.

I have mentioned Friends. I have mentioned The Big Bang Theory. I have referenced Joey Tribbiani nodding along to a conversation he had completely stopped following, which, if I am being honest, described my first several weeks of hearing people talk about MCP.

This time, the show that has been bothering me is Person of Interest (2011-2016).

If you never watched it, the premise was built around an artificial intelligence called The Machine, a system that had been given access to essentially every surveillance network imaginable and used that access to identify people who were either about to commit violence or about to become victims of it. The moral complications of that premise were part of what made the show interesting, but that is not the part I want to talk about.

The part that has been living rent-free in my head lately is what happens to The Machine when it is threatened.

At a certain point in the story, The Machine can no longer exist safely in one location. Being centralized has stopped being a strength and started being a liability. So it does something that felt like very clever television writing when I first watched it and has started to feel more like a reasonable infrastructure decision every time I think about it now. It distributes itself.

Not into a cloud platform. Not into a purpose-built facility with access control and a cooling system and a vendor-sponsored naming opportunity on the front of the building. It moves into the electrical grid itself, into utility boxes, into the kind of anonymous infrastructure that lines every street and hangs from every pole while everyone walks past it without ever stopping to think about what it actually does.

The first time I saw that, I thought the writers were being clever.

I still think they were being clever. I just think they were also accidentally writing about 2026.

Because here we are, and there is an actual company called SPAN that has announced something called XFRA, which is a distributed data center concept that places compute nodes at residential and small commercial locations. NVIDIA is listed as a launch partner. PulteGroup, which is a national homebuilder, is involved in the pilot. The nodes use liquid-cooled NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs. Fortune reported that SPAN has already deployed prototype units in Northern California, describing them as cabinet-sized nodes installed on the sides of homes and small businesses, with the stated goal of tapping into underutilized residential electrical capacity to build AI compute capacity faster and at lower cost than conventional centralized data centers can be built.

I want to say something carefully here, because this story has been traveling around the internet in a version that is somewhat cleaner and more exciting than the verified facts support. The rumor version says NVIDIA wants to put mini data centers in your backyard and pay you for hosting them. That version has the advantage of being the kind of sentence people like, forward and repost immediately, which is probably why it is the version most people have seen.

The real version is that SPAN is proposing this concept, with NVIDIA as a partner, and that the homeowner value proposition appears to involve subsidized electricity and internet rather than a straightforward monthly cash payment. That distinction matters if you are making a decision based on it. It matters less if what you are really trying to understand is what it means that this conversation is happening at all.

And that is what I keep coming back to. Not whether backyard AI nodes become a standard part of residential landscaping in American suburbs. Not whether your HOA is going to approve the GPU box before or after the fence dispute. But the reason this idea is being taken seriously by real companies with real capital and real partners.

It is being taken seriously because AI has made power the constraint that everything else is now organized around.

That shift happened faster than most of the enterprise IT world has fully adjusted to, and I think it is worth being honest about why.

For most of my career, power was present in every data center conversation, but it was rarely the conversation. It was part of the facility design. It was part of the colocation contract. It was something the colo provider or the building manager or the facilities team worried about, and something that showed up on someone else’s line item in a way that was easy to treat as overhead rather than strategy.

Storage teams talked about capacity and latency and replication and snapshots and protection policies and cyber resilience.

Compute teams talked about virtualization, CPU density, memory ratios, GPU allocation, and increasingly Kubernetes. Network teams talked about bandwidth, latency, fabric design, and east-west traffic.

Application teams talked about response time, throughput, scalability, and the user experience.

Business teams talked about outcomes, timelines, and cost.

Power was in the room. But it was rarely the point.

What changed is that AI workloads have a completely different energy profile than the workloads enterprise IT was built around. The traditional enterprise environment had a rhythm to it that the infrastructure had been designed over many years to accommodate. Workloads were bursty in ways that were relatively predictable. Applications had peak periods and quiet periods. Databases absorbed load and relaxed. Batch jobs ran during specific time windows. Users followed patterns. The data center breathed in a way that the cooling systems, power distribution designs, and rack densities were engineered to handle.

AI workloads do not breathe the same way. Training runs can sustain intense load for days or weeks without interruption. Inference, which tends to sound lighter when described per individual transaction, becomes a constant background hum when it is embedded into enough applications, workflows, copilots, search experiences, security tools, development environments, and business processes simultaneously. The load does not feel like the old load. The heat does not feel like the old heat. The planning assumptions that went into the physical infrastructure do not hold in the same way.

The International Energy Agency has projected that global data center electricity consumption could more than double by 2030, reaching approximately 945 terawatt-hours, and it points specifically to AI as a primary driver of that growth. That number is large enough to be almost emotionally useless in conversation. Most people cannot feel a terawatt-hour. It is like telling someone the ocean is very deep. True, and accurate, and somehow insufficient to produce a useful response.

So I find it more helpful to think about it in terms of what it means for a specific customer in a specific building trying to do a specific thing.

I think about the organization that has spent several years consolidating, virtualizing, deduplicating, tiering, and modernizing, and has done a genuinely good job of it, and is now sitting in a building whose power design reflects the assumptions of the era when all of that work was done. I think about the team that wants to add GPU capacity for AI workloads and is discovering that the ceiling on that ambition is not the GPU budget, is not the vendor selection, is not the use case validation, and is not the executive alignment.

The ceiling is watts. I think about the CIO who has been told by the business that AI is a priority and has agreed that it is, and who is now discovering that priorities do not override physics. I think about the customer who says they want to do AI and is somewhere in the process of realizing that wanting to do AI is a different sentence than being able to support AI with the physical infrastructure they actually have.

None of that is a failure of imagination or ambition. It is a collision between a very reasonable set of technology goals and a very honest set of physical constraints. The constraints were always there. AI made them visible in a way that earlier workloads generally did not.

This is where I think the data storage conversation starts to matter more than it usually gets credit for.

It is easy to make the AI infrastructure story mostly about GPUs, and in terms of raw power consumption, that framing is not wrong. A modern AI accelerator draws more power than almost anything else in the rack, and high-density GPU configurations push data center power planning into territory that many traditional facilities were never designed to handle. But the GPU is not sufficient as the full explanation, partly because the GPU is almost never the bottleneck people think it is, and partly because a GPU that cannot get data fast enough is not doing the work it was purchased to do.

A GPU waiting for storage is still consuming power.

It is still producing heat. It is still occupying space and contributing to the facility’s total load. It is just not converting any of that into useful computational output.

In the economics of AI infrastructure, idle GPU time is one of the most expensive things that can happen, because the cost of the GPU does not pause while the data pipeline catches up.

This means that storage architecture is not separate from the power conversation. It is part of it. The physical footprint of the storage platform contributes to rack density and cooling load. The data reduction efficiency of the platform determines how much raw capacity is required to hold a given amount of useful information, and therefore how much hardware is required, and therefore how much power that hardware consumes. The number and complexity of components in the architecture — controllers, drives, network equipment, management infrastructure — all carry power overhead. The refresh cycle of the platform determines how often new hardware is purchased, deployed, and powered up to replace hardware that is being retired, and that cycle has an energy cost too.

None of this means that all storage architectures are equal from an energy perspective, and the industry has started to reflect that awareness. Vendors are talking about watts per terabyte, IOPS per watt, rack density per effective capacity, long lifecycle upgrades, intelligent data reduction, disaggregated architectures, and designs that reduce the amount of hardware required to deliver a given outcome. Some of those claims will survive scrutiny better than others.

In enterprise technology, the tradition of every vendor winning their own benchmark is deeply honored, and I would read competitive comparisons with appropriate skepticism regardless of who is making them.

But the direction of the conversation is real, and it reflects a genuine shift in what efficiency means. For years, when data storage professionals talked about efficiency, the primary frame was capacity. How much usable storage could be extracted from a given amount of raw media, after deduplication and compression and thin provisioning? How many effective petabytes fit in a rack? How much could a customer defer buying by getting more from what they already had? Those questions are still valid, but they are no longer the whole story. The more complete question now includes how much useful work an architecture delivers per watt consumed, per rack occupied, per refresh cycle, and per operational hour. That is a different optimization target, and it implies different design decisions.

What I find interesting about the SPAN XFRA story, beyond the obvious novelty of it, is that it makes this constraint visible in a way that a data center planning spreadsheet does not. SPAN’s argument is essentially that grid interconnection for a large centralized data center can take four to seven years in some markets, and that building capacity faster requires finding power that already exists and is not being fully used. SPAN positions XFRA for inference workloads specifically, which makes architectural sense — distributed residential nodes cannot coordinate the way tightly coupled GPU clusters need to for large-scale training runs.

That distinction is worth sitting with, because it suggests something about where AI infrastructure is actually heading. The centralized hyperscaler datacenter is not going away. It is where the large training runs happen, where the enormous models are built, where the compute density is highest and the coordination requirements are most demanding. But inference, which the research suggests will account for the substantial majority of AI energy consumption by 2030, may be more distributed than the centralized model implies. And if inference can run at the edge of the grid, then the grid itself starts to look less like a constraint and more like an architecture.

That is where The Machine, as a metaphor, keeps coming back to me.

The Machine survived by understanding that centralization was not a permanent advantage. When centralization became a vulnerability, it distributed itself into the infrastructure that was already everywhere. It did not wait for someone to build it a better facility. It used what existed.

Whether or not the SPAN approach succeeds in the way the launch materials describe — and there are real questions about serviceability, security, hardware refresh logistics, regulatory considerations, and whether the economics hold outside of a controlled pilot — the underlying observation is sound. The demand for power to run AI infrastructure is growing faster than the traditional systems for building and connecting centralized power capacity can accommodate. That gap is real. Closing it requires looking at the infrastructure that already exists, including infrastructure that most enterprise IT conversations have historically treated as someone else’s problem.

For those of us who work in technology sales and pre-sales engineering, I think this means something specific about how we should be talking to customers. We have spent years getting comfortable with conversations that focus on performance, capacity, availability, recoverability, and cost. Those are still the right conversations. But underneath each of them, there is now a power dimension that is no longer optional to understand. When a customer asks whether a storage platform can support their AI workload, they are not only asking whether it is fast enough. They are asking whether it can feed their GPUs without wasting the power those GPUs need to do useful work. They are asking whether the physical footprint of the platform fits within the physical limits of their environment. They are asking whether the architecture will force them to consume more rack space, more cooling capacity, and more operational overhead than a better-designed alternative would require.

A customer with available power has architectural options. A customer who has run out of available power has to have a different conversation, and that conversation tends to be slower, harder, and more expensive than the original architecture conversation would have been.

That is probably the least glamorous lesson that AI has taught enterprise IT in the last few years.

Everything we thought we had abstracted away is still there.

The rack is still there. The cooling is still there. The power feed is still there. The transformer is still there. The grid interconnection timeline is still there. The heat is still there. The bill is still there. And the physical limits of the building where all of this has to actually work are still there, indifferent to how many times the strategy deck has been updated.

The irony of the last decade of enterprise IT is that we got very good at making infrastructure feel invisible. Cloud made it feel infinite. Virtualization made it feel flexible. SaaS made it feel like someone else’s concern. Storage efficiency made capacity feel almost elastic. Consumption models made hardware feel like a subscription. Even the language shifted toward things that do not have weight or heat or power requirements: fabrics, services, platforms, ecosystems, experiences, journeys.

AI walked back in and reminded everyone that underneath every layer of abstraction is still a physical system, and physical systems operate within physical constraints, and physical constraints do not negotiate with executive timelines.

The Machine eventually found power in the grid because it had no other choice.

Enterprise IT is finding something similar, not in utility boxes on street poles, but in the cumulative reality that there is no software release that makes a missing megawatt appear, no contract clause that relocates heat from a dense rack, and no roadmap presentation that makes a four-year grid interconnection queue shorter.

The architecture has to be right. The platform has to be efficient. The infrastructure has to respect the physics of the environment it lives in.

And the conversation about AI has to include the conversation about power, not as a footnote that facilities handles and everyone else ignores, but as a genuine design constraint that shapes every decision from the storage platform selection to the refresh cycle to the cooling strategy to the building capacity plan.

Because the machine still needs power.

And this time, unlike on television, there is no clever plot device that makes the constraint disappear.

There is only good architecture, or the absence of it.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Over the past several months, I have interviewed dozens of candidates for pre-sales systems engineering roles. Some were early in their careers, still learning how to tell their story. Others were seasoned professionals with long resumes, customer-facing experience, leadership exposure, and enough years in the business world to know how interviews usually work.

Out of all of them, only one sent a thank-you note after the interview.

One.

At first, I almost dismissed my own reaction. Maybe I was being old-fashioned. Maybe the post-interview thank-you note had quietly become one of those business traditions that aged out of relevance, like printed directions, fax cover sheets, or wearing a suit on an airplane. Maybe people no longer see it as necessary. Maybe recruiters are overwhelmed, candidates are applying to too many roles, and everyone has silently agreed that the interview ends when the Zoom window closes.

But the more interviews I did, the harder it became to ignore. This was not just a younger generation thing. It would be easy, and lazy, to turn this into another “kids these days” complaint, but that would miss the point completely. Some of the people who skipped the follow-up were experienced professionals. People who have been in customer meetings. People who have worked with executives. People who should understand that a professional conversation does not always end the moment the scheduled time is over.

And it was not only the missing thank-you notes.

I started noticing the way people showed up on camera. Again, I am not talking about suits and ties. I do not need anyone to perform some outdated corporate costume to convince me they are serious. But there is a difference between relaxed and unaware. There is a difference between casual and careless. When someone joins a professional interview in a T-shirt or sweatshirt, from a messy room, looking like the conversation interrupted something else they were doing, it sends a signal. Maybe not the signal they intended, but a signal nonetheless.

That is where this topic becomes more interesting than a simple complaint about manners.

Because I do not think business etiquette has simply disappeared. I think we are living through a strange transition where the old signals of professionalism are fading faster than the new ones have been clearly defined. The suit matters less. The formal email matters less. The perfectly structured follow-up matters less.

But respect still matters.

Preparation still matters.

Situational awareness still matters.

The ability to make another person feel that the interaction was worth your attention still matters.

The problem is that we used to package all of those things inside visible rituals. Dress a certain way. Write a certain way. Send the note. Use the formal greeting. Recap the meeting. Capitalize the sentence. Sign the email. None of those behaviors automatically made someone competent, but they were familiar indicators. They told the other person, fairly or unfairly, that you understood the environment you were in.

Now many of those indicators have been stripped away.

Some of that is good. The old version of professionalism had plenty of nonsense built into it. It often rewarded polish over substance and performance over authenticity. It confused stiffness with discipline and formality with competence.

Many people adapted and learned how to look professional without necessarily being thoughtful, prepared, accountable, or useful. They knew the costume, the vocabulary, the posture, and the email format, but not always the judgment behind it.

Remote work accelerated the collapse of that theater. Once we all started seeing each other in spare bedrooms, kitchens, basements, and home offices, the clean separation between the work self and the real self became harder to maintain. Dogs barked. Kids walked into the room. Doorbells rang. Wi-Fi failed. People took calls from cars, hotel lobbies, and kitchen tables. The polished corporate stage became a little more human, and in many ways, that was a healthy correction.

I am not suggesting we return to a world where someone’s professionalism is judged by whether they wear a jacket on Zoom or whether their email contains the correct number of corporate pleasantries. I do not think a candidate should be rewarded for sending a generic thank-you note that says nothing beyond “thank you for your time and consideration.” That kind of note is polite, but it is also forgettable. In some ways, it may even be worse than no note at all because it proves the person knows the ritual but did not put any real thought into it.

But I also do not think we should pretend that effort no longer matters.

That is the part that seems to be getting lost.

A thoughtful post-interview note is not about obedience. It is not about begging for a job. It is not about corporate brown-nosing. At its best, it is a continuation of the conversation. It gives the candidate one more chance to show that they listened, understood the challenges discussed, and connected their experience to the actual needs of the role. It is a small act, but small acts are often where judgment shows up.

The best follow-up does not need to be long. It does not need to sound like it was copied from a career advice website or was generated by an LLM. In fact, it should not. It should simply make the other person feel that the time spent together landed somewhere. It can be as simple as a sentence about something specific from the conversation, a clear restatement of interest, or a relevant thought that connects back to the business problem, the team dynamic, or the customer challenge discussed during the interview.

That is not old-fashioned.

That is professional.

The same thing applies to showing up on video. I am not asking for theater. I am asking for awareness. If you are interviewing for a role where you may represent the company in front of customers, partners, executives, or your own team, then how you show up in the interview matters because it gives people a small preview of how you may show up later. Not a perfect preview, but a useful one.

Nobody is expecting perfection. We all have real lives. Things happen. Cameras fail. Backgrounds are imperfect. But the person on the other side of the screen can usually tell the difference between someone who made an effort and someone who did not think effort was required.

That distinction matters more than the clothing itself.

This is where the broader shift in workplace etiquette becomes complicated. We are no longer arguing about whether people should follow the old rules. Many of the old rules deserved to be questioned. The better question is whether we are replacing them with anything meaningful.

I think the workplace has changed faster than our shared expectations have. Messaging tools have made communication shorter and more casual. AI tools now generate meeting summaries that sound useful but often miss the real texture of the conversation. Emails increasingly resemble text messages, with missing punctuation, lowercase sentences, and a tone that can be either friendly or careless depending on who is reading it. Younger workers often interpret formality as stiff or fake, while older workers may read casual communication as lazy or disrespectful. Both sides may be reacting honestly from their own frame of reference.

The result is not simply a decline in etiquette. It is a mismatch of signals.

A lowercase message in a team chat may feel warm and approachable to one person, while another person reads it as careless. A short Slack response may feel efficient to the sender, while the recipient experiences it as abrupt. An AI-generated meeting summary may appear to save time, but if it misses the customer’s hesitation, what was left unsaid, the political tension in the room, or the real owner of the next step, then it did not save time at all. It simply moved the work from human understanding to later cleanup.

That is one of the quiet risks in the modern workplace. We are automating the artifacts of professionalism without always preserving the judgment behind them.

A meeting recap was never just a record of what was said. A good recap showed what mattered. It confirmed alignment, documented assumptions and risks, clarified ownership, captured nuance, and gave people confidence that the conversation had been understood. It did not need to be long, but it needed to be thoughtful. When the follow-up becomes a transcript link, a generic AI summary, or a dashboard no one opens, the organization may feel more efficient while actually becoming less aligned.

The same is true with communication in general. Speed is useful only when it improves clarity. Casualness is useful only when it improves connection. Authenticity is useful only when it does not become an excuse for thoughtlessness.

That may be the new etiquette test.

Not whether you followed the old ritual exactly, but whether your behavior made the interaction easier, clearer, and more respectful for the other person.

That test applies across generations. It applies to candidates, managers, sellers, engineers, executives, and anyone else whose work depends on trust. In some situations, a quick message is enough. In others, a more careful note is required. Sometimes a sweatshirt on Zoom is completely fine. Other times, it may show that you misread the moment. Sometimes an emoji softens a message. Other times, it makes a serious topic feel unserious. Sometimes AI notes are helpful. Other times, they remove the very judgment that made the meeting valuable.

The skill is knowing the difference.

That is why I keep coming back to the thank-you note. Not because I am nostalgic for some older version of the workplace, but because it is such a simple example of the larger issue. The note itself is not the point. The instinct behind it is the point.

Did you notice the human being on the other side of the process?

Did you understand that an interview is not just a transaction?

Did you take one extra step to close the loop?

Did you reinforce the value you could bring, based on what was actually discussed?

In a customer-facing role, that instinct matters. In a leadership role, it matters even more. So much of business depends on the ability to read the room, follow up thoughtfully, and make people feel that their time and priorities were understood. Those are not decorative skills. They are operating skills.

This is where I think the conversation about modern professionalism needs to land. We do not need to bring back rigid corporate formality. We also should not lower the bar so far that every careless behavior gets excused as “I am just so busy.”

There is a better middle ground, but it requires being more explicit about expectations instead of assuming everyone grew up with the same unwritten rules.

The old world often asked people to look professional. The new world should ask people to act with professional judgment.

That is a better standard, but also a harder one. Looking the part can be taught quickly. Judgment takes longer. It requires understanding context, audience, timing, and impact. It requires knowing when to be informal and when to slow down. It requires recognizing that the same message can land differently depending on the recipient, the situation, and the stakes.

It also requires humility from those of us who grew up with the older rules. Not every change is a decline. Not every casual message is disrespectful. Not every missing capital letter means the person is lazy. Not every candidate who skips a thank-you note is unqualified. Some of the old expectations were arbitrary, exclusionary, or simply inefficient.

But humility should go both ways.

Not every tradition is empty. Not every professional courtesy is outdated. Not every expectation of preparation is performative. Some rituals survived for a reason because they helped people signal respect before trust had been fully built.

That is really what etiquette does at its best. It gives people a way to create trust in moments where trust is still forming.

An interview is one of those moments.

A first customer meeting is one of those moments.

A difficult internal conversation is one of those moments.

A follow-up after a meeting where commitments were made is one of those moments.

In those situations, professionalism is not about pretending to be someone else. It is about being aware that the other person is deciding, consciously or not, whether they can trust you with something important.

That is why I still notice the missing thank-you note.

Not because I need to be thanked.

Because I am paying attention to whether the candidate is paying attention.

There is a difference.

Professionalism did not die; it just stopped wearing a tie.

And now we have to be much more intentional about what replaces it.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

This afternoon, I had the privilege of watching the U.S. Navy Blue Angels fly over Annapolis, Maryland during U.S. Naval Academy Commissioning Week for the Class of 2026.

The day started with a partner event, which feels like the right place for this short story to begin. We spent the morning talking about the things we always talk about in business when the conversation is good: customers, relationships, execution, trust, strategy, and how to make sure partnerships actually create value instead of just creating more meetings.

Then, later in the day, we got on a boat and headed out onto the water to watch the show.

That sounds calm and almost vacation-like, but Annapolis during Commissioning Week is not exactly a quiet little cove where you accidentally catch a fish and pretend you knew what you were doing. There were boats everywhere. People were looking up before there was even anything to see. Phones were ready. Kids were pointing at every sound in the distance. Adults were pretending to be composed, which lasted about as long as you would expect.

Then the Blue Angels arrived, and whatever conversation was happening on the boat simply stopped.

What makes the Blue Angels so breathtaking is not just that they fly fast. Lots of machines can go fast.

It is the combination of speed, proximity, engineering, preparation, and human judgment happening all at once.

The team flies the Boeing F/A-18 Super Hornet, a twin-engine, carrier-capable fighter aircraft built for missions that include air superiority, fighter escort, reconnaissance, aerial refueling, close air support, and precision strike. It is not a prop for an airshow. It is a serious piece of naval aviation engineering, adapted for demonstration flying but rooted in combat aircraft design.

During a Blue Angels demonstration, the fastest maneuvers reach roughly 700 mph. Their slowest maneuvers can be around 120 mph. Some passes happen as low as 50 feet above the water. The diamond formation can fly as close as 18 inches apart. Not 18 feet. Eighteen inches. Less than the width of a carry-on suitcase, between aircraft moving at speeds where most of us would struggle to keep our coffee from becoming a cockpit incident.

There are certain things that make you feel small in the best possible way. A mountain range can do it. The ocean can do it. Standing in a stadium during the national anthem can do it. Watching seven aircraft carve across the sky over Annapolis at speeds that do not feel like they belong in normal human experience can absolutely do it.

But what surprised me was how the feeling kept building.

The first flyover gave me goose bumps. That would have been enough. The sound hit first, then the aircraft appeared, then they were gone almost before my brain could catch up. Everyone on the boat reacted at once, in that strange way people do when something is too impressive for normal words.

Then came the next pass, and somehow the goose bumps got bigger.

I did not invert this image, this is a real picture of the flyover at about 150 feet over my head.

By the third flyover, I realized I was not just reacting to the noise, the speed, or the precision. There was a deeper feeling underneath it. Pride is probably the closest word, though even that feels a little too small. Not the performative kind of pride people sometimes manufacture for social media captions, but the kind that starts in your chest before your brain has time to organize it into language.

It was pride in the aviators, of course, but also in the ground crew, the mechanics, the planners, the standards, the Naval Academy, and the young men and women walking through Commissioning Week and into service. It was pride in watching something done with that much commitment and discipline. It was pride in seeing excellence that could not be faked.

Because that is what struck me most.

The show looked effortless from the water, but nothing about it was casual. Every turn, every formation, every pass over Annapolis represented thousands of hours of preparation compressed into a few seconds above our heads. The public sees the aircraft. We hear the engines. We feel the sound in our chest. We take the pictures.

But what we are really watching is trust made visible.

And that is where my mind went back to the partner event from earlier in the day.

Not because business is the same as naval aviation. It is not. Not even close. Our jobs are not life and death, and I do not want to cheapen what those pilots and crews do by pretending the stakes are comparable.

But maybe that is exactly why the lesson matters.

If trust, preparation, discipline, honesty, standards, and personal integrity are non-negotiable when the stakes are that high, why do we sometimes treat them as optional when the stakes are “only” business?

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

This past Saturday, my wife and I sat at my son’s college graduation ceremony doing what every proud parent does after running out of tears and tissues: staring at the giant screen, scanning a crowd of thousands, and playing a very emotional, very expensive version of Where’s Waldo?

The camera pulled back and showed the graduating class. Thousands of caps. Thousands of gowns. Thousands of people who had just survived exams, group projects, late-night studying, bad cafeteria decisions, emotional phone calls home, and whatever personal version of “I’ll start the paper tomorrow” they subscribed to. Somewhere in that sea of mostly identical academic robes was my son.

I knew he was there. We had dropped him off at college years earlier, paid tuition, bought supplies, endured move-in day, survived the separation anxiety, worried about him, cheered for him, and occasionally pretended to be calmer than we actually were. I knew exactly why we were in that room.

But on that screen, in that moment, he was just one face among thousands.

So I started searching for him. Every parent around me was probably doing some version of the same thing. We were not looking at a graduating class in the abstract. We were looking for our graduate. Everyone else on that screen mattered deeply to someone, but to us they were mostly context without identity: a massive, moving, emotional dataset with almost no metadata attached.

That was the strange thing about the picture.

It showed us everything and told us almost nothing.

There were thousands of people on the screen, but unless you already knew who you were looking for, you did not really know what you were looking at. Somewhere between the pride, the camera angle, and my increasingly poor performance at parental facial recognition, my brain did what my brain unfortunately does. It connected a very human moment to the way enterprises think about data.

Because this is exactly the problem most organizations have with their data.

They know it is there. They know there is a lot of it. They know some of it is incredibly valuable, some of it is probably risky, and some of it is duplicated, outdated, forgotten, regulated, misplaced, or being accessed by people and systems nobody has thought about in years. But knowing there is a crowd is not the same thing as knowing who is in it.

That is the part we do not talk about enough.

For years, data management conversations were mostly about where the data lived, how it was protected, how fast it could be accessed, and how much it cost to keep it all running.

Those things still matter. They will always matter. But they are no longer enough.

The new question is not simply, “Where is the data?”

The better question is, “What is this data, who does it belong to, why does it exist, who is using it, where has it moved, what risk does it carry, and should this AI model, business process, analyst, application, or employee be touching it at all?”

That is a very different conversation, and that is why 1touch matters.

Not because the industry needed one more product logo, one more acronym, or one more keynote phrase that sounds important until everyone quietly admits they are not exactly sure what it means. 1touch matters because it is aimed directly at the problem of not knowing.

The lie of visibility

Most organizations believe they have visibility into their data because they have tools that can show them infrastructure. They can show arrays, volumes, file systems, buckets, databases, dashboards, latency charts, replication status, backup jobs, snapshots, anomalies, alerts, and the occasional red icon that ruins someone’s morning.

All of that is useful. None of it guarantees understanding.

An IT team can tell you a volume is 87 percent full, but that does not mean they know it contains expired customer records, old HR exports, forgotten underwriting files, production data copied into a test environment, or a spreadsheet with 40,000 Social Security numbers created in 2018 by someone who left the company three reorganizations ago.

A security team can tell you an alert fired, but that does not mean they know whether it represents real exposure, a false positive, or just another noisy event in a pile nobody has enough hours to investigate. A data team can point to a lake, a warehouse, a catalog, and a governance process, but that does not mean the data is clean, trusted, current, properly classified, or safe to feed into an AI workflow.

This is the uncomfortable truth: enterprise data visibility has often meant visibility into containers, not contents.

We could see the auditorium. We could count the very uncomfortable seats. But we still could not tell which graduate was my son.

The graduation screen was not useless. It showed scale. It proved the event was real. It helped me understand the crowd. But until I could identify the person I cared about, the picture was incomplete.

Enterprise data estates work the same way. The problem is not that organizations have no tools. They often have too many. The problem is that many tools see the surface of the environment but miss the identity, relationship, movement, and meaning of the data inside it.

That gap was inconvenient in the old world. In the AI world, it is dangerous.

AI does not forgive ignorance

Before generative AI entered every boardroom conversation, the consequences of not knowing your data were already serious: compliance exposure, bloated infrastructure costs, security blind spots, slow audits, manual discovery, painful legal requests, cloud migration delays, and business users waiting weeks for access to information because nobody could confidently say what was safe to use.

Then AI showed up and made the problem louder.

AI feeds on data. Lots of it. Structured data, unstructured data, documents, emails, transcripts, PDFs, customer records, logs, knowledge bases, support case histories, SaaS exports, file shares, objects, and anything else that might help a model answer a question, summarize a situation, automate a workflow, or make a decision.

That sounds exciting until you remember that most enterprises do not fully know what is in all of those places.

And AI is not magic. If the input is wrong, the output inherits that problem. Sometimes the model hallucinates. Sometimes it exposes something it should not. Sometimes it makes a recommendation based on data that was never supposed to leave a specific jurisdiction. Sometimes it answers confidently from a document that was obsolete three policies ago.

Sometimes it gives the right answer to the wrong person, which may be the scariest version of all because the technology can look like it is working while quietly violating the trust model of the business.

That is why “AI-ready data” cannot simply mean “we pointed a model at a repository.” That is not readiness. That is hope with an API call.

AI-ready data needs context. It needs classification, identity, policy, and confidence. It needs a way to distinguish between a harmless document, a restricted record, a regulated attribute, an exposed credential, and a data fragment that only becomes sensitive when connected to other fragments somewhere else.

A number or a name by itself may not mean much. A location, transaction, or timestamp by itself may not mean much either. But connect the number to the name, the name to the patient record, the patient record to a geography, the geography to a regulation, the regulation to a storage location, and the storage location to an access path, and suddenly you are not looking at random data anymore.

You are looking at risk. Or value. Often both.

This is where 1touch becomes important, because its value is not just identifying patterns and sticking labels on files. Its value is in discovering, classifying, and contextualizing data across environments so organizations can understand not only what exists, but what it means.

That distinction matters.

The difference between labeling and knowing

At graduation, every student had the same basic label: graduate. That label was accurate, but it was wildly insufficient.

One graduate may be heading to medical school. Another may be joining a startup. Another may be the first person in their family to earn a degree. Another may have worked two jobs to get there. Another may have changed majors three times and somehow still finished on time, which frankly deserves its own medal.

The label tells you the category. The context tells you the story.

Data works the same way. A traditional tool might identify something that looks like a credit card number, Social Security number, email address, medical code, account number, or passport field. That is useful, but it can also create noise. Strings of digits appear everywhere. Test data looks real. Real data looks fake. A file name can lie. A folder path can be misleading. A database column called “ID” might be harmless, or it might be the key to everything.

Context is what turns a guess into intelligence.

1touch approaches this problem by looking at the broader semantic environment around the data. It is not just asking, “Does this pattern match something sensitive?” It is asking, “What surrounds it? What system did it come from? Who accesses it? Where does it move? What other data is connected to it? What business process does it support? What regulatory meaning does it carry?”

That matters because in the real world, data risk rarely lives in a single isolated field. It lives in relationships.

The same way my son was not immediately identifiable to the room because he was wearing a cap and gown like everyone else, sensitive enterprise data is often not obvious because it is dressed like everything else. It sits in file shares, databases, cloud repositories, SaaS platforms, mainframes, archives, exports, and forgotten project folders. It blends into the crowd.

The old approach was to scan the crowd every so often and hope you recognized enough faces. The newer requirement is continuous understanding: discovering data where it lives, watching how it moves, connecting fragments across systems, and building a living map of identity, access, classification, and risk.

Not a once-a-year inventory. Not a spreadsheet. Not a governance theater exercise where everyone nods in a meeting and then goes back to copying production data into development because the test system “needed something realistic.”

A living map.

That is the real promise.

Why this matters

The value of 1touch can be easy to undersell if we describe it only as sensitive data discovery or Data Security Posture Management (DSPM). Those descriptions may be accurate, but they are not the business problem.

A prospect is not waking up hoping to buy a classification engine. They are waking up with pressure from the board, auditors, regulators, cyber insurers, application owners, AI initiatives, cloud migration teams, and business leaders who want faster access to “clean” data without increasing risk.

And for those of us who have been around this industry long enough to have a few emotional support scars, this problem is not new. We were talking about lifecycle data management and data classification projects 20 years ago. Kazeon, StoredIQ, and others were all trying to help customers understand what was hiding inside their unstructured data environments before the phrase “dark data” became a fashionable way to describe a very unfashionable mess.

I personally used Kazeon back in 2006, before EMC acquired it and eventually killed it EMC Acquires Kazeon 2009. The idea was right. The experience was painful.

I remember a project where it took almost two months to scan the environment, process the results, and prepare the report. We finally sat down with the customer, proudly showed them the findings from roughly 5TB of unstructured data, and waited for the moment where they would appreciate all the classification goodness we had brought into their lives.

Instead, the customer looked at us and asked the only question that mattered:

“Where is the rest of my 55TB?”

There are moments in a technical meeting when the room temperature changes without the thermostat being involved. This was one of them.

Apparently the tool did not have permissions to scan the rest of the environment. So after two months of work, the result was technically accurate and practically incomplete, which is the most dangerous kind of confidence. We had a report. We had charts. We had findings. What we did not have was the whole truth.

That is why this matters now. The enterprise data problem did not begin with AI. AI simply made the consequences of incomplete understanding much harder to ignore. Twenty years ago, a bad classification project meant a frustrated customer, an awkward meeting, and a lot of manual cleanup. Today, the same kind of blind spot can contaminate an AI pipeline, expose regulated data, break a sovereignty policy, delay a migration, or give executives a false sense of security.

For existing customers, the value is even more strategic. They already trust the platform to store, protect, move, and serve their data.

The next logical question is whether it can help them understand the data as well.

That is the bridge 1touch helps build.

That is important because customers are tired of stitching together disconnected tools where one product sees storage, another sees identity, another sees security events, another sees data catalogs, another sees cloud posture, and another sees compliance workflows. Everyone sees something, but nobody sees enough.

Customers do not need more fragmented visibility. They need connected context.

Most importantly, it helps us explain why the conversation has moved from where data sits to what the data actually means.

Back to the screen

Eventually, during the ceremony, I found my son. Definitely when his name was announced and he walked across that stage. That was the moment all the pride (mixed with tears of joy), worry, and years of parenting caught up with me.

But the moment stayed with me because it was such a simple reminder: seeing a crowd is not the same as knowing the people in it.

Every person on that screen had a story, a history, a family somewhere in the stands trying to yell the loudest, and a future that was about to begin. From a distance, they looked identical. Up close, they were anything but.

Enterprise data is like that too. From a dashboard, it can look like capacity, files, objects, tables, volumes, buckets, repositories, shares, records, and logs. But inside that data are customer identities, patient histories, citizens tax records, contracts, intellectual property, employee information, business secrets, stale copies, duplicate exports, forgotten archives, useful insights, hidden risks, and the raw material for the next generation of AI-driven business processes.

The organizations that win will not be the ones that simply store the most data.

They will be the ones that know what their data means.

That is why 1touch matters.

Because the future of data management is not just finding Waldo.

It is understanding the entire crowd.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

In Part 1, I tried to give MCP a proper “…splanation,” mostly because the first several times I heard people talking about Model Context Protocol, I had the same look Joey had in Friends when the salesman asked him if his friends ever had a conversation and he just nodded along without really knowing what they were talking about.

That was me.

MCP this. MCP server that. Agentic AI. Tool calling. Context windows. Protocols. Hosts. Clients. Servers. At some point, I realized I was nodding with the confidence of a man who had understood approximately 41% of the conversation and was hoping nobody asked a follow-up question.

The simple version is this: MCP is a standard way for AI applications to connect to tools and data. It is not the AI model itself. It is not the magic brain. It is the plumbing that lets the AI reach into approved systems, ask better questions, retrieve useful context, and potentially take action through well-defined tools.

That is important in the abstract.

But for Everpure customers and prospects, it becomes much more interesting when we stop talking about MCP as a general AI concept and start talking about what it could mean for storage operations, data infrastructure, and Everpure Fusion.

Because this is where the conversation moves from “AI is coming someday” to “your infrastructure may already need to be ready for how AI will interact with it.”

Everpure recently published a blog with a sneak peek of the Everpure Fusion MCP Server, describing it as an open-source service that connects AI assistants to Everpure Fusion storage fleets through the Model Context Protocol. The important part is not simply that an AI assistant can talk to storage. That would be interesting, but it would also be easy to misunderstand. The important part is that the assistant can interact with the storage environment through the Fusion control plane, which already understands fleet-wide context across FlashArray and FlashBlade.

That distinction matters.

Without Fusion, many environments are still managed in a way that looks very familiar to anyone who has spent time supporting infrastructure. One array over here. Another array over there. Scripts in one folder. Notes in another. Naming standards that started strong and then apparently met reality. Screenshots in tickets. Tribal knowledge in the heads of a few people who somehow remember which workload lives where, which array is doing what, and why nobody should touch that one volume because “there was a reason,” even if nobody is entirely sure what the reason was anymore.

That model may work, but it does not scale gracefully. More importantly, it is not especially friendly to automation, and it is definitely not ideal for AI-assisted operations.

Most troubleshooting in mature environments is not hard because people lack tools. It is hard because the context is not immediately obvious.

The storage admin has one view. The DBA has another view. The virtualization team has another view. The application owner has a completely different view, usually delivered through a ticket that says something deeply scientific like “the app feels slow.” Everyone may be looking at a valid piece of the puzzle, but the real work is in the correlation.

Which volume maps to which workload? Which array is hosting it? What did latency look like during the reported window? Were IOPS elevated? Was bandwidth constrained? Did anything change recently? Are we looking at a storage issue, a database issue, an application issue, a noisy neighbor, a misconfigured VM, a bad query, or just another case of “the network is innocent until proven guilty, but still somehow looks suspicious standing there”?

That is where Fusion and MCP together become compelling.

The Everpure Fusion MCP example makes the idea real. Instead of forcing an administrator to manually build low-level REST API calls or jump between tools, the MCP-aware AI assistant can query Fusion through higher-level tools exposed by the MCP server. In the example Everpure blog described, a storage admin can ask about workloads and volumes supporting a production SQL environment, including arrays, IOPS, latency, and bandwidth over a recent time window. The assistant can then correlate that storage perspective with information from another MCP server, such as SQL Server context around database files, wait types, and query behavior.

That does not mean the AI replaces the storage admin. It does not mean the AI replaces the DBA. It does not mean everyone goes to lunch while the robot fixes production.

And this is where I need to bring in The Big Bang Theory again, because apparently this is who I am now.

There is a scene in the show where Raj is very open to the idea of aliens and extraterrestrial life. At the planetarium, Raj can look at flashes of light in the sky and talk about how scientists cannot fully rule out the possibility of alien civilizations. It is funny because Raj is a scientist, but he is also Raj, so the line between rigorous possibility and “maybe the aliens are waving at us” gets wonderfully blurry.

That is how some people talk about AI operations right now.

A light flashes in the sky, and suddenly someone is ready to announce that the robots are here to run the data center.

Let’s not do that.

The point is not that the AI is an alien civilization arriving to take over infrastructure operations. The point is that the interface is changing. The way humans interact with infrastructure is starting to move from manual lookup, command execution, and tribal knowledge toward assisted reasoning, guided action, and cross-system correlation.

That is much more practical than aliens.

It is also much more useful.

Fusion already gives customers a fleet-wide control plane. It gives you the ability to think above individual arrays, above one-off configuration, and above the old habit of managing infrastructure like every system is its own little island with its own weather pattern. MCP gives that control plane another interface, one designed for the way AI agents work.

This is why Fusion adoption matters.

If your environment is still managed mostly array by array, script by script, ticket by ticket, and screenshot by screenshot, then AI can only help so much. It may summarize the pain beautifully, but it is still summarizing pain. When you use Fusion to create a more consistent, policy-driven, fleet-aware operating model, you are not just modernizing storage management. You are making the environment more understandable to automation, to operations teams, and now to AI agents that need structured context in order to be useful.

That is a very different conversation from “look, the AI can query storage.”

The better conversation is this: if AI is going to become part of operational workflows, then your infrastructure needs to be ready to participate in those workflows. Fusion is one of the ways you prepare for that.

Not someday.

Now.

And Fusion is not the only example of this direction. Another Everpure technical article shows how an MCP server can be built to integrate with FlashBlade, allowing an AI assistant to query system data and even take direct actions through a natural-language interface. That example is useful because it shows the bridge between the old world and the new one. In the old world, storage management often meant CLI commands, scripts, API calls, screenshots, and specialized knowledge living in the heads of a few very tired people. In the new world, those capabilities can be surfaced through an AI-assisted experience that understands the available tools and can help operators ask better questions in plain English.

Again, that does not mean the AI should blindly run your infrastructure while everyone disappears. Please do not read this article and tell your change advisory board that “the blog guy said the robot can handle it.” That is not the point, and I would like to remain welcome in polite infrastructure society.

The point is that the operational model is changing.

For years, we have talked about automation in infrastructure, but a lot of what we called automation still required a human to know exactly what to automate, where to look, which command to run, which script was safe, which API endpoint mattered, and which piece of documentation had not quietly aged into fiction. AI-assisted operations changes the interaction pattern. Instead of always beginning with the operator knowing the exact command or API call, the operator can begin with the question.

Those are the kinds of questions humans actually ask when something is happening. MCP gives AI assistants a standard way to ask approved systems for the data behind those questions. Fusion gives the storage estate a more consistent, policy-aware, fleet-level way to answer.

That combination is where the opportunity lives.

Now, because this is enterprise technology and not a children’s book, we also need to talk about the dangerous part. One of the readers posted this comment on Linked in yesterday:

The moment an AI system can access tools and data, the conversation changes. A chatbot that gives a bad answer is annoying. An agent that takes the wrong action in a business system can become a real incident. If a model can read sensitive files, query databases, send messages, modify records, trigger workflows, or touch infrastructure, then security is not a feature. Security is the premise.

This is where some of the MCP enthusiasm needs adult supervision.

We have spent years telling users not to click strange links, not to approve unknown applications, not to reuse passwords, and not to download random files. Now we are building systems where an AI assistant might read strange content, call external tools, and act on behalf of the user. That can be incredibly powerful, but only if we are honest about the risk.

In some ways, MCP may expose organizational problems faster. If your data is scattered, stale, contradictory, or politically curated, an AI agent connected to it will not magically produce truth. It may simply produce a more polished version of the confusion. If your workflows are unclear, connecting AI to them may help automate the ambiguity, which is not quite the same thing as progress.

The model can gather information, call tools, and complete steps, but people still need to define what should happen, what should not happen, what requires approval, and what good looks like.

For Everpure customers and prospects, the more important question is not whether MCP is interesting. It is whether your environment is ready for this kind of interaction.

That is where I would encourage customers to take a serious look at Fusion.

Not because Fusion is another checkbox on a feature list, and not because every new technology conversation needs to end with someone saying “platform” three times into a mirror. Fusion matters because it changes the operational model. It gives you a way to manage data infrastructure as a fleet, with policy, consistency, automation, and context. Those are exactly the things AI agents need if they are going to do more than produce nicely formatted guesses.

If you already met all the prerequisites (Purity 6.8.+, LDAP enabled), use it. Explore it. Get comfortable with it. Stop thinking about Fusion as something reserved for a future automation project after everyone finally gets through the current list of fires, renewals, upgrades, and meetings that should have been emails.

MCP may be the plumbing that helps AI connect to the enterprise.

Fusion helps make the storage environment worth connecting to.

And that is the real call to action.

Fusion is how Everpure customers make sure their data infrastructure is ready for it.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

My two favorite sources are Friends and The Big Bang Theory, which probably says something about me that I am not emotionally prepared to unpack in public.

There is a scene from Friends that has lived rent-free in my head for years, mostly because it captures something deeply human and mildly embarrassing. A salesman is talking to Joey and asks him a question that is both funny and a little too accurate: “Let me ask you one question. Do your friends ever have a conversation and you just nod along even though you’re not really sure what they’re talking about?”

Joey, of course, immediately zones out. Not metaphorically. Not politely. He disappears into that wonderful Joey place where the mouth stays closed, the face stays agreeable, and the brain has clearly left the building.

That was me the first few times I started hearing people talk about MCP.

Not once. Not twice. Everywhere. MCP this. MCP server that. MCP is the future of agents. MCP is the USB-C of AI. MCP is how models connect to tools. MCP is the protocol that will make agentic AI real. MCP is the standard. MCP is the integration layer. MCP is the thing everyone apparently understood already, except somehow nobody had bothered to send me the memo.

So I did what any responsible technology professional does in that situation. I nodded thoughtfully.

The next thing I did was call my son, who is a Data Scientist, and ask him what MCP actually was. After listening to his explanation, I had the uncomfortable realization that he knew more about it than I did, which, naturally, did not feel great. That was just my ego talking, of course. He is way smarter than me.

Then I went away and tried to figure out whether MCP was actually important or whether it was just another acronym that had wandered into the AI conversation wearing a conference badge.

And that brings me to the other sitcom line that kept popping into my head while I was trying to explain this to myself. In The Big Bang Theory, there is a scene where a very drunk Penny says, “I think I owe you …splanation,” clearly attempting to say ‘explanation’ while her brain and mouth are no longer managed by a ‘unified control plane.’

That is exactly how MCP felt to me at first.

I did not need another acronym. I needed a …splanation.

A real one. Preferably in English. Preferably without requiring a PhD in distributed systems, three browser tabs of developer documentation, and someone on YouTube drawing boxes and arrows while saying “obviously” before explaining the least obvious thing I had heard all week.

So this article is my attempt at that …splanation.

After spending time researching MCP, I think it is important. More importantly, I think it is important in a very practical way. It is not the kind of important that requires everyone to become an AI researcher, read white papers at midnight, or pretend that “agentic workflow orchestration” is something normal people say at dinner. MCP matters because AI is moving from something that talks to something that can actually do work, and doing real work requires access to real systems.

That is the part worth slowing down for.

Most people first experienced modern AI as an LLM chat bot window. You typed something in, and the model responded. Sometimes the answer was impressive. Sometimes it was useful. Sometimes it was wrong with the confidence of a man giving directions in a city he has never visited. But the basic pattern was easy to understand. You asked a question. The LLM answered. That was the product experience.

The problem is that most real work does not happen inside a blank chat box. Real work lives in messy places. It lives in documents, calendars, databases, code repositories, CRM systems, ticketing tools, emails, Slack messages, service logs, storage platforms, cloud consoles, spreadsheets, procurement systems, and all the other places where business reality hides after the meeting ends.

That is why the first wave of AI, as magical as it felt, was also strangely trapped. A model could write a beautiful summary of a business problem, but unless you gave it the actual business context, it was still guessing.

An LLM is not programmed to say “Sorry, I don’t know.” So it makes stuff up with proper grammar and punctuation.

It could explain how to troubleshoot an issue, but unless it could inspect the logs, check the configuration, or look at the environment, it was still operating from theory. It could tell you how to prepare for a customer meeting, but unless it could see the account history, the open opportunities, the support cases, the renewal status, and the meeting notes from last quarter, it was basically giving you a very articulate horoscope.

MCP is one of the attempts to fix that.

MCP stands for Model Context Protocol.

The name sounds like it was assembled by people who are very good at distributed systems and very bad at naming things for humans, but the words are actually useful. “Model” refers to the AI model. “Context” refers to the information and tools the model needs in order to be useful. “Protocol” means a standard way for systems to communicate.

In plain English, MCP is a standard way for AI applications to connect to external tools and data sources.

That may sound boring, but boring is often where the real technology changes happen. Nobody gets a standing ovation for plumbing until the plumbing stops working. Nobody thinks about electrical standards when they plug in a night light. Nobody wants to understand every detail of networking just to open a website. Standards become invisible when they succeed, and that invisibility is exactly why they matter.

The analogy people use is that MCP is like USB-C for AI. I know that analogy is already dangerously close to becoming a bumper sticker, but it works well enough if we do not abuse it. USB-C did not make your laptop smarter. It did not make your monitor more creative. It did not make your phone more emotionally available, although at this point I would appreciate it if mine at least tried.

What USB-C did was standardize connection. Instead of every device requiring its own special cable, adapter, dongle, ritual, and small sacrifice to the drawer of dead electronics, USB-C created a common interface.

MCP is trying to do something similar for AI. It gives AI applications a common way to connect to the tools and data they need. The model does not need to know the internal details of every application. The application does not need to build a completely different integration for every model. MCP creates a shared language in the middle.

That middle layer is what matters.

Without something like MCP, the AI world runs into what technical people call the N-by-M problem. Katie Baker wrote about it last year: NxM Problem

If you have ten AI applications and ten systems they need to connect to, you do not want one hundred custom integrations. If you have fifty AI applications and two hundred systems, you definitely do not want ten thousand custom integrations, unless your business model is selling painkillers to integration teams.

The better model is not N times M. It is closer to N plus M. Each AI application learns how to speak the protocol. Each tool or data source exposes itself through the protocol. Once both sides understand the same standard, the number of custom connections drops dramatically.

This is the point where MCP starts to become more than an AI developer convenience. It starts to look like infrastructure.

To understand how it works, you do not need to become a protocol engineer. You just need to understand three roles: the host, the client, and the server.

The host is the AI application the user interacts with.

That could be Claude Desktop, ChatGPT, Cursor, Visual Studio Code, or an internal enterprise assistant with a name like Atlas, Navigator, Compass, or whatever else the branding team selected after eliminating “Dave.” The host is where the experience lives. It is where the user types the request, where the model reasons, and where the answer or action comes back.

The client lives inside the host and manages the connection to an MCP server.

You can think of it as the part of the application that knows how to speak MCP on behalf of the model. It handles the conversation between the AI application and the external capability.

The server is the wrapper around a data source.

There might be an MCP server for GitHub, another for Slack, another for a database, another for a filesystem, another for a CRM, another for a cloud service, and eventually one for every system that vendors decide must now be described as “AI-ready” in a press release.

The server’s job is to expose what it can provide in a way the AI application can understand. It might say, in effect, “Here are the documents I can make available. Here are the actions I support. Here is the format you need to use if you want to call one of those actions. Here are the permissions required. Here is the result you can expect back.”

That is where the value appears. The AI application does not need to understand every internal detail of GitHub, Slack, Salesforce, Postgres, Kubernetes, or your company’s deeply loved but spiritually exhausted internal ServiceNOW ticketing system. It needs a standard way to discover and use the capabilities exposed by those systems.

MCP gives it that standard way.

The protocol itself is built around a few core ideas that are easier to understand than the terminology makes them sound. MCP servers can expose tools, resources, and prompts.

Tools are actions the model can ask to perform.

A tool might search a database, send a Slack message, create a support ticket, run a test, update a CRM record, query an API, or retrieve the status of a system. Tools are where the AI starts moving from “I can answer your question” to “I can help complete the task.”

Resources are information the model can read.

These could be files, documents, schemas, database records, logs, API responses, or other pieces of context. Resources matter because AI without context is mostly a very confident intern on the first day of work. It may be talented, it may be fast, and it may be enthusiastic, but it does not know where anything is.

Prompts are reusable instructions or workflows.

That sounds small, but it is not. In business, consistency matters. You may not want every user inventing their own version of “analyze this account,” “review this code,” “summarize this incident,” or “prepare this forecast update.” A prompt can define how a model should approach a task, what standards it should follow, what inputs it should consider, and what kind of output is expected.

Tools let the model act.

Resources give the model context.

Prompts help shape the model’s behavior.

That combination is what makes MCP useful.

Let’s make this practical. Suppose you ask an AI assistant to help prepare you for a customer meeting. Without access to your systems, the assistant can give you a generic meeting prep template. It can tell you to understand the customer’s goals, review previous discussions, identify risks, prepare discovery questions, and align to business outcomes. None of that is wrong. It is also not especially magical. It is the kind of advice that sounds helpful until you realize it could apply to almost any meeting with almost any customer in almost any industry.

Now imagine that same assistant has controlled access to the right systems through MCP servers. It can read the meeting notes from prior briefings, pull the current opportunity data, review support tickets, check the renewal timeline, inspect open technical issues, summarize the customer’s stated initiatives, and identify where the account team may be telling itself a story that is more optimistic than the facts support. It can then generate a briefing that is not generic at all. It is specific, grounded, and useful.

That is the difference between AI as a writing assistant and AI as a work assistant.

This is why MCP keeps showing up in conversations about agents. An agent is not just a chatbot with a better title. An agent is expected to reason through a goal, choose tools, gather information, take steps, observe results, and continue until the task is complete or until it needs human help. That requires a standard way to connect reasoning to action.

MCP is one of the strongest candidates for that standard layer.

This is also where the MCP conversation stops being abstract for anyone running Everpure Fusion.

It is one thing to say that MCP allows AI agents to connect to enterprise systems. That sounds interesting, but it can still feel like one of those technology ideas that lives safely inside a product roadmap, an architecture diagram, or a conference session where the coffee is somehow both expensive and terrible.

It becomes much more practical when you look at what Everpure is doing with the Everpure Fusion MCP Server. I can almost guarantee that you will not click the link below, so I read it for you. But that will be in Part 2. I already drafted it, but I want to be respectful of your time. Not all of my readers are Everpure customers (yet).

So that is my MCP “…splanation,” at least the Part 1 version. MCP is not the robot, and it is not the magical brain that suddenly makes every workflow intelligent. It is the standard connection layer that helps AI move from “I can answer your question” to “I can interact with the systems where your work actually happens.” That may not sound glamorous, but neither does plumbing, electricity, networking, or storage until something important depends on it. And that is why MCP matters. Because the next phase of AI will not be defined only by which model sounds the smartest in a chat window. It will be defined by how safely, consistently, and usefully those models can connect to real tools, real data, and real workflows.

In Part 2, I will bring this closer to home and look at what this means for Everpure Fusion, because once AI starts needing context from infrastructure, the way we manage that infrastructure starts to matter a lot more.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Last week I was in a meeting with an executive in New York City. We were talking about people, goals, strategy, and the value of data. At one point my Apple Watch buzzed on my wrist and I gave it a quick glance. I know how rude it is to look at your phone while meeting someone, but the watch is more like checking the time, right? That was the whole selling point in the early days when Apple released it in 2015.

The executive I was meeting with looked me in the eye and asked: “Is there something more important than this conversation right now?” The honest answer: “Of course not.”

Thinking about his question, and constantly thinking about things I want to write about, I figured: “Ooh, I am going to write my next post about the Apple Watch!”

That would have been the easier version to write, because gadgets are easy to blame. We love doing that. We blame the phone for distraction, the email inbox for anxiety, the app for bad habits, the algorithm for whatever piece of ourselves we are no longer fully in control of.

The truth is, the Apple Watch did not ruin anything for me. It did what it was designed to do, and for a very long time, it did it exceptionally well.

It helped me move more. It made me more aware of how long I sit on Zoom calls when my calendar turns into a game of corporate Tetris.

It reminded me to stand. It encouraged me to exercise. It gave me a simple visual language for something I already knew mattered but did not always prioritize: movement.

At first, the rings were harmless. Helpful, even. A small nudge. A little structure. One of those modern conveniences that makes you wonder how people managed before everything on earth became a dashboard.

Then, slowly, almost politely, the relationship changed.

That is the part I keep coming back to, because there was no dramatic moment where the watch crossed some obvious line. It did not become evil. It did not suddenly grow a personality and start whispering threats from my wrist. It just kept doing what it had always done, while I became a little more addicted to it.

And addiction, when it arrives dressed as discipline, is very hard to recognize.

For 3,014 days, I closed the rings. Eight years, three months, and four days.

I know that number sounds impressive. It sounded impressive to me for a long time too. It had consistency, and consistency is one of those words we use when we want to feel good about ourselves. Nobody argues with consistency. It is the responsible cousin of obsession.

Eventually I had to admit that the number was no longer simply measuring something I valued. It was starting to become something I protected.

That is a very different thing.

There were days when closing the rings made sense, and there were days when closing the rings was ridiculous. Travel days. Sick days. Days where I had already done enough. Days where being fully present with another person should have mattered more than negotiating with three colorful circles on my wrist. But the streak had its own gravity. Once something becomes part of your identity, you stop asking whether today deserves an exception. You start asking how to avoid breaking the story you have been telling yourself about who you are.

That is where the whole thing became interesting to me, because this was never really about exercise. It was about attention. It was about what happens when a useful tool stops behaving like a helper and promotes itself to management.

The genius of the activity rings is not the hardware. The genius is ‘the loop.’

A cue on the wrist. A number on the screen. A goal that is close enough to feel reachable but not always finished. A reminder. A reward. A streak. A feeling of accomplishment when the circle finally closes. Repeat that hundreds of times, then thousands of times, and eventually you are not just training your body to move.

You are training your attention to keep checking whether you have earned permission to feel complete for the day.

People call this a “dopamine hit,” which is one of those words that sounds scientific even though it simplifies basic human biology into something ‘cute.’ Your brain is not handing out tiny ‘pleasure coupons’ every time a ring closes.

The system teaches you that certain cues matter, that certain gaps must be resolved, and that completion brings relief. It does not have to be dramatic to be powerful. In fact, the quietness is what makes it powerful.

The watch did not need to control me. It only needed to become part of the rhythm.

That is the socially strange part of smartwatches. Like I wrote in the beginning, looking at your phone in the middle of a conversation is obviously rude. Everyone around us knows what happened. You may still do it, because we are all trying our best, but at least the social contract is clear. You left the moment, and everyone saw you leave.

A watch glance is different. It is smoother. Faster. Easier to excuse. You can tell yourself you were checking the time, which is the adult equivalent of “What?! I was just looking...” It feels less rude, so it slips under your own moral radar. You can be physically standing in front of someone while psychologically negotiating with a metric, and because your hand never reached for your phone, you get to pretend you stayed present.

But I knew I had not.

That bothered me more than the fitness part.

I started noticing these little exits. A glance during a conversation. A check during dinner. A peek while driving (my wife hates it). A tiny mental interruption while walking with someone, not because I needed information, but because ‘the loop’ wanted me to know where we stood. It is embarrassing to admit that a grown man was allowing a wrist computer to shape his behavior. But embarrassment is sometimes the tax you pay for honesty.

The more I thought about it, the more the distinction became clear.

Discipline is when we direct a behavior toward something we value. Compulsion is when the behavior starts directing us.

The activity itself can be healthy. That is what makes this tricky. Walking is healthy. Exercise is healthy. Paying attention to your body is healthy. None of that is the problem. The problem begins when the activity can no longer be interrupted by context, judgment, courtesy, or common sense.

A healthy ritual should be able to survive a missed day.

If it cannot, maybe it is not a ritual anymore.

Maybe it is a cage with better branding.

What made this more uncomfortable is that I could not isolate it to the watch. Once I saw the pattern there, I started seeing it everywhere.

Business dashboards. Email response times. Social media ‘likes.’ Sleep scores. Readiness scores. Productivity apps. Every system promises clarity, and many of them deliver it, at least at first.

I am not anti-metric. That would be ridiculous coming from someone who has spent a career in technical sales and engineering.

Metrics do matter.

But metrics become dangerous when they stop informing judgment and start replacing it.

That is true in business, and it is true in life. A forecast can help you understand the business, but if the forecast becomes the business, you start managing optics instead of reality. A fitness tracker can help you understand your health, but if the tracker becomes health, you start serving the score instead of your body.

A productivity system can help you focus, but if maintaining the system becomes the work, congratulations, you have built yourself a very elegant administrative prison.

This is where ambition gets complicated too.

We all like clean sayings.

“You cannot succeed at something you do not love.”

You can absolutely succeed at something you do not love, at least for a while. People do it every day. They succeed on duty, fear, ego, financial pressure, and the terrifying realization that other people are depending on them.

Adult life is full of things we do not romantically love but still value.

But the research-backed version is more useful than the bumper sticker version. Long-term motivation works better when it feels owned. Not easy. Not magical. Owned. You do not need to love every minute of the work, but you do need to see yourself in the reason you are doing it. There is a difference between effort that expresses your values and effort that simply extracts them from you.

That is why I keep coming back to the watch.

The ring system gave me a very specific kind of intent.

Move. Close. Repeat. Protect the streak.

It was narrow, clear, and incredibly effective. But eventually I had to ask whether that kind of intent was still serving the life I wanted, or whether it had become a way to avoid choosing for myself.

Last night I decided to go back to a regular watch.

That sounds small, and maybe it is. I am not claiming that wearing an analog watch is some grand moral achievement. A plain watch will not make anyone wiser. Unfortunately, the watch industry has not yet solved character development.

But a plain watch does one thing honestly.

It tells time. That is it.

No score. No alerts. No awards. No rings. No quiet suggestion that my day is incomplete because ‘a machine’ has not yet been satisfied. It gives me the information and then leaves me alone, which now feels almost radical. I am sure after 3,014 days of obsession, it will be hard to recover.

I still want to move. I still care about health. I still believe in discipline. I am not trying to become the guy who rejects modern technology while writing about it on a laptop connected to cloud services, wearing Bluetooth headphones, and probably checking three different apps before breakfast. That would be a little too rich, even for me.

What I want is simpler. I want the decision back.

I want to walk because walking is good, not because a bracelet is disappointed in me. I want to be in a conversation without quietly leaving through my wrist. I want to notice when a system that once helped me is now asking for more than it deserves. I want to remember that the point of measurement is to improve life, not to replace it with a scoreboard.

The uncomfortable lesson is not that smartwatches are bad. They are not. For many people, they are genuinely helpful, even life-changing. The lesson is that any system can become dangerous when it cannot be interrupted by your actual priorities.

Health that takes away from being present in the moment is a bad trade.

Productivity that undermines attention is a bad trade.

And eventually, whether the system is on your wrist, in your inbox, or in your own head, you have to ask the simple question:

Is this helping my life, or is it just helping me keep score?

That is the part I did not see coming when I first put on the smartwatch.

So, yesterday was the last time I closed the rings. As with all addictions, the withdrawal will probably be painful.

I really thought I was tracking time, movement, and health.

But after 3,014 days, I realized the more important question was what the tracking had trained me to ignore.

Time is not for closing rings forever.

Time is for people. Time is for family and loved ones. Time is for work that matters. Time is for rest that does not need to be justified by recovery metrics. Time is for walking without reporting back to anything. Time is for choosing the life before the metric chooses it for you.

And maybe that is why the plain watch feels so appealing right now.

Not because it does more. Because it finally does less.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

The Boston Red Sox went into Baltimore and won. Then they did it again. For a brief moment, it looked like exactly what you expect after a leadership reset — sharper execution, better energy, a team that suddenly remembered how to play together.

And then they lost the next two to the Toronto Blue Jays. Just… lost. The kind of losses that quietly remind you that whatever changed wasn’t permanent. The bounce was real, but it wasn’t durable.

That part doesn’t get talked about as much, probably because it’s less interesting. It doesn’t fit into a clean narrative. There’s no headline for “things returned to normal,” even though that’s what usually happens.

Yesterday I was working out of the New York City office. Someone whose opinion I respect — one of those leaders who doesn’t waste words — asked me a simple question:

“So what are you actually going to do differently on Monday to make sure that ‘manager bounce’ isn’t just a moment?”

It wasn’t framed as a challenge, but it certainly felt like one.

Because it’s was easy to write about the “new manager bounce.” It’s observable, it’s relatable, and if you’ve been around teams long enough, you’ve probably lived through it more than once. What’s harder — what’s much harder — is turning that observation into something actionable without defaulting to clichés or pretending there’s a clean, universal answer.

The worst thing you can do is give the answer that you think they want to hear.

I didn’t respond right away. Not because I didn’t have thoughts, but because I had too many of them, and most of them felt incomplete.

Then I found myself on a train from New York City to Boston, staring out the window for long enough to realize two things: first, I should have flown, and second, the answer to that question depends entirely on the situation you’re walking into.

Not all “bounces” are created equal.

And if you treat them like they are, you’re going to get a short-lived lift followed by a very predictable drop.

Not every team needs the same Monday

The mistake I’ve seen — myself included — is assuming that sustaining momentum is about doing more of whatever created it in the first place. More energy, more visibility, more communication, more presence.

Sometimes that works.

Sometimes it does the exact opposite.

Because the “bounce” is not a single phenomenon. It’s a combination of things happening at once: relief, attention, effort, clarity, maybe even a little bit of fear. What matters is understanding which of those is actually driving the change in your specific environment.

If the bounce came from relief, your job is to protect that space.
If it came from urgency, your job is to stabilize it.
If it came from clarity, your job is to reinforce it.

And if you misread it, you can unintentionally reintroduce the very friction that just disappeared.

If the team feels relief, don’t rush to fill the silence

This one feels really weird, especially if you’re stepping into a new leadership role and feel the need to prove that you belong there.

When a team has just gone through a leadership change, and the immediate reaction is relief, the instinct is often to step in quickly with vision, structure, and direction. It feels responsible. It feels like leadership.

But relief is fragile.

It usually means the team has been carrying something — uncertainty, pressure, second-guessing — and they’ve just put it down. If you immediately replace that with a new layer of noise, even if your intentions are good, you risk recreating the same environment under a different name.

The better move, at least early on, is quieter than it sounds. Listen longer than is comfortable. Let conversations breathe. Ask questions that don’t have an immediate agenda behind them.

I’ve started using a version of listening - I’m trying to pay attention to what people don’t say right away. The comment after the meeting. The hesitation before answering. The “it’s fine” that clearly isn’t.

None of that shows up in a dashboard.

All of it matters.

If the team is running on urgency, don’t let it turn into anxiety

There’s another version of the bounce that looks very productive on the surface. The team moves faster, works longer, closes gaps quickly, and everything starts to feel like it’s finally clicking.

This is the version that’s easy to celebrate.

It’s also the version that burns out the fastest.

Urgency can be useful. It sharpens focus and cuts through noise. But left unchecked, it turns into anxiety, and anxiety is where decision quality starts to degrade, even if activity levels remain high.

This is where structure matters — not the heavy kind, but the kind that reduces stress. Clear priorities, explicit trade-offs, and a willingness to say, “we’re not doing this right now,” even when everything feels important.

One of the more practical things leaders should start doing is being clear about what moves down on the priorities list, not just what moves up to the top. It sounds obvious, but in high-performing teams, the ability to say no is often more valuable than the ability to say yes.

Without that, urgency doesn’t stabilize — it compounds.

If the bounce came from clarity, your job is repetition, not reinvention

This one, I think, is the most important.

Sometimes the reason a team improves after a leadership change is simply that things become clearer. Expectations are more direct, communication is more straightforward, and people understand how their work connects to outcomes.

There’s no magic in that. It’s just alignment.

The trap here is thinking that clarity needs to evolve quickly to stay effective. It doesn’t. In fact, most teams benefit from hearing the same priorities repeated consistently, rather than watching them get repackaged every few weeks.

People don’t need a new narrative; they need to trust the one they’re already operating within.

It’s less exciting for the leader, but significantly more effective for the team.

The part nobody wants to say out loud

Sometimes the bounce happens because something — or someone — was actively getting in the way.

And when that ‘block’ is removed, performance improves not because something new was added, but because something was taken away.

If you’re stepping into leadership, that’s worth remembering.

Because the goal isn’t always to introduce something better. Sometimes it’s to avoid repeating what didn’t work in the first place.

What I’m actually trying to do differently

I wish there was a clean checklist here. There isn’t.

Try to listen longer before we decide what needs to be fixed.
Be more explicit about what we’re not doing, not just what we are.
Repeat the priorities more than feels necessary, because it usually is necessary.
Resist the urge to fill every gap with activity, even when doing less feels like the wrong answer in the moment.

None of that is particularly groundbreaking.

So what happens on Monday?

That was the original question, remember?

Why wait for Monday? This is not a New Year’s resolution.

For me, today is less about introducing something new and more about caring for people in my charge. I have to make sure they all feel safe and protected.

The “new manager bounce” is easy to observe and even easier to celebrate.

Sustaining it requires something quieter.

It requires knowing when to step in, when to step back, and having the discipline to tell the difference.

Still working on that.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

My phone buzzed, and I saw a message from my business partner, who is a Baltimore Orioles fan and happened to be at Camden Yards with his wife. His text was short and to the point: “very boring game”.

Out of curiosity more than anything else, I pulled up the score and saw that the Boston Red Sox were up 5–2 in the sixth inning.

I read his message again, and thought about responding “Go Red Sox!”. Instead, I put the phone away, said nothing, and went back to fishing.

But this got me thinking. So much for relaxation and clearing my head.

Last night the Red Sox made some major changes - Manager Alex Cora has been fired, and many of his coaching staff have also been let go. All of a sudden, this afternoon, they played a clean, controlled game that, depending on where you were sitting, either looked boring or looked exactly like what good teams are supposed to do.

That contrast is what made me pause, because I have seen that same pattern play out too many times to ignore it.

A leadership change happens, and almost immediately the same group of people appears more composed, more decisive, and somehow closer to the version of themselves that everyone assumed was in there all along. In sports, they call it the “new manager bounce,” and in business we tend to wrap it in more polished language, but the underlying dynamic is exactly the same.

What makes it interesting is that nothing fundamental about the people involved has actually changed. The players did not suddenly become more talented overnight, just like a sales team does not magically become more capable because a new leader shows up on Monday morning. The skills and the experience were already there, and the expectations certainly were not lower. If anything, they were probably higher.

What changes is something much less visible and, frankly, much more uncomfortable to talk about, because it forces you to look at leadership not as a set of strategies or messages, but as an environment that either enables people to perform or quietly gets in their way. When that environment is not quite right, the impact rarely shows up as a dramatic failure. Instead, it manifests as friction — small, persistent, almost invisible resistance that affects how people think, how they communicate, and how quickly they act.

It shows up in the hesitation before someone speaks up in a meeting, not because they do not have anything valuable to say, but because they are unsure how it will be received. It shows up in the tendency to play it safe rather than take a calculated risk, because the downside feels more immediate than the upside. Over time, these moments accumulate, and while nothing appears broken on the surface, the overall pace and quality of execution start to shift in ways that are difficult to quantify but easy to feel.

When a leadership change happens, especially one that is visible and decisive, a significant portion of that friction is removed almost instantly.

The first thing that surfaces is not excitement, but relief, and while that may not sound like a particularly powerful emotion, it changes how people operate. The sense of relief reduces the mental overhead that comes from constantly navigating uncertainty, and in doing so, it allows people to focus more directly on the work itself.

At the same time, the change signals that the situation is real and that expectations are no longer theoretical. Priorities that may have felt flexible suddenly become concrete, and we find ourselves adjusting the level of effort accordingly. This is not necessarily about fear as much as it is about clarity. People understand that what they do next matters, and that understanding has a way of sharpening focus in a way that no presentation or motivational speech can replicate.

Layered on top of that is the simple but powerful effect of a “clean slate”.

A new leader creates an opportunity for people to redefine how they are viewed within the team.

Somebody who felt invisible may see a chance to show their real value, while someone who had grown complacent may feel the need to reengage at a higher level. Nobody ever talks about this, but you can see the change in behavior almost immediately.

The new leaders also often simplify things, at least in the early stages, and that simplicity can have a huge impact on a team’s performance.

Clear expectations, clear priorities, and more direct communication reduce the stress on the team and make it easier for people to execute.

This is one of those things that feels obvious, yet is very difficult to maintain over time, especially as organizations grow and become more complex.

I say that with some level of self-awareness, because I have made things more complicated than they needed to be, usually in the name of being thorough. I am not convinced it actually helped anyone perform better.

So when the so-called “bounce” occurs, whether it is the Boston Red Sox winning a game in Baltimore or a sales organization finding its rhythm after a leadership reset, it is very tempting to attribute the improvement entirely to the new leader. I think what we are observing is the result of multiple factors shifting at once — reduced friction, increased focus, renewed effort, and improved clarity.

The bad news is that these conditions are only temporary if they are not intentionally sustained. This is where culture comes in.

What is culture? According to Errol Doebler: “Culture is essentially made up of the things we do”.

As time passes, the sense of urgency begins to fade, and the team gradually settles into new patterns of behavior. Without deliberate effort, complexity can reemerge, bad habits can find their way back in.

I have seen this play out in sales organizations where an entire layer of leadership changes at once, creating an initial period of momentum that feels both real and promising. Early wins reinforce the belief that the reset was exactly what was needed, and for a time, that belief is supported by results. The real test, however, comes later, when the novelty of the change has worn off and the organization has to rely on the consistency of its leadership rather than the energy of the transition.

This is where the ideas in “Leaders Eat Last” by Simon Sinek start to resonate in a more practical way. The concept of creating an environment where people feel safe, supported, and trusted is not just philosophical; it directly influences whether the performance improvements that follow a leadership change can be sustained. When people do not have to spend energy protecting themselves or navigating unnecessary friction, they are able to invest that energy into supporting each other.

What do you think of this?

If a team demonstrates improved performance immediately after a leadership change, it is worth considering what was happening before that made that change feel like relief.

I do not have a clean answer to that, and I suspect most people who take leadership seriously would say the same. What I do know is that the most interesting part of this afternoon was not that the Red Sox won a game that someone in the stands considered boring. It was that, for at least one evening, they looked more like a team that was playing without hesitation, without unnecessary weight, and with a level of clarity that made the result feel secondary.

The real question, as always, is whether that feeling can be maintained once the change is no longer new and the organization has to rely on the steady work of leadership to create the conditions for consistent performance.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

“BREAKING NEWS: The FlashArray now supports Object??? What in the world? I may need to write an article about that!!”

That reaction wasn’t planned, and it definitely wasn’t me being clever. It was me looking at the GUI and thinking, “that can’t be right… can it?” It didn’t line up with how I’ve been modeling storage architectures in my head for years, which usually means one of two things: either something fundamentally changed… or I’ve been confidently wrong about part of this for a while.

And if I’m being completely honest, there was also a second reaction happening in parallel — one that I didn’t write down at the time because it sounded slightly ridiculous even in my own head:

“Wait… do I actually understand why object storage exists in the first place? And more importantly… what exactly was wrong with files?”

That’s the part nobody likes to admit out loud. We’ve all spent years confidently explaining block, file, and object as if we were born with that knowledge, when in reality most of us learned it incrementally, retroactively, and with just enough conviction to sound credible in front of a customer. Object storage, in particular, has always carried this aura of inevitability — like of course it’s better, of course it scales, of course it’s what modern applications need — without always forcing us to question why the previous model stopped being enough.

Because for as long as most of us have been designing infrastructure, object storage has not simply been another protocol layered onto an existing system. It has represented a fundamentally different way of organizing and accessing data, one that required its own architectural approach, its own scaling model, and, more often than not, its own dedicated platform. The separation between block, file, and object was not arbitrary; it was a reflection of how deeply different those paradigms were in terms of metadata handling, access patterns, and performance expectations.

This is precisely why platforms such as Everpure FlashBlade exist in the first place. They were not created as extensions of traditional storage systems but as purpose-built architectures designed to treat unstructured data — and particularly object data — as a first-class citizen. The use of distributed metadata services, sharded across independent nodes, combined with a key-value store storage model, allows such systems to achieve levels of parallelism and throughput that simply cannot be replicated within a controller-based design. In that context, object storage is not something that is “added” to the system; it is the system.

Which is why seeing S3 support appear on FlashArray required a pause.

Not excitement. Not skepticism alone. Something closer to intellectual friction.

Reconciling Two Architectural Worlds

The most important step in understanding what FlashArray has introduced is to resist the temptation to treat it as a direct comparison to FlashBlade. These aren’t two different ways of solving the same problem. They’re two different answers to two different problems—and pretending otherwise is where people get themselves into trouble.

FlashBlade is built for object, not adapted to it. S3 talks directly to a distributed engine that thinks in objects, not files pretending to be objects. Metadata is spread across blades instead of becoming a centralized choke point, and the whole system scales the way modern workloads actually need it to. There’s no file system layer to fight with, no directory structure to navigate, no POSIX semantics getting in the way. It just does what you’d expect when you remove all of that: it goes fast, it scales cleanly, and it keeps up with workloads like HPC, AI and analytics without breaking a sweat.

FlashArray takes a very different path, and in reality, it’s not what most people expect. It doesn’t try to reinvent itself as an object platform, and it doesn’t throw an S3 gateway in front of the array and call it a day.

With Purity 6.10.5+, S3 just shows up as another protocol the system understands, right next to block and file.

That distinction matters more than it seems. This isn’t something duct-taped on the side — it’s part of the same control plane, the same data path, the same system you’ve already been running.

But let’s not pretend it turned into FlashBlade overnight. This is still a controller-driven architecture. The primary controller does the heavy lifting — handling requests, authenticating them, coordinating operations — before anything actually hits the storage engine. Which means it behaves differently, especially as workloads scale.

So it ends up in this interesting middle ground. Not a native object system in the pure sense, but not a hack either. Just a different way of exposing what’s already there.

The Translation Layer and Its Consequences

It would be irresponsible to discuss FlashArray S3 without explicitly addressing the implications of this design.

Even with its native integration into Purity, S3 operations are still subject to the realities of a controller-bound architecture. Every request must be processed, authenticated, and coordinated before it is executed, introducing a measurable difference in behavior compared to both native block operations and distributed object systems.

The most immediate effect is latency.

While FlashArray continues to deliver sub-150 microsecond performance for block workloads, S3 operations typically operate at higher latencies (in 1 millisecond range) due to the additional processing steps involved. This is not a flaw; it is the natural outcome of introducing a protocol that was designed for scale and flexibility into a system optimized for low-latency transactional workloads.

Metadata handling further reinforces this distinction.

FlashBlade distributes metadata across its architecture, enabling massive parallelism and consistent performance at scale. FlashArray processes metadata through its controller framework, which introduces natural serialization points under high concurrency. As workloads become increasingly metadata-heavy — particularly with small objects — this difference becomes more pronounced.

The system also enforces clearly defined operational limits to maintain predictable performance. As of Purity 6.10.5+, FlashArray supports up to 250 S3 buckets per array and a maximum of 1,000,000 objects per bucket. FlashArray Object Store Limits

Object storage operates at the array scope and does not integrate with multi-tenancy or “realms”, which has implications for service provider models and strict tenant isolation requirements.

These constraints are not arbitrary limitations; they are guardrails that ensure the system behaves consistently within its architectural boundaries.

Where the Architecture Becomes Secondary

Having established those boundaries, the conversation naturally shifts from “how it works” to “why it matters”.

In many enterprise environments, particularly within SLED organizations, the challenge is not achieving exabyte-scale throughput or supporting billions of objects. The challenge is delivering capabilities in a way that is operationally sustainable, economically efficient, and aligned with existing infrastructure.

This is where FlashArray’s approach becomes compelling.

By exposing object storage within the same platform that already supports block and file workloads, it eliminates the need to introduce a separate system, a separate operational model, and a separate set of dependencies. The same management interface, the same automation framework, and the same data services extend across all protocols.

More importantly, object data inherits the full set of Purity capabilities.

• Global inline deduplication and compression apply to S3 workloads, significantly improving storage efficiency compared to many object-native platforms.

• SafeMode snapshots extend immutability to object storage, providing a critical layer of protection against ransomware.

• ActiveCluster, combined with ActiveDR, enables a three-site resilience model that ensures data availability across multiple locations with zero RPO between primary sites.

These are not incremental improvements. They represent a shift in how object storage can be consumed within an enterprise.

Practical Use Cases in a Unified Model

When viewed through this lens, the use cases for FlashArray S3 become both clear and grounded in reality.

Development and Staging Environments

Some applications rely on S3 APIs but do not require massive scale, FlashArray provides a consistent and integrated object interface without introducing additional infrastructure. Developers can build and test against a familiar model while remaining within the same operational environment.

Backup and Recovery Workflows

FlashArray S3 enables modern data protection strategies that leverage object storage while benefiting from flash performance, deduplication, and indelible snapshots. This combination improves both recovery times and storage efficiency.

Tier-two repositories and application-integrated storage represent another natural fit.

Workloads such as document management systems, logs, and archival data often require object semantics but do not justify the higher cost of a dedicated object platform. Consolidating these workloads onto FlashArray simplifies operations while maintaining reliability and performance.

Where the Boundaries Still Matter

None of this diminishes the importance of selecting the appropriate platform for workloads that demand a different architecture.

High-performance AI pipelines, large-scale analytics environments, and use cases requiring massive parallelism remain firmly within the domain of FlashBlade. The ability to scale performance linearly, distribute metadata across many nodes, and support billions of objects is not optional in these scenarios — it is essential.

What has changed is not the relevance of those systems, but the necessity of deploying them for every object storage use case.

A Subtle but Significant Shift

The introduction of S3 on FlashArray does not represent a replacement of one architecture with another. It represents a convergence of capabilities within a unified operational framework.

Object storage, in this model, is no longer a destination that requires its own platform. It becomes a capability — one of several ways to access and manage data within the same system.

That shift is easy to overlook, but its implications are significant.

It allows organizations to design around outcomes rather than protocols, to reduce complexity without sacrificing capability, and to align infrastructure more closely with the needs of modern applications.

Closing Reflection

Looking back at that line in Part 2, it is clear that the reaction was not just about a new feature appearing in the interface. It was about the recognition — however incomplete at the time — that something foundational was beginning to change.

Object storage did not suddenly become simpler, nor did it lose the architectural complexity that defines it.

What changed is where it lives.

And once that becomes clear, you start asking a slightly uncomfortable but very honest question:

If this works… and it works well enough for most of what I actually need… why was I so convinced it had to live somewhere else in the first place?

That is usually where the interesting work begins.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere