Somewhere inside Meta last winter, an engineer reprocessed a batch of documents that didn’t need reprocessing. He knew exactly what he was doing. He was climbing a leaderboard. The company had built an internal board ranking more than 85,000 employees by token consumption, with titles like “Session Immortal” and “Token Legend,” and he had figured out the fastest way to the top. In thirty days the company burned 60.2 trillion tokens, a sum that would run roughly $900 million at standard rates. Gergely Orosz reported the whole thing before Meta quietly discontinued the board.

One engineer guessed the real point was harvesting training data. The simpler reading is that Meta told its people that using AI a lot was the same as being good at it, and its people, being good at their jobs, got very good at using AI a lot.

Orosz has a name for this. Tokenmaxxing: inflating token usage to look productive, the way an earlier generation of engineers gamed lines of code. It’s a funny story until you notice that the same instinct runs every AI scorecard in the building. We are measuring the activity because the activity is easy to see, and then we are reading the activity as if it were the result.

If you lead a team or a company through this, the numbers you’re using to judge your AI program are probably doing the same thing. Usage is up, adoption is up, headcount is down, the dashboard is green. And none of those numbers can tell you the one thing you want to know, which is whether the work got better. That gap, between the metric and the meaning, is where most AI strategies are quietly failing while reporting success, and where the few real breakthroughs hide too.

Return on subtraction

The cleanest number to show a board is a smaller payroll. So that is the number companies show.

Gartner studied 350 executives at billion-dollar companies and found that 80% of organizations deploying autonomous AI had already cut their workforce. Here is the part that should stop you: those reductions had no correlation with higher returns. The layoff rates among companies reporting strong ROI were nearly identical to the rates among companies seeing none. Cutting people produced budget room, and the budget room got booked as if it were the value.

This is return on subtraction, and it’s seductive because subtraction shows up in a way improvement doesn’t. You can put “reduced team by 12%” on a slide. You can’t as easily put “the work our remaining people do is now sharper,” because that requires judgment about output, and judgment is slow and arguable and doesn’t fit in a cell. Sam Altman has a phrase for the cover story: AI washing, where a company pins a layoff on automation when the real reasons were something else. The automation becomes the press release, the savings become the ROI, and nobody checks whether the AI did anything.

Gartner’s own read is that the organizations getting real value treat AI as a way to amplify their people. They invest in oversight and upskilling, the unglamorous human scaffolding. Those investments are real, and they’re working. They’re also hard to fit on the same slide as a headcount number, which is exactly why they lose the argument inside most companies.

The usage trap

When you reward people for using a tool, they will use the tool. Whether the tool is helping is a separate question, and it is the question the usage number cannot answer.

Salesforce set minimum monthly AI spend targets for its engineers, then removed the caps to “eliminate friction,” and developers promptly began requesting projects for no reason but to burn the quota. Microsoft’s consumption dashboards bred the same theater: engineers reprocessing documents and prototyping features nobody meant to ship, all to avoid looking insufficiently AI-native. The behavior was rational, and it was waste dressed as adoption.

The workplace data confirms what the gaming stories imply. ActivTrak’s 2026 report found AI adoption at 80%, and also found that every category of work expanded after AI arrived: email volume up 104%, messaging climbing alongside it, and not a single category of work shrinking. The tools were supposed to take work off people’s plates. Instead they added a layer on top. The lived version of that statistic is the marketer who spends the morning in an AI tool spinning up campaign variants, then loses the afternoon to the flood of email and review threads those variants set off.

ActivTrak located a genuine productivity sweet spot, workers spending 7 to 10% of their hours in AI tools hitting 95% productivity, but only 3% of employees were in that band. The rest were either barely touching the tools or drowning in them. Adoption was nearly universal. Effective use was a rounding error.

I have watched this from the other side. At Typeface my team had Claude Code, ChatGPT, and a dozen other tools open all day, and a real part of the leadership job was pushing people past the comfortable edge of what they used them for. Most stayed where it was safe. A few didn’t, and there is no looking back for them. They have become the people who challenge whatever the current solution is and keep dragging the rest of us forward.

What set them apart was never how many tokens they spent. The tokens were an artifact. The shift came when someone started with a genuine problem and wanted a 10x answer to it instead of a 10% one. Reward the token count and you breed tokenmaxxing. Reward the hunger for a 10x solution and the usage takes care of itself, and you cannot run that causation backward, which is exactly what every usage dashboard tries to do.

Shopify is the one company in this set that seems to have understood the trap. It celebrated heavy AI usage only when it was paired with great work, renamed its leaderboard a plain “usage dashboard” to kill the competition it was breeding, and started looking at which tokens cost the most rather than counting raw volume. That last move stops short of measuring quality, but it points the right direction: away from the activity number and toward what the spend was buying. The question still waiting at the end of that road is what got better because the team used AI, and answering it means being willing to look at the work.

The number that depends on who you ask

Even the adoption rate, the headline figure everyone quotes, falls apart the moment you ask how it was built. Three federal surveys measured AI adoption in the same economy at the same time and came back with 18%, 41%, and 78%, depending on whom they asked. And even the friendliest number is shallow: 41% of workers say they use AI at work, but only 12% touch it daily. Adoption counts who logged in and says nothing about who got good. Every triumphant percentage you have read papers over that gap.

So we have three different illusions feeding the same dashboard: layoffs that read as ROI, usage that reads as productivity, adoption rates that read as transformation. Each one measures something real and easy to count, and none of them touches the thing that matters.

What I learned trying to measure “good”

I build content infrastructure at Typeface, so this stopped being an abstraction for me a while ago. Making quality measurable at scale is the problem I spend my days on, and being on the building side of it taught me why the easy numbers always win.

I see it most clearly in what those people went on to build. They came back with things no straight line of coding would have produced. One carried a design from one format to another at a fidelity hand-written code never reached. Another cracked web and email layout problems that had resisted us for years. A third compressed a brand’s whole identity into something a system could carry. A designer rebuilt an entire app himself, because he now could, with none of the loss that usually creeps in when requirements and taste have to be handed from the person who holds them to the person who builds.

What every one of these shares is that no quantitative measure captures the impact. I can tell you each saved us weeks and opened a non-linear path we would not have found otherwise, but I cannot hand you the number that proves it, because there isn’t one. The value is qualitative, and reading it means sitting with the work, not watching a gauge. There is a time for metrics, and this isn’t it. Forcing a number onto this kind of impact would measure the wrong thing and miss the point.

The same gap shows up the moment I turn from my own team to our customers. The conversation I keep having goes like this. An enterprise marketing leader tells me the AI content tools they tried weren’t good enough. I ask how they were measuring quality. There’s a pause, and then: “We could just tell.” That answer is honest, and it holds up fine when a team ships five pieces of content a month. At five hundred, gut feel stops scaling, and the team falls back on the only instruments it has, the ones that count volume, throughput, and spend. None of those can see whether the work is any good. They measure motion because motion was the easy part to instrument.

So the work becomes building the instrument that leader never had: a way to judge quality that doesn’t run on one person’s gut and doesn’t collapse at five hundred pieces. What surprised me is which part is hard. The legible dimensions go first and go fastest. You can teach a system brand voice fidelity, claim accuracy, tone, whether a piece stays on message. Encode the rule, check the box. The trouble is that every time we made one dimension measurable, the thing that actually mattered slid one level up, out of reach of the rule we’d written. The hardest case is the piece that clears every check and a human still reads it and feels nothing. There’s no rule for that yet, and the teams claiming they’ve automated it away are working on a smaller problem than they think.

The lesson that survived all of it is simple to say and slow to build. The metric has to point at the output rather than the activity, and a person who knows what good looks like has to stay in the loop, close to where the work gets made. Volume dashboards are cheap to stand up, which is exactly why so many teams end up managing by them. The instrument that earns its keep, the one that tells you whether the content deserved to ship, is the one nobody builds by default, because it’s slow and human and hard.

What the dashboard cannot see

Pull the three failures together and they share one root. Every metric that misleads here is a metric of motion: heads removed, tokens spent, seats logged in. What none of them captures is whether any of that motion improved the actual output, because output quality is a judgment, and judgments are precisely what a dashboard is built to avoid. And it cuts both ways. The same dashboard that cannot tell you the work is hollow cannot tell you when someone has done something remarkable: the non-linear leap, the week saved, the app rebuilt because one person no longer had to hand their taste to anyone else. Failure and breakthrough are equally invisible to it, for the same reason: both are judgments about the work, and the work is the one thing the dashboard never looks at.

Call it the measurement mirage: a dashboard that answers every question except the one that matters. Did the work get better?

This is the through-line of everything I have been writing about this spring. I argued a few weeks ago that enterprise AI produces beautiful empty rooms, systems that run flawlessly while nobody can say whether what they produce is any good. The measurement mirage is how the room stays empty without anyone noticing. The lights are on, the meters are spinning, the chart points up. The one instrument missing is the one that would tell you the work is hollow.

This is why organizations reach for the proxy. Counting tokens is easy. Counting layoffs is easy. Deciding whether a piece of work is good enough to put your name on requires a human who knows what good looks like, and that human is expensive, slow, and cannot be fully automated. The proxy is cheap and fast and feels objective. It’s also measuring the wrong thing, and the gap compounds every quarter you trust it.

The human premium, the thread running through this whole series, lives in that gap. The judgment that decides whether the output is worth shipping is the part AI cannot yet supply and the part no dashboard can render. When the dashboard tracks motion, the quality of the work goes unmeasured, and the one capability that still separates a company doing real work from a company generating expensive noise gets steadily priced down.

The question worth asking

The fix lives in the work itself. Someone has to sit with what the team shipped and decide whether it got better.

The leaders getting real value have made a quiet switch. They replaced the usage question with a harder one: did the output improve? Shopify asks which tokens earned their keep. The Gartner leaders invest in the humans who oversee and refine the work. In both cases somebody decided the activity number was a distraction and went looking for the harder answer.

Tomorrow morning, before you read another AI usage report, try the test that no dashboard runs for you. Pick one thing your team shipped with AI this week and ask whether it was better than what they would have shipped without it. If you can answer that, you are measuring the right thing. If you cannot, the green chart on your screen is a mirage, and the desert it is hiding has been there the whole time.

This is the first essay in The Human Premium, a series on what stays valuable when AI handles everything else. The bridge essay, Foraging: The Prestige, introduced the thesis.

A VP of Marketing I spoke with recently had done everything right on paper. Her team deployed a content platform with brand knowledge wired in, quality evaluation on every asset, automated workflows across four markets. The infrastructure was genuine. Six months in, adoption was at 18%.

She understood the technology. What stumped her was the people. “The platform works. I’ve used it myself. But my team runs the old process alongside it, and I can’t figure out why.”

We started working through it together. Does the approval screen show reviewers what the system considered and where it was uncertain, or does it just present a finished asset? When the UK team discovers that a messaging angle resonates, does that insight reach APAC automatically? When the best content strategist built a workflow that cut production time in half, did the rest of the team inherit it?

She already knew the answers. Three no’s.

If you’re deploying AI at organizational scale, you’ve probably felt at least one of these.

Over the past few months, I’ve written about three problems that keep surfacing in enterprise AI deployments. The infrastructure gap between generating content and operating a content system at scale. The experience gap between building for agents and building for the humans who oversee them. The coordination gap between one person’s AI workflow and an organization’s collective capability. The infrastructure gap is what I work on at Typeface. The experience and coordination gaps are what I see in every deployment conversation.

I wrote about each one separately. What I didn’t see clearly until watching deployments like hers is that they form a compound: solving any one or two without the third is why most enterprise AI deployments plateau. Understanding how these three problems interact matters more than evaluating any individual tool.

How the problems compound

These three dimensions form feedback loops. When one is missing, it actively degrades the other two.

Infrastructure without coordination produces what I think of as the ghost system. You invest in a content operating system. Brand guidelines are encoded. Workflows are automated. Quality evaluation runs on every asset. But the 40-person marketing team wasn’t involved in defining those workflows, and the regional teams have approval norms the system doesn’t reflect. The platform is capable and the organization is foreign to it.

Usage clusters around the 3-4 people who helped configure it. Everyone else routes around it. This is the most common failure mode I see. Without shared governance across the organization, the system serves a few power users while everyone else maintains parallel processes. The tell: dashboards show that the majority of content is still being produced outside the platform, or the same asset gets created twice because teams didn’t know the system already had it.

Coordination without the right experience layer produces rubber-stamping. You get the whole team onto the platform. Everyone has access. Governance structures exist. But the translation layer between AI output and human judgment is missing. A regional marketer adapting a campaign for Germany sees the final asset but nothing about why the system chose that angle, what alternatives it considered, or where its confidence was low. She spends 90 seconds on a decision that deserves five minutes, because the screen doesn’t support better judgment.

This failure mode is quieter and more dangerous. The adoption numbers look strong. But the quality of human oversight is eroding because the product surface discourages careful review. The team achieved coordination on a foundation that undermines good decisions. It shows up when approval turnaround gets faster but error rates creep up, or when reviewers start clicking “approve” without opening the full asset.

Experience design without infrastructure produces beautiful empty rooms. You build thoughtful oversight screens, progressive trust controls, rich context around every decision point. But brand knowledge isn’t structured underneath. Performance data doesn’t feed back in. The interfaces are elegant but surface shallow information, because the systems behind them don’t supply anything deeper.

The hardest pattern to spot, because the product feels good. Users find it intuitive. But the decisions they’re making are uninformed: the knowledge layer and measurement loops that should power those surfaces haven’t been built. The giveaway is when the team loves the interface but the outputs feel generic, or the same mistake appears across campaigns because no learning loop corrects it.

Why solving them in order fails

The natural instinct is to sequence: infrastructure first, then experience, then coordination. Build the system, design the surfaces, get the team on board.

This sequence is logical and wrong.

By the time you’ve spent six months on infrastructure, the team has developed habits around the old process. The coordination problem has hardened. And the experience layer was designed without input from the people who will actually use it, because they weren’t using the system yet.

Microsoft’s 2026 Work Trend Index surveyed 20,000 workers across 10 countries and found that culture, manager support, and talent practices determine whether companies get real value from AI more than individual skill or tooling. That finding makes more sense when you see these three problems as a system rather than a sequence.

The leaders I’ve watched break through do something counterintuitive. They work on all three simultaneously, in thin slices.

Instead of building the full infrastructure, designing the complete experience, and rolling out to the entire organization, they pick one workflow. The one where the team feels the most pain. A single campaign type, a specific approval flow, one market.

For that workflow, they wire the infrastructure: brand knowledge connected, performance data feeding back. They design the experience: approval surfaces that show the system’s reasoning, trust controls that start conservative and expand. And they bring the team in from the start, defining governance together rather than handing them a finished system.

One marketing organization I’ve watched do this well started with their product launch announcement workflow: high pain, medium complexity, cutting across every dimension from brand compliance to regional adaptation. Within eight weeks, that single workflow was running through the full compound: infrastructure feeding the approval screens, the team governing their own rules, human overrides feeding back into the system’s judgment about their context. By their fourth workflow, they were onboarding new campaign types in days instead of months.

Then they expand. Each new workflow inherits what the previous one taught the system. The infrastructure gets richer because the experience surfaces real usage data. The coordination norms propagate because people helped build the thing they’re adopting. Organizational capability compounds instead of plateauing.

It’s slow at the start. By month six, it’s faster than any alternative I’ve seen.

Where you’re stuck

If you’re sensing a plateau, the interaction patterns point to the breakdown.

Strong infrastructure, low adoption: coordination problem. The system works, but it doesn’t reflect how the team operates. Involve the team in defining the workflows and governance. Better onboarding won’t fix a system that was designed without the people who need to use it.

High adoption, declining output quality: experience problem. People are using the system, but the oversight surfaces aren’t supporting good judgment. Redesign the decision interfaces so reviewers get the context to make real calls.

Strong team alignment, shallow results: infrastructure problem. Everyone’s on board, but the underlying data and feedback loops aren’t there. Strengthen what sits behind the surfaces people are already using.

Most organizations have at least two of these happening simultaneously. The diagnostic value is seeing which interaction is doing the most damage.

What this means for your career

The roles that matter in enterprise AI over the next few years will be the ones that work across all three dimensions. The content strategist who understands infrastructure architecture well enough to specify what the system needs. The product designer who can facilitate governance conversations with marketing teams. The engineering leader who builds for organizational learning.

The specialist who goes deep on one dimension and ignores the other two will keep producing work that’s excellent in isolation and stuck in practice. That was a viable career posture when the problems were separable. They aren’t anymore.

If you’re the person in your organization who already sees these connections, the move is to make them visible. Name the compound. Show the team where one dimension is degrading the other two. That diagnostic capability is rare, and becoming more valuable by the quarter.

The pattern underneath

This compound isn’t new to AI. Cloud migration had the same shape: companies that sequenced infrastructure, then UX, then change management spent years stuck in “lift and shift.” The ones that redesigned workflows around cloud-native capabilities from the start, even if the first iteration was rough, moved faster. Enterprise AI is the current version of that pattern, moving faster than previous transitions, which means the compound hits sooner.

If your organization is stuck, you probably picked the right tool and the right team. The problem is that you’re solving one dimension while the other two quietly erode your progress. Name the three. See the compound. Work on them together.

This piece draws on three earlier articles: “From Content Generation to Content Operating System,” “Building for the Agent Experience Gap,” and “AI Productivity Has a Multiplayer Problem.” Each explores one dimension of the compound described here.

A developer I know recently rebuilt her entire content workflow in a weekend. Claude Code with a handful of custom skills: one for drafting, one for SEO analysis, one for scheduling. She showed it off on LinkedIn and got hundreds of likes. The setup was impressive. Thin harness, fat skills. One person, one machine, end-to-end content production in minutes.

Then she tried to hand it off to her marketing team.

The brand team couldn’t enforce their guidelines through it. The legal reviewer had no way to flag compliance issues inside the workflow. Regional marketers in four countries needed localized versions but had no access to the prompts or the context that made the originals good. Performance data from the campaigns lived in three different dashboards that the system couldn’t read. Within a week, her solo workflow was running alongside the old process, not replacing it. Double the coordination overhead, and a growing resentment from the team that felt left behind.

If you’ve been the person who got faster with AI while your team stayed at the same speed, you know what comes next. The guilt of individual productivity that doesn’t scale. The frustration of seeing so much potential and wondering why no one else is moving yet. The growing distance between what you can do alone and what the organization can absorb. The moment you realize your 10x workflow is making everyone else’s job harder, not easier.

This pattern reveals something the current AI conversation is getting wrong.

The single-player trap

The solo operator has never had better tooling. Claude Code has a growing ecosystem of community-built skills. ChatGPT has its custom GPT marketplace. Every week brings a new framework that promises to let one person do the work of ten. Thin harness, fat skills has become the mantra: keep the orchestration layer light, let specialized skills do the heavy lifting.

The results are real. Marketing teams see engineering success stories and want the same thing: Intercom doubling merged PRs per R&D employee with 100+ custom skills, Ramp’s 800 builders shipping 1,500+ apps in six weeks.

But here is what gets missed in the retelling. Intercom and Ramp succeeded because they built shared infrastructure first. Intercom created a custom skills repository with 100+ skills encoding their engineering standards, enforced through automated hooks. Ramp built Glass, a workspace that auto-configures with 30+ connected systems on install, and Dojo, a marketplace where anyone can package a workflow and share it. The individual productivity was real. It was built on top of multiplayer infrastructure. Marketing teams copying the single-player playbook without that foundation are skipping the part that made it work.

This pattern keeps surfacing in conversations with marketing leaders. They can point to individual team members doing impressive things with AI. What they can’t point to is those individual gains adding up to organizational capability. The 5x super-user leaves for another job and takes all of it with them. No institutional learning was created. Ann Miura-Ko calls this being stuck at L1 in her AI maturity framework: individual productivity without organizational learning. “80% of employees use AI weekly!” is, in her framing, “probably true and also meaningless.”

The deeper issue is structural.

Marketing is multiplayer. Multiplayer means shared context, shared governance, and shared learning loops across roles. And almost every tool being built treats it as single-player.

What multiplayer means

In Typeface Signals, 61% of marketers use AI at the individual level, not on collaborative platforms. Of the marketers who report using AI, 82% remain stuck in pilot phases. Those two numbers are connected.

Marketing is one of the most multiplayer functions in any company. A single campaign might involve a brand strategist setting guardrails, a content creator drafting assets, a regional marketer adapting for local markets, a legal reviewer checking compliance, a performance analyst measuring results, and an executive approving the spend. Each of these people has different context and different definitions of “good.”

When one person builds a brilliant AI workflow on their laptop, it solves for exactly one of those seats. The other five are still emailing PDFs.

This is the list of things that individual AI tools do not touch:

• Governance. Who approves what, and what does “approved” mean when the AI generates 500 variants instead of 5?

• Brand. How do you encode institutional knowledge about voice and positioning into a system, rather than relying on one person who “just knows”?

• Coordination. How do you move work across teams when every team has different AI setups and different skill levels?

• Performance data. How does what you learn from one campaign feed back into the next one, automatically, across the whole organization?

These are multiplayer problems. Each one requires multiple people with different roles to agree on how it works. And that agreement is harder than the technology.

Why most deployments don’t compound

How you design the system matters more than the tools you give each person. Microsoft’s research across 20,000 workers confirmed this: organizational factors account for twice the AI impact of individual factors. And yet almost all the energy in the market is going into the individual tooling layer.

Most AI tool deployments today deliver additive returns. Ten individuals each get 2x more productive, the organization gets 2x output. Every person’s gain stays in their own workflow.

Compounding returns look different. Ten individuals learn and share through a common system, and the organization gets 5x, then 10x, because every discovery feeds every other person’s work. This is what Ramp understood when they built Glass. The insight wasn’t the tools. It was the distribution mechanic: when one person discovered a better workflow, everyone got it automatically. No memo, no training session. Individual learning became team capability.

Most marketing organizations are stuck on the additive curve. In our research at Typeface, 48% of marketing leaders cite cultural resistance as a top barrier. A Workplace Intelligence survey found that 29% of employees actively sabotage AI strategies they don’t trust. Shadow tools create data breaches. These are coordination and governance problems at their core, and they get solved by building multiplayer infrastructure that makes the right thing easier than the wrong thing. That infrastructure shows up at every layer of how a marketing organization operates.

Every layer has a single-player mode and a multiplayer mode

Every marketing organization runs on four layers: brand code, execution, orchestration, and interface. Michelle Taite, John Winsor, and Will Fernandez laid this out in HBR recently, and what struck me reading it is that every one of those layers has a single-player version and a multiplayer version. Most teams are running single-player on all four.

Brand code in single-player mode is a style guide PDF that one person references while prompting. In multiplayer mode, it’s machine-readable institutional knowledge that every agent and every workflow draws from automatically. It encodes how your brand makes decisions, how it distinguishes between “safely on brand” and “compellingly on brand,” and it evolves: when a campaign performs well, that signal feeds back into the brand code. When a compliance reviewer rejects an asset, the knowledge base learns to avoid the same mistake across every future asset, in every market. A new hire should inherit the accumulated judgment of everyone who came before them, not start from scratch with a blank prompt.

Execution in single-player mode is one person generating content with Claude or ChatGPT. In multiplayer mode, it’s specialized agents handling generation and localization in parallel, with testing woven into each step. The developer in my opening scene had this nailed for one person. The multiplayer version runs the same workstreams across teams and markets simultaneously.

Orchestration is what connects those workstreams. In single-player mode, it’s a project plan in a spreadsheet. In multiplayer mode, the system manages dependencies and triggers the next action dynamically. When a regional launch in Germany depends on legal approval from the US team, the system holds the queue until clearance arrives, then kicks off localization automatically.

Interface in single-player mode is a prompt window. In multiplayer mode, it’s a collaborative canvas where multiple people work side by side, see each other’s outputs in real time, and build on them without switching tools. The interface becomes the place where the team’s collective judgment lives.

Marketing organizations need all four layers operating in multiplayer mode. That’s what we work on at Typeface, so I should be transparent about my perspective here. But the pattern is not vendor-specific. It shows up everywhere that AI moves from demos to production: the individual workflow that wowed a conference room doesn’t survive contact with 200 people who need to coordinate around it.

If you’re the person who built the solo workflow, the next move is becoming the person who can wire individual capability into organizational infrastructure. That’s a different skill than prompting well, and a more valuable one. The marketer who can do both, build fast individually and design systems that let the team compound, is the one every organization is about to need and almost none have yet.

Back to the developer

The developer from the opening of this piece figured it out. She didn’t abandon her Claude Code setup. She embedded it inside a system that her team could use. The brand team got guardrails that enforced guidelines without touching the prompts. The legal reviewer got a compliance gate that surfaced flagged content before it shipped. The regional marketers got localized templates with the context baked in. The performance data connected.

Her individual productivity didn’t decrease. But the organizational capability around it changed. The system started learning from every campaign and every approval. New team members onboarded in days instead of weeks. The resentment faded, because people weren’t being left behind. They were being brought in.

That transition, from single-player to multiplayer, is the whole game now. The technology isn’t the bottleneck. The design problem is how you make the collective brain compound.

Picture a Tuesday morning, not far from now. A VP of Demand Gen at a large financial services enterprise opens her laptop. Overnight, three things happened without her team touching a single asset.

Her company’s website answered 340 visitor questions. One came from a compliance officer at a Fortune 500 prospect who typed, “We need a content platform that handles SEC disclosure requirements across 14 regional offices.” The page assembled itself in response: relevant case studies, a compliance-specific architecture diagram, a pricing model for regulated industries. The prospect spent 22 minutes on a page that didn’t exist before they arrived.

A product announcement email her team sent on Friday got 14 substantive replies. A CTO asked about SSO integration. A procurement lead wanted pricing for regulated industries. Each reply was fielded by an agent grounded in the brand’s knowledge graph, in brand voice, with accurate technical detail, within 90 seconds. Three of those conversations moved prospects from awareness to evaluation overnight. One scheduled an architecture review.

A campaign running across Google and Meta generated 4,200 unique ad variations overnight, each assembled from the brand’s knowledge graph. Different proof points for different industries, different product angles for different roles, different language for different regions. The system learned that compliance-focused messaging outperformed speed-focused messaging for finserv by 3:1, and that insight automatically reshaped the ads, the landing pages, and the email experiences for that segment.

Every piece of this is technically feasible today. The missing piece is the architecture that connects them.

Here’s what’s worth sitting with: this VP is not overwhelmed. She is not managing more. She spends her Tuesday morning shaping the brand’s point of view, deciding what the company believes about its market, teaching the system what good looks like. The assembly, the personalization, the cross-channel optimization: the system handles those. She does the work only a human can do: taste, judgment, conviction. The work most marketing leaders got into this career to do, and spend the least time actually doing.

That’s the shift this piece is about. Not smarter tools. A different relationship between the marketer and the content.

The break that’s already happened

For twenty years, marketing operated on a simple model: create content, place it in a channel, measure what happens. AI made the creation step 10x faster. Some organizations used that 10x to produce 10x more fixed assets: more landing page variants, more email templates, more ad creatives. Faster at the old model.

If you’ve felt the exhaustion of that approach, the treadmill of producing more assets that perform about the same, you’re feeling the structural break before you can name it.

The economics that demanded fixed assets have evaporated. When a landing page took a design team two weeks and an email campaign required three rounds of review, you needed each asset finished before it shipped. Creation was expensive, so you batch-produced. That constraint is gone. The model has not caught up.

The industry calls the next step orchestration: coordinate more channels, automate more workflows, move faster. That’s necessary but insufficient. Orchestration is coordination without intelligence.

The real shift is convergence: every channel, every interaction, every signal compounds into a system that gets smarter with use and converges on the outcome faster than any single channel could alone. Content stops being something you create and becomes something the system assembles, in real time, from structured brand knowledge, calibrated to whoever is experiencing it and whatever context surrounds the moment.

The difference between a fixed asset and a converging system is the difference between a printed encyclopedia and a search engine. Both contain information. One is alive.

Three shifts that follow

These are connected, and each makes the others more powerful.

Every surface becomes conversational

Think about the last time you visited a B2B website with a real question. You scanned the navigation, clicked through three pages, opened a pricing PDF, and still couldn’t tell whether the product handled your specific compliance requirement. You filled out a “Contact Sales” form. Someone emailed you four days later with a link to a webinar.

A converging system doesn’t work like that. The same intelligence that assembled the page can answer questions about what it assembled. A visitor reading about your data platform asks, “Does this support HIPAA-compliant environments?” and gets a substantive, brand-approved answer inline.

This extends everywhere. An email assembled from a knowledge graph can respond when a recipient replies, because the agent behind the reply channel draws on the same graph that composed the message. Consider what “no-reply@company.com“ actually communicates: we sent you something, but we don’t want to hear back. It’s an artifact of a world where emails had no intelligence behind them. When the system that composed the email can also field replies, every outbound message becomes an inbound channel. The most natural response mechanism in digital communication, hitting reply, finally works.

And there’s a second-order effect. Your prospect’s inbox agent is already summarizing and prioritizing their messages. It encounters structured metadata in your email, parses the relevance, evaluates it against the recipient’s stated priorities, and surfaces a curated briefing. The question is no longer whether your email gets opened. It’s whether it survives triage by the recipient’s agent. Structured, substantive content survives. Broadcast blasts don’t.

Intelligence travels at system speed

This scene plays out every week. The paid media team discovers that a customer migration story drives twice the click-through rate of generic product messaging for healthcare prospects. That insight lives in a Google Ads dashboard. The email team nurturing the same segment won’t see it until someone mentions it in a Monday standup, if they mention it at all. The web team updating the healthcare landing page won’t hear about it for another sprint cycle.

Cross-channel intelligence, in most organizations, travels at the speed of meetings.

Convergence changes this because the channels share a substrate. When web pages, emails, and ads all assemble from the same knowledge graph, a proof point that converts in paid media automatically becomes a higher-priority building block for landing pages and emails targeting the same audience. The insight doesn’t travel through a meeting. It travels through the graph.

This creates the content-audience flywheel: content teaches about audiences, audience signals improve content, and the system compounds with use. Without the flywheel, AI content is a commodity, because whoever has the best model wins today and loses tomorrow when a better model ships. With the flywheel, every interaction creates data that improves the next interaction. That compounding is nearly impossible to replicate. It requires both the technology and the accumulated history of what worked, for whom, in what context.

The next buyer might not be human

A mid-market retailer is evaluating personalization platforms. Before a single human visits your website, their procurement team tasks an AI agent: “Find personalization platforms that support real-time product recommendations, integrate with Shopify Plus, handle GDPR across EU markets, and cost under $150K annually. Return structured comparisons.”

That agent doesn’t see banner ads. It doesn’t scroll a landing page. It queries structured data. If your brand isn’t structured for agent consumption, you’re invisible to this buyer. A human makes the final decision, but an agent makes the shortlist.

Industry estimates put machine identities between 45:1 and 80:1 versus human users in the average enterprise. When the majority of your brand’s interactions are machine-mediated, whether your content is structured, trustworthy, and queryable stops being a technical consideration. It becomes a distribution strategy.

This is Generative Engine Optimization, and it is becoming as consequential as SEO was in the 2000s. There is no “page 2” in an AI-generated answer. You’re in the response, or you don’t exist. A convergence architecture is inherently agent-ready: the same knowledge graph that assembles a landing page for a human visitor responds to a structured query from an agent with consistent, citable, brand-authorized answers. One substrate serves both audiences.

The architecture underneath

I work on these problems at Typeface, and the same architecture keeps showing up. Four layers, each load-bearing.

The knowledge graph. Everything the brand knows, structured and interconnected. Products, claims, proof points, customer stories, compliance requirements, voice guidelines, audience segments, and the relationships between all of them. Convergence without a knowledge graph is like search without an index.

The assembly engine. An AI-native system that evaluates context and assembles content blocks into coherent experiences. It understands narrative flow, information hierarchy, and brand voice. It produces experiences that have never existed in exactly this form, but that are indistinguishable from something a skilled marketer would create.

The conversation layer. Every assembled element can be questioned, explored, or expanded. The conversation is grounded in the same knowledge graph that produced the experience, so answers are substantive and brand-consistent. This same layer powers email replies and the structured agent interface. One conversation capability, surfaced everywhere.

The learning loop. Performance signals from every channel feed back into the knowledge graph. The graph learns which blocks work, for whom, in what combinations, on which channels. An organization with 12 months of convergence data has a structural advantage over one starting fresh, regardless of which AI model either uses.

These four layers become dramatically more powerful when connected to customer data in CDPs, journey tools, and CRMs. The CDP knows who’s arriving. The knowledge graph knows what the brand has to say. Connect them, and the compliance officer from the opening gets a page assembled for her role, her industry, and her specific evaluation criteria. The next morning, her email picks up where her page visit left off. The next compliance officer who arrives gets a better page than the last one, without anyone touching a template.

The early signs are in production

Websites that talk back. R/GA built alpha.g42.ai for G42, replacing traditional web navigation with a conversational AI called Marvin. The client brief, as Kyle Wheeler described it: “Websites are obsolete and agencies are interchangeable with close to no value added.” Pages don’t exist until someone asks for them.

Advertising goes headless. In April 2026, Meta shipped an MCP server for its entire advertising platform. Campaign data, product catalogs, conversion signals: all queryable by external AI agents. A platform that processes hundreds of billions in ad spend just made its core product machine-readable.

Content assembles into commerce. Expedia signed a year-long partnership with IShowSpeed and built infrastructure that collapses the distance between entertainment and transaction. TikTok clips feed directly into a custom microsite where viewers book the exact flights and hotels they just watched. They built this because 25% of Gen Z never visits an OTA at all.

Brand identity becomes machine-readable. Google’s Stitch team open-sourced DESIGN.md, a spec that makes brand rules parseable by agents. It earned 8,600 GitHub stars in fourteen days. The pattern is converging: CLAUDE.md for code agents, AGENTS.md for navigation, DESIGN.md for visual identity. Every domain is independently discovering that agents need structured specs, not examples.

None of these teams used the word convergence. They didn’t need to. They arrived at the same architecture because the same structural forces pushed them there.

What makes it hard

The sharpest objection is that most enterprises aren’t ready for this. The average marketing organization can’t maintain a clean CRM, let alone a structured knowledge graph. That’s real. But the graph doesn’t need to be complete to start compounding. An organization with 200 well-structured proof points already outperforms one with 10,000 unstructured PDFs. Convergence is directional. But the path has real obstacles.

Brand governance at convergence speed. A brand manager approves five ad variations for a campaign. The system generates 4,200 variations overnight. She cannot review them. Nobody can. Governance has to shift from approving individual assets to governing the building blocks and the assembly rules: the atoms are reviewed, the system is trusted to assemble them within constraints. This requires making subjective brand judgment programmatic. That is the hardest problem in the entire architecture.

Closing the measurement loop. Most organizations can’t attribute content performance to specific campaigns, let alone trace a conversion back to a specific proof point within an assembled page. Convergence-level measurement is a new discipline. The instrumentation infrastructure doesn’t exist at most companies.

The org chart. 48% of enterprise marketing leaders cite cultural resistance as a top-three obstacle to scaling AI (Typeface Signal Report, 2025). Convergence dissolves the boundary between “web team,” “email team,” and “paid team.” It replaces channel-specific playbooks with shared building blocks, shared governance, and shared metrics. It asks people who built careers as email specialists or paid media experts to see themselves differently.

That last point is worth dwelling on. If you’ve spent a decade becoming excellent at email marketing, the shift to convergence doesn’t just change your tools. It changes what your expertise means. The marketer who thrives in this world isn’t the best email specialist or the best paid media buyer. It’s the person who understands the brand deeply enough to teach a system what good looks like, and who can think across channels because the system already works across channels. That’s a different kind of career. For many, it’s a better one. But the transition asks something real of people.

The gap is already open

One path is to keep optimizing the model that got you here: produce more assets faster, run more A/B tests, hire more specialists per channel. AI makes this path incrementally better. It’s a reasonable choice for the next twelve months.

The other path is to rebuild around convergence: structure brand knowledge into a queryable graph, connect it to an assembly engine, make every surface conversational, close the loop between performance and creation. This path is harder.

The gap between these two paths widens with time. Every interaction on the convergence path teaches the system something: which proof point converted, which audience responded, which combination outperformed the template. Every campaign on the asset path resets to zero. After a year, the difference isn’t speed. It’s accumulated intelligence, and there is no shortcut to catching up on what someone else’s system has already learned.

You’ll know it’s happening when your competitor’s landing page answers a question yours can’t. When their email gets a reply and yours gets archived. When an agent recommends them and doesn’t mention you.

The generation problem is solved. The convergence problem is the next decade. And the early signs aren’t on a roadmap. They’re already in production.

Your most valuable users are about to stop showing up as often. Their agents are handling everything else.

The sessions that remain look nothing like the ones your product was designed for. Every login is a decision that matters: approving a workflow the agent assembled, overriding a recommendation that feels wrong, catching an exception the automation flagged but couldn’t resolve. Familiar layouts, progressive disclosure, workflows that rewarded muscle memory. None of that helps when someone shows up for five minutes to make a call on something the system couldn’t handle on its own.

This is a product design problem that most teams haven’t named yet. And if you’re building or leading a product right now, I think it’s the most important one in enterprise software.

The shift nobody designed for

The headless infrastructure layer is table stakes. Every enterprise CIO I’ve talked to is demanding APIs, machine-readable specs, and standard protocols. The question of whether to build for agents has been settled.

What almost nobody is thinking about is what happens on the other side.

What’s left is all judgment calls, and the consequences of getting them wrong are personal.

Higher-stakes, less frequent, more cognitively demanding. They need better interfaces than anything you’ve built before.

Most SaaS companies will build the headless infrastructure because the market demands it. They’ll expose the APIs. And then they’ll discover that great infrastructure with a bad oversight screen is how you get approvals rubber-stamped by exhausted humans making decisions in 90 seconds without the context to make them well.

Five principles for product builders in the agent era

I’ve been thinking about this for a few months now, watching what works and what doesn’t as agents move from demos to production workflows. Five principles keep showing up.

1. Treat agents as a first-class consumer

Most products bolt on an API after designing for humans. Flip the order. Your agent consumer will likely drive more volume than your human users within a year or two.

This means building on the standards agents already speak. Markdown files are becoming the universal interface between humans and agents. CLAUDE.md, AGENTS.md, DESIGN.md: these are all variations of the same pattern, a structured document that tells the agent what it’s working with. If your product accepts markdown as input, agents can use it immediately. If you invent a proprietary format, you’re asking every agent builder to write a custom integration.

The same logic applies to protocols. MCP (Model Context Protocol) is emerging as the standard for tool discovery and invocation. A2A (Agent-to-Agent) handles cross-agent communication. These aren’t competing with your product. They’re the rails your product should run on.

Support them natively. Don’t build parallel systems that do the same thing with different syntax. The products that win adoption will be the ones agents can use without a tutorial.

The interaction model has shifted. It used to be User to Software. Now it’s User to User’s Agent to Software’s Agent to Database. Two systems collaborating toward a single outcome. Your product sits between those agents, and the interface quality between them determines what context is available when the human eventually shows up for the judgment call.

The counterintuitive part: designing well for agents actually improves the human experience too. Supporting standards forces you to be explicit about what your system needs. Clear schemas force you to name your assumptions. The clarity compounds.

2. Design living surfaces, not static screens

The old model was a fixed dashboard you visited daily. You knew where everything was. You built mental models of the layout. The screen was the same whether you were making a routine check or a critical decision.

That model breaks when sessions become decisions. The design challenge now is an interface that assembles itself around the decision at hand.

A living surface shows you what the agent considered, where it was uncertain, and what specifically requires your judgment. It adapts based on who you are, what the agent is trying to do, and what the agent knows versus what it doesn’t.

If the agent is confident about 95% of a workflow and uncertain about one parameter, you should see that one parameter front and center, not a full audit of every step.

This matters even more when multiple agents are involved. Every handoff between agents loses context. The living surface’s job is partly to reconstruct what got lost in the chain so the human isn’t making a judgment call with half the picture.

Most software today still serves the same pre-built screen to every user regardless of context. Even modern CMSes mostly fetch pre-created pages. But decision interfaces for agents can’t work that way. The approval screen shouldn’t exist in a fixed form. It should materialize around the specific decision, with the specific context, at the specific moment, assembled from components the way a CMS should build a page but rarely does.

Products that surface raw data and ask the human to figure it out are forcing their users to do the hardest cognitive work with the least support. More on living surfaces in practice in a follow-up.

3. Build for infrequent, high-stakes use

When a human only touches the product for the 2% that requires judgment, that surface has to load fast, show context instantly, and make the decision obvious.

Bad GUIs get forgiven when you use them 50 times a day. You build tolerance, muscle memory, workarounds. At twice a week, every friction point is a failure. The entire experience has to be optimized for someone who hasn’t been here since Tuesday and needs to make a good call in under two minutes.

This inverts most of what product leaders have been trained to optimize for. Engagement metrics, daily active usage, session duration, time in app: if you’re still running quarterly reviews against these numbers, you’re measuring the wrong thing. Your best outcome is a human who made a confident decision quickly and left.

The metrics that actually matter look different:

• Decision latency: time from escalation to resolution. Are humans getting faster as the agent improves its context presentation?

• Override rate: how often humans change the agent’s recommendation, tracked over time. A falling rate means the agent is learning; a flat one means it isn’t.

• Escalation precision: of the items the agent flags for review, what percentage genuinely needed a human? If it’s escalating everything, it’s a notification system pretending to be an agent.

All three are measurable from event logs you’re already generating. Session duration tells you nothing.

4. Close the loop between agent behavior and human judgment

This is where most products fall short. They build the agent path and the human path as separate experiences. They shouldn’t be.

No one starts by trusting an agent. Trust is earned, and the fastest way to earn it is explainability. When an agent shows its reasoning, not just its conclusion, humans can evaluate the process, not just the output. That matters because agents don’t fail loudly. They produce plausible nonsense. The dangerous failure mode is an agent that assembles something that looks right, reads right, and is quietly wrong. Without visible reasoning, nobody catches it.

Make explainability a product requirement, not a debugging afterthought. When an agent must explain its reasoning as a condition of taking action, that explanation becomes the human’s decision-support layer. The agent’s reasoning trail is the human’s context. Over time, consistent explanations that match outcomes build the trust that lets humans move faster. They stop re-deriving every answer and start spot-checking instead. That’s the transition from supervision to collaboration.

The feedback loop runs both directions. When humans override agent recommendations, that signal should improve the agent’s future behavior. When humans approve quickly without hesitation, that pattern should inform where the agent can eventually act autonomously. The approval surface is a training interface for the entire system.

Instrument every decision. Mine the patterns. Over time, the system learns which decisions the human always agrees with (candidates for full automation) and which ones consistently require human nuance (candidates for richer context in the approval surface).

5. Design for progressive trust

The biggest mistake I see is treating agent permissions as binary: either the agent can do something or it can’t.

In practice, trust develops gradually. Think about how you’d onboard a new hire: you wouldn’t give them full production access on day one. The right model is a permission ladder with four levels:

• L1: Read-only. Agents can see data but can’t act.

• L2: Write-with-approval. Agents propose actions, humans confirm.

• L3: Guardrailed execution. Agents act within defined boundaries. Humans handle anomalies and strategic overrides.

• L4: Full orchestration. For decisions where the human has approved 50 times without a single override, the agent runs autonomously. The interface exists for anomaly oversight alone.

Each rung requires a different product surface. Read-only needs good summarization. Write-with-approval needs the living surface described above. Guardrailed execution needs strategic override controls and anomaly detection. Full orchestration needs closed-loop monitoring and pattern mining across decision traces. Most products only design for one rung.

The permission ladder also creates your competitive moat. Every decision trace builds organizational context. Every approval teaches the system something about how this specific company operates. The longer the system runs inside an organization, the more it understands the texture of how decisions actually get made there. Switching costs rise with every rung climbed.

What I’m not covering

I’m deliberately leaving a lot out: pricing shifts from seats to consumption, the observability layer underneath all of this, workforce reorganization as agents absorb the coordination layer, the compiled knowledge problem. Each deserves its own treatment. This piece is scoped to the experience layer because that’s where I see the widest gap between what’s needed and what’s being built.

The gap is a product problem

The infrastructure layer is moving fast. The agent harness pattern is converging. Models are improving on a quarterly curve.

The products people use to oversee all of this are barely moving at all.

That’s the agent experience gap. It’s a product design problem that requires a different kind of thinking than the one the industry spent 15 years refining. The interfaces that matter most will be used twice a week, assembled around decisions, earning trust from every human override. The approval screen becomes the highest-value surface in the entire product.

The companies that close this gap will build something durable. Everyone else will ship impressive agent infrastructure that humans can’t effectively supervise.

I know which failure mode I’d rather avoid.

Three separate posts landed recently that each tackle one of these. Zapier released V2 of their AI fluency hiring rubric. Geoff Charles at Ramp published a detailed retrospective on how they achieved 99.5% company-wide AI adoption. And Andrej Karpathy posted a thread explaining why two groups of AI users are “speaking past each other.” Each tells a different part of the story. Lined up together, they tell the whole thing. And the pattern I keep seeing is that companies pick one of these three and ignore the other two.

1. Hire for it: every new person raises the bar

The most direct way to build an AI-first culture is through the front door. Every person you add either raises the baseline or dilutes it. Zapier decided to make that a deliberate choice.

Their V2 AI fluency rubric evaluates every new hire across four dimensions:

• AI mindset: do you approach work with an AI-first orientation?

• Strategy: can you identify where AI creates leverage in your domain?

• Building: can you construct repeatable systems, not one-off prompts?

• Accountability: can you define “good” upfront, evaluate AI outputs critically, and catch errors before they ship?

The accountability dimension is new in V2, and it contains what I think is the sharpest framing in the entire AI adoption conversation: “With AI, you can delegate the work, but not the accountability.” That sentence should be on a poster in every office running AI tools. The failure mode it addresses is real and everywhere: people rubber-stamping AI outputs without exercising judgment. Fluency means using AI well, which means knowing when the output is wrong.

The most interesting change in V2 is the shift from snapshot to slope. Zapier no longer cares only about where you are today. They care about the trajectory. Are you on an active learning curve, experimenting, iterating, improving? Or have you plateaued? A candidate who is at L1 but accelerating is a better hire than a candidate who reached L2 six months ago and has been coasting since.

The rubric also extends to managers. Individual fluency is no longer sufficient for leadership roles. Managers must demonstrate that they have led teams through AI adoption: creating psychological safety for experimentation, setting clear expectations, redesigning workflows. This is the organizational layer that sits on top of individual skill, and most companies are not even talking about it yet.

The 100% company-wide adoption number at Zapier gets all the attention. The rubric is what produced it. By filtering every new hire for AI fluency and trajectory, they are systematically raising the baseline with every headcount. The behavior you want propagates through selection, not persuasion.

2. Grow the team you have: meet people where they are

Hiring sets the bar for the future. But what about the people already on your team? Some are seeing what AI can do and running with it. Others have not changed a single workflow. You need a way to meet both groups where they are and make it clear what great looks like.

Ramp built this. Their proficiency framework is the part of their playbook nobody else is writing about. Most companies measure AI adoption as a binary: are people using it? Yes or no. Ramp rejects that framing entirely. They built a four-level ladder:

• L0: Sometimes uses ChatGPT. Has not changed any workflows. Geoff’s blunt assessment: “If you’re still here and not self-starting, you will most likely not be at the company.”

• L1: Built custom GPTs, used Notion agents, started exploring Claude Code. Starting to see what is possible but has not compounded it yet.

• L2: Built an application that automates part of their job. Committed code or contributed feedback to others’ work. “This is where things get real.”

• L3: Systems builders. They do not just use AI. They build the infrastructure that levels up everyone else. Force multipliers.

The ladder tells people where they stand. But the mechanism for moving them up matters more. Ramp uses three levers. They build tools that meet people where they are (L0 to L1). They raise expectations as the tools mature (L1 to L2). And they match the mandate to the tooling, never demanding more than the infrastructure can deliver. That last one is critical: raising expectations before tools are ready burns credibility.

Then they made progress visible and gave people space. No mandatory training curriculum. No multi-phase rollout plan. Instead, infrastructure for people to teach themselves. An AI guild. A Slack channel with over a thousand members that spun off 40+ sub-channels. Weekly office hours. An internal tool called Glass that auto-configures with connected systems on install. A skills marketplace called Dojo where anyone can package a workflow and share it. Leaderboards that created healthy competitive pressure without being punitive.

The results: 6,300% AI usage increase year-over-year. 1,500 apps shipped in six weeks from over 800 builders. 12% of all human-initiated production pull requests now come from non-engineers. 84% of the team using coding agents weekly. 350+ skills shared in their internal marketplace.

You do not need a formal change management program if you already have the culture and the measurement framework. Ramp did not start with a rollout plan. They started with a culture that already valued speed, then built tooling that made AI adoption frictionless within that culture. The measurement tells people where they stand. The tooling gives them a path up. And the leaderboards make it social. Traditional change management programs solve a coordination problem, but if the culture and infrastructure are good enough, the coordination handles itself.

Together, Zapier’s rubric and Ramp’s ladder form a complete picture: position plus velocity. Zapier measures which direction new hires are moving and how fast. Ramp measures where every existing person sits and what would move them to the next level.

3. Lead from the front: be the bridge

Hiring and team development both stall without the third piece: leaders who operate at the frontier themselves.

Karpathy’s thread names why. There is a massive gap between what casual users think AI can do and what frontier users are actually doing with it. He describes two groups talking past each other. Group 1 tried the free tier of ChatGPT, got hallucinations and viral fumbles, and formed a lasting impression. Group 2 pays for frontier models and uses agentic tools like Claude Code in technical domains, where recent improvements have been, in Karpathy’s words, “nothing short of staggering.” These models can now “melt programming problems that you’d normally expect to take days or weeks of work.”

The gap is structural. AI capabilities are “peaky.” Reinforcement learning with verifiable rewards works best in domains where success criteria are explicit: unit tests pass or fail, math proofs check out or do not. Writing, search, and open-ended advice are harder to evaluate, so gains concentrate in technical areas. Even paying $200 a month does not close the gap if you are working in a domain where improvement has been incremental rather than transformational.

This is the leader’s problem to solve, and you cannot delegate it. If your leadership team is in Group 1 and your practitioners are in Group 2, your adoption strategy is fighting itself. The people setting the agenda do not believe what the people on the ground are telling them, because their personal experience of AI does not match. The hiring rubric and the proficiency ladder both face resistance when the person holding the budget does not feel the urgency. Or worse: if you are in Group 1 yourself, you cannot influence a change you have not experienced.

The most effective thing a leader can do is build something themselves. When a leader sits down with an AI coding assistant and builds a tool their team actually uses, the perception gap closes through firsthand experience, not slides. I wrote about this recently: a weekend dashboard project changed how 200 people at Typeface think about customers. The dashboard was the easy part. The shift in how leadership talked about AI afterward was the real outcome.

Ramp understood this. Their CEO declared at kickoff they would become “the most productive company in the world.” That is a cultural signal as much as a strategic one. It tells the entire organization that leadership is in Group 2, or at least committed to getting there. Without that signal, adoption dies in the middle of the org chart, where people wait for permission that never comes.

You are the bridge between the two worlds Karpathy describes. If you are not crossing it yourself, nobody else will cross it for you.

What breaks when you only do one

The failure modes are predictable. Hiring for fluency without growing the existing team means new people face resistance from the system. Their edge erodes over time, or they stop fighting and conform to the existing pace. Growing the existing team without changing the hiring bar means you miss the catalyst. New hires who arrive fluent bring fresh patterns, raise the energy, and accelerate the people who are ready to receive it. Without that signal from the outside, even a well-built proficiency ladder can plateau. Either one without leadership at the frontier means your budget, your mandate, and your timeline are all set by people who do not understand what is possible.

Ramp’s numbers illustrate what it looks like when all three work together: non-engineers shipping production code, internal tools going from concept to deployment in hours, 800 people building 1,500 applications in six weeks. Those outcomes are not available to companies doing only one of the three.

The diagnostic

I work in enterprise AI. I see this pattern across companies of every size and industry: leaders say “AI-first” as if it is one thing, then assign it to one team. HR mentions fluency in the job description. IT handles the rollout. The CEO gives a speech. Nobody connects the hiring bar to the proficiency ladder to the leader’s own experience.

The companies that figure this out will not look incrementally better than the ones that do not. The gap will compound, because better hiring raises the team, which improves the tooling, which gives leadership clearer signal, which increases investment in better hiring. Each turn accelerates the next.

If you are leading this, the diagnostic is simple. Would your hiring rubric screen for the fluency your tools now demand? Can you tell me what level your best people are operating at? And when the person setting your AI budget sits down with the tools, do they feel what the practitioners feel? Whichever question you cannot answer is where to start.

Sources:

• Geoff Charles: How Ramp Got Company-Wide AI Adoption (April 2026)

• Zapier: Raising the AI Fluency Bar for Every Hire (March 2026)

• Andrej Karpathy: The Growing Gap in AI Capability Understanding (April 2026)

The room went quiet for a beat. Then five people gave five partial answers. The CS lead had a subjective health rating from a recent check-in. Engineering knew about two open bugs but wasn’t sure if they were resolved. Product had usage data. Sales knew the renewal date and deal size. Nobody had the complete picture, and nobody could assemble it in real time.

The answer was: “Let me follow up.”

If you have worked in B2B, you have been in this room. I have seen this scene play out at every company and team I have worked at. Different accounts, different rooms, same outcome. The data exists, scattered across four or five tools that never talk to each other.

This was the before.

The after looks different. Now, when someone asks “How is Account X doing?”, the answer takes three seconds. Green, yellow, or red. If it’s red, you can see why: three open bugs in Linear, usage down 30% in Mixpanel, CS flagged the relationship as “at risk” in Airtable, renewal is in 60 days per Salesforce. All on one screen. The data is right there, and the conversation can actually happen. Where there are gaps, those are visible too, which means the follow-up is specific: “We’re missing a recent CS assessment for this account” rather than a vague “let me look into it.”

I built this. Not because my team couldn’t. Because the person closest to the problem, armed with the right tools, is now the fastest path to a solution. That changes who should build what in any organization, and it is the core of what “AI-first culture” actually means.

Full disclosure: I work in AI. I am President of R&D at an enterprise AI company. But the problem I am describing has nothing to do with AI products. It is an operational visibility problem that exists at every B2B company I have ever talked to. I built it using Claude Code, an AI coding assistant, over a few evenings. The second version, with bug tracking and SLA enforcement, took another few days.

The technology part was straightforward. The organizational part was where it got interesting.

The PM work comes first

Before I wrote a single line of code, I found a partner. A strong customer success lead who had been living with the same frustration from the customer-facing side. We spent time upfront doing the PM work that makes or breaks a tool like this: What does “healthy” actually mean? Which signals matter and which are noise? None of those are technical questions. They are cross-functional alignment questions. Getting them right before building meant the first version was already something both teams could trust.

This step has nothing to do with AI. It is the same discipline that has always separated tools people use from tools people ignore. AI changes the speed of everything after.

From question to working tool in hours

I have an engineering background, but I do not write code nearly as much as I used to. AI coding tools changed that equation. I described what I wanted, step by step, and the AI wrote the code. The skill that mattered was knowing what to build and why, not knowing how to code it.

The first working prototype took about four hours. A Python script that pulls from four sources (Linear, Mixpanel, Airtable, Salesforce), matches the data to customer accounts, and generates a static HTML page. No backend server. No database. Just a script on a cron schedule that pushes an updated HTML file.

The first version was ugly. The health score algorithm was naive. AI ensured I did not have to spend hours learning which API to call. And it worked.

I showed it at the next leadership meeting and something shifted in the room. People leaned in. They started asking questions about specific accounts. “Why is this customer’s score dropping?” “Can we see the bug list for that account?” “What does engagement look like quarter over quarter?”

Within two weeks, I had iterated through a dozen versions. Added SLA tracking. Added trend indicators. Built an automated bot that posts warnings when bug resolution timelines slip. Connected it to our project management system so every bug links back to the customer it affects. The total build time was a few weeks of evenings. Through traditional channels, this would have been a multi-month effort with product specs, design reviews, and sprint planning, competing for priority against actual customer-facing work.

The speed mattered because fast iteration meant the tool evolved with real feedback instead of a spec.

What the dashboard actually shows

The actual dashboard has considerably more: flow score analysis, weekly trend views, a full bug hot list, customer drill-down modals, and the SLA bot’s escalation history. The above is a simplified sample for illustration.

The top row is a two-second health check: summary cards showing bug counts with SLA breach rates, net bugs this week, the team with the highest SLA debt, overall compliance rate, and mean time to resolution. You know immediately whether things are getting better or worse.

The customer table is the view that changed conversations. Each row is an account with usage metrics, days to renewal, open bugs, and color-coded health status pulled from three sources: the CS lead’s subjective assessment, bug severity, and flagged risks. Click any customer and a modal opens with the full picture: every open bug with age and assignee, the CS lead’s progress notes, usage trends, and Salesforce deal details. Everything anyone needs to answer a question about an account is on one screen.

Every team sees the same data. That turned out to be the most important design decision. When engineering and CS look at the same customer row and see the same bug count, the same usage trend, and the same renewal date, the conversation is fundamentally different.

The SLA bot turned out to be more impactful than the dashboard itself. For every bug that has breached its SLA, the bot posts a comment directly on the issue: the priority, the assignee, the age in days, which customers are affected. If there is a real update, it backs off. If not, it escalates. People respond to specific, contextual, timely nudges. They ignore dashboards they have to remember to check.

The bot sits on top of ownership culture. Everyone on the team already cares. Accountability is a muscle, and like any muscle it needs training. The bot provides the training. It turns good intentions into consistent habits.

What changed

The dashboard has been live for about four weeks. Here is what happened:

Cross-functional conversations got specific. Before, customer health discussions were qualitative. “I think Account X is unhappy.” Now the conversation starts with a number and a trend line. “Account X dropped from 78 to 64 this month, driven by three unresolved bugs and a 40% decline in weekly active users.” The specificity forces better follow-up.

Engineering prioritization got sharper. An engineer had a P2 bug in his queue for a week. When the dashboard showed it was blocking three accounts with renewals in the next 60 days, he moved it ahead of a P1 that affected no active customers. That is a judgment call that no ticketing system’s priority field can encode. A human looking at the right data can make it in seconds.

Customer success started using it for renewal preparation. Instead of building a one-off account health slide deck before each quarterly business review, they pull up the dashboard and walk through the live data. Customers have also responded well to the resulting level of transparency: “You already know about these issues and you’re tracking them.”

SLA compliance improved significantly within the first month. The transparency is uncomfortable at first. But it shifted the culture from “we’ll get to it” to “we need to resolve this today.”

These are all good outcomes. The more interesting story is what happened next.

The real shift: who builds what

The CISO leaned in

Building the dashboard required connecting to four different systems. The early versions had credentials management that wasn’t enterprise-grade yet.

Our CISO noticed. Rather than shutting it down, he leaned in. We are trying to be an AI-first company, and that means making it safe and easy for people to build tools like this, not blocking them. He and another person on his team built shared infrastructure: secure secrets management, approved API access patterns, a lightweight hosting setup. Now anyone building internal tools with AI assistants does not have to reinvent the security layer. The dashboard became the proof case for an organizational capability.

That is the difference between one person building a tool and a company building a culture.

Every question became askable

The less obvious shift: I started asking questions I would not have thought to ask before. When four systems feel like one fabric, you stop thinking in terms of which tool has the answer. You just ask.

Which customers have the highest ratio of open issues to engagement? What are the trending problem areas this quarter? Easy questions. They were hard to answer, because assembling the data took longer than the insight was worth. When that cost drops to zero, you explore. You find things you were not looking for. That is what AI-first actually feels like in practice: the questions themselves change.

Non-engineers started building

Then other people started building. A PM built automated copy evaluations for a specific customer’s brand guidelines. Someone on the startegy team built a pricing calculator that pulls live usage data and models different tier scenarios. They are domain experts who finally have the tools to solve their own problems. The backlog of “I wish I had a tool that...” is getting cleared, by the people who actually need the tools.

What starts as one leader’s side project becomes organizational infrastructure once the security team makes it safe and repeatable. After that, building spreads. It works whether you have 20 people or 20,000. The seed project will be different: maybe it is a customer dashboard, maybe it is a sales report, maybe it is an onboarding workflow. The sequence is the same.

Who keeps the thing alive

Building the dashboard was one problem. Who maintains it? Who adds the next view or fixes a score when someone spots an edge case?

In a traditional setup, this is where internal tools go to die. The builder moves on, nobody owns it, and six months later people are back to spreadsheets.

AI coding tools changed this. When someone wants a change, I ask for a one-pager: what do you want and why. I hand it to my AI coding assistant, and most of the time the change is live within hours. Sometimes in meetings, someone points out an issue and I fix it right there, while the conversation continues. No “let me file a ticket.” Just: fixed, refresh, there it is.

For anything beyond a quick fix, the whole thing lives in an internal GitHub repo. Anyone on the team can open a pull request: add a new view, tweak a score, connect a new data source. The one-pager is for people who want to describe what they need. The repo is for people who want to build it themselves.

That speed of iteration keeps the tool alive in a way that organizational process never could, because the cost of each improvement is so low that there is no reason to defer it.

That said, speed does not mean I got everything right.

What I got wrong

The health score missed a real risk. An account showed green: steady usage, no open urgents, CS assessment up to date. What the score missed was that their champion had quietly left the company, and the new stakeholder was evaluating competitors. By the time the score turned yellow, the conversation was already difficult. The tool needs to account for lagging indicators, and I am still working on that.

I over-automated the notifications early on. The bot posted too many comments, and people started ignoring them. I had to dial it back to only the most critical signals: SLA breaches on accounts with upcoming renewals, health score drops below a threshold, and new urgent bugs on already-stressed accounts. Less frequent, higher signal.

A dashboard gives you visibility. It does not give you ownership. The system only works if people keep it fed. If habits slip, the health scores go stale and people stop trusting them. The tool amplifies whatever operating culture already exists. It does not create one.

That last point matters, because it gets at what “AI-first culture” actually means.

What AI-first culture actually looks like

Most conversations about AI-first culture focus on the product: does it use AI, does it sell AI. The more interesting question is how AI changes the way an organization operates internally.

What I saw was a sequence that compounded. Each new tool someone built made the next one easier to justify and safer to deploy. That compounding is the culture.

AI coding tools give your leaders the ability to build the specific, idiosyncratic, “no vendor sells this” internal tools that change how an organization sees itself. The leader who builds has an advantage: they know exactly what question needs answering, because they have been living with the absence of that answer.

The companies pulling ahead are the ones where leaders are building. And if you are the exec setting the tone, the most important thing you can do is make it safe to try: fund the experiment, clear the compliance path, and celebrate the first ugly version. The technology just made it possible to start this week instead of next quarter.

That word, “fine,” is doing a lot of heavy lifting. It means the generation quality is acceptable. It means the novelty has worn off. And it means the hard problems, the ones that actually determine whether AI creates leverage or just creates more content, are still unsolved.

We’ve spent the last few years working on these problems. Some of what we’ve learned feels clear. Some of it we’re still figuring out. This piece is an attempt to map the territory as I see it right now, not as a finished argument, but as a framework I keep coming back to.

What the First Wave Got Right

The first generation of AI content tools brought the cost of content creation down by an order of magnitude. They forced a useful reckoning inside enterprise marketing teams about what “good” actually means and who decides. And they normalized the idea that AI belongs in the content workflow at all. Three years ago, most enterprise marketing leaders were still treating AI as a compliance risk or a novelty. The tools that shipped in 2023 and 2024 made the category real.

But here’s what they mostly didn’t do: they didn’t build the infrastructure that makes generated content useful at enterprise scale. In our latest research at Typeface, 95% of marketing leaders report rising content demand, but only 14% feel completely confident they can keep pace. That 81-point gap isn’t about generation. It’s about everything around it.

The Four Gaps That Actually Matter

When I look at where enterprise content teams are struggling, it’s not with generation quality. Models have gotten good enough that the output of a well-prompted system is, in most cases, usable. The gaps are structural.

Orchestration across workflows.

Enterprise content production is not a linear process. It involves brand guidelines that need to be enforced, regional variations that need to be managed, approval workflows that need to be respected, and channel-specific formatting that needs to be applied. Most AI content tools treat generation as a standalone event. They generate something, and then your existing processes take over. The problem is that your existing processes weren’t built to handle volume that’s 10x what they used to handle. The seams show immediately. In our research, 67% of marketers say their brands miss key opportunities because of slow or outdated content review processes. At large enterprises, 71% need more than a day just to approve quick-turn content. The orchestration gap isn’t abstract. It’s measurable.

Real orchestration means the AI system understands the full workflow, not just the generation step. It knows what happens before content is created (briefing, context-setting, persona selection) and what happens after (review, approval, distribution, performance tracking). When those pieces are connected, the leverage compounds. When they’re not, you have a faster typewriter.

Knowledge integration

The question I hear most often from enterprise buyers isn’t whether AI can write a product description. It’s whether AI can write one that reflects their brand’s specific voice, their customer’s specific segment profile, and the regulatory requirements specific to their market. Those things live in systems: a brand guideline document, a CRM, a product catalog, a compliance database.

Most AI content tools don’t have access to any of that. They generate against a generic prompt. The result sounds like everyone else’s content, because it is. Enterprise buyers figured this out quickly. In our research, 87% of marketers say AI-generated content feels generic. “AI-generated” became shorthand for “sounds like it could be from any company,” which is a problem if your differentiation is supposed to come from your brand.

Solving this requires structured knowledge integration: a system that can ingest, organize, and reason against a company’s specific context. Not a one-time upload of a style guide. A living, queryable layer of institutional knowledge that feeds into every content decision.

Quality evaluation

This is the one I find hardest to talk about with confidence, because I think the industry, ours included, is still working through it.

Here’s the version of the conversation I keep having. Enterprise marketing leader says: “We tried AI content tools and the quality wasn’t good enough.” I ask: how were you measuring quality? A pause. Then: “We could just tell.”

That’s not a knock on enterprise marketers. It’s a knock on the tools for not giving them better instruments. When you’re producing five pieces of content a month, subjective judgment is a reasonable quality control mechanism. When you’re producing five hundred, it isn’t.

The honest truth is that taking something fundamentally subjective and making it objective enough to evaluate at scale is one of the hardest problems in this space. Quality evaluation means assessing output against defined dimensions: brand voice fidelity, persona accuracy, claim accuracy, tone consistency, regulatory compliance. But defining those dimensions with enough precision to evaluate programmatically? That work is painstaking.

Here’s what it actually looks like. You’re working with a customer. The content scores well on brand voice. It’s accurate. It follows the guidelines. And then someone on the marketing team says: “It’s on brand, but it’s kind of... uninteresting.” So you push toward something more edgy. And guess what? Now it’s not on brand. You start asking harder questions. How much does brand voice actually constrain what’s possible? Where’s the line between “consistent” and “boring”? How do you encode the difference between “safely on brand” and “compellingly on brand”?

These are real questions, and sometimes the marketers themselves don’t have the answers yet. They’re discovering what they want through the process of reacting to what the system produces. That means quality evaluation isn’t a configuration step you do once. It’s an ongoing conversation between the system and the people using it, where the definition of “good” keeps evolving.

There is no easy button here. Anyone who tells you they’ve fully solved quality evaluation for AI content is either working on a narrower problem than you think, or oversimplifying. The teams making the most progress are the ones treating it as ongoing, collaborative work with their customers rather than a feature they shipped.

Closed-loop measurement

Content without measurement is an expense. Content with measurement is an investment. The difference, in practice, is whether the system can tell you which content worked, why it worked, and what to do differently next time.

Most AI content tools stop at generation. Some offer basic engagement metrics. Very few close the loop in a way that actually changes what gets generated next. The result is that teams are generating more content than ever, and they know less about what’s working than they did before, because the volume makes it impossible to reason about manually.

Closed-loop measurement means connecting content performance data back to the generation system, so that what gets created next is informed by what worked last time. It means building feedback cycles that get faster and more precise over time. This is conceptually straightforward and operationally very difficult. The data pipelines, the attribution models, the feedback signals that are clean enough to actually learn from: all of that is still being built across the industry.

Why This Is a Category Shift, Not a Feature Gap

I’ve heard the objection: couldn’t existing tools just add these capabilities? Couldn’t an orchestration layer be bolted onto a generation tool?

Sometimes yes. But mostly no, and here’s why.

Building a generation tool and building a Content Operating System require fundamentally different architectural decisions. A generation tool is built around a model and a prompt interface. A Content OS is built around data flows: how knowledge enters the system, how workflows are represented, how performance data feeds back in, how approvals are tracked. Those decisions get made early and shape everything that comes after.

A tool that starts as a generation layer and tries to add orchestration on top will struggle in the same way a spreadsheet struggles when you try to use it as a database. You can go pretty far, but you’re working against the grain of what the thing was built to do.

The category shift matters because it changes what enterprise buyers should be evaluating. The right question isn’t “does this tool generate good content?” The right question is “does this system support how my organization actually produces content at scale, and does it get better over time?”

Those are different questions. They have different answers.

Why the OS Framing Matters Now

Here’s the thing about the four gaps I described above: they’re hard enough in a world where the channels stay the same. But the channels aren’t staying the same.

Most marketing teams today operate in silos. There’s a web team, a social team, an ads team, an email team. Each has its own tools, its own processes, its own content pipeline. The first instinct with AI is to make each silo more efficient: faster web copy, faster ad variants, faster email campaigns. That’s useful. It’s also thinking too small.

The real opportunity is making marketing truly multi-channel in a way it’s never been before. And the urgency comes from the fact that the channels themselves are transforming. It’s unlikely that web doesn’t change fundamentally. Search is already changing. Ads will evolve. And increasingly, there will be a version of every channel designed for humans and one designed for agents. Those are fundamentally different. Content that works for a person browsing a website is not the same as content that works for an agent evaluating options on their behalf. The channels as we know them today may not look the same in two or three years.

That’s why the OS framing matters. A point tool that generates content for today’s channels is useful until the channels shift. An operating system is built to adapt. It’s the difference between an application and a platform.

What does that OS layer need to support? The four gaps map directly: orchestration that can rewire when workflows change, knowledge integration that persists across channels even as channels transform, quality evaluation that evolves with the work, and measurement that closes the loop regardless of where content lands. Those aren’t just nice-to-haves for today’s marketing stack. They’re the foundation for a marketing stack that can absorb whatever comes next.

A system that’s built only to fit into today’s workflows is building for a world that’s already changing. The companies that build for adaptability, not just efficiency, are the ones that will be ready when the ground shifts. And it will shift.

That’s also where this gets genuinely hard. Because you can’t transform how a marketing organization works and do it fast at the same time. The technology can move quickly. The organizational change required to actually use it? That’s a different challenge entirely. And it’s the one that determines whether any of the infrastructure actually delivers on its promise. I’ll have a lot more to say about that in my next post.

I should be transparent: this is exactly the problem space I work on at Typeface. That gives me conviction that the category is real, and also means you should read this with that context in mind. I’m not a neutral observer. I’m someone who has chosen to spend years building in this space because I believe the infrastructure layer is what determines whether AI content actually works at enterprise scale.

What This Means for Enterprise Buyers

If you’re evaluating AI content platforms, a few questions worth pressing on:

How does your system maintain and update brand knowledge? Not “do you have a style guide upload,” but: how does that knowledge stay current, how does it propagate across outputs, and how do you handle conflicts between brand standards and what a model naturally wants to generate?

What does your quality evaluation look like, and how much of it requires working directly with your team to calibrate? Be skeptical of anyone who makes this sound easy. The best answers here will be honest about how much iteration the process requires.

How does content performance feed back into future content decisions? Is that a manual process or a systematic one?

And maybe most importantly: how does your system adapt when the channels change? Is this built to fit today’s marketing stack, or to support the next version of it?

The vendors who answer these questions with specificity, including specificity about what’s still hard, are the ones building infrastructure. The ones who pivot to model benchmarks or output samples are still thinking about the generation layer.

The generation problem is largely solved. What’s not solved is everything around it: the knowledge that goes in, the workflows that shape it, the evaluation that ensures it, the measurement that closes the loop. And underneath all of that, the channels themselves are in flux, which means the infrastructure has to be built for adaptability, not just for today’s workflows.

Even when the infrastructure is right, there’s a deeper challenge: the organizational transformation required to actually use it. In our research, 48% of marketing leaders cite cultural resistance and change management as a top barrier to scaling AI. The technology is the easier part. The harder part is people and process. That’s the subject of my next piece.

The data cited in this piece comes from the Typeface Signal Reports: The Typeface Signal Report 2025 and Meeting the Moment: Big Game Edition.