RSS Amplifier

Don't Feed The Algorithm · Aug 8, 2026

Your Employees Don’t Need to Learn AI. Their Workflows Do.

0
Sign in to vote or save

Zach Chmael · Don't Feed The Algorithm

I have built my own company Slack where nearly everyone else is an AI agent.

I run work through Hermes, keep structured memory in Obsidian, use Claude Code to build products, and have opinions about context windows that would make a normal person quietly change seats.

This makes me absurdly useful in certain situations.

It also makes me an absolutely terrible model for enterprise AI adoption.

Most employees do not want to maintain skill files, route tasks between models, or develop a sophisticated philosophy about when to clear context. They want the invoice processed. They want the campaign brief finished. They want the customer question answered without spending twenty minutes copying information between systems that have apparently never been introduced.

The biggest mistake companies make with AI is turning the behavior of their most obsessive power users into the rollout plan for everyone else.

Give everyone a license. Schedule prompt training. Recruit a few evangelists. Put monthly active users on a dashboard. Wait for productivity to happen.

Then six months later, a small group is running agent fleets before breakfast, another group is using the tool to rewrite emails, and most people have forgotten which tab it lives in.

The dashboard says adoption.

The work feels suspiciously familiar.

I started thinking about this after reading Vasuman Kilaru’s X article, ”AI Adoption is a Myth”

X avatar for @vasuman

vas@vasuman

https://t.co/haApURmzAN

7:12 PM · Aug 7, 2026 · 344K Views

84 Replies · 123 Reposts · 1.52K Likes

He describes a pattern from Varick’s enterprise work… a small slice becomes deeply AI-native, a larger slice uses the tools weakly, and many employees barely use them at all.

His exact distribution comes from Varick’s own observations, not a universal benchmark. But the shape feels right because the incentives are obvious.

The people pushing hardest for AI inside a company are usually the least representative people in it.

They are curious about the technology itself. They will tolerate broken interfaces because the underlying capability interests them. They spend nights and weekends learning what the model does well, where it fails, how much context to provide, which workflows deserve deterministic software, and how to review an answer that sounds finished but is not.

They enjoy the craft.

Most of the company did not apply for that craft.

This does not make everyone else lazy, resistant, or doomed to wander through the future carrying a paper calendar. It means they were hired for finance, sales, recruiting, customer support, operations, design, or marketing. AI may change how those jobs work. It does not follow that everyone performing them needs to become a tiny AI consultant.

Power users are still enormously valuable. They explore the frontier, discover useful patterns, and show the company what is possible before the org chart knows how to describe it.

But they are scouts.

You should not make the whole company live like the expedition.

“Adoption” sounds like a business outcome. Most of the time, it is an activity count wearing a nicer jacket.

Did the person receive a license?

Did they log in this month?

Did they send five prompts?

Did one team report using AI in at least one business function?

Those questions describe exposure and activity. They tell you almost nothing about whether work changed.

McKinsey’s 2025 State of AI report captured the contradiction neatly… reported organizational use had become widespread, while most respondents still reported no material earnings impact from generative AI. That does not mean the tools are useless. It means “someone used AI somewhere” is a very generous definition of transformation.

A useful measurement ladder looks more like this:

Could the person use the tool?

This is a permission question. Licenses, connectors, security approval, and account availability live here.

Did the person invoke it?

Logins, prompts, sessions, token volume, and weekly active users live here.

Can the person use it reliably for a defined job?

This requires a task, a quality bar, and some way to tell whether the output is correct. “Uses Claude” is not a capability. “Can turn a transcript into an approved customer brief with every factual claim linked to the source” is.

Did part of the work move from manual effort into reliable assistance or automation?

Now we can ask what share of a workflow is still performed manually, what the system prepares, which actions it completes, and where a person must re-enter.

Did cost, speed, quality, risk, employee capacity, or revenue change?

This layer needs a denominator, a cohort, a baseline, and enough honesty not to attribute every pleasant quarter to the chatbot rollout.

Most AI dashboards stop at level two because levels one and two are easy to instrument.

The company can prove that 4,000 people had access and 2,100 opened the product. It is much harder to prove that the monthly close became two days faster without increasing correction risk, or that sales reps created better account plans rather than simply creating more of them.

Harder does not mean optional.

If the metric cannot distinguish “opened the tool” from “changed the work,” it should not be presented to the board as evidence of transformation.

There is a slightly uncomfortable tendency to talk about AI as if the interface made the skill disappear.

There is a text box. Everyone can type. Therefore everyone can use it.

Sure.

There is also a shutter button on a camera. This has not made everyone Annie Leibovitz.

Using AI well requires judgment before, during, and after the model produces something. You need to know what context matters, what information the model may receive, what the output should look like, how to test it, when to use normal software instead, and which consequences still require a person with a name.

I learned this while using Claude Code to build products. It is trivial to point a model at a repository, paste a ticket, and watch many colorful things happen. It is much harder to define the files it may touch, specify the behavior, create the right test, inspect the diff, catch the unrelated change, run the actual user path, and decide whether the feature is safe to ship.

That is why I wrote about using Claude Code without pretending faster implementation made me an engineer. The model expanded what I could direct. It did not inherit responsibility for what the product could break.

The same is true in every function.

A marketer can generate a campaign in seconds. Someone still has to know whether the claim is true, whether the audience cares, and whether the result sounds like every other company currently yelling “AI-powered” into the void.

A finance team can classify invoices faster. Someone still has to define the exception policy, approval threshold, audit trail, and response when the vendor, amount, or account does not match.

A recruiter can summarize candidates. Someone still has to decide what evidence belongs in that judgment and what sensitive information should never enter it.

The text box did not eliminate the work.

It moved the work into specification, verification, exception handling, and accountability.

One of the strongest studies on AI at work did not ask thousands of employees to become prompt engineers.

Researchers Erik Brynjolfsson, Danielle Li, and Lindsey Raymond studied the introduction of a generative AI assistant across 5,179 customer-support agents. The tool increased issues resolved per hour by 14% on average. Novice and lower-skilled workers improved by 34%, while experienced workers saw minimal impact.

The interesting part is not only the average productivity gain. It is how the capability reached the worker.

The assistant sat inside a defined workflow. It helped agents respond to real customer problems and appeared to spread patterns from stronger workers to newer ones. The job, context, and performance measure already existed. The employee did not have to invent a use case, construct an agent, or become fascinated by model behavior.

That is a much better model for making AI useful across a company.

The company embedded assistance where the work already happened. The worker remained responsible for the customer interaction. The system made useful expertise easier to access.

This is very different from dropping a general-purpose chatbot into the organization and asking every employee to discover their own path to value between meetings.

One approach redesigns the work.

The other distributes homework.

Trying to force every employee into the same AI behavior creates a bad compromise. The power users feel constrained by a generic tool, while everyone else gets an intimidating blank box and a training deck they will never open again.

A better company has two connected strategies.

Give the power users room to experiment.

They need broad tools, safe sandboxes, access to models, technical partners, reusable context, clear data boundaries, and somewhere to publish what works. Reward them for turning private advantage into organizational capability.

This last part matters. A clever workflow trapped on one person’s laptop is personal productivity. A reviewed, installable, maintained workflow with an owner and a measured job can become company infrastructure.

Status may work better than moral appeals here. Let people earn recognition for the workflows other teams adopt, the hours removed, the errors caught, or the systems made easier to operate. Make sharing part of the reward rather than an act of charity performed after the power user finishes their actual job.

I have written about building an agent workspace with explicit channels, memories, permissions, and stopping rules. That level of machinery can be useful for the people designing systems.

It should not become the minimum interface required to submit an expense report.

For everyone else, put AI inside the workflow they already understand.

The new interaction should often be mechanically simple:

- approve;

- reject;

- edit;

- escalate;

- inspect the evidence.

An accounts-payable analyst does not need to prompt an agent to inspect every invoice. The system can extract the fields, match the vendor, check the purchase order, flag the exception, and preserve an audit trail. The analyst handles the judgment the system cannot safely make.

A sales rep should not have to explain the entire company to a blank chat every Monday. The system can prepare the account brief from approved sources, show what changed, link the evidence, and ask the rep to correct or approve it.

A marketer should not need seven clever prompts to turn a customer call into usable intelligence. The workflow can ingest the approved transcript, extract claims and objections, attach timestamps, and route the result to the right person for review.

The employee still matters. In many cases, their judgment matters more because less of their time is being consumed by clerical motion.

But the interface no longer asks every person to become good at the machinery behind it.

Prompting became the symbol of AI work because chat was the first interface most people understood.

It is a powerful interface. It is also a strange default for repeatable organizational work.

Imagine asking employees to query the payroll database by writing natural-language requests every two weeks. Or telling a warehouse team that inventory management now begins with an open text box and a company-wide prompt contest.

We would call that unfinished software.

Yet companies routinely treat a blank chat as the completed interface for AI transformation.

A prompt is useful when the job is exploratory, ambiguous, creative, or genuinely benefits from conversation. It is less useful when the same trigger, context, rules, and output repeat every day.

Once a workflow is understood, the prompt should often disappear into the system. The employee should encounter the prepared work, the exception, the evidence, or the decision.

That does not mean hiding AI so completely that nobody can inspect what happened. Background automation without visibility is how small mistakes receive enterprise distribution.

The system should make the consequential parts legible:

- what triggered the work;

- which sources it used;

- what the model changed or produced;

- how confident or uncertain the result is;

- what rule caused an escalation;

- who approved the action;

- how to correct it;

- what gets preserved for audit and learning.

The machine can move into the background.

The accountability cannot.

Stop beginning the review with “How many employees used AI?”

Choose one recurring workflow and measure the work itself.

The unit should be something the business actually recognizes: invoices processed, support cases resolved, briefs approved, accounts researched, claims reviewed, candidates screened, contracts routed, campaigns launched, or reports completed.

For each workflow, create this ledger:

| Field | What to record |

| Workflow | The specific recurring job, with a start and a completed outcome |

| Denominator | Total units of work during the measurement period |

| Cohort | Team, role, market, customer type, or other population included |

| Baseline | Manual cycle time, cost, error/rework rate, and quality before the change |

| Manual share | Units completed entirely through the prior human process |

| Assisted share | Units where AI prepared work and a human completed it |

| Automated share | Units completed without manual initiation |

| Human gate | The exact decision a person must approve, reject, edit, or escalate |

| Exception rate | Share requiring intervention outside the normal path |

| Rework rate | Share corrected after AI produced or completed the work |

| Cycle time | Time from valid trigger to accepted outcome |

| Unit cost | Human time plus software/model cost per accepted outcome |

| Quality | The job-specific acceptance or accuracy measure |

| Outcome | The business result the workflow is supposed to influence |

| Attribution caveat | Other changes that may have affected the result |

| Review trigger | The date, threshold, failure, or policy change that reopens the design |

The categories should be boringly precise.

“Hybrid” is not enough. Did AI draft the work? Recommend the decision? Execute the action? Did a human inspect every unit or only exceptions? What exactly counts as complete? If the output was rejected and redone manually, does the dashboard still count it as an AI success?

Then compare a cohort or time period against a real baseline.

Do not celebrate that 60% of invoices “touched AI” if the exception rate doubled, the analysts spent more time correcting vendor fields, and the monthly close did not move. Do not declare victory because people generated twice as many campaign briefs if the approval rate fell and no additional campaigns shipped.

Activity is evidence that something happened.

It is not evidence that something improved.

I would keep access and activity metrics. They are useful operational signals. I would stop letting them carry a story they cannot support.

Instead of:

72% of employees used our AI tools this month.

A hypothetical report might read:

In the North American support cohort, AI assisted 61% of 18,400 eligible cases. Accepted resolution time fell from 11.2 to 8.9 minutes. Reopen rate remained within 0.3 percentage points of baseline. New agents saw the largest improvement. Escalations involving billing disputes still require human review. We have not yet established an effect on retention.

That statement is less cinematic.

It is also useful.

It gives the denominator, cohort, eligible event, baseline, quality constraint, human boundary, and causality limit. A leader can inspect it, challenge it, and decide whether the workflow deserves more investment.

The purpose of measurement is not to make the rollout look inevitable.

It is to tell the company where the system works, where it fails, and what should happen next.

I do not think prompting will disappear. I do not think training is useless. Companies should expose people to the tools, identify natural power users, teach basic judgment, and give interested employees a safe way to go deeper.

But “everyone becomes AI-native” is not a serious operating plan.

Some people will become extraordinary at directing models. Some will use a few useful features. Some will never care about the machinery and will still be excellent at their jobs.

The company does not need to flatten those differences.

It needs to design around them.

Let the power users explore, build, test, and publish. Let domain experts define the work, exceptions, and quality bar. Let product, engineering, security, operations, and legal turn the successful patterns into systems people can trust. Let employees interact with those systems through the smallest interface the job requires.

Then measure whether the work changed.

The point of enterprise AI is not to create five thousand miniature AI consultants.

It is to let the people who understand the technology redesign the work, then ask everyone else for judgment where their judgment matters.

Stop asking how many employees adopted AI.

Ask how much work changed, who benefited, what it cost, what broke, and whether the result was any better.

What is one workflow at your company where “AI adoption” looks healthy but the work itself has barely changed? Reply and tell me. I am especially curious about the denominator nobody is measuring.

-zc

P.S. If you want more essays about AI systems, human judgment, and the mildly chaotic work of making new technology useful after the demo ends, subscribe to Don’t Feed The Algorithm.

- ”AI Adoption is a Myth” by Vasuman Kilaru](

X avatar for @vasuman

vas@vasuman

https://t.co/haApURmzAN

7:12 PM · Aug 7, 2026 · 344K Views

84 Replies · 123 Reposts · 1.52K Likes

— the enterprise field observation that sparked this essay, especially the split between power users and everyone else. Treat the percentages as Varick’s reported pattern, not a universal law.

- ”Generative AI at Work” by Erik Brynjolfsson, Danielle Li, and Lindsey Raymond) — a field study of 5,179 customer-support agents showing why embedded assistance, defined tasks, and worker-level differences matter more than generic adoption claims.

- McKinsey’s *The State of AI: How Organizations Are Rewiring to Capture Value) — useful for the gap between widespread reported use and material business impact, plus the organizational practices associated with value.

- Your AI Strategy Is a Management Problem) — my earlier argument that the hard part is deciding what AI owns, what humans own, and how the system learns.

- I Built My Own Company Slack. Everyone Else in It Is an AI Agent.) — the power-user extreme: channels, memory, permissions, stopping rules, and why none of that should become the required interface for the average employee.

No posts

Read the original on zchmael.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.