# How to Read an AI Transformation Pitch

By Wes Pomeroy. Published May 8, 2026. https://wespomeroy.com/writing/how-to-read-an-ai-vendor-pitch/

A senior leader at a Fortune-something is being walked through a slide deck somewhere this week. The deck has analyst logos across the top, a unified architecture diagram in the middle, and an outcomes slide near the end with double-digit cost reductions and single-digit timelines. The pitch is "agentic AI transformation." The pitcher might be internal IT, or a consulting firm, or a vendor with a partner ecosystem behind them. The leader doesn't fully understand what they're looking at. The diagrams are dense, the vocabulary is new, the room is nodding, and the pressure to act feels genuine because the analysts on slide three say the window is closing.

That leader is who this is for.

I've spent my career on both sides of this. Years building enterprise systems. More years running marketing communications at scale. I've sat in the room as the technologist drawing the architecture, and I've sat in the room as the business leader being pitched. Both seats teach you to read decks like these. What follows is what I've learned to look for.

### How a real enterprise stack works

A modern enterprise runs on a layered tech stack that's deliberately predictable. Systems that hold the truth - the customer record, the catalog, the bills, who's allowed to do what. Systems that do specific jobs - take orders, run campaigns, route service tickets. Pipes that move information between them. Rules engines that encode decisions: if X then Y. Screens that put it all in front of humans. The whole thing is engineered around one assumption: same input, same output. That predictability is what makes it trustworthy, auditable, and legally defensible. When something goes wrong, you can rewind the tape and find out where.

The AI everyone's talking about does not behave like that. It behaves more like a very smart, very fast intern who's read a lot. Ask the same intern the same question twice and you may get two different answers. Sometimes the answer is great. Sometimes the answer is wrong in ways the intern can't tell are wrong, said with total confidence. That's how the technology works.

A working enterprise architecture puts the intern on top of the factory, not inside it. The factory keeps running. The intern's job is translation and dispatch - take a customer's request in plain English, figure out what they want, route it through the existing tools. The intern doesn't invent prices, change records, or make up facts. Wherever the intern's flakiness could touch something consequential, you build guardrails. You give the intern a fixed toolbox. You require answers in a fixed format - a form, not an essay. You add a checker that reviews the work before it ships. None of this is exotic. It's defensive engineering applied to a brilliant and powerful, but flaky new component.

### Why these pitches happen

A fair word about the people writing the deck. Most of these pitches come from people doing real work for real reasons. Every IT organization in a large enterprise lives under cost-center pressure that's not their fault and isn't going away. The instinct to expand into business problems is often genuine - technologists watching a business team struggle with something a system could help solve, told to stay in their lane, build up real frustration over real years. Some of the most consequential business innovations of the last 15 years came from technology teams pushing the business side to think differently. The unification of customer data across siloed systems is one example. Cross-functional ambition is healthy. What goes wrong is when the ambition outruns the context, and an architecture gets drawn before the conversation gets had.

### Watch the personas

Every transformation deck has a persona slide somewhere - a list of the roles that will use or steer the new platform. Read it carefully, because this is where the deck reveals what kind of expertise it thinks the work requires.

Here's what AI tooling doesn't change. The standards an AI agent operates against - what good copy looks like, what an acceptable customer interaction sounds like, where the brand line is, what counts as a real escalation versus a false alarm - have to be built and graded and maintained by people who hold the field-specific context. Generic expertise won't do it. Even brilliant experts who just joined the company won't do it. The standard is held by people who have spent years inside this specific business, watching this specific brand try things and learn from them, in this specific market with these customers, competitors, and regulators.

A marketing communications professional who's been steering a brand for a decade knows things that don't appear in any document. They know which phrases this brand has used and walked away from. They know how this voice sounds different from the neighbor brand's voice. They know which campaigns landed in their market and which ones didn't, and why. They know the legal landmines in their industry, the cultural sensitivities of their customer base, and the dozen times the company tried something cute and got punished for it.

That depth exists everywhere real work happens. A customer service operations leader knows the patterns of customer frustration in their category like a doctor knows symptoms. A pricing strategist knows why the price ladder is built the way it is, and what breaks when you flatten it. A product manager knows which adjacent companies tried this five years ago and how it played out. It's contextual, accumulated, and cross-pollinated with adjacent domains - the marketer who also understands procurement cycles, the service leader who also reads regulatory variance by state, the technologist who also tracks the financial reporting calendar. That cross-pollination is where real value compounds.

So when you read the persona slide, look past the role categories to the people behind them. Are they real, named, senior, and treated as permanent owners of the standard the agents will be measured against? Generic role labels - the kind that read like a job-family taxonomy from an HR system - are a tell that the deck was drawn at the architecture layer without sustained input from the people who hold the contextual depth. A real plan lists individuals as co-authors of the architecture itself. It treats their expertise as a permanent input, not a one-time consultation.

The healthiest version of all this is everyone winning. Technologists doing what they're brilliant at - building the systems, scaling the infrastructure, pushing the company toward capabilities it didn't know it could have. Domain experts doing what they're brilliant at - defining the standard, grading the work, catching the drift, keeping the company recognizable to its customers across decades. Each function gets sharper, not duller. The work gets more interesting, because the routine parts get automated and the parts that need deep judgment finally have the time. There is a real job for everyone in this version. The architecture either reflects that or it doesn't.

### Notice what gets called friction

Most decks have a slide showing the current process and the future process side by side, with the current process labeled as too slow or too complicated. On the left: a linear process with multiple steps and multiple teams involved. The slide labels this "delayed delivery" or "multiple handoffs." On the right: a streamlined cycle, fewer humans, faster output.

Read the left side carefully. Some handoffs are real friction worth removing - duplicated work, sequential approvals that could run in parallel, manual integrations between systems that should talk. Real targets for automation.

Other handoffs are governance work, mislabeled as friction. Legal review exists because someone with legal authority has to take responsibility for the decision. Brand review keeps a company's public voice from drifting into something it'll regret. Executive sign-off is where accountability attaches to a decision that involves real money or real risk. A deck that lumps governance into "delays to eliminate" is doing one of two things: not understanding what the handoffs are for, or understanding and choosing not to say. The senior leader needs to know which.

The mislabeling has a predictable source. People outside a system rarely have a clear read on what's happening inside it. Insiders carry their own bias and blind spots - everyone's defensive about their own work, that's human. But insider bias is a smaller risk than outsider ignorance. Insiders know which steps are doing real work and which are theater. Outsiders are guessing, and the guesses tend to favor whatever makes the diagram simpler.

### Find the guardrail layer

Open the architecture diagram. Find where the AI agents are. Now look for the layer right above them - the one that catches a confident wrong answer before it reaches a customer, a database, or a regulator.

If you can't find it, ask. The vocabulary you're listening for: guardrails, validators, hard rules, refusal patterns, citation requirements, idempotency, rollback. Don't worry if those terms aren't all familiar. Real reliability work has a real vocabulary, and a deck that doesn't use any of it is a deck where reliability hasn't been thought through.

If the diagram has agents but no visible reliability layer, the architecture was drawn by people thinking about what AI can do, not about what AI can do wrong. The first slide is easier to draw. The second slide is the one that decides whether this is safe to put in front of customers.

A real plan includes the boring parts. What does the agent do when it's not sure? It refuses, asks, or escalates - it doesn't guess. What happens when it's confidently wrong? It gets caught by another layer before anything ships. What happens if a bad action sneaks through? It can be rolled back, with a clear record of what happened. Where do humans fit? Approving before action for high-stakes work, monitoring while it runs for high-volume work, and sampling and grading the output afterward for everything else. The generous read on a deck that's missing all this is that the tech team thought it was too obvious to include. Possible. Verify by asking to see the actual engineering plan.

### Test the word "idea"

Decks selling AI-driven marketing sometimes claim the platform can take a campaign from idea all the way to launch with no humans in between. When you see that claim, push on the word "idea."

AI is genuinely good at the production work, once it's been told what to make. Drafting fifteen versions of an ad after the headline is decided. Cutting a video into ten formats for ten platforms once the message is set. Sending the right offer to the right audience segment after someone has chosen which offers to run. That's real value. The part of the work that used to take a team three weeks now takes a few hours.

What AI doesn't do is decide what story your company should tell this quarter, what promise to make to customers, what tone to take when there's bad news in the market, or which risks are worth taking with a brand that took 30 years to build. That's the idea work. That's where humans with deep context earn their keep.

A pitch that bundles those two things together and sells the whole package as automatable is either confused about what AI does or hoping you are. The question to ask is: who tells the system what to make? If the answer is "a marketer briefs the AI," the slide should say so. There's a real difference between making your team faster and replacing your team, and an honest deck draws it.

### Questions to ask in the room

Four questions that separate a real plan from theater.

*Show me the guardrail layer. Where does a confident wrong answer get caught before it reaches a customer or our database?*

*Walk me through the persona list. Which of my business leaders co-authored this architecture? Where did their input change the design?* If the answer is "they were briefed" or "they'll be consulted," it wasn't co-authored. You're being shown a finished plan, not invited into one.

*On the handoffs you're calling friction, which ones are governance? Who owns each one, and what risk are they managing?* If the answer treats them as interchangeable with bureaucracy, the team writing the deck doesn't yet understand what those handoffs are for.

*The outcomes are operational - cost, speed, volume. What's the metric for brand health, customer trust, or relationship quality?* If those aren't on the slide, they aren't being measured. The architecture can hit every number on the page while the business gets worse in ways no one's tracking.

### Healthy challenge, silent landgrab

One note before closing. The wrong takeaway here is that business teams should defend their turf and tech teams should stay in their lane. Companies need both instincts - the one that says we can do something we couldn't do before, and the one that says here's what'll actually land in market. A business team that can't be challenged by IT goes stale. An IT team that can't be challenged by the business is unaccountable or out of their depth. Pushing each other is the work. What goes wrong is when the pushing happens through architecture diagrams that quietly rewrite who's in the room, instead of through honest argument about what the company should actually do.

### What's at stake

If a company over-commits to a pitch like this, the market corrects it painfully. Customer experience degrades in ways the dashboards don't catch. Brand trust erodes quietly until it shows up in a quarter where churn is up, acquisition is down, and no one can explain why. Service costs go up after the savings hit the slide and the consequences hit the P&L. The teams that got cut get rebuilt at higher cost. The agents that weren't governed produce a public failure that costs more than the program saved.

Companies that get this right share one thing. They got the people who'd have to make it work into the room before the architecture got drawn. They argued openly about scope and ownership. They ended up with a plan that everyone had skin in.

The choice is between a co-authored plan and a handed-down one.

If you're a senior leader reading this, you're the buyer here, not the audience. Your job is making sure the architecture matches the business you actually run. Your business teams are the source of the judgment that makes any transformation hold up. The slides should reflect that.