Why Your Perfect Agent Generates Zero Results

A growing challenge facing middle market
CEOs is distinguishing between technical

functionality and business impact.

Unfortunately, you won't hear
a lot of trusted commentators

phrase it in this way.

What it looks like: we spent $200,000
on AI and we can't tell what changed.

Back in the day, I spent some
time working on a government

enterprise architecture project.

After the first draft, and a
series of presentations to key

stakeholders, we finally got some
time with the program manager.

Keep in mind, she wasn't
just overseeing our project.

She had an entire portfolio of
projects competing for her attention.

So she didn't have time to wade
through the mountain of documents that

combined to make up our architecture.

She needed to see what
was different, fast.

20 years later, the first words out of
her mouth, stick with me to this day.

What can I see that's changed?

Is there something you can point
to that has made my life better?

Not some document or pretty picture.

And in the business world, it's
gotta be hit the bottom line.

Welcome to the Enduring Advantage podcast.

I'm your host, Zachary Alexander.

Every AI implementation in your
business is doing one of two things,

generating a signal that makes your
next decision better, or generating

noise that results in work slop.

There's no third option.

So you say, what about the automation
that saves 20 hours a week?

If those 20 hours were spent by operators
making course correction and applying

uncaptured institutional knowledge to
keep the mission on track, then your

automation achieved nothing of value.

You eliminated the signal
and kept the work slop.

McKenzie's latest state of the AI
work shows that close to nine in 10

organizations now say they use ai, but
only about 6% see meaningful bottom line

impact that gap between claimed AI usage.

And profitable implementation is
what I call the 88 by six gap.

Now, the standard explanation
is that companies choose the

wrong tools or hire the wrong

Zachary Alexander: people.

I don't buy it.

The tools work for other companies.

The people have been
competent in other locations.

The problem is that 94% of
those implementations are pipes.

They move information from one
place to another, and nothing in the

organization gets smarter because of it.

Think about the nine out of 10 companies
that have AI running somewhere in

their business right now and almost
none of them can point to what

change it made to their bottom line.

Not because the technology
failed, because the technology

succeeded at the wrong thing.

It didn't learn, it produced outputs,
it didn't produce intelligence.

And for a middle market, CEO, who spent
decades building competitive advantage,

that's not just a missed opportunity.

That results in depreciating
institutional knowledge and you

get the privilege of paying for it.

Let me make that concrete.

You've got a sales team, your best
operator, someone who's been with the

company eight, maybe 10 years, gets
an enterprise renewal on his desk.

AI recommends standard pricing.

That's what the model says.

That's what the data supports.

He overrides it.

He approves a pricing exception
because he knows something.

The AI doesn't.

This customer's business plan has a three
year expansion pattern built into it.

Every time they renew, they grow into
two more divisions within 18 months.

the short term margin hit is a
down payment on a relationship

that triples in value.

He's seen it before.

He knows the pattern.

He makes the call that override is signal.

That's institutional knowledge
expressing itself in a live decision.

The AI didn't have it.

The CRM didn't have it.

It lived in his head, accumulated
after years of watching how those

relationships actually unfold.

Now, here's the problem.

What happened to that override?

Was it captured?

Did anything in your system record?

What just happened, why it
happened, and what the outcome was?

Or did it just disappear into
a closed deal in the CRM.

Undistinguishable from
every other renewal?

in most companies, it disappears.

The decision that contained the most
valuable intelligence your organization

produced that week looks exactly the same
as every routine transaction around it.

That's a symptom of the
signal to noise problem.

Now, imagine the alternative.

You deploy an automation that
handles the renewals, it applies

standard pricing every time, because
that's what the model recommends.

It's fast, it's consistent, it's
technically flawless and just

eliminated the one moment where your
institutional knowledge was being applied.

what's missing is the decision
trace when the operator overrides

the ai with informed institutional
knowledge, that's a decision trace.

It records what was decided,
why and what happened next.

Without it, the knowledge lives in one
person's head and it fully depreciates

the day she walks out the door.

The program director from 20 years ago
wanted to know what can I see has changed.

a decision trace is the one
thing that records the changes.

It turns invisible knowledge into visible,
queryable organizational intelligence.

It allows us to establish a pattern.

Without it.

You've got an automation.

With it, you've got a framework
for determining what survives.

Let's spend a little more time talking
about what a decision trace is.

It's not a log, it's not a report.

It's not another document added
to the mountain that nobody reads.

A decision trace captures the moment
where a human being applied judgment that

the AI couldn't replicate on its own.

It records four things.

What was the situation?

What did the AI recommend and
what did the operator actually

do and what happened next?

Those four things are the difference
between an organization that

accumulates adaptive intelligence
and one that just logs transactions.

Think about what your
company knows right now.

Not what's in the handbook, not
what's in the training materials.

The stuff that lives between the
lines, the way your best people read a

situation and make a call that nobody
officially trained them to make.

This is coffee break material.

This is the stuff that's discussed
at happy hours when people are

bragging about their latest win.

They learned it by being there,
by watching everything, by

getting burned and remembering.

Right now that knowledge has
one address, Somebody's head.

Every system in your business, your CRM,
your ERP, your shining new AI tools,

treats every decision the same way.

The routine transaction and the brilliant
exception look identical in your data.

There's no flag that says
this one needs to be studied.

This one contains something worth keeping.

A decision trace is that flag.

It separates the signal from the
noise at the point of origin.

The moment the decision is made, not after
the fact, not in a quarterly review right

then, and here's what makes it compound.

One decision trace is a data point.

But when you start capturing
them systematically.

Across your sales teams, across your
operations, across your customer

success organizations, patterns emerge.

You start to see which exceptions keep
working and which overrides produce

better results, which judgment calls
survive deployment in one context

and then another, and then another.

that's not a report someone writes.

That's adaptive intelligence

the organization generates as
a byproduct of doing the work.

And once you have it, every AI
implementation you deploy gets smarter

because it's drawing from what your
people actually know, not just what

your engineers choose to record.

The reason you don't see a lot of
commentators breaking it down this way

is that it's hard to find a slot for
decision traces on the balance sheet.

And the AI revolution won't
wait for GAAP to catch up.

You know, accountants love
to argue over treatments.

Here's something else that won't
show up on the balance sheet.

Institutional knowledge
is a depreciating asset.

Its value loss may not
trigger any bells or whistle.

It doesn't mean that it won't lead
to cascading catastrophic failures.

Your CFO can tell you the depreciation
schedule for every asset on the books.

the company vehicles
five years straight line.

The office furniture seven years.

That ERP system, you spent two years
implemented, amortized over 10 years.

they can tell you the useful life.

The salvage value, the accumulated
depreciation to the penny.

They run reports on it quarterly.

Now ask them this.

What's the depreciation schedule
on the institutional knowledge

your sales team carries?

What's the useful life of the
judgment your operations lead applies

every time she overrides a standard
process because she knows something

the system doesn't.

What's the salvage value when your
best operator retires and takes 30

years of pattern recognition with them?

Even though GAP doesn't let your
CFO put your star operators on the

balance sheet, the best CFOs already
are tracking their economic impact.

Revenue per employee human capital ROI.

Cost to replace a critical role:

recruiting, onboarding, ramp up time
succession coverage for key positions.

They've got proxies, they've got matrices.

They know which people drive a
disproportionate amount of value.

Unfortunately, these accounting treatments
were developed pre AI revolution.

So here's a question that separates
a 6% from the 88%, and it's not

which AI should we implement.

It's not how do we
prioritize our AI roadmap.

It's this.

Does your AI implementation make your
organization smarter every time it runs?

Most AI consulting firms right
now sell bolt-on optimization.

You take your existing processes,
you layer on AI on top of it, and

you make those less labor intensive.

The decisions still flow
through the same channels.

The org chart doesn't change.

You just added a faster engine to the
same car, and Bolton works technically.

It saves time.

It reduces error.

It s costs, it looks great
on a quarterly review.

The consultant shows you a dashboard
with efficiency gains on every node.

And that's the 88% AI is running
the implementation functions When

you run it, does it compound.

Bolt on optimization makes your
existing processes faster, or not.

Let's just agree that
it's less labor intensive.

It doesn't make your organization
any smarter than it was yesterday.

You are still using first gen
technologies, which is not to

say that it's going anywhere.

Technology never goes away completely.

I bet there are still companies
and small municipalities that

use fax machines for business.

However, you have to acknowledge
that using first Gen ai, like

using a fax machine is going
to make you less productive.

They've reached the end
of active development.

You might get security updates.

But nothing else is coming your way.

As a middle market, CEO, you probably
already have legacy systems that reached

end of life or something close to it.

Do you really want that
from your AI system?

The capabilities avalanche is
real, and every day you delay

introduction of AI native solutions
increases the blast radius.

Now I've been talking about operators
and overrides and decision traces, and

if you are a CEO listening to this, you
might be thinking, this sounds like it

only applies to my senior people, the
veterans, the ones with 15 years of

institutional knowledge in their heads.

It doesn't, everyone has a
role to play to explain why

I need to walk you through how
operators actually develop.

Because this is where even the best
AI management practices go sideways.

In AI native organization,
everyone is an operator.

Your sales team.

Your operational team, your developers,
your customer success managers, the AI

handles, the syntax, the implementation,
the execution, the processing.

Your people provide the guidance,
they keep the mission on course.

That's a human function
and it's universal.

But not all operators
are at the same level.

And this is where it gets critical.

At the foundational level.

Level 100, you get people who
are mission aware, they know

the vocabulary, they can follow
instructions, they can use the tools,

But they can't evaluate whether the
routine mission is actually on track.

They need supervision to know
if they're doing it right.

That's fine.

And that's where everyone starts,
and that's a training program.

And training solves it.

At the intermediate level, level 200.

You got people who are mission
capable, They can execute the playbook.

They know what normal looks like.

They handle standard
situations competently.

These are solid, reliable operators.

Most of your workforce is
probably at this level, and this

is where the wheels come off.

Because the next level, level 300 is where
an operator becomes a mission specialist.

That's the person who doesn't
just execute the playbook.

She owns the outcome.

When the edge cases
arrives, she doesn't freeze.

She doesn't escalate.

She makes a call based on judgment,
enriched by institutional knowledge.

She's the one who overrides the AI
on the price exception because she

knows the customers expansion pattern.

The gap between 200 and 300 between
mission capable and mission specialists

is what I call the 201 problem.

And here's where the best AI
management practices go wrong.

Every instinct tells you
this is a training problem.

Your intermediate operators are stalling.

Train them harder.

Motivate them more, hold them accountable.

Send them to a workshop, assign
them a mentor, give them a

certification to work on.

Not only do 80% of operators
stall at level 200 and never make

it to 300 through those methods.

Most will abandon the investment
made in AI and just three weeks.

And it's not because the training
is bad or the people aren't trying.

It's because the gap isn't a training
gap, it's an architecture gap.

Your 200 level operator
doesn't lack motivation.

He lacks the infrastructure that
will provide him with the adaptive

intelligence he needs to succeed.

What if your 200 level
operator faces an edge case?

The system surfaces a
relevant decision trace.

Here's how that situation
was handled before.

Here's who made the call.

Here's the rationale.

Here's what happened.

Not a training manual.

The actual institutional
knowledge from someone who

applied judgment and got it right.

That's not making your 200 level
people try harder to become 300 level.

That's changing what 200 level
operators have access to.

It means working knowledge
plus architectural access to

the institutional context they
haven't had time to accumulate.

And this is where the best practices fail.

If you're not paying attention, You
can follow every AI implementation

playbook on the market.

Prioritize use cases.

Measure ROI, manage change and
train your people and still lose.

Because if your architecture
doesn't bridge the 2 0 1 gap.

80% of your operators will
generate work Slop at best.

Work Slop is AI generated work
product that only looks like

it's doing something meaningful.

Your veterans may be generating
gold, but they're concentrating

on higher order workflows.

It's your two oh ones that validate
your systems operating correctly.

300 and above can do the majority
of what's required in their sleep.

They have so much experience
that they don't even notice

that they've skipped something.

You want the whole system to compound, not
just respond to intermediate and above.

Your veterans generate high value
decision traces through overrides.

The infrastructure, captures those
traces and surfaces patterns for

later use by your 200 level operators.

Those operators through their own
initiative can learn to function at 300

level and above based on time on task.

No additional classes are needed.

No additional investment
other than sweat equity.

The architecture provides
a context they lack.

They start generating better
decision traces themselves.

Those traces enrich the system
further and the cycle compounds.

Everyone has a role.

Your veterans provide
institutional knowledge.

Your infrastructure captures it.

Your next generation of
operators gets access to it.

Nobody's being replaced.

Everyone's being enriched.

Same people, same domain expertise,
enhanced architectural support.

That's not a training program.

That's an enduring advantage
that compounds every time

someone makes a decision.

So let me bring this home because
everything I've been describing, the

decision traces, the 2 0 1 problem, the
difference between Bolton and AI native,

it all comes down to one distinction.

Does it compound or doesn't it?

Let's discuss what compounding actually
looks like inside an organization.

Your operator overrides the
AI on a pricing exception,

that's a decision trace.

It gets captured.

What happened, why, what the outcome was.

That's one data point.

Valuable, but it's just one.

Three months later, a different
operator in a different region

faces a similar situation.

The system surfaces that decision trace.

Here's how this was handled before.

Here's the rationale.

Here's what happened next.

He reviews it, applies his
own judgment and makes a call.

That call gets captured.

Now.

You have two data points and a
pattern is starting to emerge.

Six months in your pattern has survived
deployments across multiple regions.

It started as an exception.

One operator breaking the rule because
he knew something that AI didn't.

It became a precedent.

Multiple operators applying the same
judgment across different context,

getting satisfactory results.

Eventually it becomes a policy
validated institutional knowledge that

the organization can codify because
it has the evidence to back it up.

Exception, precedent, policy.

That's how institutional
knowledge compounds.

Now I need to take a minute to explain
why this matters from an AI native

standpoint, because this is where the
infrastructure choice determines where

their compounding is even possible.

Most AI implementations today use
vector stores to retrieve information.

Think of a vector store, like a
search engine for your internal data.

You ask a question, it finds chunks
of texts that are most similar to your

question, and it hands them to the ai.

That's it.

One hop your question goes in
similar content comes out, And for

a lot of use cases, that works fine.

But here's what a vector store can't do.

You can't walk the chain.

It can't say, this operator made this
decision, which created this pattern,

which transferred to this region, which
survived deployment in this context,

which links to these three other
patterns that emerged independently.

That's not one hop.

That's four or five, and each hop
is a specific type relationship

in your organization, topography.

That's what institutional knowledge
looks like, and it is difficult to

capture with a vector database alone.

A graph does this natively.

Each relationship is an edge.

Each hop is explicit and queryable.

When you ask, show me which pricing
exceptions survive cross regional

deployment and what patterns they
link to, the graph doesn't infer

the answer from similar text.

It walks the chain.

. Start at the decision trace.

Follow the edge to the pattern.

Follow the edge to the transfer.

Follow the edge to the survival data.

Each hop is controlled.

Each path is traceable.

Why does this matter for compounding?

Because the exception to precedent, to
policy progression is a multi hop journey.

The exception is a decision trace.

The precedent is a pattern mode linked to
multiple decision traces across context.

The policy is a pattern that
survived enough hops across

organizational topography to earn
institutional classification.

A vector store can tell you what is
similar to your current situation.

A graph can tell you what survived,
show you the path it took to

get there, and here's the part
that becomes enduring advantage.

Every decision, trace adds a node.

Every pattern link adds an edge.

every cross context transfer
adds density to the graph.

The graph gets harder to replicate
with every cycle, not because

the database is proprietary, but
because the topography is earned.

Your competitor would need to
reproduce your organizational

structure, higher domain expertise.

Run the same experience, accumulate the
same decision traces, and watch the same

pattern, survive the same deployments.

That's not something you can
copy from a policy document

that's sweat equity in action.

Now, here's what your
competitors can replicate.

They can copy your policies.

Those are visible.

They can see what you do, but they
cannot reproduce the 18 months

of evolution that got you there.

They don't know which
exceptions you tested.

They don't have the decision traces
that showed which ones survived

and which one you even started.

Now contrast that with Bolton solutions.

You deploy an automation,
it saves time, it processes,

transactions quarter after quarter.

It does the same thing.

It doesn't get smarter.

It doesn't surface patterns.

It doesn't evolve exceptions
into precedence, into policy.

Not everyone enters the survival
mode at the same time, some people

come to the conclusion early,
which causes others to follow.

A year from now, the bolt-on
implementation is worth exactly

what it was the day you deployed
it, minus whatever maintenance

you're paying to keep it running.

What about the AI native implementation?

A year from now, it's captured
hundreds of decision traces.

Dozens of patterns have emerged.

Some of those patterns have
survived cross context deployment

and are becoming precedents.

a few are ready to become policy.

The system is measurably smarter
than it was 12 months ago.

Not because you upgraded the
technology, but because your people

generated institutional knowledge
as a byproduct of doing their work.

That's what compounding looks like, and
that's what the program director was

asking for 20 years ago, not a document.

Not a pretty picture, something she
could point to and say, this has changed.

This is better.

This is different because of the
work we did, The bottom line moved

because the organization got smarter.