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

In the first post, I walked through enabling file services on a FlashArray.

There was nothing particularly complicated about it. The process was clean, predictable, and by the end of it I had a fully functional file platform running on the same system that was already supporting the rest of the environment. It behaved exactly the way you would expect it to behave.

And that is precisely what started to bother me.

Because if you step back and look at what we actually did, the workflow has not really changed in years. I still made a series of decisions in a very specific order. I chose where the workload should live, I created the file system, I attached protection, and I made sure everything was named and organized in a way that made sense at that moment.

It was structured. It was controlled. It was also entirely dependent on me.

That model works well enough when the environment is small or when the same person is making the same decisions repeatedly. But as soon as you introduce scale, or simply more people, those decisions start to drift. Not in a dramatic way, but in small inconsistencies that accumulate over time. A slightly different naming convention here, a missed policy there, a workload placed somewhere because it “felt right.”

Nothing breaks.

It just becomes harder to operate.

When the model stops making sense

What stood out to me after going through the manual process is that we are still treating storage as something that needs to be individually managed, even though the platform itself has already moved beyond that.

We have systems that can deliver consistent performance, global data services, and non-disruptive operations, yet we still rely on human judgment to decide where things go and how they should be configured.

That disconnect is where Everpure Fusion begins to make sense.

Not as an additional feature, but as a way to remove an entire class of decisions that we have simply accepted as part of the job.

From managing infrastructure to defining intent

The idea behind the Enterprise Data Cloud is not particularly complicated, but it does require a shift in perspective.

Instead of treating each array as a separate system with its own boundaries, the environment becomes a unified pool of resources. Data is no longer something that you place on a specific array. It is something that exists within a global pool, governed by policies that define how it should behave.

Once you start thinking this way, the questions change.

You are no longer asking where a workload should go. You are asking what that workload needs to look like. Performance expectations, protection requirements, naming, and lifecycle behavior become the inputs, and the system automation takes responsibility for everything else.

That is the role of Everpure Fusion.

What actually changes in practice

The easiest way to understand Fusion is to look at what it removes.

In the manual model, every step is explicit. You build storage object by object, and then you attach policies to those objects. You rely on memory, experience, and sometimes documentation to make sure everything is done correctly.

With Fusion, that entire process becomes declarative.

Instead of building storage step by step, you define a preset. A preset is a reusable definition of what “correct” looks like for a given workload. It captures performance expectations, protection policies, naming conventions, and any constraints that should apply.

Once that definition exists, it becomes the standard.

When you create a workload from that preset, Fusion evaluates the environment and places it on the array that best satisfies those requirements. It creates the necessary objects, applies the policies, and ensures that everything is consistent with the definition.

The important shift is not that tasks are automated. It is that decisions are no longer made ad hoc.

Trying it in the lab

After building file services manually in the previous post, I wanted to see what this would look like using the same environment, but driven through Fusion.

I started by defining a fleet, grouping the array into a logical boundary where resources and policies could be managed collectively. Once the array becomes part of a fleet, you stop thinking of it as an individual system and start treating it as part of a shared pool.

From there, identity becomes the next requirement. Fusion relies on centralized authentication, typically through secure LDAP backed by Active Directory. This is what governs access to presets and workloads, and it ensures that everything aligns with existing organizational controls.

Up to this point, everything felt exactly like I expected.

Then I moved to the part I was actually interested in.

Where things didn’t quite line up

The goal was to take the file services I had already built and express them as a preset. I wanted a single definition that would describe the file system, its structure, its policies, and its behavior, and then use that definition to create workloads without going through the manual steps again.

Conceptually, that is exactly what Fusion is supposed to do.

In practice, I ran into a limit that I had not fully appreciated at the start.

I was running Purity OS 6.9.2.

Which, to be fair, is where most production environments should be. It is a Long-Life Release, stable, predictable, and already capable of delivering Fusion for fleet management, intelligent placement, and policy-driven storage classes.

You can create Presets and Workloads for block workloads.

What it does not include is full support for File Presets on FlashArray.

That capability, where a file system, its directories, and its access policies are all defined and deployed as a single unit, arrives in the 6.10.X Feature Release line.

Which means that the exact outcome I was trying to demonstrate was sitting just one version ahead of me.

This is where I had to laugh at myself

There is always a moment in a lab where you realize that the limitation is not the platform.

It is you.

In this case, it was me getting ahead of the version I was actually running.

My intentions were “ever” so “pure” (IYKYK). The execution was slightly behind the feature set.

So I upgraded

One of the advantages of working with this platform is that upgrading does not carry the same weight it used to. The system is designed for non-disruptive operations, and moving between versions does not require downtime or migration.

The upgrade to 6.10.5 was uneventful in the best possible way. Controllers were updated in sequence, workloads continued to run, and the system transitioned to a new set of capabilities without introducing risk.

There is something very satisfying about performing an upgrade not because something is broken, but because you want access to what comes next.

BREAKING NEWS: The FlashArray now supports Object??? What in the world? I may need to write an article about that!!

When it finally clicks

Once on 6.10.5, the model finally aligns with the intent.

Once I clicked on Create Your First Preset, it gave me these options:

I defined a preset that described the file workload I had previously built manually. It included the expected behavior, protection policies, and naming conventions. Instead of creating individual components, I was defining the service as a whole.

Now this was really neat - when you select Storage Class, it knows that arrays are available in your environment. In my case, I only have FA //X.

At this point a new field opens and allows you to select the Storage Resources.

Once I hit “Publish'“ this was the result:

Think of this entire process like this:

1. Define your Recipe (Preset)

2. Order from the Menu (Workload)

Lets create a workload from that preset.

Once I clicked on + to add a new Workload, the Wizard opened:

Give a name to that Workload:

Since Fusion Fleet has both of my lab arrays, I have an option to select an array for the workload placement.

Our of curiosity I clicked: “Get Recommendations” and this was the result:

Once I hit Deploy, within seconds, the workflow executed and I had my File System created.

How awesome is this? Come on, give me a cheer!

Think about the magnitude of what just happened.

I provided minimal input, and Fusion handled the rest. It selected the appropriate array based on capacity and performance, created the file system, applied the policies, and ensured that everything matched the definition.

There was no second pass. There were no additional steps.

The outcome matched the intent.

By moving to this model, I just shifted from being a "storage admin" to a "data architect." I defined the outcomes and it happened “automagically”.

Why this matters more than efficiency

It would be easy to describe this as a way to reduce manual effort, but that misses the point.

The real value is consistency.

When every workload is created from a defined preset, variability disappears. Policies are enforced by default. Naming is consistent. Placement is based on a complete view of the environment rather than individual judgment.

Over time, that consistency reduces operational friction and lowers risk in ways that are difficult to measure but easy to recognize. Environments behave predictably, scaling becomes simpler, and the likelihood of human error decreases.

Where this leads

In the first post, I showed that file services can run natively on the array without additional infrastructure.

In this post, the focus shifted to removing the manual decisions involved in building and managing those services.

The next step is where things move beyond automation.

As capabilities like ActiveCluster for File continue to evolve, the conversation shifts toward mobility and continuous availability. At that point, it is no longer just about simplifying operations, but about removing the constraints that tie workloads to a specific system or location.

That is a conversation for Part 3.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Then he started asking questions about enterprise file services.

They were running a couple of Windows Server virtual machines on top of VMware vSphere, serving SMB shares to the rest of the organization. Again, nothing unusual there. This is still the default design in a lot of places, and it works well enough that nobody feels compelled to question it.

But as the meeting on, a few details started to surface. One of the VMs was consistently running hot during backup windows. Another one hadn’t been patched in a while because nobody wanted to risk disrupting access to shared data. The storage policies applied at the VM layer didn’t quite line up with what was actually configured on the array. And there was an unspoken understanding that maintaining these systems was just part of the job — something you deal with, not something you optimize.

No one had made a bad decision. The architecture made sense at the time it was implemented. My guess, based on experience, is the File Server was simply P2V’d back when VMware was a novelty. It had simply stayed in place, unchanged, while everything around it evolved.

What made it more interesting was that the same environment had an Everpure FlashArray running their critical workloads. It was handling databases, transactional systems, and anything else that required consistent performance and reliable data services. It was protected, replicated, and trusted.

File services, however, were living on top of virtual machines, with their own lifecycle (please, please… don’t say VMware snapshots), their own dependencies, and their own set of operational overhead.

That disconnect is what stuck with me.

So instead of continuing the theoretical discussion about architecture and “best practices,” I went back to my lab and decided to try something very simple. I wanted to see what would actually happen if I enabled file services directly on the array and treated it as a first-class file platform instead of assuming that role belonged to something else.

There was no redesign exercise, no migration plan, and no phased rollout. I wasn’t trying to prove a point on a whiteboard. I just wanted to turn it on and see if the experience matched what we tend to claim in conversations.

Nothing broke. Nothing felt forced. And more importantly, nothing about it felt like a compromise.

This post walks through exactly what I did to enable and run file services on a FlashArray //X20R4 running Purity 6.9.2. The goal is not to explain the architecture in abstract terms, but to show how straightforward it is to take something that already exists in your environment and use it in a way that removes unnecessary complexity.

What I realized (and why this matters)

Once everything was up and running, the first realization was that this is not a workaround or a secondary feature designed to fill a gap. FlashArray File is integrated into the platform in a way that makes it behave like a natural extension of what the system already does well. It uses the same controllers, the same global storage pool, and the same data services that are already in place for block workloads. There is no separate management layer, no additional appliance (remember Data Movers and NAS Personas?), and no need to think about it as something different from the rest of the system.

That by itself is useful, but it is not the most important part.

What stood out more was the amount of operational overhead that simply disappeared. When file services run on virtual machines, you inherit everything that comes with them. You are responsible for the guest operating system, including patching cycles, security updates, and the occasional issue that appears at the worst possible time. You are also consuming hypervisor resources and, in many cases, paying for licensing that exists solely to support a function that could be handled elsewhere. On top of that, you end up managing data protection, performance, and capacity in two different places (remember RDMs, or in-guest iSCSI?), which introduces opportunities for inconsistency.

By moving file services onto the array, that entire layer is removed. You are not just changing where the workload runs; you are simplifying how it is operated, protected, and maintained over time.

The second realization was that this approach aligns with where things are clearly heading. Everpure is already extending these capabilities with ActiveCluster for File, which will bring synchronous replication and continuous availability to unstructured data. I do not have that running in my lab yet, but it is not difficult to see the direction. As those capabilities become more widely available, the remaining reasons to maintain separate file platforms will continue to shrink.

That will be a conversation for a future post. Let’s tentatively call it Part 3 of the series.

Before you start (the part that actually matters)

Enabling file services on the array is straightforward. The part that tends to create friction is everything that surrounds the configuration, particularly networking and integration with existing services.

The first consideration is the choice of network interfaces. Although the array provides 1GbE management ports, those interfaces are not intended for serving file workloads. Using them for SMB or NFS traffic introduces an artificial bottleneck that will affect performance and, more importantly, perception. File services should be configured on the 10 or 25GbE data ports, which are designed to handle production traffic and provide the throughput expected from the platform.

Here is what my array looked like earlier today:

The highlighted ports are ETH10 and ETH11 on both controllers.

Redundancy should be planned, but it does not need to be over engineered. A simple and reliable starting point is to use at least two ports per controller, ensuring that the configuration remains consistent across both sides. The goal is to achieve predictable failover behavior rather than to build a complex network design that is difficult to troubleshoot.

One concept that is worth understanding early is the File Virtual Network Interface, or File VIF. This is the logical identity of the file service—the IP address that clients use to connect. It is designed to move between controllers as needed, maintaining availability during failover events. Once this concept is clear, the rest of the networking configuration becomes much easier to follow.

I just quickly ran downstairs to connect the physical cables to all 4 ports. Each controller has connectivity to 2 separate Ethernet for physical redundancy.

My lab was built within budgetary constraints - that means I don’t have separate ethernet switches and I don’t have the time to build a separate DNS Server for FA File Services.

Everpure recommends separating file client traffic from management traffic, but that’s a best practice, not a requirement.

I am not going to invent 192.168.5.0/24 just because it “feels like file.”

Since my lab switch is a single flat, untagged network and the environment is really just 192.168.1.0/24, I will just us the most practical approach - put the FA File VIFs on that same 192.168.1.0/24 network with their own IP addresses.

Here is what I did:

• I just kept the file VIFs on 192.168.1.0/24 since that is the only real network available.

• FlashArray expects unique layer-3 subnets and does not support overlapping networks.

DNS

In my specific configuration, I don’t need a new DNS server.

• My existing management DNS servers can resolve the AD/DC hostnames and the FA File names/computer object.

• FA File can use the same DNS as management with no extra file-DNS configuration.

• By default, DNS lookups will go out the management interfaces, so my DNS server just needs to be reachable from the management network. And it is.

Let’s turn the lights on, shall we?

After assigning the IP addresses and enabling the ports, the lights came on.

Important design note

I will use one client-facing VIF IP for the file service, for example:

• File VIF IP: 192.168.1.135

• Netmask: 255.255.255.0

• Gateway: my 192.168.1.2 default gateway

Do not try to use 192.168.1.131-134 as four separate FA File IPs unless you intentionally want multiple VIFs. The ct*.eth* ports are transport underlay, not the SMB/NFS endpoint IPs.

Configuring a File Server and File VIF

Open the File Services server page

1. Go to Storage → Servers.

   

2. Open the default server (_array_server) or create a new file server if you want a dedicated namespace.

3. Stay on that server’s details page.

3. Create the File VIF

Use physical bonding first; it’s the simplest.

1. In the Virtual Interfaces section, click + Create VIF.

2. Choose Physical Bonding.

3. Select the underlying port pairs:

   • Pair 1: ct0.eth10 and ct1.eth10

   • Pair 2: ct0.eth11 and ct1.eth11

4. Name the VIF something simple, e.g.:

   • filevip1

5. Enter network settings:

   • IP Address: 192.168.1.135

   • Netmask: 255.255.255.0

   • Gateway: 192.168.1.1

6. Leave VLAN blank since there are no VLANs.

7. Save and Enable the VIF.

That creates the client-facing IP for SMB/NFS.

4. Configure DNS

Integration with DNS and Active Directory is another area where a bit of preparation goes a long way. File services rely on proper name resolution and domain integration, and it is important to recognize that file-related DNS settings are separate from the array’s management DNS configuration. The system effectively becomes a participant in the domain as a file server, which means that DNS records, domain join operations, and permissions should be planned accordingly rather than improvised during setup.

Since my DNS is 192.168.1.2 and I want to reuse management DNS:

1. Go to the server’s DNS Settings.

2. My management DNS is already configured and points to 192.168.1.2

3. If you want to explicitly add file DNS:

   • Click + in DNS

   • Name: file-dns

   • Domain suffix: your AD/domain suffix

   • DNS server: 192.168.1.2

   • Service: file

   • Source interface can remain default unless you specifically need file VIF sourcing.

And just like that I hit a big OOPS!!!

I have ActiveCluster enabled for my block workloads. And on the version of Purity I am currently running, it cannot be used with FA File.

Well, thank goodness, it’s just a lab. I can do whatever I want.

Please DON’T do this in production. You have been warned in writing.

First, I had to disconnect the host group on the second array and delete the replication pods that were a part of the ActiveCluster. Later on, I will configure ActiveDR to ensure data protection. Or maybe just upgrade to Purity 6.10.X that has ActiveCluster for File support.

Second, I deleted the connected array and was able to finish the DNS configuration.

5. Create required DNS A records

On my DNS server 192.168.1.2, I created an A record for the file service name pointing to the File VIF IP.

• Name: fa-file01

• IP: 192.168.1.135

If you are joining AD for SMB/Kerberos:

• Make sure DNS also has A records for all relevant domain controllers.

• Create the A record that matches the AD computer object / FA File service name.

6. Join Active Directory or configure LDAP

If using SMB

Use Active Directory.

Go to:

• Storage → Servers → _array_server

Then look for one of these panels:

• Remote Directory Service

1. Click Edit Configuration

2. Select Active Directory

3. Enter:

   • Name

   • Domain DNS Name

   • Computer Name

   • Use Existing Account if applicable

   • AD User

   • Password

   • TLS Mode

4. Save / Join

This part took me 2 hours. I was getting some crazy error messaged that I’m simply embarrassed to share here.

It was not the DNS. It was an NTP server misconfiguration that was causing Kerberos to not authenticate properly. There was a 10 minute time skew between the FlashArray and the domain controller.

7. Create a File System

The file system is the top-level container for your unstructured data.

• GUI Method: Navigate to Storage > File Systems and click the plus sign (+). Enter a name and click Create.

• CLI Method: Use the following command: purefs create <file-system-name>.

8. Create a Managed Directory

Managed directories allow you to apply specific policies (like quotas or snapshots) to subfolders within a file system.

• GUI Method:

  1. Go to Storage > File Systems.

  2. Click on the name of the file system you just created.

  3. Select the Directories tab and click the plus sign (+).

  4. Enter the directory name and the internal path (e.g., /users).

• CLI Method: Use the following command: puredir create filesystem1:users --path /users.

9. Create an Export

The export makes the managed directory accessible to clients over the network.

• GUI Method:

  1. Navigate to Storage > Policies > Export Policies.

  2. Select an existing policy (e.g., a standard SMB or NFS policy) or create a new one.

  3. Within the policy view, click the plus sign (+) to add an export.

  4. Select your Managed Directory, choose the appropriate Server (use _array_server for standard configurations), and provide an Export Name (this is the name clients will use to mount the share).

• CLI Method: Use the following command: puredir export create --dir <file-system-name>:<directory-name> --policy <policy-name> --server <server-name> --export-name <client-facing-name>.

A quick validation step

At this point, it is worth validating access from a client system. Map the SMB share and perform a simple set of operations—create files, read data, and verify permissions. This is less about testing performance and more about confirming that networking, authentication, and access controls are behaving as expected.

In most cases, if the earlier steps around DNS and Active Directory were done correctly, this validation step is uneventful, which is exactly what you want.

And now let the data migration begin.

I am actually doing it from my Mac. And it just works!!!

What becomes apparent after completing these steps is how little effort is required to stand up a fully functional file platform on infrastructure that is already in place.

Unless, of course, your NTP server crashed.

The system behaves predictably, integrates cleanly with existing services, and avoids many of the operational burdens associated with VM-based file servers.

And that is where things start to get interesting.

Because everything described so far is still being done manually—selecting where things live, defining configurations, and applying policies one step at a time. It works, and it works well, but it also mirrors the way storage has traditionally been managed.

In the next post, I will show what happens when you stop doing these steps manually and let Pure Fusion handle placement, policy, and provisioning instead.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

By “the team,” of course, I mean my followers and, yes, all 107 Substack subscribers. So if you are one of those 107, please know that I walked willingly into the land of finance and procurement jargon on your behalf.

There’s a concept often attributed to Albert Einstein. There are many discussions on Reddit arguing about whether he really said it.

Simon Sinek supposedly said that “if your ideas are simple enough to understand, they become simple enough to repeat — and that’s how they spread”.

The challenge is that this topic is not naturally simple.

It sits at the intersection of semiconductor supply chains, DRAM and NAND pricing, capital allocation, procurement timing, and financial concepts that, if I am being honest, I have never considered the fun part of technology. I have always enjoyed writing about architecture, technical strategy, and what makes top-performing pre-sales systems engineers and teams actually work. That is the stuff I gravitate toward naturally.

If I’m being honest, I don’t wake up in the morning thinking, ‘let me go study finance today’.

Depreciation schedules. Capital exposure. Net Present Value. The kind of material that can make even an otherwise healthy person start looking for a distraction.

The good news is that underneath all of this complexity, there is actually a very simple shift happening.

And once you see it, it becomes hard to ignore.

What we are experiencing is not another cyclical fluctuation in NAND or DRAM pricing. It is a structural shift in how semiconductor capacity is allocated globally.

The rise of AI has not simply increased demand; it has fundamentally reshaped prioritization across the supply chain. High Bandwidth Memory and next-generation DRAM are now absorbing the majority of advanced manufacturing capacity, leaving traditional enterprise components competing for what is effectively a constrained and not-as-important supply pool.

Memory & Flash Crisis Update (March 2026)

It is estimated that by the end of this year, AI-driven infrastructure consumes the majority of high-end memory production.

Deloitte - 2026 Global Semiconductor Industry Outlook

This creates a cascading effect across the market: longer lead times, accelerated end-of-life timelines for legacy components, and pricing volatility that can shift significantly within a single month. In this environment, the challenge is no longer selecting the “right” infrastructure platform. The challenge is making a business decision that remains rational under uncertainty.

Where the Traditional Model Fails

The traditional CapEx procurement model was always based on predictability. It assumes that organizations can make a large upfront investment, amortize it over time (or depreciate, if that word makes more sense to you), and extract consistent value throughout the lifecycle of the asset.

In a stable market, this model is manageable. In a volatile one, it becomes a source of risk.

The first failure point is timing.

In a market where DRAM prices can increase 50% or more quarter-over-quarter, the moment of purchase becomes super important. A decision made at the wrong point in the pricing curve effectively locks an organization into an elevated cost basis for the entire lifecycle of the infrastructure. Unlike other investments, there is no opportunity to rebalance or exit; the capital is committed, and the asset is fixed.

The second issue is over-provisioning.

In my last post The Idea That Was Supposed to Fail, I wrote about SSD over-provisioning. This time around, it’s a different kind.

Because procurement cycles are slow and expansion can take months — if not longer — architects are forced to design for future peak demand. This causes inefficiency: expensive infrastructure that remains underutilized for a long period of time. In today’s market, this inefficiency is magnified by elevated component costs. Organizations are not just overbuying — they are overbuying at historically high prices.

The third challenge is the accumulation of technical and financial debt.

As systems age, maintenance costs increase, performance becomes less aligned with modern workloads, and the eventual refresh becomes both inevitable and disruptive. In a constrained supply environment, that refresh is no longer a routine event; it is a new exposure to pricing increases, availability risk, and architecture that can no longer do the job.

Combined together, these factors transform what was once a simple procurement model into a series of compounded financial risks.

Reframing Infrastructure Through a Financial Lens

What I am discovering is that to navigate this environment effectively, infrastructure decisions must be evaluated not only in terms of performance and capacity, but through the lens of financial outcomes.

Please don’t feel like you need a PHD in finance from NYU Stern or The Wharton School here.

I know the next couple of paragraphs would make you feel like you need a nap or a double espresso. I am really trying to make it easy to understand.

Concepts such as cash flow timing, capital allocation, and risk-adjusted return are no longer abstract financial constructs; they are central to infrastructure strategy.

At its core, the time value of money introduces a simple but powerful idea: money deployed today carries a higher opportunity cost than capital deployed over time. In a traditional model, the majority of the money is spent upfront, reducing financial flexibility and limiting the organization’s ability to invest in higher-return initiatives. In contrast, a consumption-based model distributes that expenditure, preserving capital and allowing it to be allocated more dynamically.

This directly impacts Net Present Value (NPV), not as an academic metric, but as a practical measure of decision quality. Even when the nominal cost of a subscription model appears higher over a multi-year period, the ability to defer expenditure, accelerate value realization, and avoid unused capacity often results in a more favorable financial outcome when evaluated over time.

Net Present Value (NPV): A Guide to Smarter Financial Decisions

Equally important is the role of uncertainty. Traditional procurement assumes that future requirements can be accurately predicted. In reality, infrastructure demand is inherently variable. Data growth, application requirements, and technological shifts rarely follow a linear path. When organizations commit to fixed assets, they assume the risk of being wrong — either by over-investing in unused capacity or underinvesting and facing constraints at critical moments.

A consumption-based model fundamentally changes this dynamic by transferring a significant portion of that risk to the solution provider.

Subscription as a Risk Management Strategy

If you understand it correctly, subscription consumption of the infrastructure is not simply a different purchasing model. It is a mechanism for managing uncertainty.

And if that sounds familiar, it should. We already bought into this model years ago. We just called it “cloud-first” back then. The pitch was identical — stop making big capital bets, shift the risk, and consume what you need when you need it.

The most immediate impact is on cash flow.

Instead of a large upfront capital commitment, organizations move to a predictable, recurring expense aligned with actual usage. This improves budget predictability and reduces the friction associated with large capital approvals, particularly in environments where funding cycles are rigid.

More importantly, it removes the need to make a single, high-stakes decision at a specific point in time. In a volatile semiconductor market, this alone represents a meaningful reduction in financial exposure and business risk.

The second impact is on utilization.

By aligning cost with the actual consumption, organizations eliminate the inefficiencies associated with over-provisioning. Capacity is no longer purchased in anticipation of future demand but consumed as needed. This shifts the economic model from one of speculation to one of alignment.

The third and most significant impact is on risk.

Pricing volatility, supply chain constraints, and technical debt do not disappear, but they are absorbed by the provider rather than the customer. If you really think about it, the subscription model acts as a financial hedge against market instability.

Why the Everpure Model Changes the Conversation

Not all subscription models are created equal. The effectiveness of the approach depends on how well it aligns cost, performance, and risk.

The Everpure Evergreen//One model introduces several mechanisms that directly address the challenges outlined above.

First, the concept of Effective Used Capacity (EUC) fundamentally changes how value is measured.

Rather than billing based on raw or provisioned capacity, the model aligns cost with actual data written.

This eliminates an inefficiency in traditional storage economics, where customers effectively pay for system overhead and unused capacity.

Second, the inclusion of an on-site 25% capacity buffer addresses a problem that is often overlooked in financial discussions: lead time risk.

In a market with extended delivery lead times where acquiring additional hardware can take up to a year, the ability to scale immediately is not a convenience — it is a requirement. By maintaining available capacity in advance, the model removes the dependency on unpredictable supply chains.

Third, price protection becomes a central feature rather than an afterthought.

In an environment characterized by rapid cost fluctuations, the ability to maintain stable pricing over time provides a level of budget predictability that is otherwise difficult to achieve. This is particularly relevant in public sector environments, where financial planning horizons extend beyond the volatility of the underlying market.

Finally, the elimination of disruptive upgrade cycles addresses both operational and financial inefficiencies.

Continuous, non-disruptive operations ensures that infrastructure remains current without requiring you to spend more money. This removes the “forklift upgrade” as a recurring source of cost and disruption risk.

If you want to learn more, please read this blog:

How Evergreen//One Storage Subscriptions Protect Your IT Budget from Price Spikes

Implications for the Public Sector

These considerations are critical in public sector organizations, where procurement cycles are long, budgets are fixed, and accountability is high.

Navigating IT Procurement Challenges in the Public Sector

The traditional model forces state agencies, municipalities and universities to make decisions based on assumptions that may no longer hold by the time implementation occurs. In a rapidly changing market, this creates a structural mismatch between planning and execution. Subscription models, by aligning cost with usage and providing predictable pricing, offer a way to bridge that gap.

Additionally, the ability to consume infrastructure as a service simplifies compliance and improves transparency. Costs are directly tied to measurable outcomes, reducing the complexity associated with large capital purchases and multi-year depreciation schedules.

Time-to-Value as a Financial Multiplier

One of the most under appreciated aspects of this shift is the impact on time-to-value. In traditional environments, delays in procurement, deployment, and scaling can significantly extend the time between investment and business outcome.

In a consumption-based model, that interval is compressed. Resources can be provisioned quickly, expanded without delay, and upgraded without disruption. This accelerates the realization of value, which in turn improves the overall financial profile of the investment.

From a financial perspective, earlier value is inherently more valuable. This is not a theoretical concept; it is a direct consequence of how capital is evaluated over time.

A Structural Shift, Not a Trend

Most technology sellers still position subscription as a “by the way” option — something they introduce after walking through the traditional purchase. It gets framed as a different way to buy. That framing is not just incomplete — it’s misleading. This isn’t about preference. It’s about a structural change in how organizations manage risk and make financial decisions.

What has changed is not simply how infrastructure is consumed, but the economic environment in which it exists.

Semiconductor volatility, driven by structural demand shifts, has introduced a level of uncertainty that traditional models are not designed to handle.

In this context, the question is no longer which platform offers the best performance or capacity metrics. The question is which model provides the greatest resilience — financially and operationally — in an unpredictable environment.

The answer, increasingly, is not to own the asset, but to manage the outcome.

For years, we optimized infrastructure decisions around performance, scale, and architecture. Those still matter.

But they are no longer the hardest part of the problem.

The hardest part is understanding the financial consequences of when you buy, how you buy, and what risk you take on when you do.

That’s what changed.

And once you see it, it’s very hard to go back.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

Important Note for my readers: Writing this piece took me a lot longer than I normally spend on a post. It took a lot of reading and research. Many articles and blogs were written on the subject before NAND and DRAM costs went crazy.

The dry-humor version is that the storage industry spent years insisting flash was just disk with better manners, and then acted surprised when the underlying physics eventually asked to speak with management.

Now, let’s get to it.

I can still picture the room.

It wasn’t anything special — just another corporate competitive training session, the kind you’ve sat through many times if you’ve spent enough years in enterprise tech.

This was at NetApp, in 2015 or 2016, back when flash was still a question mark. Not if, but how. The industry had not fully committed yet, and everyone was trying to figure out what role it would play.

The presenter clicked to the next slide, paused for a second, and said something that stuck with me in a way most of those sessions never do:

“Pure Storage is crazy! They’re building their own flash modules. That’s stupid. It’s not sustainable. They won’t survive.”

It wasn’t said for effect. There was no dramatic pause afterward, no attempt to persuade. It was delivered as a simple, almost obvious conclusion.

And to be fair, it felt obvious.

Because the entire storage industry operated on a shared assumption: you didn’t build components, you assembled them. You relied on a mature ecosystem of suppliers who specialized in drives, storage controllers, and memory, and you focused your differentiation on software features and integration. That was the efficient path. That was the scalable path. That was how serious companies behaved.

What Pure was proposing at the time — what would later become Everpure — felt like a deviation from that logic. Building your own flash modules didn’t just introduce complexity; it seemed to reject the economic advantages of the broader supply chain. It looked like a risk without a clear payoff.

So the conclusion made sense.

Until it didn’t.

Looking Back, Differently

If I think back to that training session now, I do not really see it as a moment where someone was foolish. I see it as a moment where the industry was trapped inside the logic of its own assumptions.

If you believe flash should look like disk, then building your own flash modules sounds silly.

If you believe storage is just a sequence of refresh cycles, then a model built around non-disruptive evolution sounds unnecessary.

If you believe component pricing will keep trending in the right direction forever, then architectural efficiency feels like an academic luxury.

But once those assumptions start to crack, the logic changes.

And when it changes, the things that once looked eccentric start to look oddly prescient.

A Change You Don’t Notice Right Away

For years, nothing about that statement felt particularly worth revisiting. The industry moved forward in predictable ways. Flash became mainstream. Performance improved. Density increased. Vendors competed on features, benchmarks, and price points. The conversations most of us had with customers followed familiar patterns.

If anything, the abstraction layers built around flash made things easier to consume. SSDs behaved like faster disks — and that was good enough. There is a reason they showed up in familiar HDD form factors. The industry was trying to preserve the old world while sneaking in a new medium. Keep the slots. Keep the enclosures. Keep the assumptions. Change as little as possible.

That made adoption easier, but it also buried the problem.

Because flash is not a disk. It never was. It does not behave like one, and it does not particularly enjoy being treated like one. The only reason the illusion worked is because the industry built a fairly elaborate translation layer to maintain it.

That translation layer is where the story really starts.

The Trick That Made Flash Look Simple

When commodity SSDs became the standard way to bring flash into enterprise storage, they depended on a piece of internal firmware called the Flash Translation Layer, or FTL.

Its job was deceptively simple: make raw NAND look like a disk.

That sounds harmless enough until you think about what that actually requires. NAND cannot just overwrite data in place the way the rest of the stack would like it to. It has to handle erase cycles, wear leveling, garbage collection, bad block management, and the constant translation between logical addresses and physical locations on the media. So every SSD became its own little self-contained world, complete with its own controller, its own metadata tables, and its own DRAM to keep track of everything.

In other words, every drive became a tiny independent computer, making local decisions in isolation.

That design solved the adoption problem. It did not solve the architecture problem.

For a while, the tradeoff seemed worth it. The drives were fast enough, the packaging was familiar, and the whole system kept pretending that flash was just a much nicer version of disk. But what looked neat and modular at small scale turned out to be awkward and expensive at enterprise scale.

And that is where the “stupid” decision begins to look a lot smarter.

What Commodity SSDs Actually Drag Along With Them

The more I researched this topic (and believe me I did), the more I realized how much of the industry got comfortable with an abstraction that was doing a lot of quiet damage.

Commodity SSDs carry four structural inefficiencies that matter much more today than they did when pricing was stable.

Trapped DRAM.

Every SSD maintains its own mapping tables, so large-scale systems end up carrying a remarkable amount of DRAM inside the drives themselves. That memory is necessary for the SSD to function, but it does not really help the array think globally. It is duplicated overhead, repeated again and again, drive by drive. In a petabyte-scale system, that is not a rounding error. It is cost, power, and complexity hiding in plain sight.

Unpredictable Latency.

Garbage collection inside a traditional SSD happens when the drive decides it needs to happen. When that occurs, the drive may become temporarily less responsive, and in an array full of independent drives, those little stalls start to show up as tail-latency spikes. The system is always vulnerable to one drive having a private crisis at exactly the wrong time.

Write Amplification.

Because the SSD does not really understand the workload or the data structures above it, it moves data more often than necessary. More movement means more writes. More writes mean more wear. More wear means the media gets consumed faster than it should.

Over-provisioning.

Every SSD holds back some raw capacity for its own housekeeping and spare-cell management, but that reserved space is siloed. The array cannot use it intelligently across the system because each drive is managing its own private affairs.

None of this sounded especially dramatic when NAND kept getting cheaper and the economics of flash kept improving. It sounded like engineering trivia. The sort of thing infrastructure people argue about while everyone else waits for the quote.

Today it is not trivia. Today it is exposure.

Why AI Made This Suddenly Everyone’s Problem

For years, one of the quiet assumptions in enterprise IT was that storage capacity would continue to become cheaper and more abundant over time. Not perfectly, not smoothly, but predictably enough that the inefficiencies of the underlying architecture could be tolerated.

That assumption is now not only under pressure, it is getting decimated.

AI did not just create a new category of interesting workloads. It created a global appetite for silicon that is large enough to bend supply curves. The cute part of AI is easy to mock. The cat kicking the T-Rex. The surreal generated videos. The deepfakes that make you look twice and then sigh a little for civilization.

But behind every one of those outputs is a less funny reality: extraordinary consumption of DRAM, NAND, GPUs, and supporting infrastructure. The novelty at the edge is powered by very serious resource demand at the core.

And that demand is landing directly on the components enterprise storage depends on.

This is the part customers are beginning to feel in ways that are no longer abstract. Expansion quotes do not look as comfortable as they once did. Refresh cycles feel more expensive. Delivery windows stretch. Budgets built on assumptions from even two years ago suddenly need more explaining than anyone wanted.

There is a tendency to call this inflation because that is the easiest word available.

It is not really inflation.

It is supply and demand, with a side of semiconductor reality.

And that matters, because a traditional SSD array is exposed to both sides of the problem at once. It is exposed to NAND because that is the medium you are buying, and it is exposed to DRAM because every SSD drags its own DRAM overhead along for the ride. When those two markets tighten at the same time, the cost of the architecture gets hit twice.

That is not just a technical nuance. That is economics.

Revisiting the “Stupid” Decision

This is where the old training-room comment starts to age badly.

Because what looked like unnecessary vertical integration was really a decision to stop pretending flash was a disk and start treating it like what it actually is: semiconductor media with very specific physical behaviors that should be managed at the system level, not hidden inside dozens of drives.

That is the DirectFlash idea in plain English.

Take the Flash Translation Layer out of the individual drive. Pull media management into the operating environment. Let Purity manage flash globally instead of leaving each device to improvise its own local strategy.

That changes more than performance charts.

It means metadata no longer has to be duplicated and trapped inside every SSD. It means wear leveling can happen across the full system instead of inside the borders of a single device. It means bad block handling, garbage collection, and data placement can be coordinated with global context. It means the platform can see the difference between data that should live together and data that should not, which dramatically reduces unnecessary movement and lowers write amplification.

And when write amplification drops, the economics change.

The NAND lasts longer. The useful life of the media extends. Lower-endurance flash, like QLC, becomes viable for serious enterprise use because the software is smart enough not to abuse it. The system extracts more useful work from the same raw silicon.

That is not just clever engineering. That is insulation from volatility.

The reason this matters now is that DirectFlash changes the ratio between the silicon you buy and the value you get from it. If the rest of the market is paying more for NAND and more for DRAM, an architecture that reduces trapped DRAM, minimizes wasted writes, extends media life, and packs far more capacity into far denser modules is not just elegant. It is economically defensive.

This is where the old “they build their own flash” criticism misses the point. Building your own flash modules was never the point by itself. The point was controlling the relationship between software and media well enough to eliminate the inefficiencies the commodity model had normalized.

Why Purity Is the Real Story

DirectFlash makes for a good visual. It is a module. You can point to it. You can talk about density and reliability and the fact that a 150TB module can do work that would have required a small army of traditional devices not all that long ago.

But the real story is Purity.

Purity is where the architectural bet pays off. It is what turns raw NAND into a coordinated system instead of a pile of politely disagreeing SSDs.

Because Purity sees the entire media pool, it can write more intelligently. It can group data with similar expected lifespans together, so that when a snapshot or a temporary workload disappears, whole regions of storage can be retired cleanly instead of forcing background reshuffling of still-live data. That reduces unnecessary churn. Less churn means fewer writes. Fewer writes mean longer media life.

Because Purity sees when a NAND die is busy with an erase or program cycle, it can avoid letting that become a host-visible performance problem. RAID-3D and system-level awareness allow the platform to reconstruct data from parity rather than simply waiting for a busy drive to get its act together. The end result is deterministic performance rather than a roulette wheel of occasional latency spikes.

Because Purity owns media management globally, the over-provisioning and spare resources are no longer trapped in per-drive silos. The system can use them strategically.

I know that all of this sounds a bit scientific, and to be fair, it is. I did spend over 7 years working for Everpure and a few weeks researching for this post. I wanted to sit with that science for a bit.

Where the Economics Start to Matter

The moment component pricing becomes unpredictable, architecture stops being an engineering preference and starts becoming a financial strategy.

That is the part that matters most to customers right now.

A traditional buying model assumes that at some point you will hit a refresh cycle, a capacity wall, or a migration event that forces a purchase whether the market timing is good or terrible. You buy when you have to buy. If NAND is expensive, that is unfortunate. If DRAM is expensive too, even better, because apparently the universe enjoys symmetry.

That is what makes the combination of DirectFlash and Evergreen so important. DirectFlash reduces the amount of waste, duplication, and premature wear in the system. Evergreen removes the old habit of tying innovation to forklift replacement. Controllers evolve. Capacity can be consolidated into denser modules over time. Data stays in place. The customer is not forced into rebuying the whole environment every few years just to remain current.

That already changes the economics.

But it still leaves one more question: who is carrying the price risk?

And this is where Evergreen//One matters more than ever.

The Part I Actually Wanted to Get To

Evergreen//One is not just a consumption model. It is not just a nicer way to finance storage. It is a mechanism for moving volatility away from the customer.

That is the conclusion I wanted to earn, not just declare.

When NAND and DRAM prices start climbing, most traditional models push that turbulence straight into the customer’s planning cycle. The customer eats the increase, absorbs the uncertainty, and tries to explain to the business why the infrastructure line now behaves like it has a gambling problem.

Evergreen//One changes that relationship.

The customer consumes capacity as a service. Everpure owns the burden of the underlying hardware lifecycle, the media strategy, and the ongoing optimization. DirectFlash makes that model stronger because the platform is structurally more efficient with the silicon it uses. It needs less trapped DRAM, wastes fewer writes, extends media life, and supports denser modules that deliver more usable capacity per unit of power, space, and raw media. Purity compounds that advantage with data reduction, ongoing software improvements, and smarter system-wide media management.

Put differently, Everpure is in a much better position to absorb and manage component volatility than a customer buying boxes on a refresh schedule.

That is the real price protection story.

Not some magical promise that economics no longer apply. They do. NAND still costs what NAND costs. DRAM still costs what DRAM costs. Physics remains annoyingly undefeated.

The difference is who is exposed to that volatility, how much inefficiency is built into the system before the customer ever sees it, and whether the operating model gives the customer a stable runway instead of a quarterly surprise.

DirectFlash reduces the waste.

Evergreen removes the forced disruption.

Evergreen//One shifts the risk.

That combination is a lot more interesting than it sounded in that room 11 years ago.

The Part I Didn’t Appreciate Then

What I did not understand sitting in that room 11 years ago was that some decisions are made for futures that have not arrived yet.

The market eventually caught up to the architecture.

That does not happen often enough in enterprise tech to ignore when it does.

DirectFlash was never interesting just because it was different. It was interesting because it removed layers of inherited inefficiency that the rest of the market had accepted as normal. And in a period where NAND and DRAM pricing are under pressure, removing inefficiency is no longer just a performance story. It is a protection story.

That is why this matters now.

Not because it makes for a clever slide.

Because it gives customers a more predictable way forward when the underlying component markets are anything but predictable.

And in the current environment, that might be the most practical definition of innovation there is.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

If you remember one thing from this article: infrastructure used to organize around applications.
Increasingly, now it organizes around data.

If you spend enough time around enterprise infrastructure, you start to notice something about how conversations begin.

Someone asks about storage. Not in a philosophical way. In a practical way.

How much capacity do we have left?
What’s the refresh cycle?
Is this staying on premises or moving to cloud?
What’s the backup strategy?

For years, that framing made perfect sense. Infrastructure was the foundation, and the job of infrastructure teams was to keep the lights on and the foundation solid.

But lately, in conversations with customers across state and local government, municipalities, cities, and universities, something feels different.

Because eventually someone says something like this:

“We have this data… but we can’t actually use it.”

And that is when the real conversation begins.

Why the public sector reveals the truth about data

There’s a perspective I heard recently that stuck with me.

The public sector isn’t a niche market.

It’s a microcosm of the entire enterprise technology world.

At first that sounds counterintuitive. The stereotype is that government IT has been quietly living under a rock since the previous century, next to a beige server and a stack of COBOL manuals.

But if you look closely, the opposite is true.

State agencies, cities, and research institutions operate in environments that combine nearly every architectural challenge the private sector faces — all at once.

• Massive datasets

• Highly distributed users

• Strict security requirements

• Long retention policies

• Global collaboration

And an absolute requirement that systems remain available when people need them most.

In other words, the public sector experiences the full spectrum of data challenges simultaneously.

If you want to stress-test a data architecture, put it inside government.

Think about it.

A state government may run thousands of systems across dozens of agencies, each serving different missions but increasingly sharing the same underlying data.

A city manages infrastructure at the physical edge of society — traffic, water, SCADA, emergency services — where real-time decisions depend on accurate information.

Universities generate some of the largest research datasets on earth while collaborating across institutions and countries.

Each of these environments demands something slightly different from infrastructure.

But they all demand the same thing from data:

Security.
Integrity.
Mobility.
Context.
Availability.

And when those requirements collide in one environment, something interesting happens.

The solutions that work there tend to work everywhere.

A laboratory for the modern data enterprise

This is why many technology leaders quietly view the public sector as something more than a vertical market.

It’s a laboratory for enterprise-scale data architecture.

If a platform can operate in a world where:

• sensitive personal data must remain protected
• systems span thousands of locations
• regulatory oversight is constant
• and uptime has real public consequences

…then that architecture will almost certainly succeed in commercial environments.

Banks, manufacturers, healthcare providers, and global enterprises face the same challenges.

Just rarely all at once.

Government simply compresses those problems into a single environment.

Solve the data problem for government, and you solve it for the enterprise.

That’s one reason the shift toward data-centric platforms is becoming so important.

When organizations treat infrastructure as a place to store files, they solve only a small part of the problem.

But when they treat data as the central operational asset — something that must be understood, governed, protected, and made usable across environments — the architecture begins to look very different.

And the public sector, with all its complexity, becomes the place where those architectures are tested first.

Which brings us back to the shift we’re seeing across the industry.

Because once you start looking at infrastructure through the lens of data itself, something else becomes obvious.

The center of gravity has moved.

When multiple systems depend on the same dataset,
the data becomes part of the operating foundation.

And once that happens, moving it — or even restructuring it — becomes dramatically harder.

Which brings us to the concept that explains a lot of what is happening right now.

The quiet physics of data gravity

The first time I heard the term “data gravity” wasn’t in a conference keynote or a vendor presentation.

It was in 2015, when a recruiter from a startup called DataGravity (now Anomalo) reached out and asked if I would be interested in interviewing.

At the time, the idea sounded fascinating — and slightly theoretical. The company was built around the premise that data itself was becoming the most valuable asset in the data center, and that infrastructure needed to understand the content, context, and behavior of data, not just store it. The name alone hinted at something deeper: the idea that as datasets grow, they start exerting a kind of gravitational pull on the systems around them.

Back then, it felt like an interesting concept.

Today it feels like a description of reality.

The term “data gravity” itself was introduced by Dave McCrory back in 2010, and it turns out to be a remarkably accurate way to describe modern infrastructure. Dave McCrory Blog

The idea is simple.

As datasets grow, they become harder to move. More applications depend on them. More workflows connect to them. More policies govern them.

Eventually, the architecture starts organizing around the data itself.

Not because someone designed it that way.

Because the physics of large systems leave you very little choice.

Imagine trying to relocate a state Medicaid dataset that has been integrated with multiple benefit programs, identity verification systems, and fraud detection tools.

Technically possible? Sure.

Operationally trivial? Not even close.

The larger and more interconnected the dataset becomes, the stronger its gravitational pull.

Compute moves closer to the data.

Applications move closer to the data.

Infrastructure reorganizes around the data.

This is why organizations that once talked primarily about storage capacity are now talking about data platforms.

The center of gravity moved.

When data stops being passive

The moment data becomes operational, everything changes.

For years, most organizations treated data as something that accumulated quietly inside systems. Applications produced it. Storage kept it safe. Backups made sure it could be restored.

But that model starts to break down when the data itself becomes part of real-time decision making.

You can see this most clearly in environments that generate enormous volumes of information.

Cities now run infrastructure that continuously streams telemetry — traffic sensors, utility meters, environmental monitors, emergency response platforms. A water meter that once reported usage once a month might now generate thousands of readings per year. A traffic system that once relied on static timing can adapt dynamically to real-time conditions.

Each improvement creates more data.

More importantly, it creates operational dependence on that data.

Universities experience the same phenomenon in a different form. Research environments produce extraordinary datasets across genomics, climate science, and artificial intelligence. Sequencing a single human genome generates roughly 100 gigabytes of raw data, and large research programs may create terabytes or petabytes of new information every week.

In those environments the challenge isn’t just storing data.

It’s feeding it fast enough to the systems that depend on it.

Modern research clusters and GPU environments can process enormous volumes of information, but only if the underlying data pipeline keeps up. When storage cannot deliver data fast enough, expensive compute resources sit idle and discovery slows down.

And that reveals an important truth about modern infrastructure.

When systems depend on data in real time, the question stops being where the infrastructure lives.
The question becomes whether the data is available, trustworthy, and recoverable.

That distinction also explains why ransomware has become so disruptive to public institutions.

Attackers understand that the real leverage is not the servers or the network.

It’s the data.

When access to data disappears, the services built on top of it disappear as well.

Which brings us back to the deeper shift happening across the industry.

If data has become this central to operations, services, and discovery, then managing it as a passive byproduct of infrastructure is no longer enough.

Infrastructure alone is no longer the strategic layer.

The strategic layer is the data itself.

Organizations still need performance, availability, and resilience. Those fundamentals have not changed.

What has changed is the expectation that infrastructure should also help organizations understand, govern, protect, and use their data more effectively.

That is a very different problem than simply storing it.

And it is the reason the conversation is evolving from storage management to data management platforms.

The real punch line

Public sector organizations didn’t set out to become data enterprises.

Over time the data accumulated.

Then the dependencies formed.

And eventually everything started orbiting the datasets that mattered most.

Data has gravity.
Data has risk.
Data has power.

Infrastructure still matters.

But increasingly, the real mission is something else entirely.

The mission is the data.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere

If you’ve worked at a large tech company long enough, you’ve survived at least one Annual Sales Kickoff.

You know the drill.

The main stage “rah-rah” opener with dramatic music.
The executive vision deck with 297 slides.
The breakout sessions that begin right after lunch.
The buffet chicken that tastes like it was optimized for margin.
The late-night “team bonding” that guarantees you’ll be running on fumes by 8:03 AM the next morning.

And then there’s the universal survival tactic.

You hold a sharpened pencil under your chin. Because if you nod off during a breakout session, the pencil will jab you awake before your manager notices.

We’ve all been there.

The Predictable Script

Most SKOs follow a predictable arc:

1. Celebrate last year.

2. Announce a new quota.

3. Promise that this is the year.

4. Release everyone into breakout rooms with too much carpet and too little oxygen.

Somewhere between slide 42 and 68, your brain quietly asks:

“Is this just the same story with different colors?”

Sometimes… it is. But every once in a while, something feels different.

When the Energy Is Real

This year felt different.

Because this wasn’t just a logo refresh.

Pure Storage becoming Everpure Inc. wasn’t a cosmetic exercise.

It was an admission. The word “storage” no longer captures what we actually do.

And that realization changes the narrative.

It Was Never Just About Arrays

If you spend enough time in customer meetings, you realize something.

Storage is the mechanism.

Data is the mission.

That shift — from product to platform, from hardware to data strategy — is what I felt this SKO.

The conversations weren’t just speeds and feeds.

They were about resilience.
Mobility.
Financial models.
Operational simplicity.
Long-term durability.

That’s not incremental.

That’s narrative transformation.

Why Rebrands Usually Fall Flat

Rebrands fail when they’re aspirational but disconnected from reality.

When the logo changes, but the conversations don’t.

When the tagline evolves, but the pitch stays the same.

But when the field already feels the shift — when customers are already engaging you differently — the rebrand becomes validation, not decoration.

The energy this time wasn’t forced.

It felt earned.

The Difference Between “Storage” and “Data”

“Storage” is a category.

“Data” is the bloodstream of the enterprise.

One is infrastructure.

The other is strategy.

When a company shifts its identity toward data itself, it signals that it intends to play at a higher level — not just in IT refresh cycles, but in boardroom conversations about risk, continuity, sustainability, and innovation.

That’s a different room.

And frankly, it’s a more interesting one.

Stepping Into the Arena

At one point during the sessions, the conversation moved in an unexpected direction.

Not toward technology. But toward mindset.

The idea of the arena was introduced through the story of Diana Nyad swimming from Cuba to Florida at the age of 64. One hundred and ten miles of open ocean, currents, jellyfish, exhaustion—the kind of challenge that looks irrational from the safety of dry land.

But the philosophy behind it goes back much further, to Theodore Roosevelt and his famous “Man in the Arena” speech.

That metaphor landed differently in a room full of people who spend their days helping customers deal with the chaos surrounding their data.

Because the arena, in our world, isn’t theoretical.

It’s ransomware attacks at three in the morning.
It’s modernization projects colliding with legacy systems.
It’s AI initiatives that stall because the data isn’t where it needs to be.

If Everpure represents anything, it’s the recognition that the real mission isn’t selling infrastructure.

It’s helping customers take control of their data, even when the situation is messy.

Especially when it’s messy.

From Pirates to a Navy

Another metaphor that stuck with me was the idea that for years the company operated like pirates.

Scrappy. Fast-moving. Independent. A little rebellious.

That pirate spirit was essential in the early days. When you’re challenging established vendors in a mature industry, a bit of disruption—and a willingness to break a few conventions—is often exactly what’s required.

But pirates are built for raids.

They’re not built for long campaigns.

To reach the next horizon, the company has to evolve into something different: a navy.

Still bold. Still mission-driven.
But disciplined, coordinated, and operating at global scale.

The pirate energy built the company.

The navy discipline is what allows it to navigate the far more complex world of data itself.

The Last Word

Interestingly, the day didn’t end with a revenue slide.

It ended with a single word.

Integrity.

Because when you strip away the technology, the roadmaps, the logos, and the SKO theatrics, a company is ultimately just a collection of people making commitments.

Integrity means showing up when things break.
It means caring about the customer’s outcome more than the short-term optics of a deal.
It means understanding that the mission isn’t infrastructure.

It’s data. And helping customers trust it.

No Pencil Required

This SKO didn’t need a sharpened pencil under my chin.

Not because there weren’t long sessions.

Not because the food suddenly became Michelin-rated.

But because the narrative felt aligned with what we’re already seeing in the field.

When the brand catches up to the evolution of the company, the energy doesn’t need to be manufactured. It’s already there.

And that’s when a rebrand stops being marketing.

And starts being momentum.

Appreciate you reading.

Dmitry Gorbatov

© 2025 Dmitry Gorbatov | #dmitrywashere