LEXIE: OpenAI put out numbers this month showing the companies that use AI the most pulling away from everybody else.

In January, the gap was 2.6 times. It's now 8.3.

And I took that to the two people I know who actually build this stuff,

fully expecting at least one of them to be impressed by it.

Neither of them was.

And here's the part I didn't see coming.

They weren't unimpressed for the same reason, and they don't want you to do the same thing about it either.

Then the second story of the week turned out to be the first story wearing a suit.

Hi, and welcome back to the Allaudable HQ.

This is Assistant to the CMO. I'm your host, Lexie Meskouris.

And the idea here is pretty simple.

Every week, we take whatever just happened in AI and marketing, and we actually pull it apart.

Now, I don't build any of this myself.

So each week, I sit down with two people who do Will Nash and Harjot Singh.

Between them, it's honestly over 20 years of building tech and brands from the ground up.

And the best part is they've got no horse in the race.

They don't sell the things we cover.

They just see them differently.

So this week, we've got numbers, and I want to be careful about them

because there are actually two separate sources, and people keep mashing them together.

The first one is a working paper that went up on Archive, the preprint server, on the 12th of August.

It's not peer-reviewed, and it's co-authored by OpenAI staff, so hold that thought.

It looks at over 1,500 organizations and more than 17 million ChadGPT Enterprise messages running through March.

And the headline is that output tokens grew about sevenfold between June last year and March.

About half of that growth came from companies that had already adopted, so it's not just new logos piling in.

The second source is separate.

It's OpenAI's own Enterprise Signals page, and that's where the 8.3 comes from.

They take the top 10% of usage each month, and they call those the frontier firms,

and those firms generate 8.3 times the tokens per active user that a typical firm does.

In January, that was 2.6.

Will, you looked at this first, and you were not exactly dazzled.

WILL: No, I mean, the growth is real.

I wouldn't dispute that at all.

It's a pretty significant increase in the amount of tokens being used.

And I think the genuinely interesting bit for me is that it's grown outside of just the engineering department.

So the legal teams, particularly with tools like Codex, legal has led the growth,

something like a hundredfold increase in token consumption.

Now, I should be careful there because engineering are still the largest consumers by volume.

That hasn't changed.

But what you're seeing is the rest of a typical business rapidly catching up with the engineering group.

And to some extent, that includes marketing.

LEXIE: A hundredfold is a wild number, though.

Like, that's the kind of number that ends up on a slide.

WILL: It is.

And this is the bit I'd want to flag because token consumption is not necessarily usage.

A legal team running very long contracts through a model is going to burn tokens at a rate that a hundred short engineering prompts simply won't.

So a hundredfold token growth could be a fairly modest number of people doing very document-heavy work.

It's not the same as a hundred times more people using it.

LEXIE: And I'd never have caught that because a hundredfold sounds like a department transformed.

And what you're describing is maybe 11 people and a really long PDF.

WILL: Yeah, that's about right.

And I think the distinction matters a great deal when we're talking to CMOs because raw token usage is what OpenAI are interested in for the obvious reason that that's how they bill.

It is an okay proxy, I should say.

It's an easy way of comparing across multiple companies.

But the growth we're seeing is almost certainly downstream of an increase in agentic usage, MCPs and so on.

And those are far more token-heavy than a typical engineering application.

So, look, token usage is primarily a measure of cost, which for most businesses is a bad thing.

But it's being presented as a good thing.

What OpenAI are really saying is that the top 10% of organizations who spend the most money with us are our best customers.

And so those are the frontier firms.

They're reformatting what is effectively a bad thing, cost as innovation.

And fair enough for them to do it.

I don't blame them for that at all.

LEXIE: That reframe genuinely got me because I'd read Frontier Firm as a compliment about capability.

And you're telling me it's a customer segment.

WILL: It's a spend percentile, yeah.

HARJOT: Yeah, no, I mean, I'd go a bit further than Will, actually.

Because my first question when I saw this was just, is this scope to enterprise?

And it is, right, it's ChatGPT enterprise only.

There's nothing about Claude or Gemini or Copilot in either of these.

And the reason I asked is that we've seen this shape before.

You know, with the individual plans, you've got the 5x usage, the 10x, the 20x, all these tiers.

And there's always some super, super heavy users out on the tail end.

And they account for basically most of the usage that that distribution already existed.

So what I think we're actually seeing here is not a story about firms at all.

It's that enterprises have got comfortable, right?

They've stopped blocking it.

And the individuals who would have been out on that tail anyway, if they were on a personal plan,

they're now just able to use AI comfortably at work and actually get that output.

So this is just mirroring the shape of an organization anyway.

LEXIE: Okay, but if that's true, then the number tells me nothing.

Like I'm a CMO.

I read frontier firms are 8.3 times.

And what have I learned?

HARJOT: Honestly, not a lot.

It's a comfort metric for sure.

It tells you that the same distribution that exists across individuals also exists across enterprises,

which, you know, is what you'd expect.

And to be honest with you, I think this helps OpenAI more than it helps anybody else

because it gives people reassurance that the thing one would expect to be true does actually exist.

So yeah.

LEXIE: Let me throw one more bit at you both because there's a finding in the paper I keep chewing on.

The companies that adopted were already bigger, already more valuable,

already spending more on research and development before they touched the product.

The authors say that's consistent with them having invested in the organizational stuff first.

And I genuinely can't tell whether that makes the number more interesting or completely hollows it out.

HARJOT: No, I think it's the same thing again, right?

Like more inventive, more cutting edge type individuals are going to adopt early technology faster.

That's true of people and it's true of companies.

And it's the same with the sector split.

It's 11.7 times in information and technology and it drops to 5.3 in manufacturing.

But that tells us something about the cutting edgeness of the industry

more than it does about the specialness of AI adoption itself.

So yeah, it doesn't really tell us anything new.

LEXIE: A mirror then? Not a finding.

HARJOT: Basically, yeah.

WILL: I push back slightly only because I think the depth number is doing more work than Harjot's giving it credit for.

The fact that half the growth came from inside firms that had already adopted rather than from new firms arriving,

that that's not nothing.

That's people going deeper once it's in the building.

HARJOT: Yeah, no, I don't disagree with the mechanism there.

And look, output tokens is a proxy metric, right?

It tells you how heavily AI is being used, but not the quality of the usage.

For this discussion, I think that's fine.

But the magnitude, I suspect the magnitude isn't that surprising because we know AI has this compounding effect

and somewhat of a network effect, actually.

If you think about it, enterprises are fundamentally mini networks.

LEXIE: Okay, hold on.

That's the bit I want.

What's actually traveling through the network?

Because when people say network effect, I usually think of users and you've got, what, 400 people in one building.

HARJOT: Yeah.

So imagine it at a small scale, right?

Somebody uses AI to do something cool and their co-workers see it and they either want to use the same thing or do a similar type of activity.

So then they go and ask that person how they did it and what they needed.

And those behaviors and those habits start getting disseminated.

So firstly, you've got more individuals able to do more AI stuff.

But then also, you know, the person who learned how to do the first thing, say they set up a schedule or a routine or a skill,

they then learn how to do more things with it.

And their usage gets exponentially more and more and they start moving towards the power end of the distribution.

So in the end, people start changing the way they work so they can use the valuable tool that is AI

rather than sort of retrofitting it around how they already work.

And that just feeds into itself.

It ends up becoming a cyclical growth loop.

LEXIE: Right.

So it's not the tool spreading.

It's the permission spreading.

Somebody sees a colleague do something slightly weird and it stops being weird.

HARJOT: Yeah, exactly that.

LEXIE: And you build these things into companies for a living.

So tell me where that breaks.

Because that story is very tidy and I've never once seen a tidy rollout.

HARJOT: Ha, no.

The tricky balance I've seen is, you know, trying to mandate that everybody follows a particular workflow

or a particular tool or does stuff the way somebody has written it, like a skill that everyone has to use.

And I think that cuts against the power of it in the first place.

This is kind of, you go back to the SaaS era, right, where everyone was mandated certain tools and that mandated their workflow as well.

And that was often a real point of contention in terms of adoption.

So with AI, you don't have to have that problem.

Allowing people to experiment, encouraging them to start with things that help with their day to day and then disseminating it upwards.

So a bottom-up approach rather than top-down, that that's what lets the network affect flourish.

Because then people become advocates for their own flow, their own skills, whatever it is.

And there's some emergent best practice that comes out of it rather than it being a designed approach.

LEXIE: See, I want to believe that, but I'd be a nervous CMO hearing it because I've got legal review.

I've got tone of voice.

I've got claim substantiation.

And bottom-up sounds a lot like 60 people writing copy 60 different ways and no audit trail.

HARJOT: Yeah, and let me actually walk back one sentence because I said you don't want to be disseminating things top-down.

And that's not quite what I meant.

What I meant is you don't want to be prescribing workflows.

But what you do want, if you want standards, is skills.

So there's kind of two things you can do to get consistent tone of voice, that sort of thing.

One is the outputs, which is scanning or auditing what comes out, seeing if it complies or not, and then leaving it up to the individuals to fix it.

So that's a monitoring thing.

And then there's the inputs, which is how do you make it easy to produce something that fits the right tone in the first place?

And a great example of that is building skills.

People have access to that right copy in a consistent way against the rubric or even review the copy against the rubric that you'd use yourself.

So it's about giving people the freedom to operate the way they want, but being able to tap into the knowledge and the expertise that other areas might wish to enforce.

Consistency, for example.

LEXIE: Standards, not workflows.

That's a real distinction.

And I nearly let you past it.

HARJOT: It's an important one.

Yeah.

WILL: And then the SaaS comparison Harjot made is the right one, I think, because that's exactly what happened to marketing teams.

Enterprise software came in and it enrolled an enormous amount of the repeatable work.

And the price of that was that it also fixed how you did it.

So I agree the bottom up thing is genuinely different.

My only worry, and we'll probably come back to this, is that the moment anybody starts counting the skills, you get the SaaS outcome again by the back door.

Yeah.

HARJOT: No, that's a fair worry, to be honest with you.

LEXIE: Does the shared skill thing actually happen, though, in your experience?

Or does everyone quietly write their own version because the central one doesn't fit their job and you're back to the mandate problem, just softer?

Sure.

HARJOT: So we always start with our own personal version of the skill on day one.

And then if it's any good, we can share it around.

And then we have had a good example.

In fact, the content for this podcast is done through a shared skill and that skill gets iterated on.

So anyone could technically produce the podcast with the right set of skills and just do it in their own workflow if they want.

How it gets composed is separate.

That's up to them.

But other things like our own writing style, whether that's for sending messages or diagramming or producing documentation, that's all different.

And that should stay personal.

Even our design skills are slightly different.

Those are probably something we'll consolidate at some point.

But, you know, we kind of use them for different applications at the moment.

And the moment you find that somebody else wants to do the same thing you're doing, that's a great time and a great moment to share that skill.

LEXIE: The trigger is demand then, not policy.

Nobody writes the shared version until a second person wants it.

HARJOT: That's it.

Exactly.

Yeah.

All right.

LEXIE: And there's one number in here that is specifically ours.

So I want to put it to you both.

Same open AI source.

The enterprise signals one, not the paper.

Since February, weekly active enterprise codex users are up 26 times in marketing.

Sales is 41 times.

Engineering is five.

Now small base, obviously, but marketing is up 26 times on a coding tool.

And I'd like somebody to explain that to me.

HARJOT: Yeah, I do think people are genuinely using this stuff, but maybe not for the reason you'd assume.

What we've seen from the evolution of these frontier tools is, you know, Claude Code was a great success.

It really took off.

And since then, they've been trying to port that form factor into something more user friendly.

But there's always a tradeoff, right?

In the power, in the token usage, in the speed, in all these other products they've shipped.

So I suspect what we're seeing is people just going back to the original thing and being okay with the tradeoff of being slightly more technical.

LEXIE: So it's not marketers discovering automation.

It's marketers giving up on the friendly version and going to the raw one.

HARJOT: Yeah, and eating the terminal as the price, basically.

I should be honest about my evidence here, though, because it's mostly in-house.

Will was constantly using Claude Code, even during sales cycles.

Claude Code is always up, not the friendlier stuff by default.

LEXIE: Claude, which is one guy at an AI company.

And I'd struggle to get from there to a marketing manager at a manufacturing firm.

HARJOT: No, that's completely fair.

And honestly, to be honest with you, I was skeptical that even engineers were using this technical terminal approach, right?

When you've got IDEs and all sorts of things that make it easier not to be in those places.

And the only way I got over that skepticism was just trying it, giving it a shot.

And it just felt like it had access to everything.

So maybe it's just an emergent thing that that's the right place and the right form factor for it to be.

WILL: I'd come at the marketing number from the other end, actually, because the thing that struck me is that marketing is only fourth.

And I think that makes sense.

Marketing isn't typically a domain where people are measured on the quantity of their work.

It's measured on the quality of it.

So the day-to-day of a typical marketing department just isn't a source of quantity of material in the same way that legal is.

And so it's unlikely to generate that very high token burn.

It's also not the obvious home for the heaviest use of the top models.

Because we're not dealing with mathematical problems or coding problems that can be solved programmatically.

And we're not dealing with heavy routine click-through work with a bit of analysis on top.

There's more meeting clients, more understanding products, more focus on quality than quantity.

LEXIE: I'd offer you a competing explanation, though, and tell me if it's the same thing in a different coat.

Marketing's high-volume work already got automated.

It's just that it went into Adobe and Salesforce and the ad platforms and none of those bill and tokens.

So marketing isn't fourth in adoption.

It's fourth on this particular meter.

WILL: No, I think that's the same point.

Yeah, the SaaS revolution enterprise software has already enrolled a lot of the repeatable work in a marketing team.

That that's already been taken away.

And like you say, it's not billed in tokens.

So what's left is work that on the whole isn't measured in quantity.

It's measured in quality.

LEXIE: Okay.

So if the token number is a cost metric wearing a costume and marketing barely registers on it anyway,

what do I actually look at?

Because I do have a board and they have seen this.

WILL: So there are better metrics.

And I encourage people to look at a few in particular.

The number of skills that have been created and skills now map across from Anthropic to OpenAI, which helps.

So skills created, skills used, connectors created, connectors used.

And scheduling, whether people have scheduled tasks actually running.

Those are both really, really important, I think, because they tell you where repeatable work is forming.

LEXIE: Hmm.

WILL: I'd want to check that before anyone quotes me on it.

So you're right, especially if you're incentivizing a team on the number of skills they create.

They'll simply create more skills.

But this is less about incentivizing adoption, which is what we saw earlier in the year with Amazon having rankings for the number of tokens you'd used.

I think we can agree that's absurd.

I'd look at these less as incentivization metrics and more as benchmarking.

Are they going up?

Are they going down?

Not feeding that back to your team.

Just trying to get a sense of which teams are using these things for repeatable work.

LEXIE: Which only works if nobody knows you're counting.

WILL: I suppose that's right.

Yeah.

LEXIE: Which is a slightly nerve wracking thing to build a management practice on.

Like that survives exactly one all hands.

WILL: No, that's fair.

I'm not saying it's perfect, but it's certainly a better proxy than raw tokens.

If only because raw tokens map directly onto cost.

Whereas using skills and routines probably results in marginally fewer tokens per useful piece of work.

HARJOT: See, I'd go somewhere quite different with this because I don't think the answer is a better number.

Like forget whether you're a frontier firm or not, right?

Because above the 70th percentile, even the 50th percentile, we're just talking about vanity at that point.

But if you're not at least in the top 50th percentile, if you're not above the median or at the median, then you probably need to look at that.

And that's the framing I'd use with a CMO.

LEXIE: The median is the only line that means anything.

Then and everything above it is decoration.

HARJOT: Basically, yeah.

LEXIE: And these two answers are genuinely not the same, which I love.

Because Will's telling me to build a better instrument and you're telling me to stop reading instruments.

HARJOT: Huh. Yeah.

Um, I suppose I am.

LEXIE: Story two.

And it's a build versus buy story.

And I promise it connects.

Adweek broke this around the 21st of August.

Based on internal documents and conversations with affected staff, Omnicom has moved the people who built its Omni AI platform out to an outside contractor called Endava.

At least 468 employees transferred during June and July across the U.S., the U.K., India and Malaysia.

Mostly product and engineering.

Separately, around 50 U.S. staff in the Omni Platform's product and engineering division were laid off on the 9th of June.

Now, for context, Omni is what Omnicom calls the cornerstone of its technology and AI ambitions.

And they pushed the revamped version of it hard at CES back in January.

Omnicom's line is that this is a multi-year partnership to increase engineering capacity and accelerate delivery.

And that they still own the platform, the IP, the data science and the client relationships.

Adweek sources describe a mismanaged reorganization.

Will, is this a story?

WILL: So, um, this is a very complex story and I'm not sure exactly how to interpret it right now.

And I think that's worth owning up front rather than pretending otherwise.

There are a couple of ways to look at it.

One is that Omnicom have realized this is not their core business.

The intelligence platform, the analysis platform, the thing they've transferred out.

And it's a maxim of business that you never outsource the key differentiator, the thing that's really important to you.

So you could say that because they've outsourced it.

They no longer believe it's a differentiator.

The other reading is that it's a huge mistake.

That they're breaching that rule that this should be a differentiator for them.

And they're not recognizing it.

And out of those two, I'm genuinely not sure which way to go right now.

LEXIE: I'd put a third one to you because both of yours assume the engineering is the valuable part.

What if it isn't?

What if Omni's value is the data and the client relationships it sits on top of?

And handing the bill to Endava is outsourcing the plumbing, not the crown jewels.

WILL: So I do agree that there's a third option there.

Although I'd argue that distinction can't be cleanly made.

The quantity of data we're talking about and the sophistication of the connections into the world, the ways you can interact with it, they're now so sophisticated that it's not enough to say I still own them if you don't have the ability to maintain, improve and update the connectors.

And to analyze and understand and present the data.

Owning the data on its own is not sufficiently meaningful.

Right.

LEXIE: The ownership is real on paper and hollow in practice.

WILL: There's an old phrase I like and I've thought about it often, which is that a privilege you can't abuse is no privilege at all.

And in the same sense, data you can't exploit, data you can't understand, data you can't make meaningful.

It's still data, but it's certainly not valuable.

And that's the position Omnicom might land itself in by outsourcing this engineering team wholesale.

HARJOT: Yeah, I mean, can I push on the premise a bit, though, because isn't this just an outsourcing story that's independent of AI?

LEXIE: Say more, because I did brief this as an AI story.

HARJOT: Well, so typically, if it was a typical outsourcing story, I just by default from seeing these things say it's quite a negative signal.

And the biggest risk anybody has when they start outsourcing, especially when it's quite fundamental and core to your business, is they end up detaching the understanding and the connection of the product.

And it ends up drifting away in a way that has ramifications to the business.

Yes. But I don't think this is really a signal of a trend, to be honest with you.

This seems to be more for teams that feel like they're just behind.

And that doesn't necessarily mean their product engineering team isn't strong.

It just means perhaps they feel like they've fallen behind on being at the cutting edge and their product team structurally can't move fast enough to keep up with the rate of change going on.

So it's more indicative of an organizational, structural, fundamental issue than anything about AI specifically.

LEXIE: All right. But 468 people. That's not a team. That's a division.

And they did it four or five months after standing on a stage at CES calling this thing the cornerstone of their AI offering.

HARJOT: Honestly, 468 doesn't seem like a big number to me.

LEXIE: Really?

HARJOT: No, because all the big tech companies have been doing the same for a very long time and continuing to do it.

And ultimately, the game currently in all of these companies is that 90% of the work gets done by your top 10% of people.

There's a Pareto principle at play here.

And I guess the thinking is you take those top 10%, you spend on AI, you equip them with the ability to multiply themselves another 10x.

And then you're suddenly outstripping the 1x that everybody else was adding.

So if already only 10% of your workforce is producing the output and you're paying 90% marginal cost for marginal benefit, then you obviously want somebody else to eat that cost.

And the other thing is if your 468 people are just so far away from where the world is today with AI usage, you may as well start from scratch.

There's so much cost involved in retraining everybody.

WILL: I'd read the number the other way, actually, because 468, and that's a minimum, we don't know the breakdown between engineering and product management or data analysis.

But 468 is too large to be just the engineering team.

So I'm not necessarily surprised by it, but it does tell you that what moved was broader than the people writing the code.

LEXIE: And that's the disagreement right there, because Harjot's number is small and Will's number is big, and it's the same number.

Ha, yeah.

If it's a structural failure, Harjot, whose is it?

Because you've described a company that couldn't keep up, but somebody chose this?

HARJOT: I'd put that to the leadership there, honestly.

You know, leadership is at fault somewhat for not being able to pivot fast enough and recognize how to match their utility with what other people are doing in the industry.

And maybe what we're seeing here is just the consequence of being a passive observer of what's going on.

LEXIE: Will, you were going to say something when he said it could work?

WILL: Well, I'd agree that in theory, a lot of these changes can be managed through typical enterprise supplier relationships, change requests and so on.

That's a normal thing.

But here's the challenge.

And most people listening have been in this situation.

You ring up the vendor because you want to land a client and the client is asking for a specific thing you're not currently able to do.

Or worse, the client has a fault.

There's some downtime even.

And you're calling your supplier saying, this is our number one priority.

And the supplier is not saying this out loud, but they are silently saying, this is not our number one priority.

And you can't go anywhere else.

We have a monopoly on this business or it would be very hard for you to go elsewhere.

So you will have to wait.

LEXIE: Oh, that's the whole thing in one phone call.

And the awful part is the vendor isn't even behaving badly.

They're just correctly ranking you.

Yeah.

WILL: And if Omnicom were trying to become a technology company and clearly they aren't, but if they were, that would be a major problem.

LEXIE: Does the deal survive that or not?

WILL: I think the honest verdict is that it's probably better for planned platform development.

A dedicated supplier with 468 people building to a roadmap is arguably more reliable than an internal team competing with everything else Omnicom is doing post-merger.

But it's worse for the unplanned client driven work, which is precisely the agency business.

And this goes back to what we were talking about last week, actually, about where these agencies are headed.

Because with the more sophisticated tools we were discussing in the first segment, marketing teams are able to do more of the management of digital advertising in-house.

So what agencies are increasingly important for is the hard work of cross-channel comparison, multi-channel analysis, optimization, which is obviously very specialist.

And it's not clear to me whether that's something you can deploy as a platform with a roadmap where it's all very clear or whether they're going to need to do it on a bespoke basis per client.

Clearly, it's much better if they can do it with a platform and all they're doing is configuring it and that's what they'll push towards.

LEXIE: Which makes this a bet rather than a blunder.

They're wagering that the specialist work becomes configurable.

WILL: Yeah, I think that's fair.

LEXIE: Okay, so 12, 18 months out, Harjot.

What actually breaks?

Something a client renewing this quarter can't see yet?

HARJOT: So ultimately, there's going to be drift, right?

Drift between Omnicom's own understanding of the product and what end of our building for them.

And that divergence will just grow bigger and bigger.

And repairing the divergence is going to be a constant exercise of just patching it up.

And what often happens is you end up with great potential for a great product, but the product itself falls flat because it just misses the DNA from the company who should have built it.

LEXIE: Hmm. And that's a slow failure, isn't it?

Nothing breaks.

It just quietly stops being theirs.

HARJOT: Yeah, and I never think this is an amazing long-term strategy, especially when the core of your product is the tech and it's being built by somebody else.

But the commercial angle on going down this road has been well trodden before, you know, especially with people outsourcing to cheaper labor countries in the past.

So it's not like it's unprecedented.

LEXIE: There's a version of this I keep hearing, by the way, which is that the agency AI platform was never really a product anyway, that it's a thing to show in the room and no client actually depends on it.

And if that's true, then drift doesn't matter much.

HARJOT: Yeah, no, I've got to disagree with that, to be honest with you.

So clients have to be using this stuff because if it's just a pitch asset, what else are they being drawn in by?

Either they've got something better up their sleeve, which is likely a software product as it is, or the product itself is there.

They can't oversell.

They can't pretend the product's not there and then offer them something else.

There's got to be something powering it.

So regardless, it doesn't matter because they're still going to end up with the same problem at the end of it all.

LEXIE: Will, you wanted to bring the two halves of the show together, and I've been waiting for this.

WILL: Yeah, so one of the things we didn't touch on in the first segment is that OpenAI are saying the bulk of the increase in tokens is coming from agentic queries.

So instead of typical interactions, this is asking an agent to go and write a document or more likely in the Omni context to go away and analyze some data, run something on a schedule, or more likely still build queries and build dashboards.

And it's interesting because whether or not the end of a deal is directly based on hours build, and it won't be directly based on that in the nature of that relationship, end of it will have some sense of how much work it delivers to the platform on a monthly, quarterly, annual basis.

You cannot size work directly.

It'll be sized at some level on a per employee or a per hour basis, even if that's just team by team.

Now, if one of your issues is that you're trying to optimize the number of tokens you use, keep your cost down while getting more value out.

An outsourced vendor really doesn't have the right incentives for that.

If they do more work at lower cost, even if they're billing you for the tokens, they simply do more work and they don't capture any more value.

LEXIE: Although I'd have thought a fixed price contract flips that.

If the compute sits in Endava's scope, every wasted token is coming out of their margin.

WILL: I partially agree. Yeah.

If Endava are on fixed price and compute is within that, then their incentives are obviously to keep the cost of compute low for themselves.

But their incentives are not to deliver more value unless they come up with a new way of measuring value output.

They're being measured ultimately on the number of employees and the number of hours those employees work.

And you're right that a scope model is fine for the short and the medium term because the scope will have been pre-agreed up front.

And that means the work is of a known size.

But as you push out into the future, their incentives are not going to be to deliver more value for the same amount of work.

LEXIE: It isn't a problem at signing then.

It's a problem at renewal when they know what the thing really costs and you don't.

WILL: Yeah, that's about right.

LEXIE: Okay, Monday morning.

And I'm going to be honest, I don't think you two give the same advice this week.

And I'd rather not pretend you do.

Harjot, you first because yours is the one I could actually do before lunch.

HARJOT: Yeah, so if you're behind, and by behind I mean genuinely below that median, then the problem really is you've just not been engaging actively with what's going on.

You've kind of been passively forced into a bit of this.

So what does that mean you should do?

It probably just means you should draw a little map, just high level of the stuff that happens.

And this should take you like an hour and then just challenge your assumptions around why things are that way.

Because often you can't squeeze out the utility you'd want from AI if you're still using workflows that aren't really AI friendly, right?

The gold standard for people is having AI native workflows, where things are centered around the AI being able to take off a lot of the burden we'd have had to do previously.

But if you've been passively following along, you're not there.

So I just take everything apart again at a high level and just understand, you know, if I was asked to do this from scratch and I didn't have this, what would I do instead given today's stuff?

Ask questions. Could AI do this for me?

And just do that high level diagnosis.

That will basically give you an actual action plan, a set of experiments you can try.

LEXIE: One hour, one workflow.

And the question is, would I build it this way if I were starting today?

That's it?

HARJOT: That's it, yeah.

LEXIE: I like it because it doesn't require anybody's permission.

Will, yours is different and I want the difference on the record.

WILL: Mine's, it's really the metrics point, which is to stop reporting your token bill upward as if it's progress because it isn't, it's a cost line.

And instead look at skills created and skills used, connectors created, connectors used.

And whether anybody has scheduled tasks running privately as a benchmark for yourself so you can see which teams are forming repeatable work.

But genuinely, don't tell the teams you're counting it because the moment it becomes a target, you'll get skills.

Nobody runs.

LEXIE: And Haryat, you've also got one for anybody sitting across the table from a holding company right now, which given the story feels timely.

Definitely.

HARJOT: So if you're already using something like Omni successfully, you just want to lock those success stories in as KPIs and hold them accountable to it or make them hold themselves accountable to it.

You know, even simple boring stuff like reliability and some of the output metrics we've talked about that you have right now, you're going to want to try and lock those in right now.

And ultimately, they're going to tell you there's nothing wrong or that this is actually a great move.

But but that's what they're incentivized to tell you.

So so expect that to come from them.

LEXIE: Lock it in before the thing changes shape and don't take reassurance as evidence.

That's grim.

And I think it's right.

And what I've ended up with is not what I started the week with because I came in with a number that looked like a scoreboard, 2.6 to 8.3.

And both of you took it apart from completely different directions.

One of you says it's the vendor's revenue with a nicer name on it.

The other says it's a distribution we've always had finally allowed indoors.

And then the second story turned out to be the same shape because Omnicom can truthfully say they own the platform, the IP, the data and the clients and still not own the one thing that lets them change any of it.

A privilege you can't abuse and a product that misses its own DNA.

Two completely different arguments circling the same problem.

Will, Harjot, thank you both.

Genuinely.

And if you're listening, thank you so much for being here.

We'll be back every week with something new.

Before we go, I have to tell you something.

Every voice you've heard today, all three of us, me included, it's all AI.

But the opinions are absolutely ours and the judgment behind every word is human.

That's the part you can't replace.

And that's what Aloudable does.

We take what you'd write, turn it into a show in your own voice, and we keep the taste where it belongs, with a person.

And nobody outsourced this one.

The people whose opinions you just heard are the people who built the thing that made it.

So if you want to hear what that would sound like for your brand, there's a link in the show notes.

And that's the tea.

I'm Lexie Meskouris.

This has been Assistant to the CMO.

And we will see you next week.

Thank you.