I was in Memphis recently for a data summit hosted by GDS. Spoke about data governance — not the sexiest topic on the agenda, I'll admit. But stay with me.
Because Memphis does something to you. You can't be in that city without feeling the weight of music history everywhere. GDS took us to Graceland and when i stood at Elvis’s display of his collection of cars, it hit me.

Elvis understood something that the financial world is still figuring out. He didn't just make music. He built a system around himself - a label, a manager, a brand, a way of distributing value at scale. And when the context changed, when the industry shifted, when the culture moved on , the systems built around him couldn't adapt fast enough. The infrastructure outlived its moment.

I kept thinking about that on the flight home. Because it's exactly what's happening right now with enterprise data and agentic AI.

The context is shifting fast. AI agents are moving from experiment to production. They're not just answering questions anymore. They're making decisions, triggering workflows, acting autonomously. And the data infrastructure most organisations are sitting on was built for a completely different world, one where a human analyst always sat between the data and the decision.

That human is being removed from the loop. The systems are being asked to do something they were never designed for.

And almost nobody is ready.

The shift nobody is talking about loudly enough

For years, data governance meant gatekeeping. You defined what was valid, what wasn't, and you enforced it. Rules said a customer status could only be A, I or S. Reference tables told you what currency codes were acceptable. Validation checks fired when something looked wrong.

The human analyst was always the context layer sitting on top of all of it. They knew that last quarter's revenue figure was restated. They knew the region split happened mid-year. They knew that a product code of 999999 meant a test record. They carried all of that in their heads, and when the data landed on their desk, they applied judgment.

An AI agent has none of that. Not unless you give it explicitly.

This is the shift. We've moved from asking is this data correct? to needing to ask does this data make sense? And those two questions, despite sounding similar, are entirely different problems.

Gatekeeping says: does this value conform to the rules?

Context giving says: does this data carry enough meaning for a machine to reason with it safely?

What agentic AI actually does with your data

An agentic AI system doesn't just read your data. It acts on it. It makes decisions, triggers workflows, produces recommendations, sometimes executes transactions — all at machine speed, with no human in the loop to catch a nuance.
In a traditional analytics world, a data quality issue was a nuisance. A wrong number ended up in a report and someone eventually caught it. The feedback loop was slow but it existed.
In an agentic world, if a data pipeline drifts, the agent doesn't report the wrong number. It takes the wrong action. It routes the wrong customer. It provisions the wrong resource. It flags the wrong risk. And by the time anyone notices, the downstream effects are already compounding.

This is not a future problem. It's a now problem, for any organisation moving AI agents into production.

Before you even think about agents, get your data house in order. That means five things, done properly: audit what your data actually knows about itself — every edge case and institutional quirk that currently lives in someone's head needs to be written down and attached to the data. Graduate your business glossary from a Confluence page to a machine-readable semantic layer with real definitions, not just allowed values. Replace pass/fail validation with confidence scores that tell agents how much to trust a field, not just whether it's technically valid. Attach provenance and temporal context to everything — where it came from, what touched it, and whether it's still current. And move your quality monitoring upstream into the pipeline itself, not at the end where a batch job catches problems after an agent has already acted on them.

How developers should think about this differently

If you're building data models and systems that agentic AI will consume, the mental model needs to shift from schema design to context engineering. A database schema tells a machine what shape the data is in. Context engineering tells a machine what the data means and how to reason with it safely.

Practically that means a few things.

Design data products, not just tables. A data product is a complete package — the data itself, comprehensive metadata, a semantic model, quality metrics, lineage information and usage guidelines. It's structured so both humans and AI agents can consume it. A table is just rows and columns. A data product is rows and columns plus the briefing notes.

Build for semantic validation, not just syntactic validation. Syntactic validation checks that a date is a date and a number is a number. Semantic validation checks whether the values make sense in context — are they plausible, are the relationships consistent, do they match what we'd expect given everything else we know? This is harder to build but it's what agents actually need.

Expose data through governed APIs, not raw database access. When an agent queries for customer data, it should get back data with lineage, confidence scores and transformation context — not just rows. The architecture should enforce this. If an agent can reach around the governed layer and hit the raw database, eventually it will, and the results will be unpredictable.

Think in context windows, not just queries. When you write a SQL query, you're asking a precise question. When an agent queries your data, it's building a context window to reason over. That context needs to be coherent - internally consistent, appropriately scoped, with no silent contradictions between fields. Developers need to start thinking about what a coherent context package looks like for the use cases their agents will handle.

Design for graceful uncertainty. Agents should never silently act on data they can't trust. Build your systems so that low-confidence data surfaces a flag, not a confident answer. The agent should be able to say, I can see the data but the confidence here is marginal, I'm going to ask for review rather than proceed. That behaviour needs to be architected in. It won't emerge on its own.

The uncomfortable takeaway

Agentic AI won't fix a messy data operating model. It will expose it and amplify it.

If your definitions drift, if ownership is unclear, if your data carries no context beyond its values, agents will simply move the chaos faster. At machine speed, with no human catching the mistakes before they compound.

The organisations that get this right won't be the ones that deploy the most agents. They'll be the ones that invested in making their data smart enough to be trusted by a machine.

That work is unglamorous. It doesn't get announced in press releases. It looks like governance, which is historically the thing everyone agrees matters and nobody funds properly.

But it is the actual work. And the window to do it before the agents are already in production, already acting, already compounding errors - is narrowing.

Part 2 teaser:

Next issue I'm going deep on the developer side of this - what context engineering actually looks like in code. Real schema examples, a confidence scoring implementation, and the governed API pattern that stops agents from acting on data they shouldn't trust. If you work with data systems or build for AI, that's the one for you.

Part 2: Building Data for Agents - A Developer's Guide to Context Engineering. Landing in your inbox next week.

Did You Know? Why did i compare Elvis’s 1957 to what is changing in tech now. I want to deep dive into what i learned about Elvis .

Most people think of Elvis as a singer. But what Colonel Tom Parker - his manager, built around him was an early version of what we'd now call a platform business. Elvis was the product, but the system around him was the business. Record deals structured to extract maximum value. Merchandise licensing before anyone called it that. Film contracts. Vegas residencies. A machine that turned one person's talent into recurring revenue at scale.

That's the "distributing value at scale" part. He didn't just perform. He had infrastructure.

What went wrong

The music industry shifted. Rock and roll gave way to other genres. Culture moved on. New artists emerged. The world changed.

But the system built around Elvis - the contracts, the management structure, the way he was packaged and sold - was rigid. It was optimised for a specific moment in time. When that moment passed, the infrastructure couldn't flex. It was built for the Elvis of 1957, not the Elvis of 1977.

The infrastructure outlived its moment means the machinery kept running long after the conditions that made it work had changed. The machine was still there. The moment it was built for wasn't.

Why this connects to enterprise data

Most organisations built their data infrastructure for a specific moment too - one where a human analyst always sat between the data and the decision. The analyst was the flexible, adaptive layer. They absorbed the context gaps, applied the judgment, caught the edge cases.

Agentic AI is removing that analyst from the loop. And the infrastructure - the schemas, the pipelines, the validation rules - was never built to handle that. It was built for a world that's changing faster than most teams have noticed.

The data infrastructure, like Elvis's machine, risks outliving its moment.

That's the connection. And that's why it fits Basis Points & Beats perfectly .

Till next time,