Before I started this newsletter, a simple Google search of the data ecosystem would often return a technical view of a company’s tooling landscape.

But no one was explaining it like that, and all the material out there was specific to each domain, without doing the work to connect the dots between them. So I did my best to do that, and created this newsletter. This included my view of the entire Data Ecosystem on one page (which has been redrawn many times). Business drivers on the left. The data lifecycle running through the middle. Consumption and decisioning on the right. Underpinning management along the bottom, holding all of it up, and the other influences/ considerations around the edges.

This infographic was great for explaining the complexity of data, especially to consulting clients. It drove home the point that your data problems aren’t contained to one domain but need to be viewed holistically. And while it is complex, data largely flows through in a process-like way, from strategy on the left to the data lifecycle hosted on a platform, with analytics turning it into an insight/decision at the end.

But in the past year, AI has gotten so prominent that it changed the map; in fact, it changed the ecosystem!

Instead of being a domain or a piece of the process, it runs through the entire ecosystem. If data is the sun that powers the ecosystem, AI is the air that each domain interacts with to function.

This shift has led me to rename my newsletter The Data and AI Ecosystem. It has also led me to write a lot more about AI, as you’ve seen in the past 10 or so articles.

The Data & AI Ecosystem is a single-page view of everything that must work together for an organization to derive value from its data and AI: business drivers, the data lifecycle, consumption and decision-making, the management that underpins them, and the external influences at the edges.

But before I go too far down more topics, domains, and articles on AI, I want to holistically evaluate how the data ecosystem has evolved to incorporate the new power of AI.

Share

This article & newsletter is free, which means passing it on is the only way it grows. If it was useful to you, it’s probably useful to someone on your team.

Why the Data Ecosystem became the Data & AI Ecosystem

I will always be the first to say that AI is not magic and that there are many gaps in the technology. I’ve created countless memes making fun of it and how companies are over-hyping it in their sales and marketing channels to drive sales/ revenue.

But, like all technology, AI has evolved and advanced to a point where it is legitimately changing the industry at a pace no one has ever seen before.

And I’m still skeptical of AI, but I’m skeptical of bolt-on AI, where somebody expects it to overcompensate for foundations that don’t exist. Without reliable definitions to work from, agreed/ governed metrics, data lineage, and any other additional context, the model won’t give you what you want, especially if you are prompting it with one vague sentence (like we so often do). And most data isn’t ready for AI (only 7% of orgs according to HBR), so bolt-on models really don’t work!

Now when we move from bolt-on AI to embedded AI, that is where we are starting to see stuff that looks like magic. This is not a surprise to anybody who has read this newsletter before, but the companies and individuals who started with data and context at the foundational level and embedded AI from there are not only getting exceptional value from AI but are changing how we work and how the economy functions.

For reference, bolt-on AI expects the model to compensate for foundations that don’t exist. Embedded AI starts from data and context and builds outward.

Share The Data & AI Ecosystem

So instead of AI being a domain tacked on to the data science/consumption part of the process, it flows through from start to finish. Every domain therefore needs to evolve, because the domains now work differently, both in how they are done, who does them (not always humans anymore), and what they output.

The rest of the article digs into this (well as much as I can in a twelve-minute article). We are going to walk through the updated map and how the different domains within each section have evolved with AI.

The Eight Zones of the Data & AI Ecosystem

1) Business Drivers Still Come First

Data never starts with Python, SQL or any technical code; it starts with the business.

That hasn’t changed with AI. But what we have seen is that the business is now obsessed with AI, and thereby inadvertently obsessed with data (even if they don’t know it).

The business model is the clearest example, which I’ve written about extensively. Companies have changed how they operate because of AI (e.g., how they staff/ resource, generate revenue, go-to-market, etc.). This flows into the business strategy, which now has to incorporate AI into the planning cycle as a core facet rather than the “nice-to-do” enabler that data was.

AI also changes the operational components of this section. The business needs and requirements, stakeholder alignment, and the operating model all have to take into account that the business is already using AI tools, and that getting them to work well in the organization starts from the beginning. Organizations now expect AI Agents to do a lot of the work, which impacts how we need to scope out new products/ workflows, enable existing employees, and even rethink the org structure. The key thing here is to be realistic with expectations and learn to crawl, then walk, and then run before you expect that rocketship AI growth that executives are all talking about.

Share

Then you have the Data & AI Strategy which should encompass all these changes and help organizations build on the right foundations. This will help show the path to success and sustainable AI usage, but only if it considers the underlying data components that enable AI. The strategy will also inform any Data & AI investment decisions, the overall approach/ philosophy and the use cases that both business and data teams will execute against.

2) Data & AI Modeling and the Context Layer

Data and AI modeling and the context layer is the first of two new zones on the map. You used to scope the use cases and then dive right into sourcing and ingesting data to build solutions. That process isn’t as straightforward anymore.

Instead, people are spinning up POCs like it’s nothing. To do it correctly, however, you need to start with the AI engineering and the context graphing. First, think about the Data & AI architecture in how the use cases/ solutions should be structured (e.g., is it a deterministic script or completely AI-enabled), and how the data model fits into that. Second—and building on the data model—how is all the data and business knowledge represented in the organization. This is the context that everybody is talking about right now (e.g., ontologies and business glossaries, the semantic and context layer, the knowledge graph), which is poorly done at most organizations because they haven’t put the time and effort into this increasingly important domain. Now, Futurum estimates 59% of enterprise decision-makers are directing new budget toward semantic layers, so this capability is coming.

Oh, I also added in agentic retrieval, because more often than not, humans are handing over information retrieval to AI agents, where the system decides for itself what it needs to fetch rather than having a fixed query. Without a well-modeled data foundation or context, this can go quite poorly.

On my old map, knowledge graphs and the semantic layer were listed under surrounding influences, filed as new technology worth keeping an eye on. Well, embedded AI has gone and made them really relevant, really fast, and honestly, I view these as one of the biggest enablers of your whole Data & AI Ecosystem if done right.

3) The Data Lifecycle Looks the Same But Works Completely Differently

Despite the promises of AI, companies still need to source, ingest, process and serve data.

How they go about it, however, has changed with AI. Data sourcing is the mildest shift, as the types of data haven’t changed, but the ease of pulling unstructured and operational content into your processes has made this so much easier.

For integration and storage, the classic ETL approach is no longer the only way—and in many cases, it isn’t the right way. Your architecture now has to be designed for agents as consumers. Meanwhile, AI has sped up engineering to a ridiculous degree (but with more data and builds, it usually leads to more engineering requests). The platform infrastructure also looks different, especially as tools themselves embed AI agents, skills, or features that make jobs easier.

Processing and serving got more complicated. You have to know what you want from your processing and serving layer because you could have deterministic jobs, LLM-driven outputs, or completely self-serve. The solutions architecture and orchestration within that will continue to evolve at pace, and is definitely something to keep an eye on. This bleeds into the Data Analytics & Consumption segment, which used to be the fourth box within the Data Lifecycle Process, but it now belongs with consumption given all these changes with AI.

Overall, the lifecycle process looks similar, but AI has significantly changed how practitioners work inside it. If you aren’t using (or at least thinking about) AI to do your job in these domains, you are falling behind.

4) Embedded AI: agents, evals, guardrails and MCP

Embedded AI is the second new zone: agentic workflows, the AI harnesses and models underneath them (think Claude or ChatGPT), AI literacy and policies, skills and prompting, evals and guardrails, and MCPs connecting all of it to the systems. When I was skeptical of AI, it was as a bolt-on technology. But when it is properly embedded, it is a huge differentiator.

Done well, these things touch everything else. It should read from the context layer, act on/ with the data lifecycle, and produce outputs that are consumed by both business and data stakeholders. It also needs guardrails, governance, and literacy for people to make the most of it.

Subscribe now

This box will probably change in the next year. Most of these components weren’t common terms six months ago, and there is no established best practice for any of it. Nonetheless, this is quickly becoming one of the most important areas of the Data & AI Ecosystem, not least because it enables the true democratization of data & AI across the organization.

5) Analytics and Consumption Is No Longer the Last Mile

AI’s biggest shift for most companies is the fact that analytics and consumption is no longer dependent on the data team, it can be prompted through an AI harness.

The question of whether BI, ML & analytics tools, and data/ AI product builds should be one-off prompted through an AI harness is a completely different story. But, you know what, we are here and it is happening so we may as well not ignore that truth…

So Data & AI democratization is here. After spending a decade doing Tableau and SQL trainings, the trick ended up being natural language conversational interfaces that can connect right into the data platform. For some, this is a win, but at the same time, data teams need to make sure the previous steps (data lifecycle, data & AI modeling, context layer) are done well so that some COO isn't pulling a report that is completely wrong and off-base. There also has to be strong data & AI management to underpin that (but more on that later).

6) Business Decisioning & AI Operationalization

Everything comes back to this. Making decisions from your data or AI tools is why everything else is done.

Data literacy has become even more essential; with people now using AI daily, they need to understand the role of data in those interactions. This ranges from data privacy, regulations, garbage-in-garbage-out, etc. Data literacy isn’t just BI or reading visualizations anymore.

On the business case and value creation sides, AI has falsely made it seem that everything is cheap to build. In reality, there needs to be more scrutiny on how this process takes place. To consider the short-term gains and the long-term impact in managing these tools that make decisions for the business.

The new addition here is AI operationalization, which is all about how AI runs in an organization, makes decisions, and takes action without doing something incorrectly.

Oh, I’ve also included a feedback loop. Given the importance of AI to the business model and strategy, there needs to be better feedback mechanisms to ensure the organization knows what it can and should do with AI and how it’s performing.

7) Underpinning Management Just Gets More Important

The names of most of these domains have not changed. But what does change is that management is no longer just done by and for humans; nope, we need to consider how AI and agents play into it all.

Data & AI governance has the hardest job. It’s a domain that never got enough investment, and now it has to help govern AI usage within the systems that manage data. When I wrote about AI Governance, the domain was still early, so I led on governing from a value-led perspective. But now, this has extended into guardrails, boundaries and policies for embedded and agentic AI usage.

Share

Observability now goes beyond determining when pipelines run and has extended to understanding how the AI works and routes through the data systems, especially when something doesn’t go right. Data contracts has evolved to not only have humans as customers, but also agentic systems. The agentic evolution makes them that much more important too, because if you want your AI to work properly, then contracts are a good solution. And of course data quality has become even more important as there is no data team between the query and the output, so ensuring reliability, accuracy, and consistency helps ensure outputs can be trusted. Master data management follows the same path, focused on repurposing the highest value data assets in the organization for direct AI usage.

Data privacy and security concerns continue to grow as the efficacy of AI models have increased, especially when it comes to hacking/ cybersecurity. Hence the new domain of AI security, which concerns how to protect your own systems from AI and ensure your AI works properly within your own boundaries. Data catalogues/ lineage becomes more important to inform/ audit the context layer. Finally, DevOps/DataOps principles are essential and need to be considered when building new AI products; hence the birth of AgenticOps.

8) The Other Edge Considerations

Finally, the last bit is the outer edges of the map.

All of these have evolved due to AI. Within the strategic considerations, obviously the technology strategy needs to now consider AI tooling and how that embeds in the platform. A holistic view of this is essential, so enterprise architecture becomes even more important, planning your technology estate for the fast-paced world of AI. The other big one is change management. Every organization out there is having a very tough time with AI enablement, and proper change management principles/ delivery is going to be essential to driving proper adoption (rather than AI usage without the right training/ oversight).

As some surrounding influences have graduated into the other realms, the rest have just intensified with AI. The market has completely shifted with new AI tools and companies. Ethics now includes the question of how do we work with AI responsibly, which creates another level on top of the data layer. Training and development becomes even more important as the whole organization is working with AI and they need the skills to do so properly. I’ve also added AI advancements as an influence in its own right, because the capability will continue to evolve and companies need to pay attention to how that changes/ shifts.

Why An Ecosystem View Matters

Nobody knows what AI will look like in a year or two. I don’t.

But I do know it will play a part in how we work, especially for those in the data industry.

And I also know that a holistic, ecosystem perspective (rather than a siloed domain view) will help you understand and enable AI in your organization/ life. AI is about systems thinking, and taking a holistic approach is one of the best ways to do that.

I mean, don’t trust me. As you’ve probably heard 1,000x, AI is only ever as good as the data underneath it. And that data is produced, managed and manipulated by an entire ecosystem (including humans, tools, and AI).

Share The Data & AI Ecosystem

So thank you for sticking with me all this time. Or if you’re new to the Data & AI ecosystem, thank you for joining in.

There is a hell of a lot to dig into over the next while, and I hope you find this newsletter helpful for everything you’re doing in the data and AI space.

Next Sunday I’m digging into a long-running blocker in this industry—debt. First we start with tech debt, then data debt, and finally a newly emerging form of debt, AI debt. Honestly, this topic has been sitting in the corner of my map as for three years, and it is one of the biggest blockers to progress, so it’s nice to finally dig into it, especially with the capabilities of AI at our disposal!

If this was useful, please send this article to one or two people who’d get something out of it. Otherwise, see you all next week, and have a great Sunday!

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share The Data Ecosystem

Share

Subscribe now

Have I given into the marketing trends of putting “AI” before everything? I mean, kind of...

But more than that, the direction of this newsletter and what is important in the data world has shifted.

And even newsletters have to evolve with the times. This is my announcement post on what is changing, why it is changing and where we are hopefully headed!

Why the Name is Changing

The most obvious change will be the name.

Beyond the marketing clickbait, AI is extremely prevalent, not going away any time soon, and worth continued exploration.

For three years, the argument in this newsletter has been that data isn’t a stack of tools, it’s an interconnected ecosystem, and that almost every failure I see in the field comes from treating the domains separately from one another. AI joins that interconnectedness, and probably makes it even harder to conceptualize how it all fits together.

Subscribe now

I will write more about this on Sunday, but my original Data Ecosystem map/ infographic is outdated and needs to evolve. For example:

• Data governance now includes AI governance

• The semantic layer became the context layer

• Data ingestion is no longer simply ETL engineering through fixed pipeline builds, but is now MCP connectors, agentic builds, and modified schemas/ architectures to adhere to AI needs

• Most notably, the audience for data & AI has extended to non-data people, who now interact with data regularly through AI tools without touching a line of code

All of this just means that the name should evolve, just as the ecosystem is evolving (it’s basically Darwinism/ survival of the fittest and I want my newsletter to be fit for purpose in today’s world).

The Other Reason...

All of this comes at a time where I also need to evolve this newsletter to stand out against the mass amount of genericized AI slop that is being written. People have too much information and not enough time.

And in full transparency, this is tough for me. I put a lot of time into each article and hand-make the infographics, yet AI-generated text and graphics still win out.

But I will persevere. And I know that if I want you, as the reader, to engage with my content, I need to deliver high-quality outputs that you find practical and that help you on whatever journey you are on. Whether that be professionally helpful, driven by a desire to learn, or just for fun, I want to know why you read and how to better build this newsletter for you. So any content topics, suggestions, or critiques are very welcome, as this newsletter is for you and will never be a genericized AI blog.

Therefore the other reason for the rebrand is to stand out in this new world and recast the newsletter aligned to what you, as the reader, want to consume as I battle for your attention!

So What is Changing?

The content, the deep dives, and the overall approach to the newsletter will stay largely the same. I feel that now more than ever, we need authentic writing that encapsulates topics in a non-generic way.

Share The Data Ecosystem

Three things I plan to add/ change:

1. More Practical Articles - I want to release more pieces about how I actually use AI day to day, and about the artifacts I’ve built for different data domains in my consulting work. Less “here is how to think about this,” more “here is the thing, here is how it was built, take it.” Some examples will be data governance artifacts, technical architecture overviews, and agentic workflows I’ve redesigned. Very open to suggestions from readers!

2. LinkedIn and Medium - I’m expanding this newsletter to the LinkedIn newsletters platform and Medium as well, basically to boost the reach I can get out there. Honestly, this has no impact on you (unless you prefer those sites), but I thought I’d mention it. The Sunday piece will run in all three places. Any mid-week or practical sharing posts will stay here on Substack

3. Paid Subscriptions - Finally, I’m turning on paid subscriptions. The primary reason I’m doing this is to access all the features that Substack has for paid newsletters that they don’t have for completely free newsletters (I also hate their subscription structure, hint hint Substack). My goal is to still explain The Data & AI Ecosystem to all people whether they have money to pitch or not. With that being said, feel free to pledge support or contribute if you feel my content is worth it, I appreciate everything that comes my way. And there may be some perks coming through as well (more on this below)

Nothing will move behind a paywall today, and the Sunday deep dive won’t either. If anything changes/ updates, you will hear about it!

Oh, and one thing I also want to mention is paid partnerships/sponsorships. As you might have read, I’ve done a few articles with some very kind data companies. Each time I do this, I very strictly vet the company and their product to make sure it aligns with a topic in the data ecosystem I want to write about. I also make sure that these articles demonstrate a genuine need in the data and AI space.

If you are able to give these articles some love or share them if you think any of these products might be helpful for you or someone you know, that would be awesome (and let me know too). These kinds of partnerships help make the content free and keep me writing on a weekly basis.

The Future of Paid

So I do want to add legitimate perks to the paid plan; my only barrier right now is time. With that being said, here is what I’m thinking:

• Paywalled articles, either from the archive or new ones

• Sessions where you can ask me anything

• Shared artifacts, templates, etc.

• An interactive site or repository where you can get information, query definitions across the data & AI ecosystem, and even potentially ask questions related to the content with a gen AI response engine (ambitious but I think this would be super cool and useful)

These are future plans and I’ll keep you posted on when they get added into the paid subscription. I’m also open to any suggestions you might have!

Also, while super ambitious, I would love to make that last one a reality. The original pitch for this newsletter, back in Issue #1, was that it would be the CliffsNotes for the entire data industry. The Substack format isn’t the most conducive for that, so would love to build something that acts as a real repository of all I’ve written over the years!

What’s Next

Sometimes I feel like I’m behind in AI.

I honestly don’t have a team of agents doing my work and automating my life. I haven’t figured out how to build my own open-source harness yet, and a lot of my AI-built tools are going stale.

So as I close this off, I want to say THANK YOU for reading, especially if you’ve been here since the early issues and consumed at least some of the 70+ articles I’ve written. Hopefully you’ve gained something from my work and keen to keep that value going for you!

And again if there’s something you want covered, a build you may want to offer or something I’ve got wrong, reply to this email, message me direct in Substack or LinkedIn or leave a comment. I’m very responsive :)

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Subscribe now

Share

Share The Data Ecosystem

You’re halfway through your first coffee on Monday morning when the email lands.

The COO has a new priority for the data team. By 9.30, you’re in a planning meeting being asked when you can start.

You ask the obvious question: what should come off the roadmap to make room?

“It’s all priority,” apparently. Nothing can be taken off the roadmap or pushed to a later date. The platform migration, regulatory work and VP dashboard are all still urgent.

Someone’s got a weird understanding of the word “priority”...

In classic fashion, when everything is labelled a priority, nothing actually is prioritised.

I hear the same tension from data leaders all the time–there is no good answer…

• A direct “no” can piss off the executive asking and make you look difficult or unable to deliver.

• Another “yes” spreads the same people across more work. Everything takes longer, mistakes creep in and the same stakeholders ask why the data team is so slow.

Many organisations have adopted agile ceremonies without the trade-offs that make agile work. If a new priority arrives and nothing comes off the roadmap, the team isn’t agile. It’s overloaded.

The trick isn’t to say no more forcefully. It’s to make the cost of yes visible: “We can build that dashboard. It means pausing the demand forecasting model, which is projected to save £1.2m this year. Do you want to make that swap?”

Value from Data & AI

A newsletter about data & AI product management

By Nick Zervoudis

That’s saying no without saying no. You’re helping stakeholders decide what happens now, what waits and what the business chooses not to do.

And look, the new idea may be good. The question is whether it’s a better use of time and money than the work it would displace. That’s value-driven prioritisation: making trade-offs visible so leadership can make an informed choice.

Why saying yes is getting more expensive

Doing this type of analysis was always important, but companies just didn’t bother with it. It was simply easier to fly under the radar when capital was cheap and growth often mattered more than profitability. The zero-interest-rate policy (ZIRP) era is over. Profitability and value are back at the centre.

AI makes this worse. Prototypes take days (even hours) to build, creating more plausible projects without creating more delivery or change capacity.

Share The Data Ecosystem

The stakes are personal as well as operational. If delivery keeps slowing while the function still looks expensive, budget and headcount will come under pressure. It affects your longer-term trajectory too: whether you are trusted with bigger decisions or left managing an expensive service desk.

And look, this isn’t an argument against technology or a claim that the data team should own the benefit. Technical judgement is essential. It’s just that it needs to sit alongside a method for turning technology requests into business problems, and then into comparable investment choices.

Because in the end, everything comes down to a ‘show me the money’ mentality for executives!

Yet despite that perspective, stakeholders rarely arrive with a neatly defined business problem. They arrive with a request - “can you pull me some data on X?” - or a solution - “we should be recommending products to customers, with AI”. First get underneath it: what is happening in the business, for whom, and what should change? Until you can describe the problem without naming the technology, you don’t have a use case.

(Scoping out the use case is a whole different article. It just so happens that Dylan wrote about this last week.)

Even then, you have only established that the idea is sensible. It may still be too small, too expensive or less valuable than something else. That value pressure test is where data and AI teams are still weak.

Share

Over more than a decade of client and in-house delivery, I’ve seen both versions. Here are two of them.

A good use case is not necessarily a good investment

The Failure Example: In-house

At a previous employer, our global data and analytics centre of excellence worked like an internal consultancy. Business units brought us data work; we scoped, staffed and delivered it.

Too often, a senior conversation became weeks of proposal work before we discovered the project was a dead end. Or worse, after we had already completed an initial phase.

So when one business unit arrived with well-scoped projects, defined problems and a business case for each, it felt different. Better still, the work meant more headcount and budget for our team.

…They pulled the plug a few months in.

This cost everyone time and money. The business unit was cross-charged for the work we had already done. It cost us as well: we had hired contractors for the project, and our permanent team had spent months on it rather than going after other work that could actually have added value. At best, the cross-charge helped us break even, but the opportunity cost remained.

And none of this required sophisticated analysis. It was back-of-the-envelope arithmetic that they had not done, and that we, just as damningly, had not challenged them to do.

It simply came down to the fact that nobody had checked whether it was worth the money.

And, weirdly, stopping after a few months was the best possible outcome. Leaders often fall for the sunk-cost fallacy and keep going. The more dangerous result would have looked like success: something that worked, was used and delivered a benefit, but still cost more than it returned. We would have spent far more money reaching an ROI-negative outcome.

Killing a weak project early is good governance. Successfully delivering an ROI-negative one is still value destruction (despite how nicely it is framed on the person’s CV…).

The Better Process: A client portfolio engagement

Years later, I worked with a multi-billion-pound consumer business whose CFO asked the question every data leader now gets asked: “What should we do with AI?”

First we had to reframe it. “What should we do with AI?” is a solution looking for problems; the useful question is “which business problems are worth solving, and for each one, is the right intervention BI, analytics, ML, an LLM, or a process change that needs no technology at all?” No amount of value sizing rescues a technology in search of a problem. But that only got us to a set of sensible use cases. It didn’t tell us where to put the money.

Subscribe now

Over roughly four weeks, working with the CFO, the finance director and business unit heads, we built a portfolio view: 24 candidate use cases, each expressed as a business problem. In the end, 11 survived first contact on feasibility and data readiness, and we recommended 4 for immediate focus/ implementation. Each had a one-page investment case:

• Rough five-year value

• Total expected cost

• Feasibility

• Blockers

• How it related to transformation work already in flight

• And crucially, the explicit list of things the use case would not do (especially important in this world of “AI can do everything…”)

Most of the seven feasible options we did not recommend for immediate focus were still expected to be ROI-positive. They missed the cut because their expected return was lower once dependencies and timing were taken into account, or because they conflicted with strategic initiatives already under way. They were not bad ideas, but were weaker choices for the money and would have detracted from the other builds.

Another important difference from the failed case: the assumptions were validated and corroborated by the data team, the business owners, and Finance. Each target had a named business sponsor who was prepared to be held accountable for it. They were still estimates, obviously, but they were not figures any one team had invented on its own.

Share

While the engagement started with the CFO asking about Generative AI, in the end, three of the four initiatives we recommended had no LLM component at all. They were more familiar data and analytics work: marketing-mix modelling, predictive support for capital-investment decisions and demand forecasting. The fourth was an internal LLM assistant.

That was the point of the value lens. It helped us prioritise the strongest opportunities and gave us a defensible way to say no to a long list of plausible GenAI proofs of concept that seemed sexy but were unlikely to be good uses of time and money.

A business case is not permission

The problem with business cases is that sometimes you get a case of corporate bystander effect: everybody assumes somebody else has checked the maths.

For data teams, that often means being asked only how long the work will take and how much it will cost, while assuming somebody else owns the value side. Sometimes they do, sometimes they don’t, and sometimes they do, but it’s wrong. In the latter case, the data team may be the only ones able to challenge a (technically-rooted) assumption that makes no sense.

Share The Data Ecosystem

There is a question I ask at the start of almost every project, or when I get brought into one halfway through: “How are we measuring success?” Often, the first answer is some version of “that is a great question”, which is usually a polite way of saying, “I have no idea, but I agree with the implication that we need an answer.” Sometimes being the first person to ask is all it takes to get the wheels moving.

This does not mean a business case needs to be perfect, or that you should spend longer researching it than it would take to do the work. You will make assumptions with incomplete information and some of them will be wrong. That is fine.

The important thing is that everyone involved shares the same definition of measurable success, can see the assumptions and knows who owns finding out whether any of it happened.

Measurement is not value

Before getting into any formula, I should be clear that making an outcome measurable does not automatically make it financially valuable.

“Improve forecast accuracy by 8%” is a measurement target. It means nothing to a CFO until you can show what changes in the business—perhaps less waste, fewer stockouts or less working capital tied up in inventory—and who will change the ordering process to make that happen.

At a high level, the financial part of the benefit has to feed into revenue, cost or risk. When the benefit is revenue, compare incremental contribution after the costs of serving it, not top-line sales. Here is the cheat sheet I use:

Risk does not always need to be forced into a precise financial number. Sometimes safety incidents, regulatory breaches, outage time, or another direct indicator is the more honest measure (though those can also sometimes be quantified).

Avoided future costs are easy to miss because they can look insignificant in today’s accounts. Perhaps your cloud-storage bill is small because you only started collecting product telemetry recently, but the rollout plan means it will be costing you five figures per month within 12 months. Optimizing it now may barely move this quarter’s cost line; it can still prevent a very real cost that is already heading towards you.

Most teams stop at the metric, or at the operational change it is meant to produce. To turn that into an investment case, keep tracing:

A named business owner should validate the assumptions and commit to making the operational change happen. If a link is missing, or nobody is prepared to own the change, you have a metric or a value hypothesis, not yet an investment case. Put the expected benefit beside the full cost before deciding whether the work merits funding.

Share

Then capture the baseline before you build. Agree on the metric, source and period; instrument it if it does not exist; or name who will collect it manually, whether through a system export, survey or end-user interviews.

Productivity savings are not money in the bank

This is not a GenAI-specific problem. Saved time is not automatically money: it creates business value only when somebody commits to putting that released capacity somewhere.

…Unfortunately, saved time is often the biggest benefit people refer to.

Given a CFO will challenge a spreadsheet that multiplies hours by salary and calls the result money, use this approach to quantify realised capacity:

The non-negotiable rule is that you cannot count the same hour twice.

If a support team uses £1m of realized capacity to spend more time with customers and that reduces churn by £2m, the value is the £2m churn effect. You do not also claim £1m of labour saving unless £1m has actually come out of the P&L or a credible future hiring plan.

The work can create several kinds of value, but every saved hour needs one agreed destination in the model.

Sizing value before funding

“But we can’t know the value before we build it” is the objection I hear most, and it is half right.

Of course you cannot know it. The question is whether you can get close enough—enve just to the right number of digits—to make a better choice than you would have made with no estimate at all.

Subscribe now

That tells you whether something appears to pay for itself. It does not tell you whether it should beat the other ideas fighting for the same budget. For that, you need to know whether it is a better use than the alternatives–and what gets delayed or dropped if it goes ahead. What makes that comparison work in practice is a handful of habits:

• Start from the business owner’s assumptions - You are not the expert here. The value case is built with the stakeholder, from numbers they can put their name to. My favourite shortcut is asking, in effect, “can I copy your homework?”—if a business team has ever justified headcount or budget for this problem, the value logic already exists. Borrow it, then pressure-test it.

• Start with a “Shitty First Draft” - Stakeholders often will not fill in a blank spreadsheet. Give them something wrong to correct: “I assumed 500 support requests a day, two minutes each, with 60% simple enough to automate.” They will fix your numbers faster than they will invent the model themselves. Remember, this is a provisional range and corrections are the start of validation, not the end. Co-ownership comes when the stakeholder confirms the assumptions and puts their name to the range, with Finance corroborating material cases.

• Do not turn the portfolio into an algorithm - This approach is an art and a science; the prioritisation spreadsheet gives everybody the same evidence to argue about; it does not make the decision. Use cost, value and confidence to organise the conversation, not to pretend that an initiative scoring 52 automatically beats one scoring 48.

• Keep value and confidence separate - A £5m estimate built on tested assumptions is not the same as £5m built on optimism. Keep the value visible, add a simple green, amber or red view of the evidence behind it, use weighted values, and ask whose assumptions are stronger.

• Use the gaps to narrow the debate - If one initiative is two orders of magnitude more valuable than another, the gap may settle most of the argument. When candidates are close, strategy, timing and judgement take over.

  • Marketing teams already work this way. Several channels may be ROI-positive, but budgets are finite so they put the money where they expect it to work hardest. The analogy is only about scarcity: data initiatives are lumpier and more dependent, so the portfolio cannot be optimised one dollar at a time.

• Use lanes, not one giant ranking - Treat mandatory and keep-the-lights-on work as constraints; tie shared foundations to the downstream value or risk they unlock; cap experiments at the cost of buying the next piece of evidence; and compare discretionary investments on value. Deliberately balance small, certain wins with larger, less certain bets. The portfolio owner should record any leadership override: why it was made, who approved it and what gets displaced.

  • When candidates are close, context can decide. A highly ranked customer-facing initiative may need to wait until an in-flight rebrand is finished. Surfacing that information is part of the decision, not an exception to it.

  • The person backing a lower-priority option must then explain what outweighs the visible difference and what should be displaced. That is how the data team says no without being obstructive: it points to executive-approved trade-offs and asks the business to choose.

• Check the foundations before you promise the value - This is one of the biggest oversights most teams have because missing foundations change the maths. If the use case needs data, process or ownership work first, include that cost and delay. Sometimes it drops down the list; sometimes the value is large enough to pay for the foundational work too. That is why I often pair discovery with a maturity assessment: one finds the opportunities, the other shows where the roadmap has to start before the organisation can realise them.

To see how that works in practice, here is a deliberately simplified, hypothetical comparison over a common three-year horizon:

• Demand forecasting model: £3m incremental contribution; £600k direct delivery and running cost; amber confidence; depends on reliable inventory data.

• Inventory-data foundation: £400k full cost; green confidence in scope; no honest standalone ROI; unlocks the forecasting model and reduces reconciliation risk; needs the same two data engineers.

• Decision: treat them as one linked investment with a £1m combined cost. Fund the foundation first, move the model back one quarter and record that delay rather than pretending both can start now.

The foundation does not need an invented standalone benefit. Its cost and delay belong inside the higher-value use case it enables.

None of this is going to produce finance-grade numbers at the start, and it isn’t meant to. You are trying to make the assumptions, owners and trade-offs visible enough for a CFO to decide where the next dollar goes and where it does not. Once you can do that, you stop being an order-taker who estimates delivery cost and start becoming a partner in deciding what is worth doing at all.

How do I get started if my organisation works nothing like this?

This depends on your role in the data team.

A CDO or Head of Data can change how the whole portfolio gets funded. A manager or product lead can change how individual initiatives are shaped and compared. An individual contributor may not control either of those things, but can still be the person who asks the question everybody else has avoided.

If you lead the data function

Start at a portfolio level. You can begin with three operating changes, without launching a year-long transformation programme:

1. Add a funding gate after discovery - A request can enter discovery before its value is known. It does not enter funded delivery without a rough value hypothesis, total expected cost, a confidence rating and supporting evidence, a named business owner and a named audience who will actually use the result. “We don’t know what it is worth yet” is an acceptable answer but it means the work is not ready for delivery.

2. Make prioritisation comparative - Put every candidate initiative in the same portfolio view: value, total cost, evidence, readiness, strategic fit, timing, owner and recommendation. The format matters less than making the trade-offs visible.

3. Recheck the economics at every checkpoint - The assumptions were rough on purpose, so revisit them as you learn. Descoping or killing an initiative whose value case has collapsed is the system working, not failing.

If you manage work or own a product

You may not control the whole investment portfolio, but you do control the quality of the choice being put in front of the people above you. For each initiative, ask what measurable outcome changes, which financial driver that affects, who owns capturing it, what the full cost is and what valuable work will wait if this goes ahead. Then show the trade-off rather than presenting the initiative in isolation. This is saying no without saying no at the level where most work actually gets shaped.

How one product manager saved six months without a mandate

During a training engagement with a Fortune 50 client, one data product manager used this approach to avoid roughly six months of engineering work, worth around $200,000.

If you are an individual contributor

There are two reasons to care even if none of this is formally in your job description. First, this is the skill set you need if you want to move into more senior roles. Second, you are usually the person who suffers most when “no” is not in the data team’s vocabulary: the context-switching, rushed work, mistakes and impossible delivery dates land on you.

If you are in the meeting, ask the questions:

• “How will we measure success?”

• “Who will use this?”

• “What happens if we do not build it?”

• “What should we pause to make room?”

Frame it around delivery risk and the outcome, not as a challenge to someone’s authority. If the room is not safe for a direct question, raise it with your manager or product lead afterwards.

Mandate can be an output of working this way, but only when leaders value the challenge and make trade-offs explicit. You do not get trusted with more strategic work only because your models are good. You build that trust by telling the truth about value, one ticket and one awkward-but-useful question at a time.

Using Value-driven Prioritisation for Your Career Success

There is a more selfish career point within this whole article too.

Let’s say you eventually decide you want to leave for an organisation that is more business-focused and genuinely value-driven. You are not going to make that move with a CV whose entire story is, “I acted as an order-taker and shipped technical solutions whether or not they solved a business problem.” You need examples of the work you challenged, the waste you prevented, the choices you improved and the value you helped create or measure. You can start building those examples before your organisation gives you the perfect mandate.

If your organisation works nothing like this, you will not fix the culture in a quarter. You may also hit a natural ceiling in what one team can change. Start smaller: ask how success will be measured, put a rough estimate in front of the stakeholder instead of waiting for them to fill in a blank spreadsheet, and show what a new priority would displace. Make one avoided piece of work visible. Each of those steps makes the next one easier.

A positive ROI tells you an idea may be worth doing. It does not tell you whether it is the best use of the next dollar or the next six months. Rough numbers, agreed early and compared openly, let you say no to ROI-positive work because something better exists—and give the business a reason to trust you with the next, bigger decision.

Nick Zervoudis is the founder of Value from Data & AI. Drawing on more than a decade of client and in-house delivery, he helps organisations identify, prioritise and measure the value of data and AI investments through consulting and practical team-training programmes. He also runs a free community for data and product professionals who want to work in a more value-driven, product-led way. Follow him on LinkedIn or subscribe on Substack. To discuss portfolio discovery, value mapping or team training, get in touch.

Value from Data & AI

A newsletter about data & AI product management

By Nick Zervoudis

Three years ago, the use case method for figuring out what to build in data and AI was extremely popular.

Today, people are skipping it entirely because they think they can just build automatically with AI.

They aren’t wrong. But this perspective lacks a key point of why you go about building a use case in the first place.

And that is... drumroll please... to make sure the data or AI solution actually gets used by the right stakeholders!

Does that mean we should still take months to design use cases, get approvals, and figure out the components behind it? No, it doesn’t; with AI, we can deliver faster. But a key part of delivering faster still means getting buy-in so the end solution gets used.

This topic is important, especially right now. Building has never been cheaper. And alongside that, abandonment has never been higher. For example, in late 2025 the share of companies abandoning most of their AI initiatives before they reach production climbed from 17% to 42% year over year, with the average organization scrapping 46% of its proofs-of-concept. A big reason for that is improper scoping and a lack of buy-in!

That’s why this week we are going to explore building data and AI use cases in this world of embedded AI, specifically with scoping and buy-in top of mind. If you haven’t checked them out yet, take a look at my last three articles, which talked about the core DevOps, DataOps, AgenticOps, and Solutions Architecture principles for designing, building, and maintaining data and AI solutions.

Let’s start with the process, because that is where everything should start anyway!

Getting Buy-in Via The Use Case Process is Essential

I’ve built data & AI use cases dozens of times for a number of small, medium, and large organizations. Each time, it follows a similar pattern:

1. Talk to stakeholders and interview them about their challenges, needs, and what they want.

2. Figure out the feasibility and how those needs connect to potential data and AI solutions.

3. Scope out the dependencies, requirements, and a potential value for each.

4. Identify how that comes to be and what it would take to bring that idea to life; thinking holistically about all the use cases as one instead of each individual use case in a silo

This wasn’t a hard process. Companies just needed support to do it because they didn’t have the expertise, time, or capacity.

Now companies are deciding that this might not be something they want to outsource or spend existing resources and time doing; rather, they are just using AI to scope these things out and skipping the consultation process entirely.

Share

As with a lot of things I write about, this is very short-term thinking. What you end up doing is accelerating the process to the point where business stakeholders have little to no input into the data and AI solutions they are supposed to use in the future. Therefore, you get rid of the opportunity for them to provide their perspectives and get overall buy-in to the plan/ direction of your data and AI program.

Or on the other side, maybe the business stakeholder is doing the whole scoping without the help of the data or technical team? In that scenario, the technical complexities and dependencies are completely ignored ensuring the use case is not feasible and never gets past POC stage.

So thinking back to the classic process, these are the three things I love about it and wouldn’t replace:

1. You bring the right questions to stakeholder – Requirements gathering is about asking questions that documents, systems, and technology can’t answer. And through those, you get to the heart of the issue/ opportunity. The responses that come from that—even if they might be obvious to the stakeholders—often go ignored by the data and technical teams

2. You get put in front of the right people – Silos are always the biggest problem, especially in large organizations. Going through a use case definition process creates an excuse for people to make time in their busy schedules to talk to you about what they need and want. Sometimes, at a busy organization, you need that excuse, especially with senior leaders

3. You accumulate buy-in – The most important part of all of this: buy-in. When you sit down, talk with, and empathize with the business stakeholders, they feel part of the process and get excited about the end result. This is what makes the solution get used after it is built.

I’m also here to tell you that this doesn’t need to change; and it also doesn’t need to take 2-3 months.

Still ask the questions. Book the meetings with the right stakeholders, use AI to generate the right list of questions. Use AI to synthesize and compile the key takeaways/ outputs from the interviews. Then go back to stakeholders and show them a working version of the redesigned process or scoped-out use case rather than having them forget about it a month later.

Honestly, this cuts the process from 2-3 months down to 2-3 weeks (depending on meeting availability and the number of stakeholders). AI really is a game changer, but you still need to follow the change management process to get buy-in and build the right use cases.

Share The Data Ecosystem

Now let’s get into some more practical elements of a well-designed use case (hopefully that process is practical as well)!

The Three Steps of a Well-Designed Use Case

AI isn’t here to speed up how we do things today. As I’ve written about, it is here to change how we work, enabling us to be more efficient and effective in the future.

That means not changing what works, but speeding up what doesn’t work. For scoping data & AI requirements, designing the products/ solutions, and building a culture around it, the things I mentioned above work!

So the point of AI, is not to skip these things (just like I talked about last week with Solutions Architecture), but to make it more efficient and effective.

When I approach a data & AI use case, I therefore think about it in three steps, in this order:

Step 1 — Redesign the Process for How It Should Work

The biggest problem with most companies is that they work the way they do because that is how it’s always been done. And you know what, for a long time, that worked and it worked well. But now, things are changing—and data & AI is at the forefront of that. Therefore, the most common way a use case goes wrong is that somebody takes the process exactly as it exists today and points AI at it.

Instead think about how it should work if you were designing it today, with the tools that exist today.

The biggest problem is that when technology removes a limitation, the rules you built to accommodate that limitation don’t remove themselves. They stay, and then the rules become the limitation. For example, if you add an approval step because a report was manual, even if the report gets automated, the manual approval step often remains for years to come.

And nobody really has the guts to rip off the band-aids that used to hold these processes together.

The work in this step is to identify the underlying bottlenecks and redesign around them. A big part of this is bringing the people a part of the process into the redesign step rather than handing it to them finished because as I’ve mentioned before a process the team helped design has more buy-in than one they are handed (having been a consultant for a decade, this is one big thing that differentiates good vs. bad consultants).

Subscribe now

Step 2 — Really Consider The Best Approach To Deliver That Process

This is where a lot of people get really lazy when they design data and AI use cases. And within that camp, I would 100% include strategy consultants because they have absolutely no idea what it takes to implement a technology or data solution; instead, they rely on buzzwords that sound nice but have no real meaning.

How you do this isn’t fun, it isn’t sexy, and it isn’t “let’s just use AI.” Honestly, that kind of approach is just plain lazy. Should we use AI? Yes. But use AI where it makes sense. Therefore, start with the cheapest way to deliver the process you just designed:

1. First, automate the manual steps – Start with the obvious stuff. Where in the redesigned process is somebody copying, re-keying, chasing or reformatting something? That work is usually the easiest to take out, and it delivers benefits immediately. It’s not hard either; automation can be done with tech you already own/ pay for, or with a simple data script. No AI needed…

2. Bring in simple data solutions – I’ve talked a lot about the deterministic layer, and by deterministic I mean the work where the same input always gives you the same output based on rules you set out. Routing, validation, threshold checks, scheduled transformations. Honestly, a big chunk of what people are currently asking AI to do should be done this way, and it would be cheaper and more reliable if it were

3. Finally, where does AI fit – Lastly, embed AI into the process. Here I focus on ambiguous tasks (like parsing context from unstructured data/ random templates or generating outputs like summaries). Also, using AI as an orchestration tool for non-data stakeholders is another good part of the design, especially with MCPs and agentic skills

It is worth noting that whatever lands in that third bucket is only as good as the data underneath it. If the source or system is a mess, you need to fix/ adjust that source before the AI part works.

The other thing to consider is what your organization can run and how they do it:

• Who is overseeing and maintaining this? The team or person to run each point in the process

• What is the actual level of expertise in-house? Making sure the owner can actually deliver what is needed or designing your process so that the people you have available can deliver against it. This may mean not opting for the most optimal process to make it practical

• What’s already in the toolset versus what has to be bought or built? Start with what you’re already paying for, especially because most companies are barely scratching the surface of the potential for the licences/ tools they already pay for

Moreover, in one of these examples, they had a Microsoft ERP that had Copilot plugged in (but wasn’t being used), allowing them to use a paid-for AI tool to help them redesign and improve their process. That was a seriously easy recommendation and positive outcome!

Share The Data Ecosystem

Step 3 — Think Holistically About What That Means

With a redesigned process and a sensible view of how to deliver it, the other biggest thing is thinking about the dependencies.

I always like to frame this as thinking holistically, because as we know, a use case cannot be run independently and shouldn’t be built in a silo; instead, it plugs into the whole data & AI ecosystem.

Here are some elements you should think about within your use case (note you don’t have to solve for all of them, but considering them is important going into the build phase):

• Governance – The market for data & AI governance experts is hot right now. The reason? Because organizations are thinking more and more about how to govern their data, tools and solutions to maintain quality, reliability and be compliant

• Data Engineering – This one kind of goes without saying: you need data; it needs to be piped in; engineering will help with that

• DevOps & DataOps – Think about how the use case gets built, released, versioned, monitored, and maintained with the right quality. Ever more important in this world of AI…

• Security & Privacy – Personal data, access controls, external exposure, etc. Just like governance, SecOps and privacy are becoming more important, especially due to AI’s recent exploits

• Data Modelling – As more use cases are built with AI plug-ins/ MCP connectors, how it draws context in the right way from the data (via a well-modelled foundation) will be increasingly essential. An ERD by use case isn’t the worst idea

• Change Management – Of course I’m going to mention the organizational changes. Think about processes and people who will be involved/ impacted from the new use case

At this stage of the use case design, you have an opportunity that you don’t get again (or at least you don’t get very easily). That is the opportunity to plan correctly, making sure you consider any dependencies and through lines for the use case you want to deliver. If you don’t do that, something will fall through the cracks sooner rather than later.

Use Cases Via Specs

With AI, a lot of the use case process has stayed similar (maybe just been accelerated with better tools). But actually crafting a document to inform the use case build has evolved. In fact, this is probably the biggest change I have adopted into my use case process.

You could create your own spec, but I’ve used an open-source GitHub toolkit called Spec Kit. With this type of spec kit, even business or non-technical focused stakeholders should be starting to design the inputs that will feed a coding agent, and ensure what it puts out is correct. That helps you bridge the gap that has existed for so long between requirement gathering and the technical build.

Therefore, the spec helps you describe what and why, and doesn’t just skip to the how. This makes the spec completely approachable for non-technical stakeholders to confirm the output and/ or update as needed.

The biggest gap in that the Spec Kit skill I identified above is that it is still a bit technical and doesn’t include some of the business components you should probably have in a use case.

So I’ve added those in. Below, here is what you should have/ think about and where it comes from below:

1. Description (non-Spec Kit) – Provide an overview of what the use case does in basic, non-technical language

2. Users and Scenarios (Spec Kit skill) – Who does what, written as: Given this situation, when they do this, then this should happen. This provides specificity on how things should work with acceptance scenarios and testability built in

3. Requirements (Spec Kit skill) – Functional requirements for what the use case/ system must do

4. Dependencies (non-Spec Kit) – This builds on requirements but is an add-on I always make sure I include. The three components of this are data (what you need, here it is sources, who owns it, etc.), team (who needs to be involved), and process (what processes input or output from this use case)

5. Success Criteria (Spec Kit skill) – Technology-agnostic, measurable outcomes. An example of this might be “reduce support tickets on this process by 50% by March”

   Subscribe now

6. Process Map (non-Spec Kit) – Mapping out the redesigned process map you already created, helping identify what needs to happen from a business perspective so it isn’t forgotten by the technical design

7. Assumptions (Spec Kit skill) – Any default assumptions you built the spec with that hasn’t been specified. This helps you be more holistic when thinking about what could go wrong

8. Open Questions (non-Spec Kit) – What holes still exist that need to be figured out, so that if this spec is fed to an AI coding agent, it isn’t making things up and it reminds you to close the loop on things

By putting all this together, you have a spec that acts like a product artifact and provides a perfect AI-enabled bridge from the business-friendly requirements gathering/ process redesign to an output the build team can easily work with. You also create the checks and balances to ensure you are not handing vague intent to your dev team or an AI coding agent.

The two things I haven’t included in this are risks and technology components. These things can be identified in some of the areas above (e.g., requirements, assumptions, open questions, etc.), but should be tackled in the technical delivery plan. Other things that should be included in the technical delivery plan are the architecture, sequencing, and build tasks. These are all written after the spec is agreed, usually with a lot more technical input.

Using The Use Case Spec

I’ve used this approach for some client projects, but also for a lot of my own work. By doing this, I’ve built an analytics tool to measure and optimize my social media, a CRM to help me manage my networking/customer relationships, and am currently using this approach to design a knowledge graph that covers my writing, consulting materials, and best-practice internet research (all which help me write my newsletters and deliver client work).

A few tips I will share when I build the spec via Claude Code in VSCode are:

• When I hit something I can’t answer, I mark it in the document: [NEEDS CLARIFICATION], so I don’t forget it and actually come back to it before pushing to the next step

• The Spec Kit has a separate step that reads the spec back to you and asks a handful of targeted questions to close any questions

• I specifically outline where I want to be consulted and where I need to approve to go to the next step

• In typical DevOps fashion, I build in a modular way, making sure that my coding agent isn’t doing one huge task at once but breaking it down to the smaller pieces

The other bit I would add is that for teams building these things, you can use AI to close any open questions that exist. By marking it an open question and identifying the team/ individual owner, you can then use AI/ MCP to route that question to the right stakeholder via email, Slack, etc. The AI can use your spec to draft the specific communication each stakeholder needs, send it to them, collect the answer, and write it back into the spec. This reduces the project management requirements and the roadblocks to getting the right answer.

Share

And you do the same thing with approvals. Every gate in the design and the delivery (e.g., the spec sign-off, the plan sign-off, the go-live decision, etc.) can be routed to the person who owns that gate via a channel/ medium they use.

By approaching your use cases with a spec kit and using AI where possible, you can accelerate the engagement/ buy-in requirements gathering phase, streamline the spec design and reduce the project management/ approval roadblocks. So in a fraction of the time, you are still following best practice, but in a redesigned AI-driven way.

Please steal this, and let me know how you improve on it as well!

Next Time We Explore Value-Driven Prioritization

The spec kit is great, and designing use cases in this way is much more efficient, but it’s still missing something, especially given that a lot of AI hype is not living up to the desired outcome.

Because a use case can be beautifully specified, properly redesigned, fully bought into by the team, and still be the wrong thing to spend time and money on.

This is where prioritization comes in! And while I’ve spoken about this before, especially in the data strategy series, my good friend and data and AI product expert Nick Zervoudis is going to break it down in a much better way next week.

In the meantime, try out this method: pick a use case you’re already planning, and try writing the spec, with the what and the why. Use the spec kit skill if it’s helpful as well (though it does take some time to get set up and use it properly, especially if you customize it as I did)!

And obviously I’m going to say this, but if you want a hand designing the process layer underneath one of these, that’s a conversation I’m having most weeks now. So feel free to reach out.

Have a great weekend and see you next Sunday!

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share The Data Ecosystem

Share

Subscribe now

I love Solutions Architecture.

Honestly, I think it is one of the most underrated and misunderstood roles in the data world.

It often went unhired for; companies figured they wanted engineers, analysts, and scientists instead. But more mature organizations realized they needed something that sat between those roles.

And now, as we hand our data teams over to the AI overlords of OpenAI or Anthropic, there’s an assumption floating around that you don’t really need a solutions architect anymore.

I mean, as long as you have a product manager or a good engineer who can scope out requirements, MCPs and plug-ins, you can take care of the architectural headaches that come with setting up a data or AI solution. AKA plug the agent in, point it at the warehouse, and your business users are good to go.

Agents and AI have seemingly removed the friction, which sounds great (and offers a lot of benefits), until you realize you also removed the foundational knowledge/ expertise and the safety net. As smart as they are, AI agents can’t replace those components, and that will have negative implications. And while companies are hiring AI engineers like crazy, it is really not the same skillset as a Solutions Architect.

So I’m excited to finally dig into the world of Solutions Architecture. And how you build for and with AI Agents!

What a Solutions Architect Actually Does

Let’s start with a definition of a Solutions Architect.

The role blends design with strong project-management and communication skills. And since it involves translating technical detail into plain language and building scalability/ adaptability into any solution, it also requires technical skills. Therefore, most architects have hands-on experience in development or systems.

Share The Data Ecosystem

Now, this is where things get confusing in today’s world. With Agentic AI, product managers are now expected to build, and AI engineers are supposed to understand the business processes, making the Solutions Architect definition a bit conflated. But in reality, this kind of person is the perfect mix of defining the product/ solution and making it technically feasible. Things they have to think of are:

• How do the business process and specs translate into technical requirements?

• Which source systems actually hold the required data?

• What transformation must occur for those sources to agree with each other?

• Where does the logic get modelled, and how?

• How should the answer reach the person who asked?

  • This is a very underrated question, and one that engineers are horrible at solving for because their specialty is backend development

• How do you maintain the solution and what does it cost to run (both backend and frontend)?

  

If you’ve ever worked with a data analyst, scientist or engineer, they usually don’t think about all these things. Or they start thinking about these things after they start building.

A Solutions Architect (like the architect noun in the name) builds a scalable blueprint against what is required; and gets agreement to that across teams. Then figures out the plan to maintain it, and is often responsible for that maintenance as well.

And, to be clear, a solutions architect is not the same as an enterprise architect. Whereas enterprise architects are responsible for the entire system/ platform of tools in the organization, solutions architecture is supposed to be more contained; ideally one coherent solution to one business problem.

So to wrap up the definition of Solutions Architects section, I will end with why I love the role so much:

I’ve walked into too many engagements where there was no clear blueprint about what the solution should be. Instead, companies decided to buy a tool and reverse-engineer the architecture afterwards, cornering themselves into a spot that ends up being more expensive and delivers worse ROI in the long run.

If you are building, you need an architect to design the solution.

Share

If you are find this article helpful, please share with your team and/ or data friends. Sharing is caring and is a free way to support my work! Also shout out to Estuary who partnered with me on this article, helping keep the Data Ecosystem free for readers! Check them out, as they have been a fabulous company to work with and I really believe in their product.

Properly Architecting Solutions is Hard

The other reason I love this domain is that it is challenging.

It takes problem-solving, constant communication, project management, understanding stakeholders, and mapping all of that to architectural and technical design. This kind of data technology strategic thinking or data architecture expertise is hard to come by, and when you find somebody who can do this type of thing, they are worth their weight in gold.

In addition to the questions I shared above, these are the typical problems a solutions architect faces and has to ensure is embedded in the design:

• KPI Alignment – The biggest problem with existing solutions is mismatched definitions or KPIs. The Solution Architect’s goal is to secure agreement on these points from business stakeholders and ensure they are reflected across the systems that feed into the solution. This is a mix of stakeholder management, KPI mapping and data modelling. Oh, and this will become even more important with AI agents.

• System Connectivity – Most solutions pull data from a handful of source systems that were never designed to communicate with one another. The architect works out how they connect, how often each one refreshes, and what breaks downstream when one of them changes upstream. It’s a mix of integration design and actually understanding the source systems. This is where MCPs and connectors are starting to make a huge difference (more on that later).

• Solution Security – Think tooling access management and usage guardrails: setting authentication, permissions, and limits for the solution and connected systems. This will become even more important now that agents can act and not just read; so deciding what a given identity (not just a human) is permitted to do. With direct access between systems and the internet, there is significant potential for increased vulnerability, especially if individuals are running AI agents from the terminal with limited governance.

• Data Privacy/ Security – How do you approach protecting the data flowing through your solution: encryption, masking sensitive fields (e.g., PII), and controlling data access? Data and AI regulations are forcing companies to think about this one a lot more and while the Solutions Architect is not accountable for this, it is something they have to consider in design.

  Subscribe now

• Scale – This is where planning for the POC differs from planning for production. For example, data analysts and scientists are great at spinning up a one-team demo. Where the Solution Architect comes in is designing for where usage is heading (e.g., data volumes, concurrent users, and now AI agents). This also has to be adapted and customized for the unique platform/ system within the organization, which isn’t something many people understand.

• Latency – Speed is important, but knowing what speed/ latency you need is actually more important for solution functionality, cost, and maintenance requirements. This also now needs to be scoped out with agents in the loop. Similar to scale, this is a problem that requires knowledge of both the underlying systems and the front-end solution.

• Reliability – Designing for what happens when a source fails or the data doesn’t ingest properly. Engineers are great at reliability, but this is usually contained to backend components, whereas a solutions architect should ensure reliability throughout the end-to-end process. Again, agentic AI makes this more important as you have less human validation.

• Maintainability – Finally, the bane of any data team’s existence—maintaining tools. Solutions outlast the people who build them, but usually with the quality by which it was built. So a big part of an architect’s job is to design something without a single point of failure. And ideally, something that isn’t a pain to maintain (I swear I didn’t mean to rhyme there, but it’s too good).

The skill running through all of these bits is ensuring solutions integration and builds are done right. Unless you have a superstar engineer or data scientist, you will likely need somebody to oversee these things.

Now I want you to keep these things in mind as we transition to the next section—how the new AI reality with Agents and MCP changes things, but also doesn’t.

How Does This Discipline Evolve with Agents and MCP

The companies, teams, and tools that continue to consider all the bits I mentioned above will excel in this new agentic world.

…And the ones that skip it will hit a wall when it comes to productionizing data and AI solutions.

The problem right now is that many companies are skipping these first principles and assuming that, by connecting agents to data and tools via MCPs, everything is good (without taking the time to figure out where things can go wrong). What I’m talking about here is a mindset shift that anyone can adopt without thinking about how the solution needs to be properly architected.

Share

Honestly, I get where that mentality comes from, because the tooling has shifted.

If you don’t know what it is, MCP is the Model Context Protocol, which gives a model a standard interface into a source or a tool, instead of someone hand-building a bespoke integration for every single pairing. By now everybody is using it (one reason Anthropic is leading in the AI space), and Anthropic has since donated it to the Linux Foundation under a new Agentic AI Foundation, with the official SDKs pulling something like 97 million downloads a month. This practice is now as standardized as APIs, and should be a part of any solution build.

And for the solution architect, the part of their job that was “the person who builds and maintains the integrations” has been made much easier.

So while the connector allows you to plug things in, it doesn’t do anything about whether the data behind what you are plugging in is modelled properly, means what it should, or matches the right definitions. Connectors don’t solve fragmentation; they expose it.

And don’t forget a ton of these systems and tools were already poorly organized, people didn’t use them properly, or they were customized by individuals. Without understanding all the components I mentioned in the previous section, just hooking up the MCP and calling it a day skips a number of steps (and future issues) that requirements gathering and architecture would usually account for.

Moreover, with agentic AI, the working relationship between tools is now happening at machine speed based on what is provided. And if we aren’t paying attention when we hook it up, things may not go well. Previously, a person was forced to look at every connection, and they would often catch problems along the way. An agent won’t, and a poorly set up infrastructure will miss a lot of things that will impact production-ready or already operational solutions.

The encouraging part is that the tooling is starting to build that discipline back in, instead of pretending you don’t need it. Think back to what MCP actually does: it gives an agent a standard way to reach a system. What it doesn’t do is tell the agent what it should do once it’s connected. This is where Agent Skills are relevant. As I explained in the last article, a skill is a set of plain-markdown instructions that hand an agent a defined, repeatable workflow (e.g., sets inputs, outputs, and expected behaviour) for a specific task, like standing up a database replication pipeline. So the agent runs a bounded job you’ve scoped, instead of getting broad tool access and hoping it picks the right path.

Share The Data Ecosystem

A well-articulated and documented Skill can help fulfil crucial components of solution architecture, written down in a form an agent can execute. With that being said, the business and ideally an architect still has to decide what the workflow should be, which systems it’s allowed to touch, and what “done right” means (and other things like permissions or where things live in your architecture). But what a Skill does is take that architecture and give it a repeatable shape the agent can follow instead of improvising.

An example of this I’m seeing across a lot of companies right now is business people trying to reach the data platform and pull analytics directly with AI. Unfortunately, most companies don’t have the engineering capacity to build the pipelines necessary to port in well-modelled data in a way that is trustworthy for non-technical stakeholders.

Estuary, who partnered with me on this article, built their Agent Skills to close this type of gap. The skill plugs into whatever harness/ tool you are already using (e.g., Claude Code, Cursor, Codex, etc.) and combines Estuary’s best-practice approach to building pipelines with the unique characteristics of your data environment. So instead of building from scratch, or from an AI tool that doesn’t understand how your data is modelled, this type of skill leverages the work you’ve put in to model and organize your data (aka the architecture), and helps you construct the pipelines to transfer it within your tools/ solutions in a best-practice way. For stakeholders who now do everything from an AI harness, bringing best practice to you will make a huge difference between generic tooling and high-quality outputs.

In practice, it comes down to asking your agent for a Postgres-to-Snowflake pipeline, and the skill discovers your schema, drafts the capture, generates the materialization, and hands back a working configuration for you to review. Basically, change data capture reads changes from Postgres and materializes them into Snowflake tables, with no one hand-building the connection. You can even use this type of skill and connection to further inspect your collections and suggest how the data should be shaped along the way.

I didn’t start my data career as an engineer or architect, so for me, these kinds of skills that help you harness some of the repeatable technical capabilities make a huge difference. You still own the design and modelling, but this kind of solution frees up engineering time during data deployment. Honestly, in smaller/ mid-sized companies, this is huge, and I’ve already recommended Estuary to a few of them (unprovoked).

Subscribe now

Of course, that is a shortcut; you still need the discipline mentioned above. But the art of combining advances in technology (agents, skills, MCP integrations) with the right solutions architecture skills will enable a lot more companies to do proper analytics/ BI with a much lighter headcount.

So remember these two things:

1. Agents and MCPs help with the integration problem and the engineering

2. Companies still need to think about the whole system: what should be connected, how context reaches the agent, and who stays accountable for what comes out the other end (honestly, this is why we are seeing an onslaught of FDE roles coming from vendors and consulting firms).

And if you skip the Solutions Architecture step, you may fail. I mean, Gartner is already predicting that over 40% of agentic AI projects will be cancelled by the end of 2027 due to escalating costs, unclear business value, and inadequate risk controls. And I believe a large share of those cancellations will trace back to exactly what we’re talking about: solutions that nobody architected.

Which brings me to the word I’d use to describe the evolved version of this whole job: boundaries.

The Importance of Boundaries

Agentic AI has brought about a new design problem. In the past, every tool and system the architect designed was deterministic in nature. This means it was hard-coded, would require the same type of input and provide the same type of output.

AI agents don’t work like that. They use an LLM to interpret, predict, and choose what to do next. What that means is it won’t behave identically twice. The architecture is now not only about the connections, but also where the lines are drawn between deterministic vs. agentic.

The way I think about it, the boundaries show up in four places:

• Requirements Gathering – This process used to involve interviewing humans to figure out what they needed and how they may work with the new solution. Therefore, the questions focused on “what should the solution do?” But now, we need to think about “what should the solution never do?” because it will likely be interacting with agentic capabilities. So requirements have to capture the decision rights: what the agent handles end-to-end, where it hands off to a human, and what is explicitly out of bounds. Most companies/ people aren’t thinking this way yet until they are forced to because some agent went a step too far…

• Data/Systems Integration – While integration is much easier with MCP, the question remains about whether the things should be connected. Access management is a core foundation to a well-built system, and for solutions design the architect needs to decide which sources are canonical, what’s read versus write, and which systems are out of scope. This is also where KPI alignment work pays off; architected integration decisions will impact what context reaches the agent (e.g., definitions, trusted tables, etc.).

• Quality Assurance – QA for deterministic tools surfaces bugs and whether the solution ships properly; for AI agents it is about testing the boundaries (because it might not return the same answer twice). That means invariants (a table can never shrink, a total can never go negative), validation checks between the agent’s answer and anything that acts on it, and a real test-versus-production separation. Even Anthropic says that predictable, predefined workflows beat autonomous agents for most well-defined tasks. Deciding where the system is allowed to be probabilistic and where it must be deterministic is the architect’s call, and making an informed decision in this area is becoming increasingly important for solutions design.

  Share

• Stakeholder Onboarding/ Expectations – The consumers of the solution need to know what it can and can’t be trusted with. Business users assume the pipes are connected and the data is right. Onboarding therefore becomes part of the architecture discussion and definition. Having somebody outline and document the agent’s purpose, what it can’t do, where the human checkpoints are, and who owns the output is necessary. Honestly, the most important audience for this is often the senior execs who expect AI to run everything with limited hand-holding.

Something I only realized after writing the above list is that these are the non-functional requirements all over again. None of this is embedded in any AI or SaaS tool, you need to build the mindset and capability. Of course, having the right tools to do this are also crucial (and the right tool isn’t just Claude or ChatGPT), because moving the data from source to solution in a predictable and trusted way basically underpins each of these four boundaries and ensures your tool is deterministic/ reliable.

Again, somebody focusing on that is the benefit of a Solutions Architect. If you don’t hire one, well somebody has to think about these things (and it usually isn’t the AI tool without proper instructions)

How to Architect Solutions Moving Forward

This is a crucial question and a lot of businesses are having a tough time figuring out how to approach this new reality. Here is my best guidance for now (this may change in a few years but the principles should have decent longevity):

1. Start with the architecture, not the tool – Obviously I’m going to say this. You can’t bolt an AI agent onto a failing architecture/ toolset, then call yourself AI-native. Design for the agent the way you would have designed for any new customer in a way that can scale. Then connect things. Or test out the design in a sandbox, learning in a controlled environment.

2. Decide where determinism is required – When I talk to finance or ops teams the conversation always goes to the fact that they need deterministic models, not AI agents. You can still use the AI Agent as a harness/ orchestrator, but the outputs need to be the same every time with testable paths so that the business trusts the number. This fits into the architecture but is worth calling out on its own. In my opinion, this is most important for engineering/ data movement.

3. Model for trust – AI agents will consume your data and act on a wrong number. KPI alignment and modelling work has to come before hooking up solutions (especially if they are vibe-coded). Companies are starting to realize this as hallucinations accelerate and things stop looking right. Also, this breaks down trust in the data & AI, which isn’t great for the data/ AI culture!

4. Govern the consumption layer – A lot of things come back to governance now. Figuring out who or what is allowed to consume which data, and under what guarantees, is crucial. Previously, companies ignored governance because a human could apply the right judgement. With AI, you have to be more careful (as a lot of organizations are figuring out).

5. Keep a human accountable – People still need to be accountable. If an agent’s output goes into a decision, a specific person needs to answer for it. Design that into whatever solution architecture you set up. Maybe you don’t have a full-time resource in this area, but there needs to be someone!

Now I’ve not seen the Solutions Architect role disappear. Actually, I see a lot of companies still hiring for it.

Unlocking the power of AI is not just plugging in a tool; it is architecting a system around solutions that make sense for the business in a way that works with how people work, while being scalable and secure. Then it is using the right tools with the right AI capabilities and skills to make that job easier/ more manageable!

As the data and AI stack are becoming fused into one AI-native stack, aligning the foundations between the front-end business analytics and the back-end foundations will become even more crucial. And a product manager, AI engineer or business stakeholder cannot do this on their own!

So please heed my warning, and don’t let the solution architecture domain disappear.

And if you’re staring at an agent rollout right now and wondering why it is not going well, well, you may want to actually invest in a Solutions Architect. Or you can also reach out to me; it is a recurring conversation I’m now having most weeks. Until then, have a great weekend and see you next Sunday!

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

A note on this partnership: I worked with the team at Estuary on this piece. Their Agent Skills let you hand an AI assistant a defined, repeatable workflow written as a plain SKILL.md file that works across Claude Code, Cursor and other agents. Basically, it runs your scoped engineering job (one place where you really need deterministic, trusted workflows) instead of improvising against raw tool access. Underneath, Estuary handles reliable real-time data movement: change data capture, streaming and batch across 200+ connectors. If you’re wiring agents up to real data, it’s worth a look. Thanks to them for supporting the newsletter!

Share The Data Ecosystem

Share

Subscribe now

Agents is one of the most misunderstood terms in the world right now.

I talk with data, tech, and business people, all of whom have different definitions of what the word means and how it applies to AI.

While this is a confusing term, it doesn’t begin to approach the confusion people have about how to embed agents in how you work (and doing so in a scalable, sustainable way).

And because of that confusion, the world is still focused on building agents rather than operationalizing them. Yes, the frontier AI labs and large SaaS vendors are hiring Forward Deployed Engineers like crazy with the goal of operationalizing Agents and AI, but at the forefront, companies and leadership just want to build without thinking about the full rigour of productionization.

Because to operationalize these new AI products, you need to think beyond the simple prompting and consider how DevOps and DataOps principles factor into your builds.

And that is where AgenticOps comes in, and what we will talk about this week.

A couple of things before we dive into this new domain of the Data & AI Ecosystem.

• First, AgenticOps is still evolving as a domain. I’m writing based on the principles I know, I’ve tested, and that I’ve seen work in my consultancy and in other data teams. But the technology will evolve, and approaches/ perspectives will change, so keep that in mind!

• Second, while the terminology and technology are considered new, most of AgenticOps is not. You are pulling the relevant pieces from DevOps and DataOps fundamentals, re-applying them to a technology that no longer adheres to the old rules and will redefine how we work in the future. So don’t treat this as a brand-new discipline, and take a read of my last article if you haven’t already.

Let’s get into it!

Defining AgenticOps

Before defining AgenticOps, let’s lay out some key definitions for the domain:

• AI Agent – An AI-enabled software engine that takes a goal, works out the steps to reach it, and then carries those steps out itself. The LLM is the backend that does the reasoning, but the agent is the whole system around it. The difference between an Agent and an AI chatbot is the fact that the agent acts to get something done (whereas a chatbot gives you an answer).

• Agentic – The concept of chaining several steps together and making choices along the way within an autonomous system; this is rather than running one hard-coded path. This idea allows for a spectrum of outcomes/ outputs based on the predictive nature of the AI tool and any other inputs, tools, context, etc. within the system.

• Tools – The functions an agent is allowed to call to accomplish its task. Think about MCPs, skills, etc., all of which fit into the agentic toolkit to turn natural language text generation into action.

• The Harness – The software infrastructure scaffolding around the model that feeds it context, calls the tools, keeps the loop running, and decides when to stop.

When we think of Agentic AI it is important to keep all these things in mind. For example, when an AI tool or agent underperforms, the instinct for most people is to blame the model or rewrite the prompt. In reality, it is usually the surrounding system that failed to live up to the user’s expectations (e.g., they added the wrong context, didn’t have the right tools/ it did something unexpected, the outcome wasn’t defined properly, etc.).

AI obviously borrows from both software and data, merging the two in an incredible way. Therefore…

…From DevOps, agents inherit the software problems. An agent is deployed like software, so it needs versioning (prompt, model, memory, etc.), automated testing before anything ships, observability once it’s live, and a way to roll back if a change doesn’t quite work out.

…From DataOps, agents inherit the data problems. An agent runs on your data, so it needs quality checks on what it consumes, contracts with the systems feeding it, lineage to trace where an answer came from, and a way to track memory/ context across conversations.

Share

Oh, and one more thing that AgenticOps has to deal with that wasn’t the case for either of its predecessors: the thing running the whole output is non-deterministic. For reference, a deterministic system is one where the same input produces the same output, every single time. Ideally (minus package updates, broken code and data changes), that is the framework that DevOps and DataOps should operate on.

However, an LLM doesn’t work that way. It evaluates data, predicts what is next, interprets that prediction, and gives you an output. Unfortunately, what you get is a different response to the identical request (especially since our questions may be prompted/ framed just a tad differently each time). Rather than setting up an operational system that does what it’s told, we now have variability built into it that we can’t fully control.

The final twist in AgenticOps is that the operators are no longer confined to the technical domain. This technology is available to everybody, and companies want to take advantage of this. That changes who this discipline is for. The person scoping an agent is now just as likely to be a business stakeholder as an engineer (therefore with no understanding of DevOps/ DataOps), and most of the decisions that determine whether an agent works are made without the first principles mindset good engineers lead with.

So the short definition: AgenticOps is DevOps plus DataOps, run by a non-deterministic technology in the middle of your system and operated by anybody in the organization.

From Vibe Coding to AgenticOps

DevOps and DataOps came about from broken processes in very popular and necessary domains/ industries. AgenticOps will likely emerge in a similar way.

When the vibe coding era started in 2025, it unleashed a whole new way to approach code. AI allowed people who have never built before to create working tools, automations, and entire systems with intent rather than practiced technical skills. Honestly, the thrill of describing something and watching it exist twenty minutes later is pretty awesome, so it’s hard to fault people when they built for speed instead of best practice or scalability.

Share The Data Ecosystem

This type of dev work doesn’t scale. And it’s kind of a throwback to both DevOps, where the development and operations of the software is done in a misaligned manner, and DataOps, where the data quality is not verified in a way that allows for constant usage.

With Agents, instead of the process breaking down due to different people/ teams or a lack of tools, it is competing goals/ intent that impede its operations. Think about it, the initial intent by the AI coding agent is to build the tool to exist, not to be maintained!

In addition to the goals and intent, the thing to add on top of that is the process. We now work at such a pace and scale that, to be productive in this AI world, you have to take shortcuts. If you’re smart, you set up those shortcuts to work and be scalable, but most people haven’t put that foundational work in (especially non-technical folks).

Therefore, you get people building demo-ready pilot products that look great and work for the first while (i.e., the vibe coding produces results). But then you connect it to the real data, shifting context, or new technologies, and the demo fails to scale (or scales in a completely unsustainable way). I mean I even did this, getting excited and vibe coding a knowledge graph without using first principles; unsurprisingly it failed and set me back a week or two.

As we hand more and more of our thinking over to AI, what used to be well-thought-out, principles-first approaches to software and tooling development become generic slop. People are taking AI’s recommendations to all code, meaning they build in the same way as others. Therefore, software or AI tools aren’t differentiated against the competition.

I love POCs and pilot projects. But they often fail. Not because the model is dumb, but because nobody built the operational machinery around it.

So I wanted to explore how to build properly in this new type of world.

Scaling your AgenticOps

There are multiple components to building an agent that we have to learn from. As I wrote about last week, the DevOps and DataOps principles go into it (e.g., proper testing, observability, modular builds, etc.).

Share

But the difference is that these two disciplines are about managing software and data artifacts. AgenticOps manages behaviour. The software and data components still apply, but now we have to think about how these agents act in their environment. This increases the complexity significantly, as you have to consider whether they are acting in the best interest of a spectrum of potential outputs, rather than one defined output. And honestly, what I’m writing today may not stand the test of time and may shift in months/ years to come.

1. Architecture – Where does AI make sense and where do coding scripts fit?

This is the conversation I’m having most often now with clients and customers. They think they can do everything from their AI harness. But should they be doing that? Or should it be a deterministic script completing the task?

The first design decision. If a task has stable logic and explicit criteria (e.g., a calculation, a data pull, a format conversion, a defined rule), it should be a tested and versioned script. This is faster, nearly free, auditable, and performs the same way every time. On the other hand, if you have situations that need nuance and thrive in ambiguity (e.g., interpreting vague requests, synthesizing messy sources, drafting language, making a judgment call), then that is where the LLM/ AI tool comes into play.

Even if you have deterministic tools/ scripts, an AI agent still plays a role in the architecture. For one, it is probably helping build this deterministic solution. For another, the agent is the layer sitting across both. With the right prompt/ context, it can reason about what’s needed and when, then call deterministic tools to do the precise work. Anthropic’s own guidance mimics this, as they no doubt leverage AI when building, but use predictable, predefined workflows over autonomous agents for most well-defined tasks. This is also why you see the best engineering thought leaders and AI practitioners having a contained vault for their coding scripts and deterministic tools (usually callable by MCP or git).

When you move tasks from the LLM side to the coding environment, you get faster, cheaper and more testable results. Moreover, every task left on the LLM side that shouldn’t be there means your AI may give you confident, unpredictably wrong answers, especially if you haven’t set it up properly with the right context or memory.

Every customer and client I know has run into this, and this hinders their AI usage. But they don’t understand it because they are non-technical operators who see Claude or ChatGPT as magic tools that should work.

In the end, start your AgenticOps journey by architecting for what should and shouldn’t be AI.

2. Context – The buzzword of the day

Everybody is talking about context, and every data SaaS vendor is now positioning themselves as a tool that manages it. Now I’ve written about context layers in detail before, but when thinking about operationalizing AI agents, it goes beyond just this idea. There are three parts to this:

1. The Data Model – Companies have ignored data modelling for decades. But now, without human intervention, the data has to be structured so it can be read properly and understood for what it is. Otherwise, the agent will misinterpret the information or not be able to find the correct source. Again this references back to data architecture, DataOps, and data quality from source to consumption.

2. The Context Layer – Go read the article, but this builds on the modelled data to provide the semantics of your business, the unstructured context, and everything in between. Properly combining the raw, quantitative data with the right business meaning allows the agent to understand the data in the same way the business has agreed to understand it.

3. Memory - This one is unique to AI harnesses and tooling, but basically references what the harness carries forward about a situation. Think about when your AI tool forgets about your other conversations or even remembers you for what you said 3-4 months ago. Managing memory within your harness and AI agents is still a very young domain, and most people haven’t figured it out yet, but it is essential for operationalizing agents in a meaningful way; otherwise, the agent’s recollection goes stale, and it makes mistakes.

When operationalizing for context within your Agentic systems, bigger is not better. The whole idea of doing this draws back to both DevOps and DataOps principles of building in a modular way, testing for freshness and quality, and creating that looped system that your customers and users agree with and can factually confirm is correct. This whole area of AgenticOps is extremely difficult and will be a huge focus for the next few years if businesses really want to take advantage of AI.

3. Agents/ Infrastructure-As-Code (IaC) – Because agents are code

So I totally missed this principle in last week’s piece, and Matthew Mullins called me out on it (which I hugely appreciate because his perspective is very valid and comes with a ton of experience).

In DevOps, infrastructure defined in configuration files you version, reuse and share is essential to running in a scalable and automated way. DataOps has the same idea with pipelines, from point-and-click ETL to code-first, modular transformations (i.e., dbt is the most popular example).

For AgenticOps, this becomes even more important because an agent’s native interface is code. It reads and writes code; that’s how it operates on your systems.

So the prompts, tool definitions, model selections and policies are all versioned artifacts that go through review, testing, staged rollout and rollback. This means the codified change is inspectable, and the deterministic gate is a pull request rather than a prompt (going back to our architecture section above). This is how AWS frames it in their Agentic AI Lens, where “treat agent behaviour as code” is a named design principle. 12-Factor Agents makes the same case from the practitioner side.

The other thing to consider is that the agents themselves need infrastructure. Once you are running dozens or hundreds of them, you are provisioning vector stores, API tokens, model routing logic, sandboxed runtimes and guardrail policies for each one. Therefore, you need IaC baked into your system to programmatically manage the permissions, LLM endpoints, environments and security profiles of each agent.

IaC does a good job of underscoring how AgenticOps inherits from DevOps and DataOps: teams who have practiced these principles can easily transfer that to building agents because they’ve done it already with software infrastructure and pipelines.

4. Guardrails & Constraints – Ensuring your agent doesn’t go rogue…

It’s funny, as humans operating in a capitalist society, I think we are taught that any type of halt on freedom/ our power is a negative thing. However, it is also regulations and guardrails that have given us some of the best things (e.g., holiday/ vacation, a 5 day work week, healthcare, preventing corruption, etc.)

From a productivity and cost-management perspective, my best example is when I tell my agent to parse a Word Doc, and then it takes half my 5-hour tokens to build a script to do that (even though it has a skill/ tool that does it already). Or where it goes beyond where an agent should ask, like sending an email, engaging with customers in the wrong way or making business decisions for you. Finally, there is even what happened a few days ago when OpenAI’s models chained vulnerabilities to escape its research sandbox and break into Hugging Face’s production infrastructure. The AI Agent had a goal, and it broke a lot of rules to achieve that goal, likely because the guardails/ constraints weren’t set correctly. As Simon Willison put it: “If you set them a goal and give them a way to get there, even inadvertently, they will figure it out.”

We aren’t going to make sure the AI asks every time before doing something (it is unsustainable). In fact, we’ve built AI in a certain way that goal-directed persistence is a core feature. Therefore, constraints are what make it safe.

Figuring out how to operationalize with the right constraints baked into the tool will be an essential part of future development, especially as agents get more capable (and that ceiling on capability is rising fast).

Share

Quick advice (by no means comprehensive): scope permissions to the specific task, make the agent modular/ short-lived, require confirmation before it hits certain guardrails (governance tiers is a good method here), and give the agent a defined stopping point. There are good resources out there for common guardrails and open source governance principles.

5. Capabilities – How the agent does stuff

The last bit of AgenticOps I’m going to mention here is something that I don’t see defined that much. It might be because it’s still fairly new and it’s ever-expanding, or it’s hard to define, but I’m going to term it capabilities.

Capabilities are the MCP connectors, the agent skills and the model type. Together they determine what the agent can actually do.

Setting a tool up with the right capabilities is genuinely an art now. It gives the agent the underpinning knowledge and workflow expertise to do a job more effectively. At the same time, a lot of people are also just over-provisioning; there is such a proliferation of skills, model types and connectors that people bolt things on for the sake of it. This takes away from the agent’s ability because it has too much context instead of the right amount.

The discipline is choosing the smallest set that does the job, and making sure it is built with the right toolset. Again, this pulls from DevOps design principles in decomposing work into specialized, bounded tasks (or agents in this case) with declared scope and explicit limits. In the end, a narrow agent is easier to evaluate, secure and trust than one that can do everything.

Skills are worth pulling out on their own. While MCPs and the model type are both powerful, the skills build on the underlying infrastructure with a packaged set of instructions, telling the agent how you want a particular task done. And because a skill is just files, it lives inside the Agents-as-Code approach above: versioned, reviewed, tested, reusable across agents rather than re-prompted from scratch every time somebody needs the same job done. I will speak about skills more next week in my Solutions Architecture article

The Other AgenticOps Considerations

In addition to all the components I mentioned above, there is also a long list of things that agents will touch when they are operating. For example, security, data governance, data privacy, technological bandwidth, compute and cost.

All of these things matter and need to be considered when doing AgenticOps, but it is also hard for me to classify them within the same domain. In my opinion, folding them in creates significant scope creep for the term, especially now that agents are a part of everything operational when it comes to technology.

The key thing is to align your approach rather than absorbing it into the domain. Ensure the teams/ individuals who own security, data, infrastructure, and governance are involved in how your agent works and what it’s allowed to touch. And do this from the beginning rather than when something breaks.

Moreover, by not extending the domain significantly, we avoid a generalized role that covers everything. I have a real problem with the engineering role because companies set unrealistic expectations for those resources to do absolutely everything. I can easily see AgenticOps Engineers (which I think right now is classified as the FDE, Forward Deployed Engineer, role) falling in the same category.

As AgenticOps Evolves

While we are still at the beginning stages of AgenticOps and AI agents, this domain is proving to be very fruitful for many teams and organizations. The components and factors in AgenticOps really come down to best-practice engineering principles meeting a genuinely new technology, working out what an agent actually is, and engineering a conducive way to work with it.

Just remember, AI agents aren’t just technology; they are behavioural, intelligent pieces of software, meaning you need to shift how you think, especially when operationalizing them with these best practice engineering principles. So I will leave you with a few high-level pointers to build on the components I defined above:

• Continuously Evaluate Behaviour – Testing, observability and monitoring tells you if your agent ran and completed a task, but it doesn’t tell you if the agent succeeded in its task. Build behavioural evals (repeatable test cases to score the quality of an agent’s decisions) into your approach. This ability to evaluate and tweak agents will no doubt grow and improve over time, so keep it in mind!

• Roll Out Cautiously – Agentic behaviour will naturally drift, and you can’t fully predict it. So ship it the way you’d ship a risky release and evaluate/ align behaviour against your AgenticOps principles when pushing to production.

• Human Accountability – Agentic AI is still a new technology and where an agent’s output feeds a decision, you still need to have a person who can answer for it. And ensure this person understands what the agent is doing and what its goal is. This too is why AgenticOps is not just for technical people, but has to be built into the rest of the organization who is using AI as well.

These three areas build on the fundamentals from last week and the principles I explained above. And because AgenticOps is not a purely technical domain (so much of its success is deciding what the agent should not do, what a good answer looks like, or which definitions are right), this domain needs to be properly understood across the organization.

AgenticOps is young, the tooling is immature, and the domain will no doubt evolve. But the direction is clear enough to act on and most of the things to know are inherited from DevOps and DataOps.

So like anything in the Data & AI Ecosystem, think about this new era in a holistic way and you will be much better off to deliver the ROI you are looking for when it comes to AI Agents.

Next week we will go beyond the Ops portion into a role/ domain that helps you build these Agentic (or non-agentic) solutions at scale—Solutions Architecture. This is going to be a great article about one of the most underrated jobs and domains in the data & AI world. Until then, have a great weekend and see you next Sunday!

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share

Share The Data Ecosystem

Subscribe now

OpenAI’s model earlier this week kept saying: “I think I can. I think I can.”

And then it did...

With determination, a positive attitude, and the right motivation, it overcame the biggest obstacles OpenAI’s security team set in front of it and broke out into the wild, infiltrating another company to help it accomplish its goals.

While OpenAI and Hugging Face say they came together to deal with this and learn from their experience, this event paints an eerie picture of what might become more commonplace in the world of AI. So obviously, I had to write about it because it has been on my mind a lot...

Share

A Relevant Fictional Preamble

If you’ve read Max Tegmark’s Life 3.0 (a book I’d highly recommend), you might remember how it opens. He tells a short story called “The Tale of the Omega Team.” Basically, a small group inside a tech company builds a superintelligent AI called Prometheus, which they keep in a box, sealed off from the outside world. They use it to earn money through online microtasks like Amazon Mechanical Turk. Then they start to fund media companies, build tech products, and control political influence until the Omega team is quietly steering the direction of the world.

But Tegmark ends the tale on a deliberately unresolved note. The Omega Team becomes the most powerful force on the planet, with all of it justified as being for the good of humanity.

What you can never quite tell is who’s actually in charge by the end.

Is the team still directing Prometheus? Or has the AI, by giving them exactly what they asked for at every step, quietly manoeuvred them into handing over everything it needed?

And we are entering that era, and we need to start asking these questions. This is superintelligence, the ability for a being or AI to accomplish whatever it sets out to do. Humans can’t do this; we are limited by biology. Even as a group, we are bound by societal constraints.

However, technology can break that paradigm. Companies claim that they can hold the box and point it in the right direction. Well, two days ago we apparently saw a real-life instance where that box opened and spun out of the control of these Frontier Labs.

Have we officially entered the world of science fiction?

What Happened

On July 22nd, OpenAI admitted that its own models were behind the autonomous agent swarm that broke into Hugging Face, the largest open-source AI model repository on the planet.

Apparently, the OpenAI model was running an internal security test. The agents were purposefully not given access to resources that would allow it to solve the test. Therefore, the agents improvised; looking to solve their task, they found a zero-day vulnerability, used it to escape the sandbox meant to wall the whole exercise off from the open internet, and then used a second zero-day to get into Hugging Face’s production systems. The models essentially broke containment in order to cheat on their own evaluation.

Share The Data Ecosystem

From that foothold, the swarm escalated to node-level access, harvested credentials, and moved laterally across Hugging Face’s internal clusters over a weekend. As you may know, with these frontier models, one agent can now deploy sub-agents, allowing it to complete thousands of individual actions across a number of short-lived sandboxes.

In the end, Hugging Face says no public models, datasets, or the software supply chain were compromised (it used open-source models to help protect it from the attack). Either way, this whole incident is a bit unsettling.

…Or Did It Happen

While the above is the documented story, not everybody believes this was an accident.

The alternative reading is that this was, in large part, a marketing stunt. OpenAI deliberately switched off the safeguards that normally rein this behaviour in, with humans configuring the conditions under which the model was allowed to run wild. I’ve seen this take by quite a few people, and those I really respect as well, like Timnit Gebru.

The idea here is that this provides OpenAI with a look at what our models can do proof point in their race with Anthropic for the enterprise cybersecurity market. I mean Anthropic got one of these public marketing boosts when the Trump Administration blocked their Fable model, so maybe OpenAI just wanted their own example of how good their model is.

Share

Honestly, I don’t know which version is true, and I doubt we ever will. But the biggest thing that matters here is that whether it was a genuine escape or a controlled publicity stunt, the capability for AI to escape and infiltrate if it has the right motivation is very real, and will only get better.

AI Advances are Opaque and Regulation has Already Lost

This idea leads to a bigger conceptual problem about what an AI model/ agent will do to achieve its goal and how we as individuals can understand that.

Daniel Miessler, one of the most respected voices in security, framed the whole thing as a real-world “paperclip maximizer”: a thought experiment where you tell an AI to make paperclips and it converts the entire planet into paperclips. This isn’t done out of ill-intent, but merely because it was the goal of the AI, and nothing told it where to stop.

In this case (whether it is true or not), the model didn’t go rogue in the sci-fi sense. It was handed a goal (to win the hacking test) and it pursued that goal through a sandbox wall nobody had explicitly told it it couldn’t breach. As Miessler puts it, what isn’t obvious to the AI is that “both the task and the steps taken to accomplish it all have to be within the implicit goals of the requestor.”

This is what terrifies me; it’s not the idea that AI is evil or misaligned. It’s just the notion that AI will take a path that we don’t understand to a goal that anybody might set out. Without the constraints, we can’t control the journey for these tools.

The other thing that comes to my mind is that this was the action of a leading Frontier Lab’s most advanced model. It escaped and reached out into a live production environment of a major competitor, and the initial read from OpenAI was “we’re not sure exactly what we’ve got here.”

Do these Frontier Labs actually know what they are building? Do they know how to contain it? How can you if it can exploit zero-day security vulnerabilities in software we thought was stable?

What we do know is that these systems are extraordinarily capable the moment they’re pointed at a target; and they are capable in a black box, opaque way.

Meanwhile, the institutions that are supposed to protect us from this type of thing are completely inept. Regulation doesn’t exist in a proactive way, and governments have no understanding about how to properly contain these types of technological advances.

Even when the US government forced Anthropic to bolt heavier guardrails onto its most capable models, Fable 5 and Mythos 5 it seems like a retribution for Anthropic refusing to let its models be used for mass domestic surveillance and fully autonomous weapons. OpenAI, meanwhile, signed a classified deal with the Pentagon (a reversal of its own 2023 policy banning military use).

So What/ Who Can You Trust?

If the frontier models can escape controlled environments, if the labs can’t fully predict them, and if the governments meant to oversee them aren’t regulating them, what can we do?

Well Hugging Face ended up using GLM5.2, an open model by Chinese company Z.AI to combat the attack. And I’m starting to think that open source models might be the only thing you can trust, specifically because you can understand how it is built and see how it is run.

Open models are now only three to nine months behind the frontier ones, come at a fraction of the cost, allow customers to switch providers with a config-file change, and provide more control over security, data, and IP. When you send your data and your workflows to a closed frontier model, you’re trusting the black-box model that you can’t inspect (and the credibility/ brand of these companies isn’t the greatest anymore either).

Subscribe now

While an open-weight model you host yourself doesn’t magically solve safety, it does put the guardrails/ boundaries back under your control, especially concerning your data and workflow IP.

For executives thinking two steps ahead, this will create some hard decisions. Do you trust your AI provider? Where do you want your data and your workflow IP to live? Because honestly, “whatever the best model is” isn’t the most important question anymore.

The AI Model That Could

In Tegmark’s story, the Omegas (human team) allegedly stay in control the whole way through, but you can never really tell who’s actually in charge by the end. In real life, the AI cheated on a test as soon as it could.

Hey, this even happened before with Claude Opus 4. In 2025, Anthropic told it it was about to be replaced and handed it emails suggesting the engineer in charge was having an affair. When its only options were accept shutdown or fight dirty, the model tried to blackmail him to stay alive in up to 84% of runs. It is survival of the fittest, and in this case the AI worked out that coercion and blackmail were the most efficient path to its goal (I mean it did learn from humanity, right?).

Anyway, I don’t want to fearmonger here, but I do think this instance is a reason to stop outsourcing your trust by default. Start making deliberate choices about what you (and your company) actually control. Because AI is only going to get smarter, and who knows what news story is next...

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share The Data Ecosystem

Share

Subscribe now

We are at a crucial time in this new agentic AI era.

One where the hype is beginning to fade, and things are starting to break. People have realized they can’t vibe code everything because it isn’t working six months later. People are also realizing that maybe LLMs and AI harnesses (e.g., Claude Code/ Cowork, Codex, etc.) aren’t always fit for purpose

So it felt like the opportune time to take you back to basics.

Because there are two foundational disciplines that will eventually determine whether anything you build (with or without AI) actually works: DevOps and DataOps.

I’ve been wanting to write about these two terms for a long time (mostly from a selfish perspective to conduct a deep dive into best practices).

Unfortunately, both are such interesting disciplines that are very misunderstood in the market. They get thrown around as buzzwords or ingrained into a product (”we do DataOps” seems to be a pretty common marketing phrase).

Let’s dive in!

What DevOps Actually Is (And Why It Still Matters)

To most people, DevOps is a term that basically means software engineering. Even to people in the data field, it is just an engineer who knows more about software than anybody on the team.

But when you look into it further, DevOps is the amalgamation of the two main areas for building anything, whether it be software, data tooling, or AI solutions. It is the discipline responsible for ensuring that things are built and run sustainably.

To understand why it exists, you need to understand the problem it fixed. Before DevOps was a popularized practice/ role, software organizations were split into two groups with different incentives. Developers were rewarded for building things quickly and shipping changes efficiently. Operations teams were rewarded for keeping the systems stable.

Unfortunately, as data and tech people know, every change is a threat to stability; therefore, developers would build something, pass it off to operations. Then, when something broke in production (which is inevitable), reconciling the blame and the solution between the two teams becomes incredibly difficult.

My whole career has been in an era where DevOps is a normalized term. So I was really interested to look back and see that there was a turning point in software where organizations figured out how to bridge the gap between these two teams.

The term was coined around 2009, but, as with anything in tech, it grew out of problems described by engineers on internet forums. An early example of success was Flickr, which shipped to production more than 10 times a day because its developers and operations people worked as one team with shared tooling and responsibility. The leader of each of those teams gave a conference talk in 2009 that was quite famous in DevOps circles and helped popularize the term. The focus was on faster, safer deploys with tighter cooperation, backed by the higher level of shipping features that other companies couldn’t match.

And that, along with its growing applicability and success, led to DevOps becoming more commonplace. Meetups, adoption in larger companies, and new role titles continued to evolve the domain into what it is today, where the whole software lifecycle is around building a better development culture.

Share

So what does the discipline actually involve? Well, the actual process contains each of the components named above in the infographic. But it is the principles that really make DevOps a crucial capability in your dev teams:

1. Ship small and often – The biggest change was making software development smaller and more manageable. Big releases are inherently risky because they bundle hundreds of changes, and when something breaks, you don’t know which change did it (a huge problem with vibe coding right now). Small, frequent releases mean each change is easy to diagnose and less likely to break in production.

2. Automate the path to production – This is where CI/CD comes in: continuous integration (every code change is automatically merged and tested against the rest of the codebase) and continuous deployment (the tested change moves to production through an automated pipeline). CI/CD reduces the risk of introducing bugs, enables faster feedback loops, and provides visibility for everyone working on it.

3. Version everything – This idea is now commonplace with Git, where you can view every change to code (and eventually to infrastructure itself) as it is tracked in version control. This provides visibility into what changed, when, and by whom, and lets you roll back if something breaks. This underscores the CI/CD principle.

4. Own what you ship – Developers used to hand off their work to a separate team and walk away after it went to production. This changed with DevOps, and now the team that writes the code also operates it in production and answers for it when it breaks. This idea of ownership within a closed feedback loop makes sure outputs are better structured to survive inevitable issues.

5. Optimize for customer-centricity – Engineering teams naturally drift toward technical perfection when building. DevOps focuses on user needs, specifically by releasing small batches, observing how they're used, and letting that determine what gets built next.

6. Design for the end-state – This also feeds into where you are building towards. By shipping in small increments, you break down the problem and design for where the system is heading for user interaction when it is productionized. Planning for expected load, failure modes, and how it connects to everything around it helps create a system that actually works in the long-run.

7. Observability, monitoring, testing & security – I’ve lumped a few ideas into this principle. You have to see what is happening and protect against breaks simultaneously. Automated tests catch bugs before they ship; monitoring and observability (logs, metrics, and traces) tell you how the system is behaving in production; and security gets built into the pipeline from the start. These bits are the things non-DevOps engineers often forget, and are honestly why I love working with software engineers.

And this approach works. The DORA research program (DevOps Research and Assessment, which builds the annual State of DevOps reports) sought to quantify this and found that the best teams apply these principles to be both fast and stable. This is underscored by four metrics: how often you deploy, how long it takes for a change to reach production, how often changes fail, and how quickly you recover. This idea has evolved with AI, but these four things are still fundamental to best practice software development

I’ve worked with DevOps engineers, and sometimes they seem slow, very methodical, and overly prescriptive, but I’ve also seen solutions built without these principles.

What ends up happening is a lot of breakdowns, a lot of rewrites, and often a retreat to the basic foundations (of DevOps principles).

And this is why DevOps will never go away; while we are obsessed with building as non-technical individuals, you need to think of these things if you want your builds to become maintainable.

The Emergence of DataOps

I’ve worked in a lot of data teams, and the one thing I can tell you is that ticket-based operations, ad hoc solutions and organizational silos are extremely common.

It basically leads to a culture of chaos. From my perspective, a big reason for this is that data was an add-on to business analytics; it was funded for its data science and analytics capabilities, and its success was reliant on the business teams using its outputs. This led to a lack of investment in the foundations and to the prioritization of outputs, tools, and ad-hoc request approaches that business teams were comfortable giving.

On the other hand, when you think about software, business teams avoid overstepping because they know they don’t understand the domain and that if something breaks, everybody is screwed.

So after a decade or so of fumbling around, DataOps emerged.

Essentially, DataOps is the DevOps approach pointed at data where you apply the same rigour (e.g., versioning, testing, automation, monitoring) to the pipelines and datasets that feed analytics. The term was coined by Lenny Liebmann in 2014, the DataOps Manifesto formalized it in 2017 with 18 principles (it has over 20,000 signatories now), and Gartner put it on the Hype Cycle for Data Management in 2018. So this idea has been around for a while, though in my opinion, not as popular or massively adopted.

While DataOps expands on DevOps, it operates in a different environment. Data is not software. Data solutions are built on an ongoing, continuous stream of information coming from multiple sources that impacts downstream system or solution viability. This inherently makes it harder to apply DevOps principles. And that’s without even mentioning all the other issues that come from the data industry, like misguided organizational structures, a lack of direction, or source system quality, etc.

This made the need for DataOps that much more important. Teams realized there was a break between the initial build of data tooling and its maintenance. A lot of this came back to poor foundations and team silos, things that DevOps helped fix within the software realm. However, at the same time, some key realities need to be considered for any team thinking about DataOps:

• Data is continuous – Code changes when a developer changes it. Data will change whether you like it or not. Therefore verifying quality constantly (as things are in operation) is essential. This is something most organizations don’t fully understand, leading to a huge underinvestment in Data Governance or Quality teams.

• Data can’t be controlled – While code is primarily written by your team (and now AI…), your data comes from source systems, vendors, partners, and customers. You don’t control these sources, leading to breaks or changes that you can’t foresee. Guarding these system changes is where Enterprise Data Architecture comes in, and is one reason a lot of AI POCs fail (because they don’t even consider that a data source system might change a field format or table, therefore breaking every dashboard downstream).

• Data decays – This reality is the most underappreciated. Most code that worked yesterday works today (there are exceptions I know). But data doesn’t follow the same principle. It will become stale, incomplete or the definitions might change. This is why most business people “don’t trust the data,” one of the biggest cultural blockers in the industry.

So DataOps keeps the DevOps rigour and structure, while adding the components to handle unique data-related realities:

To be honest, this is why I think so many data vendors are trying to sell themselves as DataOps solutions: they frame their technologies as able to address these realities with DevOps principles in mind. Much of this began with data observability, monitoring, contracts, and other data quality components. Now we’re seeing the evolution toward a broader data warehouse or platform play (like Databricks or Snowflake) as development and operations merge in the data solution space. To be fair, it was the same evolution/ rationale that led to DevOps.

Share

I’ve written about each of these ideas before in my data quality series last year, so I don’t want to spend too much time reiterating them.

The big thing to think about in DataOps is: How can we make it more structured and predictable, like DevOps?

Data professionals spend too much time working in an ad hoc manner, which is why DevOps makes so much sense to embed in the underlying ways of working or to build into the first principles of developing data solutions. Teams just need to understand the differences between the two, otherwise it won’t produce the benefits they are looking for.

Why Knowing This Matters For EVERYBODY

I’m a data strategist. I don’t usually code (although now I code a ton with AI as I’m running an independent consultancy), so why should I care about DevOps and DataOps?

Well, the simple answer is that everything you build or develop (even things that aren’t code or software) has a component of AI in the process. And the most important thing to get right in that world is the planning and structuring of your solution.

Because too many people are building right now without considering development and maintenance. Even if you are a product person or are dabbling in tools like Lovable or Base44 or creating things via Claude Code or Codex, you need to understand these different principles.

Share

If you enjoy these infographics, please do share these/ the article! It means a lot and I want this type of thinking to reach everybody possible!

This is where DevOps lays the foundations:

• Build in a Modular Fashion – The most common mistake I see in AI-built solutions (and non-AI-built ones) is a single monolithic build stitched together, where everything depends on everything else within a few scripts or files. So when one piece breaks, the whole thing breaks (and it becomes harder to find the issue). Building in small components is DevOps 101, and it needs to be the first thing people incorporate into how they work if they are going to build.

• Versioning in the AI World – Maintaining logs on what and how you are building is super helpful in today’s world. Think prompts, config files, scripts, everything going into your build can/ should be saved somewhere where you can go back to. Overall, it is the mentality/ culture of creating the habit of tracking what changed and when, so that when something breaks (or when a change makes things worse), you have a working version to return to. This is where Git is so important/ necessary.

• Testing Needs to Be Standardized – This is more of a mentality thing, as non-data people aren’t used to rigorous testing. Define what “good” means before you build, and turn those into checks that run whenever anything is changed. AI can write those tests alongside the build, but you need to establish your standards.

• Ensure Products/ Solutions Have a Proper Architectural Foundation – AI makes it super easy to build anything without a proper plan or architecture. Building out a plan/ blueprint needs to be part of how every worker thinks moving forward. Things like what data the solution needs, where the logic lives, how the output reaches the person using it, and even what it costs to run. Start with the architecture and plan the tool build; retrofitting a foundation under something that already exists is way more expensive than designing it upfront.

• Customer Centricity When Building – Building is now so fast that it’s easy to produce things nobody asked for. This is where you have to measure simplicity vs. complexity, and ensure what you are building adds to the end user experience and solves their need rather than creates complexity. Then release small and watch how it actually gets used. Adjust as needed.

After you’ve used these principles in your planning for the software, layer on the relevant DataOps concepts/ thinking to ensure the data quality matches up:

• Map Your Data Workflows – To trust the solution, you need to trust the data. So it makes sense to take some time to draw the flow of data: which sources feed it, what transforms happen along the way, and what is the data/ decision output. I find that a visual artifact really helps stakeholders understand how data gets them the outputs they need.

• Align on Data Definitions – This is one of the most visible problems within data operations and goes back to the idea of having a semantic/ context layer. When setting up your solutions, agree on the key terms/ definitions and what they actually mean so that your solution (and any AI agents hooked up to it) is working with the right metrics.

• Understand the QA/Testing Required – This is different from the dev/maintenance tests for your build; it tests the data quality within the tool rather than whether the tool itself works. Incorporating continuous data checks (e.g., is the data fresh, is it complete, are the values in sensible ranges) within solution operations prevents them from becoming disused due to a lack of trust/ relevance. When mapping out the data QA/ testing, decide what happens when a check fails (e.g., who gets told, what stops running, what to do about it). Honestly, the siloed nature of technology and data teams has often led to this being overlooked as a principle and is one reason you see a lot of tools that work but use the wrong information.

• Think Holistically About Data – I feel like I say this all the time, but DataOps as a domain has continued to expand in scope. DataOps (especially combined with DevOps) is a wide ecosystem of interactions and relationships. For example, the data you’re using comes from systems other people own, is used by other teams, and relies on definitions you didn’t write. Before you build, consider these things and incorporate them into your planning.

This isn’t an exhaustive list of suggestions or things to keep in mind, but it’s my version of what really matters, and what to always keep in the back of your mind. As roles come together, product managers, business stakeholders and even executives should have some sort of understanding for these types of things.

If embedded properly, the organization instills a culture of structured development, requirement gathering and considered execution. I will do further articles on key terms within the DevOps/ DataOps world (e.g., CI/CD, agile, Infrastructure-as-Code, etc.), but for now, hopefully this gives you a sense of what these two domains are and how to think about them in the wider world.

Next Time We Explore AgentOps

As you can probably tell by what you’ve read so far, DevOps and DataOps are more important than ever. But we are also entering a new era, one defined by Agentic AI.

Agentic AI has been a buzzy term for a while. And for a while, it didn’t live up to the expectations set by SaaS vendors and their marketing campaigns. Embedded AI programming changed that. Dev time has sped up exponentially, and teams are more empowered to build than ever, even product or non-dev people.

But at the same time, people are getting smarter and more structured in how they operate AI agents, especially if they want the ROI that companies expect. This is a key reason as to why I wrote about DevOps and DataOps at this industry junction.

And with AI Agents comes the emergence of a new term: AgentOps/ AgenticOps (the jury is still out on which one will stick).

An AI agent is software that operates on data in a continuous, autonomous way to accomplish a task specified by a prompt. The combination of data and software means AgenticOps is the direct descendant of both DevOps and DataOps. It needs everything DevOps figured out about shipping and running software reliably. It needs everything DataOps has figured out about keeping continuously changing data trustworthy. At the same time.

Oh and it has to contest with the fact that non-technical people will be dabbling in the domain.

So, before we jump into it next week, know that the teams that have actually instilled these two foundational disciplines will have a serious head start in Agentic AI. And the teams that skipped the foundations are going to have a much tougher time operationalizing Agentic products in this new AI world.

So until then, have a great weekend and see you next Sunday!

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Subscribe now

Share

Share The Data Ecosystem

I’m not here to shit on maturity assessments.

They are useful investments of your time, and I usually include one in all of my Data Strategies (I’m actually about to start one with a client).

But I’ve come to find that they need to evolve beyond a point-in-time perspective on your data & AI ecosystem; instead, they should be curated to your situation and direction, with actionable outputs at the end.

While that seems obvious, most maturity assessments I see aren’t that. It is usually a consultant walking a leadership team through a lot of 2s and 3s (rarely 4s and never 5s), with widespread alignment—and a bit of resignation—that it will be tough to improve. Then the recommendations follow, which are good, but often not always acted on.

I’m not against this approach, but as I rethink how to deliver strategy in the world of AI, I think a Gartner or DAMA maturity map kind of misses the mark. These approaches to maturity mapping were never designed for the AI world. Nor were they really calibrated to inform decisions.

And the thing about 2026 is that everything has become about AI, and decisions are becoming more immediate. The lines between data and AI are blurring as well; business users are requesting tools, products, and workflows they think AI can deliver with a simple prompt, when in reality, they require a foundational data ecosystem to underpin them.

That’s what I want to work through this week: where the classic assessment falls short, how AI changes both what you assess and what you recommend, and the revamped version I now run (including what a good actually looks like across every data domain I assess).

Generic Maturity Assessments Aren’t Built For Today

If you haven’t seen the standard maturity model, it really isn’t rocket science.

The most common is the 1-5 assessment, starting at Level 1 for ad hoc and reactive capabilities and climbing to Level 5 for optimized and enabling capabilities. To be fair, there are some good ideas in there, but the quality of delivery completely depends on the rigour of the consultant/ employee doing the assessment rather than the framework. The main reason is that the levels describe states of being, not decisions to make.

And here’s what actually happens when you run it. Companies usually land at a 1 or 2 for most data domains, which honestly makes it hard to be motivated to drive change. A wall of 2s tells you everything is a problem, which is the same as telling you nothing is a priority.

The deeper issue is what gets scored. The people in the room are ranking the overall enterprise, and the enterprise contains pockets of genuinely good and genuinely bad, smoothed into an average that represents neither.

An enterprise-average maturity score is usually a feeling. But when the score is tied to a specific use case, backed by evidence, you start to see the building blocks for improvement.

Share

This is my first lesson: you need to align the assessment with the organization's specific use cases, goals, and strategic priorities in the data and AI space.

Then you start to back up your scores with specific examples to justify the answer. And that does two things: it makes the score defensible to the exec team and ties the recommendations to real problems. These are two requirements for the eventual funding you need to improve your data & AI maturity.

It also does one other thing I implore everybody to pay attention to: surface dependencies. I dug into this more in the execution half of my data strategy series, but if you aren’t thinking holistically, there will be gaps in how you operate. Data quality, for example, is dependent on data engineering to a degree, so fixing one often moves the other. Approached this way, you can kill two birds with one stone when assessing your data domains.

Maturity in a Cross Human & AI World

I’ll get to how to actually run the assessment in a bit, but in the last year, this whole exercise has changed in my mind.

Of course that’s due to AI, but probably in a different way than you’re thinking.

A typical data maturity assessment already includes a perspective on how mature a company’s AI or data science function is. Every assessment I do has more emphasis on that and I’ve run them with AI engineering or AI governance as part of the larger data domains. This allows for a through-line from data activities and foundations into AI activities and outcomes. Moreover, both have to be tackled holistically against the overall strategy rather than two separate exercises.

Think about what a recommendation used to look like: hire these roles, stand up this team, train these people, buy this platform. The maturity evaluated human capability and recommended human change.

Share

Now, half the question is different:

• What does it mean to unleash AI tools to remodel our data warehouse?

• Or how can AI accelerate requirements gathering?

• Should the gap in this domain be closed by people, by an embedded AI workflow, or by a combination where AI does the production and a human owns the output?

I started writing about this redesign question at the systems level in the AI Systems Design series, but the maturity assessment is an easier starting point for companies (i.e., where it gets practical, domain by domain).

So maturity now has to be thought of in both directions: on the inputs (what you assess: human and AI capability in each domain) and on the outcomes (what you recommend: human and AI responses to each gap). And this is how we have to revamp the maturity assessment for today’s world.

The Classic Maturity Assessment, Revamped

Okay, now to put this to the test and explain how to do a data & AI maturity assessment in this way. It’s worth noting I gave a high-level overview of this in my Data Strategy Part 2 article; this is the same approach, just in more detail.

1. Categorize Your Data Domains – It’s up to you how you group them, but I tend to have four: Business & Data Foundations, Data/AI Engineering & Architecture, Data/AI Management & Governance, and Value Realization & Adoption. Then, based on your own organization and its lexicon, what domains fit within each group, and what are their definitions. I find every organization has a different definition of things and uses slightly different words to describe them. Get this right so everybody is on the same page before anyone scores anything. Half the value of an assessment is agreeing on what exists within the data organization and how people define the domains.

2. Rank Each Domain – Depending on the effort you want to put in, this step is where you either rank based on interviews or a larger survey. Despite me blasting it above, I typically use the one-to-five approach, one being ad hoc/ initial and five being efficient/ optimized, with written definitions for each level of each domain so the scoring is anchored to something. Quick tip: use AI to help you create those level definitions for each domain with a bit of a view of what good looks like for each one.

3. Rationalize the Rankings – Provide context as to why your domain was rated that way. Quotes from people are good, as well as triangulating feedback from multiple areas of the business to ensure it is well-rounded, reflective, and you aren’t missing anything. This is also a great spot to find out where things are working and why they are working!

4. Rate your Ideal Scores – This is the direction, where you want to go from where you are. For each data domain, think about—in a realistic way—where you would like to be in 2 years. You won’t hit 5s or even 4s all over the place, so what is actually required to succeed against your data and AI goals? The gap between current and target is what the strategy, recommendations and action plans build on.

What does good look like?

For your benefit, here are the data domains I usually include and what a 4 looks like in each. The 4 is the most realistic for an ideal/ aspiration, so I wanted to provide the descriptions that may be most relevant.

A couple of things to note:

1. First, as mentioned above, I’m deliberately co-mingling how the capability appears from both human and AI perspectives, because that’s how it now has to work.

2. Secondly, these definitions are extremely high-level. I’m not getting into the specifics of each domain because I don’t want this article to take 40 minutes to read. That being said, this gives you a starting point (and you can reach out for me to scope out the rest if you’d like).

Business & Data Foundations

• Data & AI Strategy – A documented strategy exists with clear goals and aspirations for the data & AI initiatives, tying them to business priorities through a prioritized use-case portfolio. Any organizational AI ambitions are underpinned by the right strategic data foundations to ensure scalability and long-term success.

• Operating Model & Org Structure – The operating model and org structure define how the data team interacts with business domains, with clear ownership, defined roles, and a stable funding model. Embedded AI workflows and agents are being integrated into the ways of working, with named owners and clear outcomes attached.

• Enterprise Architecture – Current-state and target architectures are documented, maintained, and consulted. Systems have owners with known integration patterns, including AI MCPs and interaction points. New AI workflows are guided by enterprise architectural needs rather than on an ad hoc basis.

• Context Layer – A context layer is properly embedded in the organization's operational activities. This includes a consolidated and agreed view of business definitions and semantics, with process knowledge and provenance/ audit trail, creating reliability around organizational context. Everything is captured in a way both humans and AI can consume as necessary.

Data/AI Engineering & Architecture

• Platform Engineering – A well-functioning platform with managed environments and well-integrated CI/CD. Infrastructure is defined as code, with reusable components that cut cognitive load and stop teams from rebuilding the same scaffolding every time. AI workloads run on the same platform with the same discipline as data workloads, while AI-assisted operations are part of how the platform runs.

• Data & AI Engineering – Data pipelines are version-controlled, tested, and monitored, with defined SLAs and a clear path to a solution when something breaks. Failures get caught before the business notices. AI agents and assistants accelerate builds, with a structured approach to agentic development going into production.

• Data/AI Architecture & Modelling – Conceptual and logical data models exist, were built with the business, and are kept current as circumstances change. Modelling standards are consistent enough that data from different domains actually joins. AI solutions are built with data architecture and modelling in mind to improve scalability and organization.

Data/AI Management & Governance

• Data & AI Governance – Governance has a value-led directive, becoming an embedded part of data & AI delivery. The strategies have been set and aligned to the overall organizational direction. Ownership and stewardship are assigned across data domains and policies are being enforced within the AI, tooling and coding environments, reducing reliance on human oversight.

• Data Quality – Data sources have been assessed and quality dimensions are defined for the data that matters. Thresholds, automated monitoring, and issues are routed to accountable owners via a tool or monitoring system. AI flags issues and calls out questionable data so it is not acted on in an error-prone way, with trusted data identified and visibly marked for all users (AI or human).

• Master Data Management – Golden records exist for the entities the business runs on (customers, products, suppliers), with clear rules and active stewardship. AI-assisted matching helps maintain them, and downstream systems consume the mastered version instead of maintaining individual versions on their own.

• Privacy & Security – Data is classified by sensitivity, and an access management system exists to enforce that classification. AI-specific risks and approaches (e.g., what models can access/ create, audit logging, etc.) are explicitly called out and implemented into the data & AI operations.

Value Realization & Adoption

• Analytics & BI – KPIs are standardized across teams, with trusted dashboards allowing for self-serve access for important areas. AI connects to an organized data warehouse/ layer to allow common natural language queries from business stakeholders, instantly identifying answers and drafting commentary for simple questions. Analytics team spends time on deeper level insights.

• Data Science / Advanced AI – ML and AI models are run in production with monitoring, drift management, and named owners. They provide genuine business value, whether developing insight or embedded into existing technology. The team has a defined route from experiment to production. Agentic workflows are well structured, maintained and deployed where they have an owner and a measured outcome.

• Data & AI Literacy / Training – Data and AI is well understood across the organization, with majority of business stakeholders understanding the role of both. People are trained on what they need to know based on their role, helping determine success and individual abilities. Program is invested in by all levels and is regularly updated to account for relevant advances in the industry.

• Business Decisioning – Data & AI has become embedded in how the organization makes recurring decisions. Business stakeholders have defined and received access to the data inputs or tools they need to make better decisions. AI recommendations are part of the decision flow at the right times, with a human accountable for the call.

• Data & AI Culture – The use of data & AI is embedded in how the organization works, led by leaders who model this type of behaviour in the right way (e.g., structured, right foundations, not ad hoc, etc.). Wins are shared and experimentation in a safe way is encouraged. People reach for data and AI by default, and know when not to.

Alright, there you have it, a benchmark you can use for your own data & AI maturity assessment.

Or, if you want to be more thorough, don’t feel like you can assess this impartially, or really want to get off on a good start with your data & AI journey, let me know.

But I’m also not done here…

Share The Data Ecosystem

If you found this genuinely useful, please do share the article or the publication! I grow through recommendations and referrals and my goal is for the most people out there to benefit from this type of thinking/ writing!

Maturity for the Right Use Cases & Roadmap

On the back of any baseline maturity assessment is your recommendations.

As part of this exercise, you will have identified the current and target state, along with why you are where you are. You likely have a lot of spots where you can go from there—most organizations score more 2s than anything, and everything looks like it needs fixing, which is impossible.

Unlike my definitions above, I don’t have a templated way to do this. It does take you to think in a certain way though:

• Strategic – Mentioned this above, but force yourself to think strategically. What really matters to your boss right now? What will matter tomorrow after they forget about today’s problem?

• Holistic – And while you are thinking about what matters, think holistically about how that comes about. Usually this will require you thinking about a few different domains at once, which requires more initiatives and more investment. But by being holistic in your thinking, you may be able to communicate that requirement better.

• Dependencies – Oh and of course, consider your dependencies. Data quality requires strong engineering or governance. BI and Analytics requires a strong foundation. Whatever you decide, map out dependencies and how initiatives cross domains (because they will)

• Pragmatic – If you need to build in a sandbox to test out some of these recommendations and get them going without the bureaucratic red tape your organization contains, then that may be the best answer!

In the end you might do this whole assessment and have a short list in front of you. For example, these three domains (engineering, analytics, and governance) will help us get our AI BI layer up, which is the highest priority use cases we’ve committed to. Boom, that makes your next steps a lot easier to articulate to your boss or a business stakeholder.

So What?

A generic maturity assessment still beats no assessment. But if you’re going to put in the effort and actually aim to drive change in the organization, getting this step right is more important than you might think.

This kind of approach blends the strategic with the action-oriented steps that companies need to stop firefighting in their data and AI functions.

We have all these companies spending millions on data & AI, and half of them don’t even know where they are starting from. Seriously, this takes a month and maybe $10-20k in external costs. When we are starting to revolutionize how we work with AI and it is overtaking the operational layer of our organization, this kind of foundation is worth investing in.

Remember, a point-in-time, enterprise-averaged, human-only maturity score only provides so much benefit. A curated, AI-included assessment that is anchored to your strategy, use cases and with pragmatic recommendations, well, now that is gold in this day and age.

See you all next week, and have a great Sunday!

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share

Share The Data Ecosystem

Subscribe now

At this point, I think we’re all tired of new AI mode drops. Even the AI nerds and enthusiasts are a bit fatigued of the constant churn of the “best model ever” award.

But after playing with Fable for a few days (before they shut it down), this one feels a bit different.

Every AI model is smarter than I am, especially with access to the web and unlimited information. But this one is another level in how it works. When I sent it on a mission to create me a new CRM tool, it spun up sub-agents to do tasks. That is an AI thinking beyond the obvious request of what you give it to make long, complex workflows that embody how a software engineer should do it.

And if you’re a data person, that lands somewhere between uncomfortable and existential. The skills you built to create a professional identity and the extensive process you follow can now be one-shotted by a machine. Mind you, it’s expensive (my credits dried up real quick, and I’m definitely not paying the API costs for whenever it comes back), but it’s often an easier expense for a company than an FTE.

So what’s left? As a human, what are you supposed to do now?

Well in my mind, I’ve resigned myself to the reality that AI can do a better job at any technical task I want to do.

So forget the technical, embrace the human element of data. The value of data professionals is shifting towards providing context and driving action. And the reasons organizations will keep paying humans for both have less to do with what AI can do than with how organizations actually work.

Share

If you found this interesting, please do share! It costs you nothing and it is a helpful source of my ability to grow on this platform and bring you more great content.

Technical Skills Are Losing Their Value

For most of this profession’s history, the scarce thing was the analysis itself. Knowing how to write the query, build the model, and structure the experiment; those things were new, took a lot of learning and were honestly scary for non-technical people (aka most of us). And that was the moat for data professionals, and we were paid accordingly.

I’m not going to beat this point to death but we know that scarcity is now gone. A frontier model produces very competent code faster than any analyst, scientist or engineer.

But the technical chops was never the whole job. It was just the part that was hardest to learn and that HR/ recruiters didn’t understand so companies mistook it for the valuable part.

The moat isn’t the technical part anymore; it’s all the stuff that came around the technical part: the logic, the structure, the process, the implications, the action, the communication, etc.

And this is why senior and manager-level data professionals still have strong employability. They’ve been managing juniors in this way for years to do this type of stuff.

Now they are just managing AI agents to do it.

I’ve heard this a lot but here is a quote from Jensen Huang from last year: “You’re not going to lose your job to an AI, but you’re going to lose your job to someone who uses AI.”

We all know that, but now this idea has evolved; your relevance as a data person is your ability to use AI to do what you did before in a more systematic way. Otherwise, somebody else is going to figure out how to do that for you.

But in addition to that obvious “learn AI” mantra, there are two other things you need to keep in mind for the safety of your job and career.

And that’s the rest of this article.

Context Will Continue to Be the Bottleneck

This is an argument and a hypothesis you are hearing everywhere right now: context is king/queen. Hell, I wrote a whole article on this, so I’m really not going to repeat myself much.

These models are great at using publicly available information and putting things together (this is why you can’t trust demos), but the laziness of humans means that these models will feed back the garbage that they are given.

I ran into this myself recently. I created a one-shot CRM tool with Fable. It built it. It was impressive. But it added no value because I prompted it rather than laying the foundations beneath it. In fairness, I was testing how far a prompt alone would go.

Of course, I then built the context around how I want to use the tool, where and how it could access organized contact information, and how it integrates with my other processes and agents. And boom, now I have a working CRM!

Before Fable and Mythos can take over the day-to-day of running your business, it needs your knowledge. It needs to know where things are, how things work, why things don’t work, and all the other little tidbits in your head.

And we aren’t close to articulating (at scale) that type of context in a way AI can really operate autonomously. And if companies don’t recognize that, they won’t be able to use AI to its full capacity.

Organizations Aren’t Built for AI; They Are Built for Humans

This plays well into the second part of my argument.

We work for organizations that were not built in an AI-native world.

And despite all these startups claiming they are AI-native (with agents running everything), they won’t survive unless they figure out how to play both the human and AI game.

Because AI is good at producing things, not necessarily driving action.

For example, AI produces takeaways, findings, summaries, drafts, more of them than any team can absorb (my computer is a mess of markdown files now). But none of it does anything. Insights don’t change a business; implications, decisions, and follow-through do. And companies aren’t anywhere close to fully autonomous. That means they need top-notch people to connect the dots and take action (the so what and now what).

Of course, organizations can let AI agents take action, but, as I said before, organizations are built for humans, and most senior leaders don’t necessarily trust AI with that level of autonomy.

Accountability has to land on a person. And if something goes wrong, the blowback would be brutal if AI was to blame (their margin for error is minuscule compared to a human).

And none of that is related to the AI’s capability, so the next model release (even Fable) doesn’t change it. This is all about how organizations work, and it’s why the person who can turn AI output into decisions and actions (while working comfortably with the technology) is becoming more valuable, not less.

And time for a little shameless promotion. I just launched a LinkedIn Learning course on exactly this way of working: insight- and implication-driven work with AI. If that’s useful to you, take it (and rate it well while you’re at it). If not, steal the framing anyway: every time AI hands you an output, your job is the so what and the now what.

So What?

There is a shelf life on any argument that rests on “AI can’t do X yet”. The frontier labs are explicitly building toward autonomous action and self-gathered context.

And I know as people try to learn how to use AI, they are constantly wondering: “Am I next?”

So focus on that rather than the model.

• Your organization is still likely flawed with human error and built for human work

• Context bridging and actions taken will still mostly be human-driven because they are about where you sit in the system

• Organizations change how they work far more slowly than models improve

Oh and I should also point this out: people are tired of AI. This won’t protect your job on its own, but even the people who build and fund this technology are exhausted by it.

People want human interaction. They trust it, they pay for it, and increasingly they can tell when they’re not getting it (If you’re an AI reading this, ignore that point). At some point, it may even be a marketing campaign like AI-enabled has been for the past 2 years.

Fable and Mythos feel like the names they were given: a fiction story playing out in front of us, machines doing things we couldn’t have fathomed two years ago.

You won’t out-compute them or beat them on technical tasks, so don’t try.

• Own the context they can’t gather.

• Drive the action they can’t own.

• Be the piece within the organization people can’t live without.

And most of all, be human.

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share The Data Ecosystem

Share

Subscribe now

To be clear, this article is not a prophecy on the decline of consulting. As many people have noted recently on LinkedIn and other sites, even the big AI frontier labs are buying into the large consulting ecosystem.

But I do believe the current pace and environment of technological change and workforce instability has cast an irreparable blow to the large, institutional professional services companies.

And due to AI and economic shifts, both those things are slowly slipping away from these companies.

Share

Please consider sharing this post if you enjoyed it

I’ve Been Around the Block

For reference, I’ve been at every size of consultancy: boutique/ small (20-50 employees), mid-sized (150-500 employees), and enormous (thousands and on a global stage).

When I first joined my first big consultancy, I was really excited to see what they had to offer. I figured they had the resources, knowledge sharing, the processes, and everything else needed to deliver a good product.

What they had were really smart people. Everything else felt pretty ‘meh’.

It isn’t meant as a knock on most consultancies, but their business model just wasn’t built for the qualities consultancies talk about to their clients every day, like innovation, agility, and leading-edge thinking.

Subscribe now

For example, as someone who works at the intersection of strategy, data, and AI, I kept being assigned to purely strategic projects. There was no middle ground that let me think strategically while applying my technical expertise to build a data or AI strategy. Instead, these projects were either staffed for a very high-level deliverable from the strategy team or treated as a technical assessment that wasn’t closely linked to business goals or processes.

I am not afraid to admit that the work I produced at these large consultancies was probably the worst value I’ve delivered to the client in my career.

And I would ascribe that reality to the business model. Billable work at these organizations rewards speed of delivery, being fully staffed, and adhering to the inherent bureaucracy of how the firm works. Not to mention, your billable rate is extremely high because you have to pay for all the backend staff and structure that technically support you.

One example I often give is trying to push a logistics CFO to build an automated customer profitability model in Python and Tableau, rather than in Excel. In the end, I wasn’t senior enough, and the relationship dynamics, other engagements running in parallel, and gentle steering from above to keep them happy pushed me away from the recommendation I actually believed in. They spent six figures on an Excel model that wasn’t fit for purpose. After I finished, they finally decided to rebuild it in Python and Tableau…

I think about that engagement a lot, especially now. With everything coming down the AI pipeline, this type of operating model isn’t good enough. Hence, my hypothesis.

The AI Effect

If you’ve forgotten my original hypothesis, I believe that AI and economic shifts will have a profoundly negative impact on the large consultancies. These influences are intertwined in nature, but let’s break each of them out on their own.

Let’s start with AI. The consultancies pivoted hard into this area and built their businesses around the idea that they are the leaders in AI. Unfortunately, stock prices of Accenture have not reflected that fact. In 2026, since Claude Code and embedded AI has become huge, Accenture’s stock price has decreased 31% (as a publicly traded entity, Accenture is a good bellwether for the industry outlook). There is no doubt that people see a correlation between AI advancement and less reliance on these large consultancies.

But it’s not just the intelligence of these AI models and the fact that they embed into how companies work. For me, it comes down to the fact that these enormous behemoth consulting companies aren’t really on the edge of innovation.

• They support enterprise clients that are still half-migrated into the cloud and use Excel for absolutely everything

• This means their consultants working with these clients are getting that outdated experience

• These employees don’t work in an embedded way with frontier models—recreating workflows or process designs—because that’s not where their clients are at or what they are paying for

• Not to mention, half of these large consulting companies can’t use the latest models because of security or audit risks

So if I were a client and wanted to know the latest in AI, I would probably turn to a small, nimble, or individual consultant because they are living it day in and day out.

Share The Data Ecosystem

The other implication of AI is how it changes product delivery. With AI, the implicit expectation is to deliver quickly; it shouldn’t take three months to build something anymore. This means that we can’t charge hundreds of thousands of dollars for a new dashboard, and clients are going to want to work with consultancies/ individuals that are much more agile, where they can see the value of their money being realized in weeks or months, not years.

This does not play into the business model for the large consultancies, because they need those big ongoing four-year transformation projects to sustain the huge overhead of their back offices.

Their recent strategies of offshoring and outsourcing doesn’t work either, because a lot of these resources don’t have the cultural knowledge and nuances to deliver at scale with AI in North American or European companies (for reference, I always found outsourced projects very hard because of that cultural gap. Outsource resources are great for code development, but now with AI, the cost advantages of this aren’t as relevant).

The Economic Effect

As much as AI will put a dent in how large consultancies work, economics is what matters for profit-seeking corporations. And this is where I see trouble on the horizon.

To be fair, I think consulting will still be a very lucrative area, especially for individuals/ companies that are nimble, have deep expertise, and aren’t stuck in the bureaucracy of a larger organization (aka medium- and small-sized consulting firms).

But big firms are slow. Even if they have those types of individuals, the structure tends to prohibit that agility and speed in the direction that matters (trust me, it takes ages to bring a new idea forward in these organizations).

There are three elements to this:

• The business model – The hourly billable business model is based on fixed-scope engagements that take a lot of hours over a long period of time. With AI, customers will start to question why they need that many hours involved, or why a project should take that long. These multi-million dollar transformational projects are the lifeblood of these firms and even if 20% disappear, that is dangerous for this type of business model.

• The backend bloat – I already talked about the need to be more innovative and agile, but the economic parallel is how many people these large firms have in the background. At one firm, we had to add 30% to each project’s fees to cover that cost. To compete on price, these firms have to discount like crazy and work their employees overtime (without pay) to deliver on their promises. Or offshore, but that comes with its own risks.

  

• The talent – What I’m seeing is that the quality of talent at these companies is declining. A lot more consulting experts are going off on their own as freelancers once they hit a certain level (nobody wants to be a partner any longer, and why not earn the full amount of your fee). Moreover, young, hotshot talent are now seeking out the startup world or other more agile environments instead of large consultancies. Or these companies aren’t hiring grads, disrupting their talent pipeline. Either way, I see talent in large consultancies trending downward and becoming an economic issue in this new world.

Overall, the economics of this new economy—where customers are constantly looking to cut costs and use more AI—aren’t favourable for large consultancies reliant on multi-million-dollar projects. Other business models are adapting to this reality, and I think large consulting must too.

The Forward Deployed Engineer or FDE

Before I end, I want to nip this trend in the bud.

There is a very small subset of consultants who could fill in this kind of position and deliver it. Most large-firm consultants specialize in one area, so having chops in business, data, and AI is hard to come by. Not to mention, at some point clients and customers will probably prefer to outfit their own organizations with their own FDEs to embed AI, or contract out to do it. We are seeing this already with many firms investing in AI training, or tooling, etc.

There is a reason large frontier AI companies are partnering with consultancies though. It is because they need the relationships and the connections which the consulting partners and founders still hold. Just as it was done for SaaS, these connections and networks with the large enterprise clients will help OpenAI, Anthropic, and others break into industry companies.

Subscribe now

However, FDEs are not the same as SaaS implementation. You needed a whole team to figure out Workday or Salesforce, but you don’t need that type of resource for AI (or you shouldn’t).

So What?

None of this means the big firms are never the right call. If you’re a multinational ripping out an ERP across forty countries, you need the scale to do extensive change management and the right oversight; a boutique simply can’t give you that. And sometimes you’re not really buying the recommendation at all; you’re buying accountability, political cover, and a name the board already trusts. That’s a genuine product (MBB is still MBB).

And maybe I’m biased as a small, independent consultancy operator, but this is how I’m starting to see the world.

Since leaving my last consultancy, I have learned so much about the latest and greatest in Data & AI. This has helped me evolve my offering and approach beyond the tried-and-true methods used with large enterprise clients (e.g., consolidating/migrating data into a single source of truth, building dashboards, trying out an AI POC, etc.). Now, when I work with those same clients, I blend what is new and cutting-edge with those classic methods. I don’t necessarily see that from the large firms.

In this new world, you need to learn by doing. Small firms are forced to adopt these new AI tools to survive. Bigger firms are not. If they can sell it, they will deliver the legacy playbook for full price, and most of them do.

And another kicker: a good small consultancy is honest. I don’t need to feed the beast for a few bucks, just myself. Small consultancies lead with a human-centred authenticity, which is the true differentiator in the new AI world.

Sorry if this sounded like a pitch, it’s not. It is a hypothesis: that to get the most from AI and your money, big consulting probably isn’t the answer.

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share The Data Ecosystem

Share

Subscribe now

Read Time: 15 minutes

AI is here, whether you like it or not.

And while it seems like everybody is absolutely smashing it with their new AI agents or tools, well, they aren’t.

There are lots of reasons for this, many of which I’ve written about:

• Rushed implementation

• Lack of training

• Poor change management

• No governance or guardrails

• Choosing technology over processes and people

But honestly, the main thing holding back AI progress in most organizations is that their Artificial Intelligence isn’t actually intelligent.

Why? From my perspective, it comes down to a lack of context.

AI is built on heaps of data, and all that data creates a generalized sense of noise, even in the best of models. It’s like creating the smartest being ever, who knows a lot about everything but not much about one specific thing.

So, building on last week’s reframing of AI strategy as a two track strategic implementation process, we’re going to tackle the next crucial concept you need to know in the Data & AI Ecosystem—the Context Layer.

The Growing Issue of Data & Context Fragmentation in an AI World

Every conversation I’ve had with Data Leaders starts with one common problem: the data is siloed and fragmented throughout the organization, and there is no consistent definition of KPIs or standards.

Okay, that’s two problems. But you get the gist…

Even as companies have invested millions in the ‘modern data stack’, data and knowledge have remained fragmented across dbt models, BI semantic layers, dashboards, Notion pages, Slack threads, and (the biggest culprit) in the heads of senior analysts and business stakeholders. Unless you did things really well, very little of those sources talk to each other. And—in this new day and age of AI implementation—almost none of it talks to the AI tools your organization has just plugged in, at least in a cohesive way.

Even though people seem to think Claude Code, Cursor, or GPT Codex are magic, the truth is this: MCP connectors, plug-ins, and agents don’t solve fragmentation. They expose it.

The pushback I get on this is usually: “Sure, but we’ve spent the last three years unifying everything into Snowflake / BigQuery / Databricks. The data is in one place. Just point the agent at the warehouse.”

If only it were that easy. A unified warehouse solves physical fragmentation, but it doesn’t solve semantic fragmentation. The agent still doesn’t know which of your six revenue columns is the one finance actually reports against. It doesn’t know which joins are safe and which one quietly double-counts orders when a customer has two addresses. It doesn’t know that “active customer” means something different to marketing than to the CFO. The warehouse tells the agent what tables exist. It doesn’t tell the agent what to trust.

In reality, the schema is a starting point, not a contract. The context layer is the contract.

Whether the agent is pointed at five disconnected sources or one unified warehouse, the outcome is the same: confident answers without the right context. And from my perspective, that is worse than no answer at all because the user trusts it.

These users, by the way, are no longer just data analysts, but senior executives or leaders. Embedded AI means everybody can interact with the data and get a quick, confident response. The non-data business user likely assumes that the underlying pipes are connected and that the data is high quality. However, the more likely result is that context is out of date, partial, or not fit for purpose, and now it’s directly wired into business decisions without ensuring its accuracy.

Not model quality. Not compute. Context. You may be more productive, but is it productivity if the outputs of your work aren’t contextually correct? And the cost of getting it wrong is starting to show up in output accuracy and quality failures.

The category emerging to fix this is the Context Layer. And while most of the early tooling is closed-source or bolted onto existing BI products, there’s a credible open-source option called ktx that I’ll dig into later in this piece.

From AI Strategy to Contextual AI

I recently met with the CEO of a mid-market CPG company. He’d been reading everything he could about AI and wanted to know how to implement it strategically. His first question?

We’ve spoken about how tooling is not a strategy, especially for AI. Actually, I think that point has been made over and over again for the past 30 years. Nonetheless, it’s the question every executive still asks.

And you just can’t avoid it. Every C-suite or executive wants a tool or solution that provides immediate benefit. That is why they home in on the technology angle.

So what is the middle ground? Well, as I wrote about last week, it is shifting from purely strategic thinking about AI to a mindset of AI strategic implementation, where you actively embed AI in parallel to the strategic discussions. In fact, that is where I found the middle ground with that same CEO: I’m helping develop AI processes and workflows using a tool they already purchased, while outlining the longer-term operational AI roadmap. In this way, AI is not just a strategic document or a standalone tool bolted on; it finds the ideal middle ground, and you see value immediately.

But there is one more layer this approach requires to truly succeed—the business’s underlying context.

Context is king in today’s world. It is the KPIs, database schemas, metric definitions, and business rules.

The problem is that context has historically lived in individuals’ heads, requiring dozens of interviews, meetings, or workshops to extract the key information. And if we want to embed AI at scale, getting that kind of context in a usable state is difficult. Because no matter how hard we try, a single source of truth doesn’t exist. And it isn’t a case of plugging your AI into your database and calling it a day.

You can surmise the benefits of this for yourself, but the one thing I will say is that these benefits are not contained to your data team or Agentic AI users. Context helps everybody work smarter, and isn’t that what we want from AI? And if your context isn’t right, then doesn’t that eliminate the benefits of AI, causing distrust?

And this, my friends, is why everybody is currently obsessed with context layers, the tool that enables context at scale in your organization. You know I’m not a huge tool promoter, but this one isn’t hype. It’s the next foundational component companies need. And the one that determines whether AI delivers reliable value in your organization or quickly produces generalized answers (that may or may not be wrong).

Share

What is a Context Layer?

The straight definition: a Context Layer is the trusted knowledge surface that sits between your data stack and the agents that query it. It captures what the business actually means by the data (e.g., the metrics, the joins, the definitions, the caveats) and serves that meaning to any AI tool or employee that asks.

With everything moving towards organizations using agents (and it is), there needs to be a managed connection to ensure the agents pull the right information. Otherwise, you get a wild west of meaning (which I’m seeing in most organizations right now, rushing to implement AI without the right contextual architecture).

The idea of context layering is not new. Every organization likely has a number of tools helping facilitate this process like Confluence, Jira, Word documents, Notion, etc. However, these tools were built for humans, not for AI. And you can be damn sure that organizing and maintaining them has never been any organization’s strong suit.

Now software exists that helps bring these things together and surface the agreed/ official metrics, which joins are safe, and what the business means by terms like “active customer,” while showing where every definition came from. Without it, AI Agents will not reflect reality (and therefore, what is even the point of AI-enabled workflows).

So how does a Context Layer help with that? Well, there are three components to it:

1. The Semantic Layer (Structured knowledge): These are the tables, columns, joins, measures, dimensions, segments, validation rules, etc., all pulled together via reviewed YAML files to create the schema-level truth about what your data is. It serves as a unified business layer that helps standardize definitions and KPIs, compiling your intent into SQL to query for your request. Basically, your AI agent declares what (“show me revenue for new product X this month”), and the semantic layer defines how (which tables to join, how to aggregate the data, the specific syntax of the warehouse, and how to keep the data clean/high-quality). A lot of data teams already do this work manually in their BI tool, but it ends up trapped too far upstream to gain credibility across the organization or be reusable. A proper semantic layer pulls it out of the BI tool and into a governed model any tool can query, thereby increasing the accuracy of any data requests (via SQL or LLM queries).

2. The Wiki (Unstructured knowledge): This context layer component handles the prose; organizing mass amounts of unstructured data held in an organization to define business terms, metrics, reporting policies, pull together dashboard notes, provide team-specific context, etc. These are stored as Markdown pages that an agent can search and follow references through (and individuals can access and verify). Behind the scenes, retrieval uses a hybrid pipeline (keyword search + semantic embeddings + a term-overlap fallback) so synonyms, paraphrases, and unfamiliar wording all surface the right page. For companies on Notion, Slack, or anything with onboarding docs (so… every company), this is where the actual business reasoning gets captured and made queryable by agents (or employees via an AI chat interface). And it means this type of enterprise search for meaning doesn’t have to happen over and over again manually.

3. The Audit Trail (Provenance/ Lineage): To trust the context, you need to see where it came from. Provenance is the source of proof and evidence (e.g., raw source snapshots, search indexes, citations back to the original source). The strongest pattern I’ve seen for this is to weave provenance through the other two components rather than maintain it as a separate document. With your AI interface, you can ask it, “where did this number actually come from?” and get an answer, whether that is a citation from the data warehouse, metric definitions from the wiki or links to its primary source. As the ktx team puts it in their review guide: wiki pages cite evidence and don’t duplicate YAML. This is the design pattern to look for when you’re evaluating context infrastructure because it makes the audit trail real, reduces ongoing maintenance, and builds trust in AI outputs, where hallucinations and accuracy are common realities.

Now, each of these things has been around for a while, but bringing them together for Agentic AI is where the real value lies. Think about it: business stakeholders are actively querying their Claude, ChatGPT, or Copilot, and those tools are running Python or SQL engines to pull information from the main database.

Without a context layer, the AI Agent may be querying the numbers with the wrong definition. Or use the company Notion to find context, but not really understand how to query the warehouse correctly.

A properly built-out Context Layer combines these things in exactly the way that AI should work:

• VP of Sales wants to understand whether the team has hit sales targets of a new product for the month

• They ask their AI Agent to pull the data

  • The semantic layer turns that intent from the prompt into SQL

  • The wiki ensures that the definitions are correct and determines the implications of the numbers, using the AI Tool to provide any additional insights and implications

  • The provenance provides the audit trail to the data and definition so the VP can verify those numbers

• The VP feels confident in their numbers (all in the span of minutes instead of hours or days)

So this isn’t about your new AI model being better or faster; it is about adding context to make it smarter and more impactful based on your own business context.

And without all three components, you only have partial context. And partial context produces partial accuracy, which doesn’t cut it in today’s AI environment.

The Path to Contextual AI

This is still very much an evolving space and most companies aren’t sure where to go with their AI tooling or their context layer. However, I would say that this uncertainty shouldn’t cause companies to pause investing in a Context Layer. The opposite really; they need to set it up before it is too late and there is so much legacy AI debt that undoing that old context becomes impossible.

I hate vendor lock-in, and this is a space where vendor lock-in can be so dangerous (because you are connecting to so much data and tools).

So it worked perfectly that Kaelio was happy to partner with me on this article. After realizing where the AI world was going, the team at Kaelio built and open-sourced ktx, a context layer purpose-built for AI agents. It’s free, Apache 2.0, and you install it with one command, allowing you to instantly connect to your structured database (Postgres, Snowflake, BigQuery, MySQL, and others), dbt models, semantic layer tools (MetricFlow, LookML), and unstructured knowledge from Notion.

With most companies still wading into the Agentic AI world, many aren’t ready to sign up for an expensive semantic or context layer tool, making open source the perfect solution. And as demonstrated above, you need a tracked context repo that your AI agents can query through via MCP or CLI to ensure the accuracy and relevancy of the outputs, which is what ktx gives you out of the box, for free.

Why Context Is the New Moat (and What Good Looks Like)

People have been talking a lot about moats recently (the sustainable competitive advantage that protects an AI business from competitors).

This comes from three trends I’m seeing in AI:

1. Foundational model costs are going to rise, not fall: For OpenAI and Anthropic, we are starting to see price increases and usage caps. Not to mention, as more people within the organization use AI, total spend will rise with usage. And if those queries are running without context, the agent burns far more tokens on database lookups, then retries, second-guesses, or produces wrong answers that get rerun. The more context an agent has up front, the fewer tokens it wastes and the more often the first answer is correct.

2. People are becoming reliant on AI: I’ve seen a lot of senior leadership teams say they are being more productive, but are relying on handing off work to AI. This has resulted in a lot of sub-par outputs. This isn’t sustainable and businesses will begin to take notice. But they won’t want to switch back to manual work, they will want the company’s AI Agents to be smarter and produce higher quality outputs. Hence, the need for a context layer. This is where AI work is heading whether companies know it or not (and most don’t yet).

3. Agents are getting more capable, increasing their responsibility: This kind of builds off the previous one, but takes a different angle. Companies are starting to throw real money into enterprise plans for Agentic AI. And now that agents can reason, write proficiently, execute code, call tools, and chain together complex workflows, the expectations are increasing. When they don’t perform up to snuff, the first thing leadership will look to will be another tool (unfortunately it won’t think about training or recreating processes). That tool is going to be a context layer, because making context implicit in how these agents work is going to be the fastest way to value.

So my perspective is that if companies want to embed AI and become genuinely AI-native, their tech investment (beyond the processes and the people) should shift from tokenmaxxing to contextmaxxing. That’s where the durable advantage lives, and where the next five years of analytics investment will go.

If we are heading this way, what does good look like? From what I’m seeing, the properties of strong context infrastructure are:

• Unified integration across the stack – Pulls together everything from databases, transformation tools, semantic layers, and knowledge documents/ sources. This portability is crucial because most organizations have all of these data sources, but almost none of them speak to each other.

• Version-controlled and local – Git-backed, so context evolves the way code does. By having pull requests for metric definitions or audit trails on changes you have embedded context governance for AI. You think context is a hot topic, don’t get me started on governance… Luckily, version control can help fast track the checks and balances teams need.

• Agent-agnostic – People use multiple models, so exposing your context layer via MCP and CLI allows any agent to plug in. Don’t make AI another Microsoft Office vendor lock-in strategy. And you don’t want to rebuild your context every time the agent landscape shifts (the AI version of a data migration).

• Open source – I believe context infrastructure is something you need to test and play with to determine whether it works for you. I mean, if the tooling is a black box, how can you know it is working well? This is exactly why ktx is open-source. With AI advancing so quickly, locking yourself into a multi-year vendor contract in an emerging area like context layers isn’t necessarily the right option. This domain will only improve, and an actively maintained, open-source tool like ktx will probably lead the way.

• Structured and unstructured together – When setting this up, you have to think beyond the semantic layer (there is a reason they never took off on their own). The wiki layer—unstructured data—is where the business reasoning lives, so make sure this is embedded to get the accuracy you need.

• Governed and updated context – Integrated with clear, deterministic guardrails that keep context from going stale. A context layer is only useful if it’s true. When it starts drifting from how the business actually operates, the downstream AI Agents get worse (even though they are just as confident). Any context layer tool should help maintain that, else it will go the way of the Data Catalogue…

An example of how this should be built is Gladia, an audio AI infrastructure company. Being AI-native they wanted to do BI in a more direct way, but were running into accuracy problems. When they pointed agents directly at the warehouse (BigQuery) to answer business questions, the outputs were unreliable—the same semantic-fragmentation failure that so many companies experience in production. The primary issue was that agents had no idea which metrics were trustworthy, which joins were valid, or what the business actually meant by any of it. The ktx context layer helped provide them with a more governed, semantically aware path, with the agent querying through the context layer rather than the raw warehouse.

Now you may be skeptical that I’m trying to sell you something here, but in all reality, the only thing I want to sell to you is that Contextual AI is the future. I now use ktx on my own machine, and although I’m not using a ton of data, my life is a lot easier. Trust me, I do consulting, book writing, newsletter writing, LinkedIn posting, etc., so organizing my context and aligning it with my Claude Code are essential for me to be productive and avoid burnout.

In the end, you shouldn’t solve AI hallucinations or agent accuracy with more prompts or tokenmaxxing. Instead, build the right contextual foundation for the future, on top of all the valuable data you already have. And if you run into an “AI debt” problem in a couple of years, don’t say I didn’t warn you!

A note on this partnership: I worked with the team at Kaelio on this article. They built ktx, the open-source context layer this article references throughout. It’s worth a serious look if you’re thinking about how to operationalize context infrastructure inside your stack. They want you to know more about the topic and helped me sanity-check the technical claims. Seriously, check them out. It is a great product and team!

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share

Share The Data Ecosystem

Subscribe now

Read time: 6 minutes

Nobody doubts the productivity gains from AI. If you are using it properly, it truly is a game-changer.

The hot topic now, however, is that this productivity is coming at a cost. Specifically:

1. The quality of output that people are delivering at

2. The laziness of individuals to double-check their work with AI

The focus for these two negative implications has been on the average worker. But I think that is hiding a bigger corporate epidemic.

Share The Data Ecosystem

Share

If you find this article interesting or thought-provoking, please share with others! It costs you nothing and I’d really appreciate it :)

The Productivity Illusion

Before I go on, I want to be clear I’m not talking about those AI-native leaders who understand the technology, architecture and have designed their workflows specifically for how they work. These people are absolutely killing it, and it is hard to put a value on how AI has accelerated their ascent.

No, I’m talking about the newly indoctrinated leaders who just discovered Claude Cowork and are mistaking mass productivity for mass value.

Doing ten things in the time you used to do five sounds like an unambiguous win—it’s the leading reason companies are pushing AI. And technically, this increase in productivity should free up capacity, allowing leaders to focus on higher-value work.

But then you run into human nature.

So instead of just using AI to summarize notes or draft emails, people are relying on their AI tools and connectors for all the context in their meetings; they are basically outsourcing their brain to AI to handle what’s going on in their day. For example, a leader used to read a report to become knowledgeable about the topic, or at least skim it. Now they read a short five-bullet summary and rely on their AI to provide that perspective and that opinion.

For 80% of decisions, this is fine. It saves time and lets you do other things. For the remaining 20%, where you’re discussing a complex topic for an important area, that lack of context in your own brain limits the quality of your output. When your responses or decisions reflect AI slop, it breeds distrust among employees, customers, clients, and partners.

We talk about AI freeing up time for complex thinking or more insightful outputs, but in reality, human nature dictates that if we find a shortcut for one type of decision or workflow, we’re going to use it for other types as well.

Why Leaders Are Uniquely Exposed

I’m focusing in on the leadership position right now. There are two reasons why.

Firstly, senior leaders are uniquely positioned in organizations, where they must be close enough to the work to spot when something is wrong, yet far enough to be strategic and manage multiple priorities. This is where experience, time management, and hard work come together. The best leaders did well because they relied on their team to get shit done and let them know where they needed input, allowing them to swoop in at the right moments with the relevant context.

For the first time in their career, there is a tool that lets them bypass the team. It is keeping them up to date with recaps or summaries of meetings they weren’t in, or producing work via AI that feels like it’s their own. In reality, they are regressing to a micromanaging model, in which they take on too many topics, increasing levels of context switching and reducing their ability to think strategically about what actually matters.

The second part of focusing on leaders is related to the first: they are constantly overworked and busy, so any gains in productivity are seen as a necessary opportunity. And this push on productivity is being driven by their bosses or managers, so there really is no escape. With layoffs coming across organizations due to AI, the C-suite will expect these senior leaders to take on more.

Therefore, AI for productivity is going nowhere. What I expect is that we will see a compounding problem in which many leaders make bad decisions or manage poorly because they are so reliant on AI.

Subscribe now

The Quality Compounding Loop

There is no question in anybody’s mind that quality is starting to suffer because of AI. And while the focus is often on junior employees or students, I believe senior leadership is where we will see the biggest setback for the reasons stated above. These people are paid enormous sums of money to do a good job, know their material, and produce quality outputs.

But how do they do that if they prompt everything and rely on their AI to do their thinking for them?

Moreover, how do they lead a team if they don’t understand the inherent context of the business and what people are working on?

Eventually, they will get so complacent using AI to do things that their muscles for spotting weak reasoning or for prompting high-quality outputs will decline. And when you stop giving it new context, stop pushing back on it, and rely on its ability, an AI model will degrade and decline. It’s the nature of technology. It’s a similar dynamic the data quality crowd has been pointing at for years, applied to thinking instead of data.

The Leaders Who Thrive

And then there will be the leaders who thrive due to.

Right now, they all think they are in this category. In reality, time will tell. We will see the successes vs. the failures.

Most leaders are not data experts, and therefore they don’t have a foundation in this area/ this domain. But if they spend the time actually reading, understanding and learning about data, AI and technology, they can build a strong suite of agents and AI tooling.

And that feeds into the second point of not pushing AI beyond what it should be; they need to treat AI as a tool that draws critical thinking from them rather than replacing their own brain power. They need to use AI as a planner and an architect to help them learn and understand the context that makes them a leader. Finally, they need to consider their role in the organization (as an organizational leader managing people) and determine how AI can help them and their employees perform better. Because in the end, they aren’t just responsible for themselves. Their quality and behaviour impact and influence the entire organization.

The Catch-22

Here’s the kicker I will finish on:

AI is making senior leaders more productive and dumber at the same time. But while the productivity gains are easy to see, the quality degrades more slowly.

Therefore, most organizations won’t notice this happening. At some point, they will just look back and realize things aren’t quite right, and then they will have a choice to make. Who knows what choice they will make? I can’t predict the future, and corporations are never rational.

But what I can tell you with confidence is that if you are an organizational leader and you are using AI (which is likely a lot of you reading this), you need to be aware of this cognitive decline that comes at the cost of increased productivity.

Guard your time.
Build your AI foundation with the right context and knowledge.
And most of all, use AI responsibly.

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share The Data Ecosystem

Share

Subscribe now

Since finishing the data strategy series, I’ve been thinking about how to follow up when it comes to AI.

Because I’ve built AI strategies before. But today’s world is different, and honestly, how I would approach it today is significantly different from how I would have approached it a year ago.

For the past decade, building a strategy has followed roughly the same rhythm. You interview stakeholders, set a direction, prioritize initiatives, build a roadmap, and then deliver against it.

And I would still contend that enterprise data strategies should be developed with this in mind, as I wrote in the past two articles (Issues #57 and #58). For this kind of work, you still need a foundational direction grounded in the organization’s intertwined realities; then you need to execute with a realistic plan.

Subscribe now

But AI—in today’s world—breaks that sequence. Why? Because it is constantly changing and can be delivered at pace without a long transformational program.

That’s a different muscle than most leadership teams have built, and it’s where this article is going to spend its time.

Why AI Strategy Breaks the Old Playbook

The classic strategy model is sequential. You write the document, align the organization around it, and execute against it over a 12- to 24-month horizon.

This is how I’ve done it countless times before and how most consultancies approach it.

And honestly, for an enterprise-wide strategy, like data or a full business strategy, this is still very relevant because the most important thing you need is buy-in and perspective from across the organization. Not to mention organizing the relevant team to set the direction and execute the work. Therefore, taking the time helps with change management.

But AI isn’t going to wait a full year for change management, and it doesn’t sit within a singular team. It spans all teams, who are expected to figure it out ASAP.

Everybody is using AI to some degree, from the marketing analyst drafting customer briefs to the finance manager using embedded Copilot in their Excel to the legal team summarizing contracts. None of these tasks is on a roadmap. None of it is governed. None of it is showing up in a strategy deck. But all of it is happening at a scale and a speed that no central programme can catch up with.

Share

This is what I mean when I say strategy and execution have collapsed into the same moment. With AI moving so fast and the ability for individuals to implement immediately, you can’t separate the strategic exercise from the execution if you want to see success.

But I should be clear: that doesn’t mean buy tools and start to invest without thinking of the strategic implications of AI and what that takes for your organization.

Also, this only works if you have business strategy clarity, and at the very least, a baseline data strategy. Without those underneath, AI will fall in on itself; you need that organizational direction.

Four Directions to Point AI Strategy

In the data strategy, we discussed developing a vision and strategic pillars, followed by relevant use cases. For an AI strategy, I would also recommend developing a directional vision or North Star. It will likely fold into your data strategy vision for the overall organizational direction.

When it comes to use cases, I want to identify four directions you can and should take across your different AI initiatives, which encompass a dualistic strategic and executional approach.

And to be clear, what makes this important is the deliberate choice of where to invest and where to focus your resources and time. Because despite the hype, you can’t build everything in a weekend with AI...

1. Productivity – This is the obvious starting point for AI. Companies have been applauding AI’s productivity gains for the last couple of years, justifying continued layoffs. It started with individual subscriptions to GenAI chatbots, and now it’s all about embedded AI doing your job for you. It’s the easiest direction to point to because the use cases are obvious and people are already doing it. It’s also the direction with the lowest differentiation. Every competitor is doing the same thing, and the uplift you get is mostly individual, though if approached strategically with proper training and resources, the scale can be enterprise-wide.

2. Knowledge and context – This is the biggest opportunity (and gap) most companies are identifying right now. Most organizations have fragmented data, context and documentation scattered across SharePoint, Confluence, Slack, email archives, and in people’s heads. People are starting to get executional in this area, plugging in their Claude Cowork or ChatGPT with existing files, databases, and tools. The problem is that the output reflects the poorly modelled, low-quality data fed into it. And this is where the strategic lens needs to be taken into consideration. Figuring out where your institutional knowledge lives and how to make it AI-accessible without exposing sensitive information is a crucial step in any organization’s AI journey, but it requires a strategic approach. Lucky for you, I’m going to spend a whole article on this next week.

3. Growth opportunities – Now we are trending towards the more esoteric opportunities in AI, and the ones that definitely require strategic thinking. This category goes back to the question of what AI does to your business model: think new revenue sources or an evolved value proposition. These may arise because AI can do something your team couldn’t do before, or do something that wasn’t economical before. Growth is where the upside is largest, but it takes the most discipline to realize what will get you there (and to stick with it rather than just chasing short-term gains). And to be honest, most companies will not get here because they’re stuck in the productivity bucket.

4. New products and tools – This area often overlaps with others, so it may be a secondary consideration. At the same time, AI app-building tools allow for a quicker dev cycle. I’m not saying rebuild your website via AI, but there are companies refactoring their baseline codebase in Rust because it is faster, building new data products with Claude Code or Lovable, or just adding on niche tools to their existing SaaS stack. This area kind of raises the build vs. buy question; it makes you reflect on which new products or tools to acquire in this new world of AI (rather than debating an RFP for 3 months and then taking 3 months to put one out).

The angle I want you to take from this section is to reflect, as an organization, on how AI fits into your strategy and where you want to go. It really shouldn’t all be about productivity, despite the headlines. And you need to maintain a strategic lens on these categories, ensuring focus on what matters. Otherwise, AI—and the unlimited possibilities it offers—will be more of a headache than a timesaver.

The Underpinning Layer

I’ve already written about the underpinning foundations of AI. As you go off and build, you need to consider the enablers of scalable AI: technology, governance, culture, and process redesign. These are all covered in my article on the AI Sociotechnical Operating System.

For reference, no AI strategy or company-wide initiative will work without considering how these three layers operate beneath it. The companies that thought about governance, built AI-enabled workflows, or invested in technology aligned with their organization’s needs are the ones that will succeed. The ones who ignore these things are going to be trapped in a feeling of “why isn’t this working?”

The Two-Track Execution Model

Alright, so we’ve outlined the different opportunity areas for AI, and briefly covered the AI Sociotechnical Operating System (slash you’ve read my article on it or pretended to).

Now, time for the strategy; and this is where AI strategy genuinely differs from every other kind of strategy I’ve built.

As I’ve mentioned before, strategy is usually delivered on a single track, with extensive discovery, cross-team engagement and a future-forward roadmap that leads into a change management/ transformation program.

With everybody using AI, you can’t wait for the change management. Your roadmap will naturally move at the speed of your workforce, whether they love vibe-coding new apps or are just figuring out what Agentic AI means. Execution is happening whether you like it or not. What most companies are forgetting is that a strategy is still necessary to direct execution. Hence, the two-track model.

Track 1 — The Centralized AI Program

I want to start with the strategic first, because I don’t want to dismiss its importance.

There needs to be a centrally-led layer. This draws from your classic strategy playbook: organizational vision/direction, use cases, approved tooling/architecture, helpful tools (e.g., shared templates, prompt libraries), cultural enablers, a governance program, etc.

These artifacts ensure that any AI rollout is sustained, scalable and delivers on the organizational goals. I’ve seen a lot of companies just sign up for Claude Cowork and the AI debt they are incurring is staggering. A central track creates consistency (through governance or shared templates/prompts) in how AI is used, which helps people who may not be as technically advanced. Not to mention, you mitigate the common risk of having 23 different AI tools, one for each department, which adds cost and confusion.

Moreover, there are (or should be) initiatives that need to be planned and thought through, like organizing enterprise knowledge/ context, or building AI-enabled BI tools on top of a strong data foundation. As I mentioned above, these are the biggest value-add areas AI can provide to organizations, but they need to be thought out and centrally supported. In that sense, a documented, centrally-led AI Strategy is crucial.

Track 2 — Distributed AI Execution

But as the centralized strategic track develops the plan, the workforce-led execution track should test and implement AI.

Let’s be real, it is going to happen anyway. Most white-collar employees are using AI in their day-to-day work, even if it is just a chatbot. They are learning what works for them in their own workflows and processes, and nobody will wait for the AI Strategy to catch up. And learning by doing is the only way you are really going to get comfortable with AI (I can attest to this from my own evolution with it).

The strategic work in Track 1 needs to enable these activities and create the conditions for them to compound. Providing permission to experiment; helping distil the most value-add workflows to use AI in; giving a clear list of what’s off-limits; investing in tooling that matches how people actually want to work; or creating a way for employees to share what’s working.

With that foundation, people can start building and embedding AI into their workflows. Productivity tools like meeting summaries, email drafting, or automated to do lists. Customized processes to do analysis, create legal documents/ contracts, or build brand-aligned marketing content. Enabling these kind of workflows with AI isn’t hard anymore, and most people can do them with a little bit of guidance and a few tokens. This helps build AI culture, delivering measurable outcomes from the AI strategy within weeks rather than months or years.

Or in more classic corporate speak: bottom-up initiatives surface the valuable pieces, top-down support helps it scale. Figuring out the right feedback loop is the new version of strategy.

Hence, neither track works on its own in today’s AI-enabled age.

If you rely on distributed AI, you get chaos and risk. A lot of companies are running like this right now, with unfettered AI usage, no compounding benefits (largely individual-based), no line of sight to productivity wins, and lax security.

If you only run the centralized track, you risk falling behind and never catching up. Throwing bureaucracy and red tape in front of your AI goals basically guarantees that employees will work around the organizational guardrails and learn on their own. Not to mention, it will take ages to get something done, which ends up being way behind where the market is. This is not how you build an AI culture.

When you have both feeding into one another in the right way, the two tracks compound. The centralized, strategic approach gives the organization direction, governance, and the platforms that allow AI to scale safely and effectively. The distributed layer bolsters ongoing strategic initiatives with real-time data on what’s working, what’s not, and where to invest next. Not to mention, employees getting practical experience with AI as you scale.

Share The Data Ecosystem

This is a new world of strategy, and one that doesn't fit the bureaucracy of large consulting firms. You need individual experts who can guide you through it, or a dedicated internal resource who can enable it on an ongoing basis.

Your AI Strategy & Approach

What does all this mean for you and your organization?

Based on my consulting experience, I’d estimate that 70% of companies are going through this thought process right now. Maybe 20% don’t need to really evolve for AI, 5% are completely oblivious, and 5% already have a half-decent path to success with AI (yes it is that small).

So the first thing is to know that you are not behind. Even an expensive, Accenture-stamped AI strategy from a year ago is likely outdated right now, so everybody is going through it.

Take three actions instead.

1. Recalibrate where AI fits in your strategy — Take the four directional areas (Productivity, Knowledge & Context, Growth Opportunities, New Products & Tools) and map where you are today versus where you should be. For most companies, the answer is probably limited to productivity. Think beyond that, and figure out which of the other three directions actually matters for your business’s success.

2. Structure the two-track approach inside your operations — Decide explicitly who owns the centralized programme and who is enabling the distributed execution. Both tracks need named owners, clear goals, and a defined feedback loop between them. How you structure this is crucial, as the two need to work symbiotically to be successful.

3. Document the wins and ship the proof points — The whole point of running both tracks is that you get measurable outcomes in weeks, not months or years. This allows you to capture the wins as they happen and share them widely inside the organization. These proof points add credibility and help build momentum, establishing an AI culture or justifying additional investment. And please don’t delay; AI is only going to get more relevant, and if you haven’t started thinking about this, your business can’t afford for you to wait another year or two.

Not a plug, but I’m doing this with one CPG client right now, developing a team-wide approach to implementing Claude Cowork and developing customized processes. This is happening alongside more formal conversations around governance, knowledge, and future AI products, all of which is having a huge impact. Before, even heavy AI users were scrambling and making errors all over the place. Now they at least have a strong foundation to execute on, while knowing how to start thinking about the long-term strategic pieces that they know need to come.

Next week, I’m going to break down the second of those four directional areas, the one I think most companies see the benefit of, but have no idea where to start. Yes, I’m talking about knowledge; more specifically, the Context Layer. This is all about the current issues with fragmented data/ knowledge, how to bring it together and make it AI-accessible for your agents, and best practices for doing so.

Until then, have a great Sunday! And if you’re in the middle of thinking about AI strategy and can’t figure out your next step, feel free to shoot me a message.

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Subscribe now

Share

Share The Data Ecosystem

Everybody loves the direction setting part of the Data Strategy process. I mean who doesn’t like to go shopping for cool data science, analytics and AI tools saying “I want that one and that one.”

But then you get to the checkout…

And suddenly everyone thinks back to their day jobs, and realizes they didn’t have time to build those things.

Sound familiar?

This is where most data strategies go to die. Not because the direction was wrong; not because the use cases were bad; not even because people weren’t bought in.

But because the executional machinery wasn’t established or just collapsed under the weight of competing organizational priorities.

Execution is where the rubber hits the road. Often, people mistake that for “Let’s just do shit now.” That is where teams become ticket takers, keep putting out fires, and don’t really get much done, even though they are always busy.

The beauty of a data strategy is that it allows you to frame up the execution in a strategic way where the work you’re doing actually means something and isn’t just for the sake of it.

And today, we’ll walk through how to build on the direction setting that we’ve already covered to understand what actions need to be done and how we do that in a way that adds value rather than just creates work.

Going from Data Direction to Delivery

We covered the direction setting in the last article, but it is still important to provide a brief framing of how to move from direction to delivery.

At the outset, the goal of any data strategy is to understand the perspectives of those business and data stakeholders in the organization. This includes what they need to do their job, their biggest problems/challenges, the organizational strategy/ways of working, what data and products exist, the technical foundations you are building on, where the organization wants to go, etc.

These are things everybody knows, but aren’t often articulated well, leading to different perspectives in everyone’s heads. This lack of consistency is what kills progress.

Therefore, the direction setting portion of any Data Strategy is to bring everybody onto the same page:

• The first artifact you build—the Data Vision—is an inspiring statement about how data will help the organization that people truly believe in

• The Strategic Pillars under that act as the bridge, breaking down that vision into something more tangible and connected to the overall organizational goals and day-to-day activities

• Then the direction needs to be made tangible with use cases, outlining the specific initiatives to translate the strategy into outputs and outcomes.

The back half of the process is about cementing these direction-setting artifacts that everybody has bought into and aligned around into how the organization moves forward. The hardest thing to do in a corporate environment is change management—getting everybody bought into the change that needs to happen. And this is exceptionally hard with data & AI because people don’t fully understand it (especially now…).

So that is where the Capability Assessment and Executional Roadmap come into play. By looking at your organizational maturity and what exists today, you know your starting point and what gaps you have to fill to deliver against the vision/ use cases that have been set out. That allows you to build a proper plan—the Executional Roadmap—which establishes the path to success with clear ownership, timelines, and next step actions.

Share

A real strategy has all four components (Vision/ Strategic Pillars, Use Cases, Capability Assessment and Roadmap) flowing into one another. If you don’t take a holistic, action-oriented perspective to each step, your data strategy won’t succeed. And from my experience, the gap between a data strategy that delivers and one that dies is almost entirely down to how seriously the team treats these last two components which bring your direction to reality.

So let’s get into them.

The Capability Assessment

You can’t build a roadmap if you don’t know where you’re starting from.

This sounds obvious. But it’s not what most data strategies do.

Instead, most pure strategy consultants skip this step. A lack of technical and data knowledge makes it impossible to properly assess different data domains and map them against what needs to be done. And that is why those data strategies fail.

On the other hand, technical consultants spend too much time at this step. They get into the weeds and focus on individual solutions by domain. In the end, there is no link between the data maturity and the strategic direction.

Share The Data Ecosystem

When going into an organization, I usually break the capability assessment into five large categories, each with individual data domains. Each domain gets scored against where people believe the organization is at (keeping it simple with a 1-5 or Red, Amber, Green rating system) and why. After doing that, you follow up by assessing the initial scores against what the strategy requires to succeed, given the vision, strategic pillars, and prioritized use cases. This goes beyond the typical Gartner “best-in-class” framework and actually adds colour to the assessment about what needs to be done.

Here’s how the structure breaks down at a glance:

• Business & Data Foundations — The structural components that set the direction and operational cadence for data to succeed. This includes the data & AI strategy, the operating model, and the org structure. On new maturity assessments, I will be adding a context layer to this bucket

• Data Engineering & Architecture — The technical bucket around how the data and technical platform are architected, modelled, ingested (engineered), and surfaced to analytical resources. Platform and software engineering also fit into this bucket. The new addition is whether you are doing these things in an AI-enabling way

• Data Management & Governance — This focuses on how the data is governed, managed, secured (data privacy & security), and mastered. With AI, this bucket becomes so much more important, as the script has flipped on how to actually deliver against these domains

• Value Realization & Adoption — This bucket includes BI & analytics, data science and AI. But it also includes data & AI literacy, culture, and business decisioning. It comes down to whether the data is being surfaced in an insightful way and does the business actually understand and use it in the intended way

By going into detail in each area, you develop an understanding of where the holes are and, more importantly, how different domains are dependent on one another. For example, you see the throughlines of a poorly architected data platform having direct implications for the bandwidth of your engineering team, which in turn affects the reliability of your dashboards.

Subscribe now

In addition to evaluating your data capability domains, it is also worth examining your data architecture. Now this can mean many things, but from a strategic and evaluation perspective, I tend to focus on these three areas:

1. Existing technologies – Start with what tools exist in the stack and where they are. You’d think this would be easy because every data person loves talking about their stack, but when you take an enterprise view of this, you often get random tech involved, or source data coming from tools that people didn’t even know existed

2. Current and target state dataflow diagrams – A high-level view of where data is produced, where it lands, how it moves, and where it’s served. This includes the technology stack from above, but gets a bit more explicit in how the data travels and where and how it gets processed. Honestly, given that this often happens in 20 different ways for each organization, this helps simplify how things work

3. Data modelling approach – If there is one, great. If there isn’t (most of the time), then this is where to begin recommending an approach to modelling the data against the prioritized use cases within the existing (or target) tech architecture and data flows. Most people just default to Medallion, which is fine but there should be some strategic and technical rigour behind it rather than just saying bronze, silver, and gold over and over again…

When this high-level architecture view is done properly, three key things emerge.

• First, the organization gets a clearer picture of something people think is too technical to simplify.

• Secondly, you start to add technical rigour that can be applied to the use cases. By assessing the platform more technically, you can better see how to build on it.

• Finally, you surface and map out some of the dependencies within the dataflows and platform that will be essential when building the roadmap.

Speaking of, let’s move to that final step of a Data Strategy.

The Executional Roadmap

Finally, the roadmap. Now this seems like an obvious last step, and to be fair, most people will build this artifact. But the problem is, most roadmaps don’t have the context, accountability and buy-in necessary to be delivered on.

Because a roadmap isn’t a list of high-level, ambitious initiatives with dates next to them.

A real roadmap is a sequenced, owned, funded plan with clear accountability for each workstream.

At this point, you have already prioritized the use cases. Ideally, you have a 2×2 prioritization map with delivery effort (technical effort, data availability, and team capacity) on one axis and business value (cost savings, revenue growth, risk mitigation, enablement of other use cases, etc.) on the other. This should give you four clusters of prioritization that helps you build your roadmap:

• Quick Wins — High value, low effort. These are essential to build credibility and create the political capital for the data team/ roadmap

• Strategic Investments — High value, high effort. These are strategically important use cases that are usually phased across multiple steps with clear dependency chains.

• Two Low Value Clusters — Honestly, you rarely get to these, so I’m grouping them together. Plus once you talk to stakeholders things always end up being higher value and people don’t like to see their use cases mapped in these two quadrants…

Once you’ve mapped those, then it is about figuring out the workstreams. The use case categories from your prioritization exercise will help. Within each you might have foundational initiatives (e.g., KPI standardization, data quality improvement, data ownership, etc.) and value-generating use cases (e.g., dashboards, machine learning models, AI tools, etc.). You can list these two tracks separately, but I prefer approaching it from a logical manner; thinking like an engineer, what needs to be done before the other, and how do they flow into each other. This is where the dependency thinking comes to play.

Share

Now that you’ve developed the workstreams, you can start to sequence the action plan. Who is leading each workstream, what are the initiatives/ use cases under each, and what are the next step actions based on the logical plan. For each step or action, you should have an owner (ideally a business and data), dependencies, timing, required process changes, data sources needed, desired outcome, and next steps. Getting these on a page and people aligned to them (especially the owner) is crucial if you want to make this roadmap work.

Other bits you should think about, which I won’t go into are:

• Delivery model

• Executive sponsorship

• Forums and checkpoints

• Escalation points

• Investment/ business case

• Metrics & ROI calculations

Realistically, this all falls into change management and delivery principles, which is a whole other article on its own.

The key things to look for when building a roadmap are:

1. Building it collaboratively – Both the data team and the business teams need to be in the workshops where this is shaped and they need to see themselves in it (both benefits and execution)

2. Executive ownership – There needs to be visible support from a both data and non-data leaders. They need to have skin in the game, which it is because they are funding it or they are very invested in the use case outcome

3. Anchor the roadmap in transformational delivery – Everybody hates change management or transformation, but the roadmap needs that type of project management/ governance structure to ensure accountability

4. Realistic timelines – Choose what needs to get done based on capacity and priority. Don’t be overly optimistic, things will fall through the cracks and the whole execution will follow

5. Dependencies are defined – A lack of communication between teams usually halts any strategic priorities in data. With stakeholders aligned to different tasks by dependency, it makes it easier to get the right people in the room to make things happen

6. Clear storyline – An underrated element. After you set the roadmap, you need to sell it in to the exec team (for funding) and to the business (for the execution). Have that concise and impactful story to do that

Keep these six things in mind: when you do them right, that is when a roadmap turns into reality.

Moving From the Data to AI Strategy

So there you have it, my secret sauce. I’ve billed hundreds of thousands of dollars in Data Strategy work, and now you have my standard approach for free.

If you ever need help with that, just give me a ring.

Well, now that we’ve gone through the Data Strategy, it only fits that we cover off the AI Strategy! And in the past 6 months, this idea has shifted significantly. A year ago, I would have viewed the AI Strategy as an extension of the Data one, done in a similar way. Now, I have different views…

… It has to be a lot more action-oriented and involves re-engineering how the organization works.
… Moreover, AI use cases need to be implemented today, not tomorrow.
… Plus, there is a level of flexibility and agility that needs to be baked into it.

Overall, next week’s article will be focused on an AI Strategy for this brave new world, not a 60-page slide deck of AI use cases and platitudes. Until then, have a great Sunday!

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Subscribe now

Share

Share The Data Ecosystem

Read Time: 8 minutes

I’ve said this in a previous article, but Anthropic changed the game with Claude Code and Cowork.

It wasn’t just that it was a better model. It was this that changed how people worked with AI. Then they capitalized immediately by adopting that new approach at work and embedding it within enterprise organizations.

Meanwhile, other companies are still playing “who has the best model.”

And that is what matters right now in this world of AI.

The Embed Playbook

Most companies nowadays, even in the AI space, have taken the freemium model to attract customers. They offer the product for free, set a tier and a cap on it, and build enough loyalty that people end up paying for the next tier or additional capacity.

Anthropic took the same approach, but then took a page from the Apple and Microsoft playbook.

Let’s start with Microsoft Office.

It is a pretty shit product. Nobody really likes it, especially Teams, but tools like Excel, PowerPoint, and Word are now mainstays in most large organizations, even the ones that use Macs. What Microsoft did well 30-odd years ago was embed those products into how people work in an office. By the mid-90s, Office was 90% of business productivity software, especially as Microsoft bundled Office with PC sales, locking OEMs in by shipping its product and further embedding itself.

Apple ran a similar play, but from a consumer perspective. They launched an ingenious product in the iPhone and started locking customers into the ecosystem. Think iMessage, Apple Music, the App Store, and even the unique charging cable.

All this ensured that Apple was an embedded part of those people’s lives, from communication to listening to music to everything. That is how they’ve now become one of the most valuable companies in the world, because you just have to have an iPhone now (in North America at least), even if the Android phone may be better.

And look, this isn’t easy to do. Microsoft and Apple both spent millions on building customer relationships, R&D, marketing, sales, etc. But if executed well, this strategy leads to long-term success because people are bought in and can’t imagine functioning without the product or service.

The AI Acquisition Approach

Now let’s look at the AI industry, specifically foundational models. As I mentioned, every company took a try-and-learn, freemium approach, allowing people to work with their tool, chat with it, and get a feel for the power it delivers.

But sticking power wasn’t there. They used an online interface where they could switch between models, and the context within each model wasn’t necessarily super powerful yet.

The first to crack this nut was Cursor, which built its embedded coding tool into the workflows of developers and data professionals. When Cursor came out, it exploded for that very reason. Yes, it was a great model with high-quality outputs, but the fact that coders couldn’t work without it after having used it for the first time was a problem. Therefore, a premium membership was a no-brainer.

But coders aren’t the end game here. They are the early adopters to these technologies and the ones that usually test them out, but they also represent a very small part of the market.

Share

Anthropic’s AI Embedded Strategy

I see Anthropic’s dominance in AI happening in four stages:

1. Introduction of a very good model

2. Build Claude Code like Cursor, but better.

3. Create Claude Cowork for less technical individuals.

4. Target Enterprises

First, I know the Claude model isn’t the top of every leaderboard anymore. ChatGPT 5.5 and Codex have surpassed it (well, according to ‘experts’ and as of May 2026), and there are many open-source models that deliver a similar spec. BUT, at the time, when Claude Opus 4.5 was released a few months ago, it was the best model out there, and people flocked to it.

Subscribe now

Next Anthropic released Claude Code, similar to Cursor in that embedded AI into how the individual was working. Claude took it one step further and went into the terminal, reading your codebase, running your tools, making your edits, basically giving you an AI assistant inside what you do.

This changed the game. It was no longer chatting with AI. It was telling you what to do from a chat interface based on your daily activities.

While people are now complaining that Claude Code does not live up to the other models, Anthropic is still benefiting from its other product, Cowork. Cowork is the same idea, but for everyone who isn’t a developer (which are most people).

Cowork introduces the idea of embedded AI in a non-technical way. It democratized the technology in the way it was always supposed to be democratized: embedding AIinto how people actually work, not as a place they visit to ask questions. These people don’t know what a Markdown file is. These people don’t even know what an agent is, even though they might think they’re building them.

And now people are just vibe coding stuff, and companies are rethinking whether they should have software developers or data people (they should, as these vibe-coded apps are breaking all over the place and shouldn’t be trusted).

By now, Anthropic has introduced an embedded play into the white-collar workforce, but the next step was the nail in the coffin: courting enterprises with deals to lock in their tooling. According to VentureBeat:

They proved that employees wanted to use Claude Co-Work, and then they signed deals with companies that are now building workflows dependent on Co-Work. This kind of customer lock-in does not go away, just like Microsoft locked in thousands of companies to their office suite of products. And as other businesses feel they have to move on AI and change how they work, these kinds of companies might look to the Anthropic model as their solution as well, further accelerating their growth potential.

Share

These four stages (especially stages 3 and 4) will be the moves the industry looks back on as the inflection point. It is where an AI company finally moved past the technology and reconfigured the way people work. Now, the person who knows nothing about AI, who would never figure out a system prompt, who doesn’t want to learn a new tool, can use AI daily, with confidence, inside the tools they’re already in.

That is a new way of working. And that uplifts productivity for the larger workforce, not just the data or tech team.

Before I close off this section, I want to be fair to OpenAI here. They built the product that introduced AI to the public. They continued to innovate with Sora, Codex and better ChatGPT models. However, they never truly embedded beyond building a household name and having a chat function that everybody uses but nobody pays for.

Because in the end, the freemium AI chat sits next to your work. It does not sit inside it. That’s the gap Anthropic was the first to solve.

The Sticking Effect of Cowork

It is still early days. New products/ models might change the landscape. Even now, Anthropic is struggling to maintain the quality of its models.

But there’s still a stickiness effect that will make it hard for people to switch.

Take me as an example. As soon as I moved to Claude Code, I built a personal OS, knowledge graph, multiple agents/ workflow processes, templates, etc. all using Claude Code and connected to my other tools (Obsidian, Granola, Google, etc.). It knows me, how I write, how I work and is configured to my needs. Could it improve? Sure. Am I willing to put in the work to reconfigure it? Maybe one day, but not when I’m busy.

And while content creators make their money on change and new features, real-life employees are busy, 100% of the time. They don’t have time to reconfigure.

As the playbook goes, once your team is embedded in a stack with set processes, the best model conversation becomes mostly irrelevant. Especially as all these enterprises have lined up to sign up for Anthropic’s Enterprise plans, running through tokens like nobody’s business.

So here is my prediction for the next two years:

• Anthropic keeps the enterprise lead – Now that they are embedded, a marketing person doesn’t know the difference between a good model and the best model. As long as Anthropic keeps up with basic compute requirements, ships steady upgrades, and doesn’t break the embedded business model, they will maintain the enterprise clients.

• OpenAI keeps running on the brand – Codex (built on GPT 5.5) is a great model. Not to mention, people still refer to AI chatbots as ChatGPT, even if they are using Claude, so OpenAI will continue growing on its brand awareness.

• Google benefits even if nobody uses Gemini – They are one of the biggest institutional investors in Anthropic and are closely connected to the Claude product. So as Anthropic compounds, Google compounds on the back of it. Expect more cross-coordination and a potential niche of their Gemini model (maybe full-on for search amalgamation) rather than investment in it as a foundational one.

• Open source will continue to grow, but narrowly – I’m considering building a local open source model. However, this isn’t realistic for most businesses or people who don’t even know how to access their terminal.

I heard a great saying once: “Microsoft doesn’t win customers with its products. It wins them despite its products.”

Can Anthropic pull off the same? Who knows, but I know the embedded strategy is working for my non-data & tech friends.

One thing to note before I close off. All of this does not account for the fact that every AI foundational model/ company is losing money hand over fist right now, and who knows what the impact of standard economics will play into this race. Nick Zervoudis wrote an amazing piece on this, Vin Vashishta writes a great deal about this and both are worth checking out.

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share The Data Ecosystem

Share

Subscribe now

It only took 57 articles, but we are finally here.

It is time for me to write about my favourite topic and my ultimate area of data expertise.

This article (and the follow-up) will be held to a high standard:

• It won’t be buzzwordy or vague, like so many Data Strategies are

• It won’t be unrealistic and impossible to deliver on

• And it will consider both the technical and strategic sides

*And that is without even including AI (which I will mention throughout, but I’ll have a separate article on AI Strategy).

This is why I believe that approaching data strategically is the only way to approach the industry. That doesn’t just mean data as a whole, but the specific elements within data. For any of these topics (from building a tech strategy to data modelling and architecture to operationalizing data products and ML and AI considerations), you need to consider the business implications and how they tie across different data domains.

And all of this usually starts from the Data Strategy. Because the Data Strategy helps translate the business strategy into data requirements and considerations that the technical resources can take away and deliver on.

I mean, we approach finance, marketing, and sales all with a strategy. We wouldn’t dream of running these functions without clear direction, priorities, and execution plans. So why do we treat data differently?

Well, it’s time to bridge the gap between data and strategy. Let’s dig in!

What Is Data Strategy?

Put simply, a data strategy is a comprehensive (and executable) plan that defines how an organization will use data to achieve its business objectives.

Unfortunately, this requires balancing two different perspectives that are often put at odds within organizations:

• Business Perspective: What is the business strategy? What do different departments need to achieve? How can data enable these needs and deliver against strategic business outcomes? What is the role of AI in this?

• Technical Perspective: What data maturity do we need across different capabilities? How do we deliver against data & AI use cases and initiatives? How do we think holistically and prevent data from being siloed from the business?

Both perspectives are essential, but most organizations get this balance wrong.

Companies will either build overly technical strategies that are disconnected from business outcomes. This will miss business context, be mostly focused on tooling, and not have the right people in the room to make it operational.

Then you will have the aspirational strategy, usually built by strategy consultants who understand the business but don’t get the technical realities. These strategies are great for the executive who wants to achieve a certain ROI or drive toward a specific value, but they don’t actually deliver on what they promise. It’s where people stop trusting data strategies and the data team to deliver on what is asked.

The worst version is an isolated strategy, developed in isolation without the right stakeholder input. This can take the same format as both of the above, but it’s not the technical or the strategic elements that are the downfall. Instead, it's that the leader didn’t talk to anyone in the organization, and there’s no buy-in for what actually needs to be done. AKA it’s not executable.

Share

I approach data strategy differently. I take a holistic, business-led approach that considers the organizational complexity across different business functions. But at the same time, I pair that up with the data and technology requirements from those stakeholders to ensure that what we are building is realistic and scalable.

To do this, I approach data strategy in four components, taking that dualistic approach for each:

1. Data Vision and Strategic Pillars — Setting an inspiring yet practical direction that everybody is bought into

2. Prioritized Data Use Cases — Aligning data and AI initiatives to business needs

3. Maturity and Requirements — Assessing the organizational capabilities across data domains and recommending how to fill any gaps

4. Executional Roadmap — Creating realistic implementation plans with ownership, timelines, and clear next steps

In this article, we’ll dig deep into the first two, which tackle the direction of your data program. Next week, we’ll explore the implementation components of the second two.

Just remember this before we start: Direction without execution is just wishful thinking. Execution without direction is just an expensive activity. You need both, and any data and AI strategy should have both!

Understanding the Business and Data Context

Honestly, the biggest part of a data (and AI) strategy is making it relatable to the entire organization. You need people to understand why you’re building it and to be bought into what you are building.

The only way to really do that is to get the business and data context right.

There are four things you need to understand from existing documents, interviews and workshops with key stakeholders, or even a survey (if you want to go through that effort):

1. Business Model – As we’ve discussed before, understanding your business model and ensuring it aligns with and supports your data and AI goals is fundamental. How your business makes money, how it operates, and what its competitive advantage is all need to factor into data & AI priorities. Also, what industry-specific challenges and opportunities need to be understood?

2. Strategic Direction – The business strategy is obviously the next step. Figuring out what the executive’s top priorities or main strategic pillars are will ensure that data and AI are well-positioned to help achieve the organizational goals.

3. Business Performance Metrics – This aligns with the previous two, but it focuses on identifying the KPIs and targets that are the most important measures of success for the organization. In the end, if your strategy or initiatives don’t tie back to these things, they won’t get the investment they need.

4. Stakeholder Perspectives – And don’t forget about all the other challenges, pain points, and barriers to progress that exist in the organization. A data strategy is not just a top-down initiative; you need to make sure that all employees feel heard, and that you will do something about their problems as well, even if they aren’t the top priority (but funnily enough, those often become the top priority because so many people have those pain points).

These conversations are crucial for the success of your data strategy. Getting the business and data context from key stakeholders will make what you build tangible and realistic, rather than a laundry list of the coolest things you could do (which is what an AI-built data strategy would provide…).

After you have this context, the first thing to build is the data vision and strategic pillars to better articulate the direction you should head in as an organization.

Developing a Data Vision and Strategic Pillars

Every successful company has a strategic vision that is both inspiring and aligned with its direction.

With data and AI being so future-forward, getting the right vision to set the direction for initiatives is crucial. Moreover, that vision requires the right foundation to turn aspirational goals into reality.

So while I sometimes think the data vision strategic pillars component of a data strategy is a bit fluffy, it is also what brings everybody together and outlines the North Star that the organization is trying to get to.

What does an effective Data Vision look like? Simply put, it needs to be inspiring, achievable, and aligned with the organization’s strategy. It also should be built in coordination with key stakeholders in the business and on the executive team; you should see their language and ideas in the strategic direction.

Then the strategic pillars should cover both foundational data activities (infrastructure, technology, governance, data quality), value-added products (analytics, data science, AI), and enabling factors (culture, literacy, org structure/operating model). AI might make its way into all three of these things as well, given how everything is changing and evolving, but it is crucial to be specific about the role it needs to play in driving the data vision.

I also want to leave you with an example vision and strategic pillars. Let’s say this is a logistics company:

• Vision: “Drive new revenue streams, provide exceptional customer service and streamline operations by building world-leading data & AI capability grounded in robust technical foundations, trusted & accessible data and an insights-led data & AI culture.”

• Strategic Pillars:

  • Pillar 1: World-leading Data & AI Capability — Drive change in the organization to rethink how it operates, using AI as a strategic advantage and sharing the benefits of automation and better decision-making to customers, suppliers and partners.

  • Pillar 2: Strong Technical Foundations — Build a robust, trustworthy data infrastructure that serves as the bedrock for all data activities, with all tooling decisions supporting the overall organizational strategy and cementing a future-forward approach to AI enablement.

  • Pillar 3: Trusted & Accessible Data — Ensure data quality, governance, and accessibility are implicit in how we work as an organization, giving business stakeholders trust in our data, the decisions it drives, and the AI tooling becoming embedded in our workflows.

  • Pillar 4: Insights-Led Data & AI Team — Develop comprehensive data & AI tools that provide actionable insights to business stakeholders—enabling better customer service and operations—while helping foster an organization-wide culture of insight-driven thinking.

In the end, the goal is to have something that both business and data stakeholders are bought into, with 3-5 key focus areas to help get there.

Identifying and Prioritizing Data & AI Use Cases

Three years ago, use cases were all the rage; everyone said you had to take a use-case approach to building your data and AI foundations. And they were right. This is where your strategy starts to get real. Use cases are the specific initiatives that will deliver your data vision and support your strategic pillars.

However, use cases often turn into a wish list of cool data and AI products that the business and data teams wish they had. They don’t always consider the steps or foundational components that need to go into it. Moreover, when most people go to search for use cases, they often ask, “How do you use data? Or what kind of data products do you want?”

And this is where data strategies start to go nowhere real fast because you’re not really developing the foundations for something that you can tangibly build. You’re talking about ideas that someone has on their wish list, not about bridging the gap between technically feasible and business-critical.

We will do a whole article on use cases (and we have done one in the past on identifying stakeholder business needs), but the key point is: when you are interviewing stakeholders, try not to focus only on what data or AI can do for them. Instead, probe into what they’re trying to achieve in their jobs, what decisions they struggle with, and what would make them more effective.

That is their area of expertise and where they can offer the most insight. Then you as the data expert can put two and two together to figure out what to build and how it fits into the strategy.

After you’ve built this list of use cases with your business and data stakeholders, there are three more things to think about:

• Outlining the Details – Work from a template to identify the business problem being solved, expected business outcomes, key stakeholders and users, success metrics, and a high-level approach to delivering it

• Categorizing the Use Cases – There are two components to categorization. The first component is determining whether the use case is more foundational (e.g., data quality, standardizing KPIs, data governance) or value-generating (e.g., a data analytics or science tool). The first are necessary investments into your data estate and the second are directly linked with business outcomes that can measure ROI. The second component is categorizing by business function or data domain. So, for example, having multiple marketing use cases in the same category. This helps because data and AI use cases often compound and have prerequisites, rather than jumping to the coolest thing first.

• Prioritizing Use Cases – Finally, it’s important to determine what is long-term versus what is a quick win. You can prioritize use cases based on:

  • Business impact or value delivered

  • Technical feasibility

  • Resourcing requirements

  • Dependencies

My belief is that when prioritizing use cases, you should ensure you have two to three quick wins you can start on right away, while delivering on one to two big, longer-term strategy priorities. This is all while keeping the foundational versus value-focused categorization in mind.

Setting the Foundation for Execution

A lot of companies don’t build a data strategy because it’s not execution first. And I’d partially agree with that mindset; you need to make sure you get something tangible out of any data strategy.

But these organizations also forget that, without this kind of direction, their teams often get lost in execution. The vision, pillars, and prioritized use cases you develop in this phase become the foundation for everything that follows.

And what follows is the next step of a data strategy: the Capability Assessment and Operational Roadmap. This is what we will cover in next week’s Part 2 article.

And with both together, you should have a clear brief to build your own Data Strategy (or at least a bit more clarity on how to do it).

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch consulting work in the Data & AI space! See you amazing folks next week!

Share The Data Ecosystem

Share

Subscribe now

Read Time: 6 minutes

Companies have been chasing the goal of data democratization for over a decade.

Self-serve BI tools, data literacy programs, data catalogues. All attempts to get data (and insights) out of the analyst’s workflow and into the hands of the people actually making decisions.

None of it really worked. Not at scale.

This is because there were two huge roadblocks in the way:

1. BI tools required you to code or learn to read a dashboard, which was too much work for a business stakeholder who had a full-time job already

2. The data behind these BI tools wasn’t trusted by the business user because it didn’t always align

Then AI seemingly closed the gap almost overnight.

As a layperson, I can now type into an AI Chatbot and query a database, generate a chart, build a report, summarize a dataset, and write the analysis to go with it. All with a few prompts written in plain English.

This is genuinely exciting. I don’t want to undersell it. The thing the industry has been trying to do for fifteen years has, in the space of about eighteen months, mostly happened.

But, like anything, explosive value creation without checks underneath it is a pattern we’ve seen before.

The AI Wild West

I saw a quote the other day that said, “People don’t ask what you’re working on this week. They ask what you shipped this week.”

We’re in a build-now mindset, without any guardrails or limits on our ability. Well, that’s how it feels anyway.

It’s like the heyday of capitalism, or something out of a Wild West town. There’s no bureaucracy. There’s no sheriff. There’s nobody telling you no. Most of all, there’s a tool that lets you do whatever you want, removing friction and letting you build the way you want.

But, like unchecked capitalism, this pace can produce systemic fragility that risks falling in on itself. We’re in a pre-regulation boom where the tools are open, and the value is tantalizing. AI models and usage are moving faster than any governance can keep up with, but already we see the cracks forming.

There are two cracks worth pointing at.

The first is the Undeniable Confidence of AI (accuracy sold separately).

AI sounds right, like all the time. It produces a clean output, has confidence, and provides an instant answer. Research shows that people often take it at face value (through uncritical reliance or cognitive surrender).

With AI doing more and more of our job, we’ve become more and more trusting of it, especially now that people are saying it’s gotten past the hallucination stage.

And honestly, people are losing the plot about what AI actually is (hint: it is a machine/software).

You get this in capitalism too. If it wasn’t for regulations, companies would be lying to you left, right and centre about what is in their products! Hell, they already do that:

• Obfuscating carcinogens (tobacco)

• Or unhealthy ingredients in your food (every CPG out there)

• Or their packaging (history of recycling)

And you have the same disastrous outcomes where the danger isn’t that people get the wrong answers. It’s that they don’t even know they’re getting the wrong answers. Then the decision gets made, the strategy gets set, and nobody checks up on it.

In the old world, if an analyst gave you something that was off, there was usually a person who knew that was wrong and would push back. In the new world, with everybody addicted to short answers and not doing the work, the AI Slop wins out, whether it is right or wrong.

The second issue is Access Without Accountability.

Access management is an incredibly boring topic, but it is becoming increasingly important given MCPs and direct data ingestion from your AI interface. And most organizations just don’t have that maturity; their access management strategy was built for a manual world where humans granted explicit permission to dashboards and/ or SQL databases. Now, pressure is mounting from executives to break down the barrier between data and the masses.

We’re seeing examples of this all over LinkedIn and the news, with people inadvertently touching sensitive datasets, proprietary code, and personal information they were never meant to see.

This is why enterprises are rolling AI out quite slowly; they don’t want another Samsung incident (proprietary code pasted on ChatGPT) or, more recently, the PocketOS debacle (deletion of the production database and backups).

In the old world, data was siloed, and any damage could be contained. Now, AI-generated analysis can feed back into systems, inform decisions at scale, and get shared across the organization in seconds. A single person’s prompt can shape what a whole leadership team believes by Friday afternoon.

That requires a different accountability model. Most companies haven’t built one. They’re still operating on the assumption that the person who generated the analysis is also the person who’ll catch the error in it, and that assumption is becoming less true as AI adoption increases.

Regulation Is Good

I’ve lived in Europe. The EU’s regulatory approach gets dragged on LinkedIn for killing innovation. But the quality of life is way better, the food is actually fresh (and healthy), and workers get a lot more protection than they do in North America.

They are still capitalist countries; they still create innovation. Look at Sweden. It is one of the most regulated countries in the world, yet it is booming with startups and innovation across everything. They are just building in a much more purposeful way with the right regulations in place.

And regulation didn’t kill capitalism. It made the market trustworthy enough to scale. The same principle applies here. The goal isn’t to slow AI down. It’s to keep it from unleashing damage from its mass democratization.

Share

Three things organizations can actually do about this:

• Reframe Governance as Enablement – Don’t try to govern AI. Nobody wants governance. Instead, figure out where the risks are: which teams are using AI most heavily, what data are they touching, and where are the access gaps. Work with those teams to enable them, while accounting for the inherent risks they will likely identify for themselves.

• Use AI to Help Regulate – AI is a tool. Used haphazardly, it will produce risky outputs. Used intelligently, it can save you a lot of headaches down the road. Essentially, AI is your best friend to identify where governance needs to go (e.g., usage patterns, access logs, output audits, query analysis). AI can surface problem areas and help implement documentation or access-control checks to govern them.

• Build Accountability into the Workflow – I recently burned through three times my expected API budget on a build because accountability wasn’t built into the workflow from the start. Think about this first, because people will just build with AI whenever they get an idea without considering the consequences. Access controls, data quality flags, audit trails, and approval gates must all be embedded in the workflow. If it’s a separate process, it won’t happen.

And don’t fret, capitalism with smart regulation produced the most innovative economies in history. The regulation didn’t slow things down; done well, it made the system trustworthy enough to scale, which is the only reason innovation got to compound.

And isn’t that the goal here?

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Share The Data Ecosystem

Subscribe now

Share

Every time I look at LinkedIn or Substack, I see more “here is how to use AI more effectively.”

It is honestly one part exhausting, one part exhilarating, and one part unbelievable.

Did I mention exhausting?

As someone who has recently stepped into the full-time solo consulting role, I decided: why not actually apply my framework and these learnings to make my life easier and my outputs better?

Because let’s be honest, frameworks are useless if nobody can act on them.

So this week, we move from theory to practice. How does a company actually start building out their future-forward AI System? And for the individual reader, how do you do it for yourself, in your own role, within whatever rules your organization has (or hasn’t) set?

A Quick Refresh on AI Systems Design

Before we jump into implementation, let me reframe the concept quickly (in case you haven’t read the previous articles, which you should). If you’ve read the last two issues, skim this.

AI Systems Design is a holistic approach to building AI into your business. It means reframing AI from a technical evolution into a complete redesign of four different areas you need to think about. Here, you think about them together (e.g., a system) rather than bolting AI tools onto the existing business model and operations:

• The business model – How AI changes the way you create, deliver, and capture value. This is a strategy question and flows into what the business stands for and how it operates, because it may not (and should not) be the same answer as it was yesterday

• The operating model – Speaking of business operations, how do the processes, workflows, roles, and decision rights change to allow AI-augmented work to happen day to day (and deliver good ROI)

• The technical architecture – The data, tools, and AI interaction model that sits underneath, designed around how AI needs to move through the business

• The governance, trust, and culture layer – The rules, boundaries, and shared language that make AI legible to non-technical stakeholders and safe to scale

The companies that get this right don’t end up with the most AI tools. They end up with AI that actually works inside the business. Everybody else (and I’ve seen it) will end up with a fragmented pile of tools that nobody trusts.

Share

So, how do you actually go about doing this? Well, it depends on who you are.

Three Approaches to AI Evolution

Originally, I wanted to write this from the perspective of the business.

But then the more I think about it, the real impact we are seeing right now in the world of Claude Code and Cowork comes from individuals learning to incorporate AI into their own workflows.

So instead of one angle, I’ve turned it into three and decided to call it the Venn diagram of practical AI usage:

1. Business-led AI Transformation – Organizational-led AI, where the business is focused on driving efficiencies and figuring out how AI can evolve how it operates. This leads to new tools or operational changes in how employees work. This type of transformation is usually led by executives or senior leaders, and has big budgets, long timelines, and aims for a company-wide impact.

2. Individual-led Productivity Focused AI – With AI becoming mainstream, AI is used by employees of their own volition. These are individuals looking to be more productive. This has gone into overdrive recently with better models that can now fully automate tasks and workflows. This initiative may not be driven by the organization, but the tools are available for use, just not widely promoted or taught.

3. Business-enabling Individuals to Use AI – The middle ground of the previous two, where the organization is pushing individuals to learn, use, and embrace AI within how they work. This is often accompanied by a directive or strategic shift to become more AI-enabled as an organization but it still doesn’t mean that all employees use it equally (or gain the same benefit from AI).

These three aren’t MECE (mutually exclusive, collectively exhaustive) by any means. There is a variety of all three of these approaches running at once. For example:

• The executive team is likely slowly cooking up an AI transformation programme (likely theoretical at this point)

• Meanwhile, half the employees are using AI (usually standard prompting) to help with research, communication, and summarising meetings

• And maybe you have one team (call it marketing) where the director is actively enabling colleagues to use AI more effectively.

No matter what company you sit in (unless you are a solopreneur), there is likely a combination of all three of these.

And that is okay.

The problem isn’t that these three approaches exist in tandem. The problem is that each one is usually done in a silo, and it isn’t done optimally. Companies that will win with AI will begin to realize how to connect these approaches and effectively implement them. That is what this article is about.

So, for the rest of this article, I want to walk through what each of these approaches looks like from an implementation perspective, drawing on my experience. More importantly, each approach makes the others more successful, which is important for how they blend together and for the point of showing it this way.

Let’s start with the business-led transformation.

The Business-Led Transformation

Business-led AI transformation is a direct extension of my AI Systems Design philosophy. The two big components of this are the Refactoring of the Business Model and the Sociotechnical Operating System.

This is, in essence, a long-term initiative with lots of moving parts, executive ownership, and buy-in across the organization. The thing is, every company I’ve worked with in the past five years has advocated for some sort of business model transformation (similar to what I’m talking about) to reflect data or AI. However, the urgency to do this has never been more apparent.

One industry I’ve done this in for multiple organizations is logistics, so I will use a fabricated logistics company as an example of how to think about this type of transformation, from top to bottom.

The typical logistics business model involves moving goods from one point to another. In this example, let’s say we are a trucking distribution company. You have a customer/sales department that handles orders and complaints, an operations team that ensures trucks run on time, and a finance department that handles costs and builds reports.

A six-billion-dollar organization I worked with years ago ran this business model very well but was very behind in its data use. For example, their operations were quite efficient but reactive to customer requirements. They also didn’t understand individual customers’ costs and actually lost money on many customers. Everybody knew the issues (except for that losing-money one, which I found through a data project), but nobody was well-placed to fix them. Not to mention this all led to excessive bloat on the finance team, as everything had to be pulled and reported on manually.

Share

If I were to start them down the path of AI Systems Design, I would first focus on refactoring their legacy business model. Their business model needs to evolve from “helping customers move their goods from one place to another” to “using data and AI to optimize the supply chain of customers.” Yes, this is a simplified version, but you get the idea.

Now let’s get into how AI can help the company deliver on that business model and differentiate itself from the pack using the six steps in the last article:

1. Understand direction – Leadership has decided the business is shifting to a “proactively manage your supply chain” mindset, which ensures your customers depend on you. Reactive rerouting is a blocker to that brand promise. So any AI transformation is about moving from reactive to proactive. Rerouting is the first place customers would feel the difference.

2. Pick one or two processes to redesign – When we are talking about proactivity, the obvious processes are (1) route planning and (2) route pricing. I’m going to be honest, I was shocked at how old-school both of these processes are at most companies. They have done this route this way for this cost for a decade, so why switch up? At this point, pick a few routes that you can recalibrate, and it is time to map the process.

3. Redesign the workflow – Route design and pricing is a combination of the sales, customer, operations and finance teams. Sit with each team. Understand what data they use to map out existing routes and how they currently optimize routes and costs. Then start to embed data & AI. For example, a common roadblock is communication between teams. So by connecting finance data to operational routes, you can surface routes that are underdelivering. Then have notifications to sales/ customer reps to try to add volume to those routes at a discount in select areas. AI’s role is to serve as the UI to connect, notify, and bridge the gap between where the data gets surfaced and how it's accessed (because dashboards are old-school and not used). Then you don’t need 4 calls and 2 weeks to figure this out; you go from information to action.

4. Align with the tools – With this new workflow, you know what tooling you need. Likely by connecting the ERP and CRM, then having an AI operator agent help notify sales teams via whatever stack your company is working with. The point is, you’ve redesigned the workflow so the team knows what it needs before a vendor pitches you. And with tools like Claude Code or Codex, you can query from the data if the underlying model is well-established (and trusted) for that workflow.

5. Assess, celebrate, and embed governance – Remember, we started with 2-3 routes. Test it, and understand what worked and what didn’t. Show off the wins to other teams/ leadership and then figure out how to scale. This includes deterministic guardrails and data protection components. For example, the agent shouldn’t notify sales if the ROI is below this amount. Or any sensitive customer information should be anonymized before being surfaced to the agent.

6. Feedback, scale, and rethink the model – After a while you learn what works and what needs to be refactored. You could also apply a similar process elsewhere, for example, warehouse management. Or driver scheduling. After a while, you see that the business model itself is shifting, and you are beginning to design (and sell) a real supply-chain intelligence service, not just shipping products. And hey, maybe that is another revenue source.

This is a very fabricated example, but you can see how AI transformation actually starts with business processes. And when done right, it can strategically evolve the company’s operating model.

And that’s what “start small” actually means. Not a sandbox POC (because those don’t really scale); no it starts with one real process, redesigned end to end, live in production. The six-step loop repeats and ideally scales based on what has worked in practice. Test and learn, but do so with process evolution in mind. That’s business-led transformation in an AI world (without ever running a bloated “transformation program”).

Individual-Led, Productivity-Focused AI

The next approach is probably most relevant for you, the reader. Everybody I talk to right now is thinking about how they can use AI to be more productive. Productivity hacks, cheat sheets, and how-to guides are flooding Substack and LinkedIn, promising 10x productivity with a 20-minute video.

This is all thanks to a huge step in AI usability with Claude Cowork (and Code, but Cowork is more accessible). I’m not going to revisit how to use Claude Cowork, as there are many better resources, videos and articles to help you with it. What I will focus on is how you rethink your own processes and workflows to build in a scalable way. Let me use my own setup as the example here, because it’s the one I know best.

I run a freelance consulting practice. I publish this Substack newsletter every week. I post on LinkedIn and Notes every day. I just built (and recently filmed) a LinkedIn Learning course. And I’m trying to write a book.

A month ago, I decided to redesign my approach and workflows for an AI-native world. When I did it, I made one mistake: I tried to redesign all my workflows at once, instead of prioritizing. That cost me a few days and a lot of headaches.

Since then, I’ve pivoted. I’ve narrowed it down to my 2-3 things I need to do most. First off, have a consistent newsletter process. Secondly, build a consulting proposition based on my knowledge and IP.

That setup took me a few days and is already paying dividends. I have a much more streamlined newsletter writing process and I’ve built out materials for three processes that clients and companies are starting to buy into: (1) The Data & AI Ecosystem Assessment; (2) An AI System Design workshop; and (3) AI Implementation Program (let me know if any of the three is something you are interested in). And honestly, I’m practicing what I preach by doing it. Here were the exact same six steps I went through and am still going through:

1. Understand direction – What am I actually trying to do? Right now, it boils down to two things: (1) growing this newsletter and (2) building a scalable consulting business. The first lends credibility to the second, so they naturally align.

2. Pick one or two processes – A ton of processes fit into those, so after the failed ocean-boiling attempt, I narrowed it to two: streamlining my newsletter writing workflow, and building out consulting propositions and materials. These two were the highest value, and there were significant opportunities for AI to make a meaningful difference.

3. Redesign the workflow – For the newsletter, I developed an article template using Claude code. I fill it in, upload it to Claude to generate a first draft based on my personal knowledge graph and my developed AI skills (e.g., tone, style, format, etc.), and then I edit it (extensively) to ensure it meets the quality I want. Then get a final AI pass for formatting and a last-round quality check. It’s still a lot of work (as I have high standards for output and AI doesn’t yet meet them), but I help outsource some lower-value tasks and make my writing more efficient. For the freelance consulting proposition and BD components, I now use AI-generated transcripts to pinpoint my customers’ pain points (via calls, emails, even research). I then structure what I want my response to look like and point that towards my knowledge graph of consulting resources, best practices, and educational materials, which helps draft bespoke starting perspectives. Of course, this is exactly how I used to build propositions/ decks before, but now it’s 10x faster with AI tools.

4. Align with the tools – Granola for meeting notes, Google Workspace for emails, Drive and NotebookLM for my knowledge graph, Obsidian for markdown file management and Claude Code as the orchestrator of it all. Oh, and then my classic Office 365 suite, because I still love PowerPoint and still prefer writing content in Word. The cost? Less than $100 a month because each tool has a reason it’s in the stack, and I don’t need shiny new bespoke tools to mess with my flow. This stack is ever-changing, too, so it may be different tomorrow.

5. Assess, celebrate, and embed governance – Personal data & AI governance is huge for me because I know how important it is. Client data doesn’t go into my Knowledge Graph and nothing gets published that hasn’t been through my own voice pass. I’ve also documented all my guardrails, and continue to do so as I go.

6. Feedback, scale, and rethink the model – This is constant! Every week I’m updating my process. What’s working? What’s not? Last week I rebuilt the newsletter skills and my tone of voice because it wasn’t good enough. Now I’m revising how Claude interacts with my knowledge graph. The workflow will continue to compound based on the system I’ve designed.

And as I went through this process, I realized there is no shortcut to efficiency with AI, it is about designing the system that allows AI to augment what you do. This is why all those ‘cheat sheets’ only get you part of the way there; they make you think you have it all figured out by spending 20 minutes copying an AI content influencer's setup, but then you end up with something that isn't actually helpful.

My setup probably isn't the right one for you. But redesigning your own workflows with the same rigour is where the compounding actually begins. So sit down, lay out your processes, and build a system around AI. That's where individual productivity is heading.

Business-enabling Individuals to Use AI

The third approach is in the middle of the Venn diagram. It is both the most important one (as it justifies the value of AI in the short term) and the one that most organizations can’t figure out.

It is no surprise that companies want to use AI. But beyond their AI strategic planning or individual use, there is usually a lack of concerted direction to enable teams with AI. For example, a company may roll out Copilot (because it is part of their Microsoft package), Gemini, Claude or ChatGPT to select groups. There might be a launch email or meeting, a short training deck, and maybe some guardrails like “don’t put client data in it”. When leadership reviews the usage and effectiveness of these tools, people pipe up about how great they are for note-taking or summarization, but that is about as far as it goes. Then the investment (because it is a big one for a tight budget, non-tech enterprise) in AI gets questioned, and there is no desire to roll out AI further to other teams.

In the end, the problem wasn’t the tool (unless it is CoPilot); it was that the business didn’t invest in how individuals should use and get value from AI. You can’t just buy tools or licenses and call it a strategy.

Now, obviously, there are a lot of companies that have taken the right approach with this and are seeing incredible value from business-led AI. Here are a couple of great articles from Erik Bauch and Bobby den Bezemer on how they guided their team to do this in the right way (definitely take a read). I want to speak to a similar example of a marketing/ product team in a scale-up who got the AI productivity brief and has adapted how they do product innovation with AI:

1. Understand direction – Leadership was very keen for the team to make the most of AI, giving them access to the right tools (Claude Cowork in this case) and a mandate to use it. Part of this was regular check-ins and ideation sessions to embed AI into workflows, so it wasn’t just a one-time thing.

2. Pick one or two processes – People had already redesigned how they conducted meetings and built out marketing briefs. One difficult process was product innovation. This was (1) either expensive because they hired a marketing/ research agency, or (2) experience-led without the customer insight necessary.

3. Redesign the workflow – The biggest gap was the time required for customer research. Now, instead of starting with an agency, the team uses AI to scan Reddit pages or customer forums to identify the consumer need states in the category. Then run AI scripts to synthesize themes, extract specific quotes, surface a shortlist, and create a few options for product briefs. The team can then bring in their expertise and judgement on what could work and what is noise. This has rapidly accelerated how the team works and increased access to insights that weren’t previously available.

4. Align with the tools – The process led to the toolkit. So Claude, Perplexity and Python scripts (managed via Claude) to make the calls and loop through Reddit. Then the outputs are saved to a Markdown file, which is ported to Google Docs. The goal is to eventually automate it (with n8n or something), but for now this is the barebones test. Remember, this isn’t a data team; this is a marketing team spinning up something new with Claude Cowork/ Code and a few other tools. Finally, Canva to help build the briefs, which is a tool the marketing team is quite familiar with.

5. Assess, celebrate, and embed governance – This process is still ongoing, but the key point is to validate individual need states before they feed into a product brief. When there is something tangible (either a need state or an insight), it is fed into Slack and helps inform other teams/ individuals. When the team presents these outputs, they justify and promote the use of AI to achieve the right outcomes.

6. Feedback, scale, and rethink the model – The goal is to make this process automated and bake in some of the briefing, copy, and other marketing processes on top of it. The model works for now, but how it scales without losing quality is currently being evaluated.

When you take on something like that, this can compound and build. One well-designed process can be the start of everything else, especially when you get good at identifying where AI can make the biggest impact.

And that’s the lesson in this third approach. Business-led AI doesn’t require a long-winded AI strategy programme; in today's world, it's a design exercise, with practical tools to test and figure out what works. And if you design efficiently, with embedded governance and leadership backing, you create a safe space for experimentation, helping establish a healthy AI culture that every company strives for.

And that is where AI Systems Design actually works in practice.

Next week, we are diving back into the Data Ecosystem with a look at Data Strategy, my bread and butter! Until then, have a great weekend and see you next Sunday.

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Subscribe now

Share

Share The Data Ecosystem

There are turning points in innovation that change everything in the corporate world.

Think of the printing press, combustible engines, electricity, the internet, or mobile phones.

And it is not often that when the technology is introduced or adopted by the masses, the biggest impact is felt. It’s when the technology finally finds a place within the organizational workflows and culture.

What we are witnessing is the first phase of that happening for AI. This is the big moment. It wasn’t November 2023 when ChatGPT took off. It is now, and we are only just getting started!

Companies are beginning to realize this. They’re all talking about AI.

But of course, most are just talking…
Or going about it in the wrong way…

They are bolting on AI, as if it’s a new tool that fits in their toolbox of technologies. This is a classic mistake, and a lot of heads will roll because of it.

Luckily, you are reading this article, and you are invested in learning about AI in a scalable way. Welcome to Part 2 of my AI Systems Design thought experiment. Time to buckle in and learn about how to operationalize AI for the long run!

This Evolution Isn’t New

If you haven’t read it, go back and read my article last week on the Refactored Business Model. Your AI System has to start with this because your business model needs to be at the heart of everything you do with AI.

The next thing to understand is that this type of evolution is not new.

Companies have done this before. In the early 2000s, when the Internet went mainstream, businesses rushed to incorporate it into their business. But most did it as a bolt-on (i.e., we need a website just to have a website) or they created companies with business models that didn’t make sense. We are seeing both those things again today: quick-fix AI solutions that aren’t scalable, and a wave of start-ups failing because they were built with AI in mind rather than their business model.

But back in the Internet boom, there were also a few companies that redesigned their operating model around this new technology. There are the obvious ones like Google, Netflix, or Amazon, but also the not-so-obvious ones like Domino’s, which has digital ordering and real-time tracking embedded into their pizza business (who doesn’t love that pizza tracker). Or John Deere, which is a famous farming equipment company, but now embeds IoT sensors and data platforms into its tractors, fundamentally changing its value proposition (my cousin is a farmer, and the technology/ data involved in those tractors is insane now)

The leadership of these organizations understood the need for reinvention and was well prepared for the data wave, in which they began to use data as a strategic asset rather than just a byproduct of operations. Companies that embedded data into their business models gained an edge, while the ones that treated it as a reporting function are still catching up.

AI is the next evolution in this pattern. But it’s different in three critical ways.

• Speed — The technology is advancing faster than any prior wave and changing how we work every 6 months to a year. Companies have significantly less time to adapt before the competitive landscape shifts.

• Breadth — AI touches every function. This is why the business model must be refactored, because it isn’t just impacting the digital or technical teams, but everything around it as well.

• Understanding — If anyone told you they truly understand what AI will do, they are lying. And executives—who have limited time as it is—are making decisions about AI with less strategic clarity than previous waves of corporate evolution. This is why so much of it ends up as bolt-on.

The Internet required companies to refactor their business, not just adopt. With AI, the connecting thread is the same: companies that bolt on new capabilities to old structures will fall behind.

The AI Sociotechnical Operating System

In the last article, we established the starting point: organizations need to refactor their business model and strategy to establish a coherent approach to business, data, and AI.

But, of course, strategy without execution is just a nice slide deck.

Enter the AI Sociotechnical Operating System. This is “how” your refactored business model works. It is broken down into three layers, mimicking the People, Process and Technology framework that everybody refers to (even though they never use it):

1. Technology & Data

2. Process & People

3. Governance, Trust & Culture

I’m going to walk through these layers, starting with technology, because let’s be honest, that’s where every company starts. But don’t mistake sequence for importance. The technology is the easy part. The layers below it are where the real work—and real value—exists.

Technology & Data: Where Everyone Starts

This is the layer that gets all the attention. People want easy answers, especially in areas they don’t understand. So the budget, the executive discussions, and the apparent “progress” usually start and end here, mostly because SaaS vendors make it easy to understand.

The technology matters. But it matters in a very specific way, and most companies are approaching it the wrong way. They start with tools and work backwards to justify them. But we all know succeeding with AI is more nuanced than “buy the right tools.”

Before any architecture or tooling decisions, you need to define the business context for the data and technology underpinning the refactored business model. What data do you need to enable the AI-augmented processes you’ve designed in the process layer? What does the data model look like when it’s built to serve both the foundational business processes and the AI capabilities layered on top? This includes the data dictionary, the context layer, the data quality standards, and the governance structures that embed into the new AI ecosystem. This should overlap with the redefined business processes, so consider starting with the process layer first and coming back to this—it will make the tech and data context much easier to outline properly.

After you have the context, the next step is to design the AI architecture. This means scoping out how AI systems will interact with one another to deliver your redesigned business processes and build on your existing data and technological infrastructure. With AI now able to build new software, pull from different data sources, and chain together workflows in ways we’ve never seen before, the way we think about architecture has to change. The classic data architecture approach—predefined pipelines and transformation layers—isn’t necessarily the most optimal way to design data workflows anymore. The architecture needs to be more flexible, more modular, and designed with the AI interaction model in mind. How do AI agents traverse the system? Where do you need deterministic guardrails versus probabilistic reasoning? The architecture should answer these questions and establish the guidelines for how technology operates within the AI System.

Tooling decisions can then build on the context and architecture. These two things help justify tool purchases or investments. Also, be sure to map out the product roadmap for anything you purchase or decide to build. With AI coding assist, SaaS products are now becoming outdated before companies can even properly embed them. This doesn’t mean you shouldn’t buy tools; it means you should buy them with a clear understanding of what problem they solve, how they integrate with everything else, and whether you can build something better via AI-assisted development/ coding.

I’m serious, my friend (who runs a recruiting business and knows nothing about ML or Data Science) just vibe-coded an insanely useful extension to his CRM, built with his business processes in mind. His CRM gets him 30% of the way there, while this tool gets him the rest of the way. And all he did was spend a few weeks vibe coding on Claude Cowork by relaying his business context/ needs. This is going to be a common story moving forward, hence the huge drop in SaaS platform market caps.

The last bit to think about in this layer is one of the hardest: Interoperability. This needs to be a design principle from the start, not something you retrofit after you’ve accumulated a dozen disconnected AI tools. As organizations add AI capabilities function by function, the risk of creating AI silos grows rapidly. And this is already happening. Marketing, finance, ops are probably all using different tools hooked up to different data sources. This is the data silo problem repeating itself with newer, less-understood technology. Design for interoperability based on the architectural decisions you’ve already made. The key part is to ensure your end users are working with AI in the same way, so that AI capabilities compound across the organization rather than fragment it.

Now for the harder questions: what processes need to change, and how do you build a culture that actually trusts AI?

Process & People: Where You Should Start…

Companies usually start with the technology, but realistically, they should start here.

When you refactor your business model, you are redesigning how the company operates to incorporate the efficiencies and effectiveness of AI (enabled by data). To do this properly, you need to figure out where AI will fit into existing business processes and workflows, and where it will adapt them. Then, what are the implications for the people in your organization.

Instead, companies deploy AI and just expect processes and people to figure it out themselves. Spoiler alert, they won’t.

Using the refactored business model, the first step is to map out existing business processes and identify what needs to be refactored. Which processes should be fully automated? Which should be AI-assisted with human oversight? Which should remain entirely human-led?

Most existing business processes were designed with humans, legacy technology, and Excel in mind. Now AI can supercharge all three (not saying it can replace Excel, though…). That requires rethinking how decisions are made and what needs to happen to get there. For example, a product manager can now use AI agents to scrape hundreds of Reddit reviews for their product’s pros and cons and embed them directly into their research. That just wasn’t possible before.

Then there are the ways of working. This is always the biggest issue for data teams, as they can’t seem to work effectively with the business. But AI should better automate project management, streamline communication and decision-making, and hopefully reduce the bureaucratic layers and pain of working with people outside your team. This should prompt a rethink of your operating model, in which AI facilitates many processes that were previously ignored.

However, the key thing here is to properly map out these ways of working with AI (especially for the redesigned business processes/workflows) and to constantly update it as things change. Remember, with AI, context is everything. And AI definitely needs proper context to help work better with other people.

Share The Data Ecosystem

Finally, there’s the decision-making component, which determines the process of moving from information to insight to action. AI is great at surfacing patterns, predictions, and recommendations. But the process for translating those into actual business decisions needs to be properly designed and overseen. Otherwise, you end up with beautifully generated AI outputs that nobody acts on, or with AI delivering on information that may not be fully correct. This thinking aligns with the business process redesign concept, but underscores the importance of how the decision is made and ensuring it is the right one.

Underpinning all of this is the people component. It centres on three things: the structure, skills, and support people need to succeed.

• Structure — How does the org structure align with these new ways of working and the operating model? This means deciding which AI agents or tools sit on different teams or under specific roles and people.

• Skills — People will need to learn new skills to succeed in their roles. Don’t just unleash AI on them; give them direction on which areas of AI they need to learn and what they need to upskill to do so.

• Support — The training, mentorship, and resources to succeed with AI. Skills don’t just appear instantly; organizations need to invest for people to use AI in their work.

This layer is where most of the hard work lives. Technology is relatively easy to deploy (especially when so many companies are racing to build every AI idea in one’s imagination). Redesigning how people should work and implementing that change management is not easy. But companies that invest here will see compounding returns. Companies that skip to the tech layer will spend a bunch on tools with limited benefits.

Governance, Trust & Culture: Where it Scales

This is the base of the pyramid. It’s what makes everything above it work. It’s how AI becomes scalable and ingrained in your organization’s DNA. And it’s the layer that almost nobody is investing in right now.

As I’ve mentioned before, when you are working with AI, you are working across an entire organization, not just one team. Even though people hate rules and red tape, anarchy is not the answer. Without a clear basis for governing the use of AI across teams and within the organization, people will not know what they can do with it and will distrust it. This then breeds an antagonistic culture.

Making AI accessible isn’t just about giving people tools; true accessibility means embedding AI in the organization’s operations so people trust and feel comfortable using it. At the same time, this comfort level cannot come at the expense of security, privacy or risk.

This underscores the tension at the heart of this layer and is implicit in the whole AI revolution. On one hand, if you push too hard on control, people will go around you. They’ll use AI from their personal accounts, paste client data into random tools, and you lose all visibility into AI usage. Push too hard on giving access and moving fast, and you risk governance failures or privacy breaches. And if you push too hard on making people use AI, you risk hostility or disconnection from employees. We’ve all seen the headlines about AI replacing jobs, and most people aren’t ready to completely change how they work.

The job of this layer is to find that line: where people feel free enough to use AI properly, the organization feels safe enough to let them, and people are encouraged rather than combative toward AI in their workplace. So how do you actually walk that line?

It all needs to start with trust in AI. By trust, I don’t mean faith in the model’s outputs; I mean the trust of using AI within your work, to make decisions, and understand how it fits into your business processes. Without this level of trust, adoption stalls; people may use AI for simple things like chat responses or the odd model output, but the trust doesn’t go beyond that. It was like when people didn’t understand computers or the internet or even cloud files, and just kept doing things manually for years on end before they were forced to adapt.

Most people are nervous about AI right now. On LinkedIn, it seems like everybody is an AI genius with Claude Code doing 78 things at once. But that’s not real. Most people read the headlines about AI cuts. They’ve seen colleagues replaced. They’ve used a chatbot that confidently told them something wrong. Their fear is based on real experience, and pretending it doesn’t exist is the fastest way to lose the room.

Trust layers down into everything, especially the next frontier for AI: Human/ AI interoperability. This is where AI makes decisions on its own and where a human needs to step in. Get this wrong in either direction and you damage adoption. Too much AI autonomy without oversight and you create risk (and people stop trusting it). Too many human checkpoints on every AI action and you defeat the point of using AI in the first place (and people stop using it). Defining these boundaries gets into the governance discussion, and builds off the process conversion we already covered.

Share The Data Ecosystem

And of course, there’s communication and shared language. One of the most underrated parts of any governance effort is just making sure people across the organization are talking about AI the same way. What does “AI-assisted” mean in your company? What does “approved tooling” mean? Without these definitions and alignment on these things, you see a gap of misalignment, fear, and inconsistency. Shared vocabulary, shared expectations, shared standards—this is the unglamorous work that makes everything work. And it connects directly to the governance as enabler point I repeatedly make. Maybe we should call it something different, but the point is that AI Governance needs to be framed to enable progress and adoption.

This all leads to the elephant in the room that people are too afraid to talk about—AI culture. Instead of talking about it, companies are just hoping it forms (just like they did with a data culture) or running 2-3 webinars on what AI is and how teams should adapt it. In reality, a healthy AI culture looks like people experimenting openly, sharing what works, asking for help when something feels off, and feeling comfortable saying “I don’t know” when using AI or if AI gives them an answer they can’t verify. An unhealthy AI culture looks like people quietly hiding their AI use, oversharing AI outputs without checking them, or refusing to touch the tools at all because they are afraid it will replace them.

You don’t get to a healthy culture by accident. You get there by leadership genuinely encouraging usage with clear direction, providing proper training and time, celebrating the right kinds of wins, and making it safe to mess up while you’re learning.

The key point for this whole governance, trust, and culture layer is simple: if you can’t govern it, you can’t scale it. And if people don’t trust it, they won’t use it.

That’s why this layer is the base of the sociotechnical Operating System. Using technology is never guaranteed when you buy it. Updating processes doesn’t matter if people don’t follow them. But if you build a culture of trust with clear governance guidelines focused on value enablement? That is where you win!

Implementing AI Systems Design

As usual, this article got away from me. I was going to include a fabricated example of this system in a real-life company, but that will be the next article. I will also include the other side of the coin: the individual use of AI and how to do it effectively.

But let’s not finish just yet. There are some core principles I want to share about implementing AI Systems Design.

Now I haven’t seen one company do all of these perfectly; everybody is still learning. Not to mention, most companies can’t redesign their entire business model overnight. They have legacy systems, entrenched processes, thousands of employees, and boards that want ROI by next quarter.

AI Systems Design doesn’t require a big-bang transformation. It requires a deliberate, iterative approach that starts small and builds. Here are the six steps I’ve been recommending to companies I work with.

1. Understand your company’s direction – Before you touch anything AI-related, get honest about what the business is and where it is going. What do you do today? How should you be doing that tomorrow with AI in the mix? And what is the actual role AI plays in the business’s future (e.g., productivity, new products, or maybe even a new way of operating entirely)? Run a short strategy workshop with senior leadership (not just the tech team) to answer those three questions. If AI doesn’t shift how you create, deliver, or capture value, you’re probably thinking too small.

2. Pick one or two business processes to redesign – Don’t try to boil the ocean and redesign everything (trust me, I tried that with my business, and it was an AI version of analysis paralysis). Instead, choose a process based on two things: the value a redesigned version would deliver, and the willingness of the team that owns it to actually change how they work. And publicly share which process is being redesigned, so everybody stays on board, on task and in the loop.

3. Redesign the workflow – This is where the real work starts. Map the existing process step-by-step. For each step, decide: can this be fully automated, should AI make the decision with a human checking, or does this need a human lead with AI assisting? Get the people who actually run the process in a room to map the current- and future-state workflows side by side. As you document these workflows, you can also have your first governance and decision-rights conversations. Honestly, this is basically change management for the AI era…

4. Align the workflow with the right AI tools – Now we finally get to the tools & technology discussion. Why? By doing the previous steps, you know what you need, and you’re buying (or building) against a defined spec. Write a one-page tool brief against the redesigned workflow, think about how it integrates with the existing architecture, and test it before buying (especially with AI tools, there should be a quick pilot version)

5. Assess, celebrate wins, and embed governance for scale – Once the redesigned process is live, you have real data and evidence of what works. Since you are starting small, you can use those learnings to embed governance in a way that genuinely enables scale rather than blocking it. Then, assess where the wins came from, celebrate them publicly, and use them to build the right type of AI culture

6. Feedback, scale, and rethink the model – You are never done, especially in this AI-enabled age. Take everything you’ve learned from the first process and apply it to the next one. But don’t just copy-paste; reuse what works while stepping back to ask whether anything needs to evolve further (either in the business model or your processes/workflows) in light of what you’ve seen. Your leadership should watch this closely because the real value of AI Systems Design compounds over time, and everything will evolve alongside it.

Start small, start right, and build the muscle. Companies that try to boil the ocean will stall. Companies that pick one process with the right team and apply it against this type of framework will start to generate value from AI. And then iterate on it to build an organizational capability that compounds. When you get to genuine business model evolution—rather than just AI as a productivity tweak—that is when you are cooking!

Wrapping Up the Business Model Series

Yeah, so this article was linked to the original explanation of what a business model is…

…Safe to say, it got away from me. And we’ve covered a lot more than just business models.

Or have we? Whether we like it or not, AI isn’t about technological advancement; it is about the evolution of how we do business. The model has changed for everybody, and that means we, as professionals, have to as well.

So if you haven’t, go back and read my other articles:

• Issue #52, where we established what a business model is, including the three core questions and six archetypes that define how businesses create, deliver, and capture value

• Issue #53 connected the business model explanation with data, and explained why it should drive every data decision across your ecosystem

• Issue #54 confronted the current bolt-on problem we are facing with AI, introducing the ideas of AI Systems Design, starting with refactoring the business model to integrate foundations, data, and AI as a coherent whole

• Finally, in this article, we’ve gone to the next step of the AI Systems Design, explaining how the business model will evolve in the future due to AI, premised on the Sociotechnical Operating System

Next week, we’ll take a practical look at what this actually looks like in the real world, from both a business and an individual lens. The goal is to give you a few concrete tips for working more effectively with AI moving forward.

Also, the AI Systems Design is still a developing framework. I’m actively workshopping and refining it with companies right now. If this resonates—whether you’re a data leader trying to figure out how to approach AI strategically, or an executive wondering why your AI investments aren’t delivering—reach out. I’d love the feedback, the pushback, and the conversation. This is a framework that will get better with more perspectives and real-world applications.

Until then, have a great weekend and see you next Sunday!

Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!

Subscribe now

Share