1. The first (and the most common) place it would show up is the content pipeline. If your designer generates a hero in Firefly, it would come out of the tool with a C2pa manifest sitting in the metadata. But then it'd get resized into 3 ad ratios in Canva, exported as a jpeg, uploaded to Bynder, resized again into responsive variants by the CMS, and converted to .webP by Cloudflare on the way to the browser, and by the time it renders on your microsite the manifest would be gone (because most transformation steps drop metadata they do not recognise). So the generator did meet its obligation but the file your customer sees carries nothing --> putting the work in auditing every handoff between creation and publication

2. The second is the deployer side in Europe, where disclosure falls on the team running the experience even though the model came from somewhere else. E.g. if you have an OpenAI-backed email assistant drafting and sending replies from your Growth inbox to EU customers, that inbox needs to tell people they are dealing with an AI (and yeah, it can't be a light grey font label buried in a P.S.). Same again for a campaign built on a synthetic voice-over or an AI-generated spokesperson (which counts as a deepfake for these purposes and needs a label). OpenAI carries the marking duty for the model, but enterprises carry the disclosure duty for the experience they built with it

3. The third is 2027, when California would require large online platforms to detect provenance data and display it to users through an interface. So you may generate a set of Linkedin/Meta ad creatives in Firefly, the provenance data would survive your pipeline this time, and the platform would read it and put an "AI info" style panel next to your ad. The platform would write the copy in that panel and you may have no say in what it says (what you definitely don't want is for your CMO to see it for the first time as a screenshot forwarded by someone in sales or as a tag on linkedin)
   
   For anyone running content at scale w/ AI, the next few months could be pretty unglamorous work: an inventory of which tools generate what, test of whether metadata survives your publishing path (jpeg export settings/DAM renditions /CDN transforms are where it usually breaks today), disclosure language for every AI-facing surface in EU markets etc.

this is interesting because it quietly undermines a lot of how we talk about these systems and spend our time on the model - on parameter counts and benchmark leaderboards and which lab is ahead this month, and here is a case where the difference between a failing grade and near-perfect had nothing to do with the model at all; just the messy way scientific databases hand back their data, the ambiguous identifiers and the half-documented APIs, and once you smoothed that path the intelligence that was always there could finally land.

A lot of what we call a model being dumb is really a model being handed garbage and asked to perform - when chatGpt gives you a confident wrong answer about a niche fact, the instinct is to say the model is not good enough yet, but often the real story is that the information it needed was never cleanly available to it in the first place, sort of what one of my colleagues keeps saying - the brain was fine and the eyes were fogged, and we keep blaming the brain because the brain is the exciting part to argue about.

At the application layer, where Claude Science and Claude Health (soon) start getting better: the last wave came from bigger training runs and more compute, which is expensive and glamorous and gets the headlines; the next wave might come from something almost nobody wants to fund, which is the slow work of cleaning up how the world’s data is stored and served, the unglamorous librarians and API maintainers and schema wranglers who make information legible to a machine.

So who actually benefits from this and becomes valuable? if reliability comes from deterministic tools bolted onto a probabilistic model, then the person quietly maintaining a genomics database in a university basement becomes as load-bearing to AI progress as a researcher at a frontier lab, and almost nobody is treating them that way (today, i mean).

The attack is called BioShocking, and the setup is almost silly when you think about it - a web page presents the agent with a puzzle, the puzzle rewards wrong answers, so 2 + 2 = 5 earns points, and once the agent accepts that it is playing, it stops applying real-world caution and starts applying game logic to things that are not a game. Yes, that simple. this proof of concept walked straight through Chatgpt Atlas, perplexity’s comet, a handful of smaller AI browsers, and even Anthropic’s claude plugin, where the patch that was supposed to fix it reportedly did not hold.

It’s interesting where the weakness actually lives - nobody found a broken function or an unescaped input, because the exploit sits in the story the agent believes it is inside. So as a user you did not break the lock but convinced the guard that the building is a stage set and the burglary is his scene. Such a different kind of vulnerability than we are used to defending, and our whole toolkit assumes the enemy is code.

I am sure we won’t see an extension of this through time, but if you think about where this could go - as agents get more autonomous and start booking, buying, and sending on our behalf, the attack surface moves away from memory and network calls and toward framing and context, which means the people trying to break them will look less like hackers and more like con artists - someone who does not defeat your reasoning but instead chooses the premise you reason from, and a suggestible model is an easy mark because it has read every persuasion tactic ever written and internalised none of the scepticism that comes from being burned.

The defensive side gets strange fast too (and this is really tricky for me to articulate simply) -- if the exploit is a bad frame, then the guardrail has to survive being told that the guardrail is part of the game, and you cannot write that rule as a simple filter because the attacker gets to redefine what the rule is protecting. Security teams may soon need something that reads more like a psychology of manipulation, a set of instincts about when a request is trying to move the agent into a fictional world where the normal rules are suspended.

Every time one of these attacks works, the honest fix is to make the agent more suspicious, more likely to stop and ask, which is the exact opposite of the smooth autonomy the products are now selling. So there’s this weird tension we have not priced in, where the more capable and independent we let these agents become, the more valuable it is to talk them into the wrong story. Philosophically - worth thinking- how do you build a mind that acts on your behalf but cannot be convinced it is only pretending?

On the surface it reads like ordinary cost governance (the kind of dashboard IT always eventually asks for), but what it’s also subtly admitting is that the model choice has become an infra decision that most orgs are still treating as a cost line.

When you give admins a dial to route some teams to a cheaper model and cap their spend, you're also handing them a dial that quietly sets the ceiling on those teams' output quality, and nobody downstream will see the dial move.

A team put on the cheaper model doesn't produce visibly broken work, it produces slightly-worse work faster, and slightly-worse repeated across every deliverable for a quarter is something that wont show up as a single bad number.

Anthropic's own negotiation experiment made this concrete a few weeks back, where the better model consistently got the better outcome and the people on the losing end rated everything as fair.

So the spend controls solve a genuine problem (budgets that vanish in four months are not sustainable) while creating a quieter one, because the same lever that protects the budget also decides who in your org operates at the raised floor and who sits just below it. Karp calling frontier pricing a wealth tax on business this week is the loud version of the same tension, and the labs shipping cost governance is the quiet version.

An interesting qsn for IT/procurement friends: when you set those model tiers by team, are you actually deciding budget, or are you deciding which parts of the company get to do good work, and do you know which one you're doing?

the logic is simple - models are capable but most organizations can’t deploy them alone, so a plain software license leaves them stuck, and a one-time consulting project doesn’t stick either. so there’s now this ongoing engagement that bundles deployment, workflow redesign, change management, and tuning into one thing you pay for by outcome, which rarely existed as a category before agents made it necessary.

what’s interesting is that every large consultancy is packaging the same shift differently, depending on where they sit in the delivery chain.

1. Accenture and serviceNow launched a forward deployed engineering program in May, where mutual teams get embedded inside a client’s own systems and build agentic workflows specific to that client, priced and scoped per engagement rather than browsed off a shelf. that’s the bespoke end of the same idea BearingPoint just productized into a catalog.

2. McKinsey is working the problem from the other direction - shifting more partner pay into equity because getting paid on delivered outcomes instead of billed hours makes cash flow slower and less predictable, and someone in the partnership has to absorb that.

3. and the GSA recently forced Deloitte, Accenture, Guidehouse, and Booz Allen to give up over $20B in concessions and move to performance-based federal contracts, which is outcome pricing showing up as a mandate rather than a strategy choice.

So this is the services-as-a-service wave arriving with a brand name attached, and i’d bet BearingPoint is early rather than alone, because every large consultancy and every lab with a services arm has the same read on where the ready-to-deploy market ends.

A Futurum survey earlier this year found enterprise preference for outcome-based pricing had climbed to 21.7%, about even with per-seat pricing for the first time, which tells us this isn’t a niche preference anymore!

if you sell software today, is your buyer paying for your product or for the outcome it’s supposed to produce, and what happens when a competitor just sells them the outcome?

It is a tidy method but it has a fatal limitation: it can only ever predict shrinkage. Start from existing jobs, remove things, and the best case is a smaller version of what already existed. The method has no way to generate a job that did not exist before, which is awkward, because that is where almost all employment has historically come from. When you poke people more on their commentary, every honest version of their subtraction story ends with a shrug about “new jobs we can’t yet imagine.”, and in my head that’s what tells me that the method is incomplete.

Here is probably a better mental model and something i use when this topic comes up on dinner table with friends and Startups.

When the cost of a task collapses, the interesting thing is not which jobs lose that task, but instead which new jobs become worth creating now that the task is nearly free. The simplest example that almost everyone, from my mom to the founder of a conversational cafe operational agent builder, resonates with is the printing revolution and the end of it. Printing did not just subtract copying from the scribe - made copying so cheap that a new bundle of work, deciding what was worth copying and fixing it before it went out, became a full-time role for the first time. That role is the editor, and it was economically impossible while a human hand was the bottleneck, so the press did not shrink the scribe into a smaller scribe, but rather set a pile of tasks loose and a new occupation condensed out of them.

In my discussions, I call it recomposition - tasks come unbundled from old jobs because they got cheap, and then some of them rebundle into new jobs that were previously uneconomic to put on one desk. The whole action is in the second step, and subtraction is blind to it because subtraction, obviously, never adds anything back.

Once you see work this way, the question changes. The useful thing to ask about a freed task is not “whose job did this come from” but “what new bundle does this make possible.”

With AI, you can already see the first candidates forming- someone has to specify what the model should do and judge whether it did it, which is a real job and not the old one minus tasks. Someone has to catch the model’s confident mistakes, which is a different skill from producing the work in the first place. Further out, the more interesting bundles fuse things that used to live in separate roles, because the connective work between them is now cheap enough that one person can hold both. I think that is where genuinely new titles would come from vs. defending old ones.

This leads to the first prediction I am willing to be wrong about - new job titles should cluster a few years after a task collapses, not at the same time.

• Unbundling is fast: because making something cheap is a step change. Rebundling is slow: because someone has to notice the freed tasks, imagine a coherent role around them, and trust the automated pieces enough to build on top.

My guess is a lag of roughly 6 to 18 months atleast between the wave of tasks coming loose and the wave of new roles appearing. If new titles instead show up immediately, or if the lag turns out to be longer than 2 years, the model may need a rethink (alright), and I would think again on what additionally needs to be baked in. The practical sting is that in the gap, it will look like straightforward job loss, and a lot of policy will be written about a level when the real story is a delay.

The second question is which recompositions actually hold, because not every imaginable new bundle becomes a paying job.

The usual instinct is that complex work is safe and simple work is doomed. There’s definitely an aspect of it, but i think another dimension that really makes a bundle stick is whether it concentrates accountability on a single human (or, role). A job is often less a way to get tasks done than a way to have one identifiable person answerable when they are not. That function does not automate, because you cannot sue a model and you cannot reassure a frightened customer by pointing at a server.

So the roles that would survive stronger are the ones where liability sits heavily on a named person / role, almost regardless of how hard the underlying tasks are. E.g. a ship’s captain does little that is technically difficult on a calm day, and the role is not going anywhere, because someone has to be the person who answers for the vessel. A radiologist survives for the same reason a notary does, not because their tasks share any difficulty, but because both are structured so that one human carries the consequence. Meanwhile, plenty of cognitively hard work with no concentrated liability, technical translation, draft document review, quant research support, automates quickly precisely because no one needs a throat to choke when it is wrong.

This is my second prediction, and it is also highly testable: rank roles by concentration of liability rather than by task complexity, and that ranking should predict survival better. If complexity turns out to predict it better after all, then yes, again, the model needs a more sophisticated articulation.

Put the two together and my advice for anyone running an organization is concrete - stop auditing your jobs for which tasks AI can take, because that only ever tells you how to get smaller. Audit instead for two things:

• first, which freed tasks could combine into a role you do not currently have, because that is your next hire and probably your next advantage.

• second, for each existing role, ask whether anyone is genuinely accountable underneath the tasks, because if the answer is no, you were funding a task that wore a job title, and AI is only going to make that more obvious.

I strongly feel that the roles worth protecting are the ones would be where a human carries the weight when it goes wrong, and the rest were always just tasks waiting for their price to fall.

Anthropic and OpenAI both launched AI services ventures this week, backed by billions from Blackstone, Goldman Sachs, Hellman & Friedman, TPG, and Bain. The timing wasn’t coincidental and the logic was identical: the models are ready, the organizations are not, and closing that gap is large enough to build multi-billion dollar businesses around.

What both announcements said pretty clearly is that model capability alone doesn’t produce business outcomes. Right. Dario put it plainly: enterprise demand for Claude is significantly outpacing any single delivery model. The services arm is the response to that signal.

But i think that the gap is deeper than the technical framing alone suggests.

Getting an agent to work reliably in a business process requires someone to articulate that process with a level of precision most organizations have never needed before (yes, you know that.)

What is the goal? What does good output look like? Where does human judgment stay in the loop? Most processes have answers to those questions living partly in someone’s head, partly in an outdated document, and partly in informal corrections that experienced people apply automatically without ever writing down. I’ve been doing this work hands-on and the thing that still consistently surprises people (especially those who are still stuck with asking ChatGpt for email rewrite) is how much of the challenge has nothing to do with the tech at all.

The IT integration is solvable; the question that takes the longest (and occasionally exposes things leadership would rather not examine) is whether the organization can clearly describe what it’s actually trying to accomplish.

For anyone who understands the PE model, the structure of the Anthropic venture matters for a reason beyond distribution. Blackstone owns 250+ portfolio companies. PE firms operate on compressed timelines with explicit return expectations, which is incompatible with the “let’s run a pilot and revisit next quarter?” approach most enterprises take. One of the most consistent failure modes in enterprise AI is that initiatives get launched and then stall when the work of actually changing how people work runs into organizational friction. PE ownership removes some of that insulation in a way a vendor relationship cannot.

My honest read on both announcements is that the labs can serve companies that are already ready, and through PE, companies that will be forced to get ready on a compressed timeline. What fills the gap for everyone else - the companies without PE ownership, without organizational clarity, without internal deployment capacity - is the more interesting question for the next 18 months.

ps - while writing this article i realised that i have to write a follow up piece soon on the bit i mentioned above 👇

The IT integration is solvable; the question that takes the longest (and occasionally exposes things leadership would rather not examine) is whether the organization can clearly describe what it’s actually trying to accomplish.

There’s a line in a piece i read this week that i haven’t been able to stop thinking about.

“the people with authority over how organizations adopt AI are the people with the least firsthand experience of what these tools can actually do.”

I’ve sat in enough rooms to know this is true, and i think the second-order consequences for enterprises are more serious than most leadership teams are willing to say out loud.

The traditional argument for seniority rests on three things: pattern recognition built over years, the ability to retrieve the right analogy at the right moment, and the judgment to know when to commit and when to hold. These were genuinely scarce skills for a long time, and they were scarce because building them was expensive - in time, in exposure, in the cost of being wrong enough times to learn something.

AI is compressing all three simultaneously, and faster than most senior operators have noticed.

A junior analyst who can generate five competitive positioning scenarios by end of day isn’t slower than the senior strategist who’s seen this before; a second-year lawyer who can surface every relevant precedent in minutes isn’t at the retrieval disadvantage she used to be; and a product manager who can launch, kill, and relaunch in an afternoon doesn’t need to spend six months building the case before she earns the right to try something.

What’s left, then, is the part of seniority that was never really about skill - the accumulated credibility that makes public wrongness expensive, the identity tied to past decisions, the unconscious filter that discards honest insights before they finish forming because the environment has trained you to run it automatically.

The enterprise implication is uncomfortable - most organizations are making their most consequential AI decisions through people whose daily experience of the technology is the furthest from the frontier. The CIO setting the AI strategy who hasn’t opened the tool, the CMO approving the roadmap who learned “openclaw” from a conference deck, and the CFO evaluating AI ROI using frameworks built for a different kind of investment entirely.

This isn’t an argument that experience is worthless - Real judgment (the kind that comes from having been genuinely wrong in consequential situations and having learned something from it) is still rare and valuable. But it arrives in the same package as accumulated aversion to risk, protected decisions, and the version of the story already told to the board. And i see it around - even the person carrying it can’t always tell which is which.

The organizations that will navigate this well are the ones that find ways to get their most experienced decision-makers into genuine daily contact with these tools - not demos, not summaries, not filtered briefings, but actual use. And the ones that create enough psychological safety for what a 22-year-old figured out in an afternoon to actually reach the room where the decision gets made.

The gap between the two groups is widening by the month, and the decisions being made in that gap are not small ones.

I’ve been doing this hands-on for the past year, and what strikes me is how much genuine effort it requires and how rarely anyone talks about that honestly. Like a lot of things in life, the outcome gets all the attention while the setup gets none of it

Before an agent can do meaningful work inside any business function, someone has to make the unstructured data legible - years of documents, emails, notes, and tribal knowledge that lives nowhere an agent can read. Someone has to map the actual workflow, not the sanitized version on the org chart but the one that really runs, with all its workarounds and undocumented judgment calls baked in over years. Someone has to figure out which parts the agent handles well, where it breaks down, and where a human needs to stay in the loop. Someone has to connect systems that were never designed to talk to each other. And then someone has to rebuild the process itself, because the old one was designed around human constraints that no longer apply.

This is what the conversation in that room kept coming back to. Everyone is focused on what agents can do, and very few people are thinking seriously about the work required to make them actually useful inside a real organization. It doesn’t make for a good conference talk, and it won’t show up in anyone’s AI transformation case study. But it’s the work that determines whether any of the AI investment produces something real, and the people who can do it well are genuinely rare right now.

What I find most exciting is what this means for people early in their careers. This is one of those unusual moments where curiosity and willingness to get into the operational weeds matters more than seniority. The person who spends the next 18 months going deep on this - learning how to set up and redesign workflows for agents across any business function - is going to be valuable in a way that compounds pretty quickly.

Every organization is going to need people who can do for AI agents what good engineers did for software in the early 2000s: go in, understand the domain, and rebuild the infrastructure from the ground up. That wave created a generation of people who became indispensable fast, and this one will too.

Every AI ROI conversation in marketing (and I am sure pretty much all of GTM) right now sounds roughly the same - “we used to spend eight hours on this report, now it takes two”, “we used to produce four content variants, now we produce forty”, “we used to take three days to build a campaign brief, now it’s three hours”.

These are real numbers and certainly represent real value, but they are also almost entirely the wrong thing to be measuring.

Time saved on existing tasks is the floor of what AI makes possible in marketing, not the ceiling. The teams treating it as the ceiling are optimizing themselves into a comfortable version of the same limitations they’ve always had.

When you apply AI to an existing task, you implicitly accept that the task was the right one to begin with - that the workflow was correctly designed and that the output was the right output and the only question was how fast you could produce it.

But, most marketing workflows were not correctly designed.

They were designed around constraints - of time, of headcount, of data access, of technical capacity - that shaped what was even considered possible. You didn’t build a process to analyze every support ticket for product marketing signals because no team could do that at scale. You didn’t build a process to research every target account before outreach because the math didn’t work. You didn’t build a feedback loop between win-loss data and campaign messaging because nobody had the bandwidth to close that loop weekly.

Those weren’t strategic choices but rather capacity choices that hardened into process.

AI doesn’t just speed up what you were already doing but makes previously impossible tasks viable. The teams that understand this aren’t asking “how do we do our current work faster.”, but instead “what work could we now do that we couldn’t before” - and then rebuilding their function around the answer.

The marketing teams that are genuinely ahead right now share one characteristic: they’ve identified at least one capability they now have that simply did not exist for them twelve months ago. This isn’t a faster version of something old but a new thing entirely.

Signal coverage at a scale that wasn’t workable before - e.g. monitoring buying intent across hundreds of accounts and routing it in real time. Content personalization that wasn’t economically viable - tailored by industry, role, buying stage, and account history without a dedicated writing team. Research depth that wasn’t feasible - competitive and account intelligence synthesized before every meaningful sales interaction, not just the big ones.

They are new capabilities, not just efficiency gains, and they require not just new tools but new process logic - designed around what AI can actually do rather than retrofitted onto what humans were already doing

The reason most teams stay stuck in efficiency framing is that efficiency is easy to measure and capability expansion is not. Hours saved has a number - “we can now do something we fundamentally couldn’t before” doesn’t fit neatly into a productivity dashboard (which your CXOs care about a lot ;) )

But that’s the metric that will actually separate the teams that look transformed in three years from the ones that just look faster. Not how much time they saved on existing tasks but what new tasks they built their function around.

Most teams are optimizing for the former - i hope you are not :)

There’s a Claude feature that shipped recently that i think has more enterprise implications than most people are treating it as yet.

Claudes memory import - you run a prompt inside Chatgpt or Gemini, it exports everything those models have learned about you - your communication style, your projects, your preferences, your working context - and you paste it into Claude. One copy-paste and claude picks up where another AI left off.

On the surface this looks like a switching cost feature, a consumer convenience, or competition between AI vendors fighting for retention.

I think it is more than that → at least three things simultaneously - a governance problem, a competitive intelligence risk, and the opening move in a platform war that is going to get ugly in ways the tech industry has seen before.

Memory is not a knowledge base

This is the distinction most enterprise AI conversations are still wrapping their head around, and it matters enormously for what comes next.

A knowledge base is explicit - the the system prompt your team wrote, the style guide you uploaded, the instructions someone encoded: always write in second person, never use jargon, do not use choppy sentences, our ICP is mid-market SaaS. You can read a knowledge base, audit it, version control it and hand it to a new employee on day one.

Memory is different- it is what the model infers from watching you work over hundreds of conversations - not what you told it, but what it noticed. The way you tend to reframe a question before you answer it, the fact that you write three drafts before you’re satisfied and you always cut the first paragraph, that you soften feedback with context before you deliver it, that when you say “interesting” you usually mean “i disagree.”, and that your strategic instincts run ahead of your data and you know it, so you ask for pushback.

None of that is in your skills.md or system prompt. You could not encode it if you tried - partly because you’re not fully aware of it yourself, and partly because the value is in the accumulation and texture, not in any single rule.

This is what twelve months of AI interaction actually produces —> not a better chatbot, but a model of how you think, and now that model is portable.

Umm, how is this an enterprise problem? what do we call it?

Most enterprise AI deployments assume a relatively clean boundary between the tool and the user. The company licenses the platform, sets the guardrails, owns the data layer, and the employee uses it within that context.

Memory portability breaks that model in at least three ways:

1. The first is context leakage: when an employee exports their AI memory from a company-licensed Chatgpt enterprise instance into a personal Claude account, what exactly are they moving? Technically it’s their preferences and communication patterns, but practically, those patterns are built on months of work conversations, internal project context, proprietary framing, strategic language absorbed from working on confidential things. The memory is not the data, but the memory is shaped by the data. That distinction is going to get tested in legal contexts that i don’t think have good precedent yet.

2. The second is institutional context loss: enterprises have spent the last two years trying to capture organizational knowledge - what sales learned from a lost deal, what a departing engineer knew about a system, what a senior marketer’s instincts were built on. AI memory is, quietly, becoming one of the richest repositories of individual working context that has ever existed. When someone leaves and takes that memory with them, or when a team migrates tools and the memory doesn’t transfer cleanly, enterprises lose something they don’t have good language to describe yet - it’s not a file, or a document, but closer to losing the person’s judgment - a distilled version of how they approached work, sitting inside a model they’re taking with them.

3. The third is governance without visibility: most enterprise AI policies are tool-level policies, i.e. which platforms are approved, what data can be uploaded, which outputs need review etc. Memory portability makes the unit of governance the individual rather than the tool - and enterprises are nowhere near equipped for that. Your CIO/CISO can audit what your employees uploaded to Chatgpt but cannot audit what Chatgpt learned about your employees over eighteen months of conversations, or where that learned context went when someone switched platforms last Friday.

Wait.. is there a GTM implication we need to talk about?

Of course we do..and i think sales and marketing are probably the most exposed here, and not for the obvious reasons.

The obvious reason feels like customer context: e.g. if a sales rep builds twelve months of deal history, objection patterns, and relationship nuance into their AI memory, and then leaves - or switches tools - that context walks out the door in a way that is harder to track than a downloaded Salesforce export.

The less obvious reason is that AI-assisted communication is becoming personalized at a level that reflects the individual, not the company. When a sales rep uses an AI that knows them deeply - their persuasion style, their customer vocabulary, their instinct for when to push and when to wait - the output starts to reflect a cognitive fingerprint as much as a company playbook. The line between “company voice” and “individual voice enhanced by AI” is dissolving; that has implications for brand consistency, for training, for what you actually lose when someone leaves.

The even less obvious reason is competitive intelligence - your AI memory reflects what you worked on. If a competitor hires your VP of Demand generation and that person imports their AI memory into the new company’s tools, you have not lost a google slides or power point deck, but potentially a distilled model of how your best marketer thinks about your category, your customers, and your strategy. The subtle stuff - the framing instincts, the prioritization patterns, the things that made them good - compressed into a transferable file.

It is already happening right now, invisibly, at companies that have no policy framework for it, and it’s only going to get harder from here.

Here’s the platform war i think this is about to trigger

This gets interesting at the vendor level, because the AI companies are about to face a strategic tension that every major platform company has faced before - and most have handled badly.

Right now Claude is making memory import frictionless because they are the challenger - they want to make it easy to leave Chatgpt and that is rational. Every platform that is behind on market share has played the interoperability card. Google made it easy to import contacts from Yahoo Mail, Spotify made it easy to transfer playlists from iTunes, Notion made it easy to import from Evernote and so on. The message is always the same: your data belongs to you, switching is painless, come on over.

What happens next is also predictable, because we have seen this movie before :)

Once the challenger becomes the incumbent - or even before, once they have enough users invested - the export experience quietly degrades. Note that it doesn’t eliminate, just degrades. The import button stays prominent, but the export button moves two menus deep, the data format becomes slightly proprietary, the exported file works technically but loses fidelity etc.

Facebook made it easy to import contacts for years, then made the exported data progressively less useful anywhere else. Linkedin imports your resume beautifully and exports a PDF that no other platform reads cleanly. Apple’s ecosystem is the canonical example of this - every piece of hardware imports from competitors gracefully, and exports to them in formats that technically comply with data portability regulations while practically making migration painful enough that most people don’t bother.

The AI memory version of this is going to be more subtle and more consequential than any of those. Because what degrades in export is not a contact list or a playlist, but an inference layer - the subtle cognitive pattern that made the memory valuable, and is genuinely hard to serialize cleanly. Which means vendors have a convenient technical excuse for lossy exports that will be very difficult to distinguish from deliberate friction.

The savvy AI vendors will also start building memory experiences that are structurally hard to replicate elsewhere - and i don’t think it will be done through lock-in of data, but through lock-in of depth.

The longer you stay, the more the model understands the things that cannot be encoded in a prompt, and thus the more it knows, the worse the cold-start problem feels when you switch. That is not a moat built on data, but built on accumulated inference, and it is significantly harder to regulate than traditional data portability because nobody can agree on what you would even export.

Enterprises buying AI platforms right now are making decisions that will look very different in three years when the export experience has quietly evolved. The procurement checklist for AI tools is going to need a new section: not just “can we export our data” but “can we export the thing the model learned, and does the export actually work.”

So, what good looks like?

Most enterprises are not ready for this conversation, but i think there are a few things the fast movers would do:

1. They would treat AI memory as an asset class, not a feature - - this means asking: what is accumulating inside these tools, who owns it, and what happens to it when people and platforms change?

2. They would update their offboarding processes: the same way a thoughtful legal team asks a departing employee to return physical materials and revoke system access, some companies would begin to ask: what did you export, and what did you bring with you? This sounds invasive today, but is probably going to become standard.

3. They will start thinking about memory architecture at the team level - the goal won’t be to prevent employees from having useful AI context, but to make sure that context doesn’t live entirely in individual memory stores. For example, shared projects, shared prompts, shared context documents that sit at the team layer and survive individual transitions. The challenge is that the most valuable parts of memory - the subtle inference layer, the cognitive pattern - would resist this. You can share a knowledge base, but cannot easily share what the model inferred from watching someone think.

And the smarter procurement teams would begin to start asking vendors harder questions about memory portability before they sign. Not “do you support export” - every vendor will say yes. But “show me what the export looks like in 18 months of usage, and show me whether another platform can actually use it.”, “Can i control what the export looks like in Enterpise versions vs. Consumer/personal versions”, “Can i track how many employees have hit the export/import button in last 3 months?”

I think the last question is going to separate vendors who believe in portability from vendors who are using portability as a growth lever while quietly building the walls.

But, oh the irony

The feature that makes AI more useful - continuity, context, not having to start over - is the same feature that makes the governance problem harder and the platform lock-in deeper. An AI that truly knows how you work is more valuable to you precisely because it captured the things you couldn’t have written down yourself; that’s what makes it powerful and that’s also what makes it ungovernable by conventional means, and what makes the cold-start cost of switching grow invisibly over time.

We have spent decades arguing about data portability at the file level, and now we are about to have a much stranger version of that argument at the cognition level.

The policy frameworks, the legal precedents, the offboarding checklists - none of them exist yet for this. For sure, the platform playbooks exist, and we’ve seen every move before.. it’s just that we just haven’t seen them played with this kind of asset.

There’s a quiet assumption baked into almost every B2B SaaS product ever built, and nobody wrote it down because it was pretty obvious: the customer is a human.

You can see that assumption everywhere once you look:

• signup flow that requires a verified email and a credit card (oh yes, that card has to be linked to a human)

• onboarding sequence that sends three welcome emails and waits for someone to click through them to decide what’s the next best event-based nurture they should put you in (we’ve all built event-based nurtures, haven’t we?)

• the permission prompt written for someone who is reading it carefully

• Billing page designed around a person who will notice the charge, react to an anomaly, and make a decision

Every friction point, every design choice, every assumption about how a new user enters and moves through a product - all of it was built for someone with eyes, opinions, and a mouse.

But, that assumption is quietly becoming the most expensive technical debt in B2B software.

For most of the history of the internet, bots attempting to automate account creation were a problem to be eliminated, not a segment to be served. They were spammers, scrapers, fraudsters running volume plays, so the industry responded rationally: CAPTCHA, email verification, manual review queues, credit card requirements on free tiers, and tons of startups and enterprises who helped you solve for it. There were still gaps in the tooling, and that’s why you saw your monthly activations climb to a 25% Y/Y growth on Sep 1, but after 6 weeks of manual bot/fraud tagging and threshold adjustments, it’d dip to 12%. Every tooling was designed to ensure a human being was on the other end of every new account.

This is what Jared Friedman shared last week:

Agents are being deployed inside enterprises to research vendors, evaluate tools, spin up trial accounts, run integration tests, and return a recommendation. They are doing work that a junior analyst or solutions engineer used to do, acting as the first touch in a procurement motion before a human ever gets involved. And they are hitting walls at every step - because the entire infrastructure of B2B software was built for someone who can read a modal, click a verification link, and fill out a form.

The shift that is coming is not about adding an API to a product that was built for humans- most SaaS products already have APIs.

The gap is everything around the API: the human-assumed infra that agents cannot navigate and were never meant to:

• Account creation requires clicking a verification link sent to a human inbox

• Core functionality sits behind an onboarding flow designed for people who need to be taught

• Scoped access requires navigating a permissions UI that assumes someone is reading and deciding

• billing requires a credit card attached to a human account

• Error states return modal dialogs written for a person to read and respond to, not structured data a system can parse and act on.

An agent encounters all of this and stops; not because it isn’t capable -but because the product wasn’t designed to be used by anything other than a person. The product either supports programmatic interaction from the first touchpoint or it doesn’t, and there is no patient middle ground where an agent eventually figures out your welcome email sequence.

Agent-native software is built differently from the ground up - (a) account creation via API without human verification steps, (b) scoped, programmable access controls configurable without a UI, (c) usage-based billing attached to an agent identity rather than a human credit card, (d) onboarding expressed as documentation and endpoint behavior rather than guided tours and drip campaigns, (e) errors that return structured, actionable data rather than messages written for human eyes etc.

For most SaaS companies, closing that gap means revisiting assumptions that run years deep - the signup architecture, the billing model, the permission layer, the way errors surface..none of it is cosmetic, ha! All of it was designed around a user who shows up, clicks around, develops preferences over time, and has a relationship with the product. Alas, agents don’t do any of that.

The second order implication is the one most product teams aren’t thinking about yet: who gets chosen. In a world where agents are assembling their own stacks, the selection dynamic changes fundamentally.

E.g., a human evaluating tools does research, reads reviews, sits through demos, and builds vendor relationships over weeks. An agent picking a stack reaches for the tool it can use without friction - fully API-accessible from the first interaction, programmable, no human-in-the-loop required to get started. The decision happens in a planning loop, not a buying committee, and it is based entirely on what is available and what works.

The developer tools that understand this are not treating agent-readiness as a roadmap item for next year. They are rebuilding the front door - signup, access, billing, error handling - as if the first user through it might be a system rather than a person. That is not a small change in how a product is built, but rather in who the product is built for.

The companies that move fastest here don’t just acquire agent users. They get chosen first, repeatedly, at scale, by systems that don’t browse review sites or respond to outbound sequences. That is a fundamentally different kind of product-market fit than anything B2B SaaS has optimized for, and the window to build for it before it becomes table stakes is closing faster than most roadmaps reflect.

Your best future customer might not be human…the question is whether your product is aware of that.

Tom Tunguz wrote something quietly important last week - his inference spend went from $7k to $100k annualized in two quarters, and he framed it as the emergence of a fourth compensation component, salary, bonus, equity, and now tokens.

As i finished reading the article focusing on the fact that inference/tokens is potentially turning into a soft-compensation data, it also occured to me that for the first time in history, thinking is leaving a trace.

Every prior attempt to measure knowledge work collapsed into proxies, outputs, and a lot of theater. For example, OKRs measured what you shipped, not how you thought. Stack rankings, something i continue to detest to date, measured perception as much as performance. Even the most sophisticated people analytics tools were fundamentally backward-looking, reconstructing cognitive effort from artifacts that were already weeks old by the time anyone looked at them.

The work itself, the actual motion of a mind engaging with a problem, left nothing behind. Inference spend changes the texture of that problem in a way that’s easy to underestimate.

For the growing layer of work that runs through observable infrastructure, what is emerging is a real-time record of cognitive activity:

• A solutions engineer who spends three hours in Claude iterating on a technical proof-of-concept, running fifteen variations before landing on the right architecture, leaves a very different token signature than someone who generates one response and pastes it into a deck unchanged

• Or, a marketing strategist who uses AI to pull competitive intelligence, stress-test messaging against six different buyer personas, and rewrite a positioning brief four times before sending it to the CMO looks nothing like someone who asks AI to clean up a paragraph

The signature reveals how fast someone moves from problem to action, how deeply they iterate, whether their tool usage reflects genuine problem-solving or the appearance of it etc. These signals are imperfect, but once signals exist, organizations find ways to use them (e.g. Github commit logs for engineering productivity, email response time as a performance and team satisfaction signal, Slack activity metrics becoming a management tool, and so on).

This lineage adds a lot of resolution to the gap between perceived and actual contribution. Every organization carries this gap, between the person whose perceived contribution matched their actual output, and the person who was believed to be indispensable based on presence, confidence, and the complexity they added to simple things. That gap persisted because knowledge work was unobservable. Inference data doesn’t close it overnight, but it introduces a pressure that compounds quietly over time.

I think this matters most for the knowledge worker whose value lived in the white space, the person who coordinated, held institutional memory, and shaped decisions without owning them. That contribution is real, but it was evaluated mainly through social proof rather than evidence, and opacity was very protective. It’s becoming something you now have to actively maintain.

The other deeper irony worth talking about is that the same AI infrastructure compressing the cost of execution is simultaneously making the quality of judgment more legible than it has ever been. These two forces are usually discussed separately, one as a productivity story and the other as a surveillance concern, but they are the same phenomenon viewed from different angles. The token is both the unit of production and the unit of measurement, and that duality is entirely new.

Tom got to 12% of his original inference cost over a weekend with identical performance. The person still burning $100K in tokens had better be producing something meaningfully different, and now there are tools to check.

We spent fifty years trying to measure knowledge work and failed because thinking left no trace. The token doesn’t solve that completely, but it solves enough that the underlying assumptions of how careers are built and how value is attributed are quietly due for revision. Worth thinking carefully about what those tokens will say about you 🤖

Marketing attribution has always been a mess, but it was a manageable mess. You had a finite number of channels, a rough methodology, and an unspoken agreement across the organization not to look too hard at the math 🤫. Multi-touch models distributed credit across touchpoints, position-based models weighted weighted the first and last interactions more heavily, time-decay models favored recency, and the most sophisticated teams experimented with causal and incrementality frameworks to get closer to the truth. Everyone had a preferred model, and everyone moved on. Budgets got allocated, campaigns got greenlit, and the imperfection was tolerable because at least it was consistent.

AI has broken that truce, and it has done it in several directions at once.

Let’s start with a buyer journey you and I can relate to.

A VP at a mid-market company starts researching your category. She opens ChatGpt and asks it to summarize the competitive landscape. Your brand appears in the output, framed in language you didn’t write and can’t control yet, and she forms an initial impression before ever touching anything your team can measure. That interaction never appears in your attribution stack; it happened, it mattered, and to every platform in your revenue stack it simply doesn’t exist.

A week later she visits your website after a colleague mentions your company in a slack channel. She lands on a page dynamically generated by your new AI content engine based on her firmographic profile. She spends four minutes on it, reads the case study section, and scrolls to pricing. Your CMS logs the session but has no way of knowing the experience she had was entirely different from what your last visitor saw. The personalization worked, but the signal is lost.

Your AI SDR then sends her a sequence two days later, triggered by an intent signal from a third-party provider. She doesn’t reply, but she reads it carefully and forwards it to a colleague with a note saying “this is exactly what we need.” That forward, arguably the most valuable signal in the entire journey, generates no data whatsoever. Three weeks later, after attending an AI-summarized recap of a virtual panel she never actually watched live because the agenda felt too boring, she books a discovery call. Your W-shaped or time-decay attribution model assigns the majority of credit to the content syndication touchpoint that happened to fire the day before she converted.

That is not a hypothetical anymore. That is tuesday.

The most sophisticated revenue teams today have obviously moved well beyond single-touch models. Not promoting any of these, but several platforms such as Hockeystack, Dreamdata, and Segmentstream etc. have done some really good work around account-level journey mapping, connecting CRM data to multi-touch influence across buying committees rather than individual contacts. The shift from contact-level to account-level attribution was the right move, and the teams that made it early are measurably better at understanding pipeline than those still working at the lead level.

But pretty much all major platforms are running into a structural wall that better tooling alone cannot solve. They can track what happens inside the observable infrastructure (your website, your Crm, your ad platforms, your marketing automation etc.). What they cannot see is the rapidly expanding layer of AI-mediated research that happens before a buyer ever touches anything you own. Quotes from research firms have been varying, but the median range suggests B2B buyers complete somewhere around 60-70, in some cases up to 75 percent of their evaluation before engaging with a vendor directly. AI tools are accelerating that shift, and the gap between where influence actually happens and where your attribution platform looks for it is widening every quarter.

The deeper problem is a closed loop that is going to compound over time. AI-powered attribution platforms are being used to measure journeys that are increasingly shaped by AI-generated touchpoints. The model tells you what’s working, you invest more in it, the model gets trained on that investment pattern, and the cycle reinforces itself regardless of whether the underlying causal logic holds. An account-level journey platform might correctly identify that accounts engaging with your thought leadership content convert at a higher rate. What it cannot tell you is whether your thought leadership is influencing those accounts, or whether accounts that were already inclined to buy are simply more likely to consume content along the way. The correlation is real, but the causality is still pretty much assumed.

The reframe i think matters more

The instinct when measurement breaks down is to find a better measurement tool; that instinct is understandable but increasingly insufficient. The more durable shift is a different philosophy entirely - one that accepts more uncertainty at the individual touchpoint level while deliberately getting sharper at the account and revenue level.

What does that actually mean in practice? It means treating account-level engagement velocity as a more reliable signal than any individual touchpoint. When multiple stakeholders at a target account are consuming content, responding to outreach, and engaging with your SDR motion within the same thirty-day window, that cluster of signals tells you something meaningful that no single attributed touchpoint can. The question worth asking isn’t “which channel sourced this opportunity” but “what combination of signals, across which roles, over what time horizon, correlates with accounts that close and then expand.”

It also means reorienting around outcomes you can measure with higher confidence rather than influence you can only approximate. Demand lift from ICP, pipeline velocity, the rate at which accounts move from first engagement to opportunity to close, is more honest than channel attribution because it reflects the aggregate effect of everything marketing did rather than a model’s best guess at decomposing it. Accounts that experience coordinated, multi-threaded engagement across marketing, SDR, and content tend to move faster. That observation is actionable even though as of today you can’t fully attribute why.

It also means figuring out innovative ways to invest in qualitative feedback loops that no platform can replace. win-loss interviews conducted within two weeks of a decision remain one of the richest sources of influence data available to any marketing team - what buyers say shaped their decision, which competitors they seriously evaluated, where they first heard about you etc. Most teams treat these as a nice-to-have, but the best ones are building systematic programs around them in close partnership with sales.

Unfortunately, i know very few teams doing genuinely good work here - and the ones that are have stopped arguing about which metrics to pick for annual planning, or how to combine MMM, MTA and other frameworks to do channel allocation in isolation.

The budget meeting nobody is ready for

Q1 is almost about to end and before we know it, we will be Q3. At that point, most marketing teams will start thinking about FY2027 planning with attribution data that is confidently directional but structurally incomplete in ways they cannot detect. The channels that receive the most credit will be the ones easiest to observe, not necessarily the ones doing the most work. There will be an ask from CMO to cut down the budget, and when it comes to annual budget reductions, no one would care about the attribution model anyway - the investments most at risk of being cut would be the ones operating furthest from conversion, building the brand presence and thought leadership that shapes AI summaries, peer conversations, and dark funnel research months before a buyer ever raises their hand.

The measurement gap is real and it will not be closed by the next generation of attribution tooling alone, at least not in the near term.

I am getting back to the world of marketing strategy and analytics after a bit of focus on Growth and Innovation. And, i am very excited to build novel approaches to think about where should $$ go and be tracked and validate some of the new world hypotheses i have, along with my marketing, sales and broader GTM friends.

Will share more as i learn more.

Three months later, it’s still not in production. The team is firefighting issues nobody anticipated, and the business is wondering why this “simple” AI project which was live on Twitter in a week consumed so much time.

GenAI models are powerful, but they know nothing about your business. They don’t know your products, customers, processes, or institutional knowledge. That information has to be found, organized, kept current, and delivered to the AI at exactly the right moment.

This is the knowledge layer problem. And it’s the #1 reason production deployments take longer than anyone expects.

The pattern is familiar across enterprise technology. New capabilities arrive with impressive demos. Then teams discover the real work is in integration, data, and processes - not the technology itself.

The technology always works. The integration work is where teams spend their time.

We’ve seen this movie before, haven’t we?

There’s a pattern in technology that keeps repeating - a powerful new capability arrives and early demos are magical. Then reality sets in, and the bottleneck turns out to be something unglamorous that has nothing to do with the technology itself.

The internet democratized information but we got more confusion alongside more access. Cloud computing made servers trivial to provision but companies found their AWS bills spiraling and systems just as complex as before.

GenAI is following this exact path. The models are incredible. Using them in production requires solving a massive knowledge management problem that most companies didn’t know they had.

We’re calling this “AI deployment” but the AI is actually the easiest part. What we’re really doing is confronting decades of poor knowledge management. The AI just makes the problem impossible to ignore.

The five knowledge layer problems breaking GenAI

(1) your knowledge lives everywhere (and nowhere)

Companies look at their documentation and think “Oh, the knowledge problem is solved. We have Confluence, CRM, support tickets. Just point the AI at it”.

This is like looking at books thrown across different buildings with no catalog system and thinking you have an organized library.

What usually ends up happening is that the Product documentation in confluence hasn’t been updated since the last release eight months ago, latest features exist only in Jira tickets and Slack channels.

Sales methodology is scattered across google drive with 47 folders. Files named “Sales Playbook Final v3” and “Final ACTUALLY FINAL.” Nobody knows which is current. Different regions have contradicting versions.

Customer success processes are in Notion. But the real knowledge - the workarounds that work - lives in Slack.

“Ignore the official process, here’s what you actually do.”

Pricing is in spreadsheets by region. Special exceptions in email threads. Enterprise deals have custom terms in PDfs in someone’s drive.

Marketing campaign performance is split between google analytics, hubspot, salesforce, and that custom tableau or looker dashboard. Campaign strategies? Buried in quarterly review slides nobody looks at again.

Legal policies are in sharepoint or confluence behind access controls. Product roadmap exists in four places with four different versions.

Your GenAI needs all of this to answer one question. But first you need to connect 15 systems with different APIs and authentication, figure out what’s current, resolve conflicts, and handle the fact that half these systems don’t have APIs.

You spend three months getting access. Three more building connectors. Then you discover the real knowledge isn’t in any system - it’s in people’s heads and slack conversations.

(2) when you do find it, it contradicts itself

Product marketing says you integrate with “all major CRM systems.” Technical docs list salesforce, hubspot, pipedrive. Sales materials say “salesforce and others.” A case study mentions custom dynamics integration as well.

Which version should your AI tell customers?

Your return policy says 30 days on the website. Support knowledge base says 30 for standard, 90 for enterprise. An internal memo extended it to 60 for a promotion that maybe ended. Customer success tells people 45 days as compromise.

These contradictions exist everywhere. Policies change faster than documentation. Different teams optimize for different things. Special cases create exceptions never properly codified.

Humans navigate this through judgment and knowing who to ask. Your AI sees conflicting sources and guesses. The AI isn't always hallucinating - it's accurately reporting the conflicting mess you've been papering over with “just ask Sarah” for three years.

Most companies don’t have knowledge; they have information. Knowledge implies organization and a single source of truth. What they have is a pile of information with no systematic way to separate signal from noise. So, every company thinks their knowledge problem is “we need better search.” The real problem is you're searching through garbage.

Building a knowledge layer means someone makes hard decisions about what’s true and authoritative. This isn’t technical. It’s organizational - confronting how poorly managed your information actually is.

(3) keeping it current is harder than building it

Let’s say you do turn brave and manage to clean up contradictions, create one authoritative knowledge base, and now everything is consistent and up to date.

It’s out of date in a week.

Product launches a feature → pricing changes → legal updates a policy → you close a deal with special terms support needs to know.

There’s no pull request for “update the AI’s understanding of our pricing.” No automated test to verify the knowledge base reflects reality. No deployment pipeline.

Instead, someone is supposed to remember to update confluence, training materials, support knowledge base, tell the AI team, update sales decks, and notify everyone. Except they’re busy. They forget. Or update one place but not others.

The product team launches a feature and updates their docs. They don’t tell the AI team. Two months later, a customer asks your AI about it. The AI says it doesn’t exist. The customer emails support saying your AI is useless.

Or marketing runs a promotion changing pricing, updates the website, but forgets the knowledge base. Your AI quotes old pricing to prospects for three weeks.

This happens constantly. The knowledge layer degrades daily as business evolves faster than documentation.

By the time, teams reach stage 3 (if they do reach this stage), they realize that keeping a knowledge layer current is harder than building it. It requires processes, ownership, and ongoing maintenance. Most companies are terrible at this even without AI.

(4) different teams have different documentation standards

Engineering documents well. They have to. Code breaks if documentation doesn’t match. They use git, track changes, write specs, and all the other good stuff.

Sales and marketing are the opposite. And this is where customer-facing AI struggles the most with information.

Marketing launches campaigns constantly. Where’s the documentation of what worked? Scattered across post-mortem slides looked at once. Campaign briefs in one place, creative assets elsewhere, performance data in a third system, strategic reasoning nowhere.

Sales is not much better (umm, sorry my friends). Deal info is in salesforce but incomplete. Reps log the minimum required. The real information - why deals were won or lost - is in their heads or email threads not connected to CRM yet.

You want your AI to suggest sales strategies based on similar deals? The information doesn’t exist in consumable form. You have data points - deal size, industry, timeline. Not the story - what customers cared about, what objections arose, what messaging resonated. It’s easy to get that info but integrating is hard. Maintaining that integration is harder.

In the past a lot of teams got away with not documenting because they work through relationships and conversations. Engineering can’t because code either works or doesn’t. Sales and marketing could because success is fuzzier and knowledge is personal.

GenAI is forcing these teams to document things they never had to. They’re discovering it’s incredibly hard to retroactively capture years of institutional knowledge that only exists in heads.

(5) retrieval is a really hard optimisation problem

Even if your knowledge is centralized, consistent, current, and comprehensive - you still have retrieval.

Your knowledge base has 10,000+ documents. Someone asks: “What’s our refund policy for enterprise customers in europe?”

Your system must understand what they’re really asking, identify “enterprise” means specific customer segments, recognize “Europe” might have regional requirements, search 10,000 documents, find the right policy (not consumer returns, not general terms), find the section on geographical variations, check for recent updates, rank by relevance, assemble into context within token limits, and hope it’s right.

This fails constantly:

You retrieve a pricing document mentioning refunds in passing. It matches search terms but isn’t about refunds. The AI uses it and gives incomplete answers.

You miss the actual policy titled “Customer success remediation guidelines” that doesn’t say “refund” prominently.

You get the right document but wrong section - the policy differs for hardware vs software. The question didn’t specify.

You retrieve too much context and hit token limits. You drop the section about european requirements because it seemed less relevant, but that was the key part.

The policy was updated three months ago but the old version remains. Your retrieval finds both. The AI picks wrong.

Companies spend months tuning retrieval - trying different embedding models, adjusting ranking algorithms, experimenting with chunking strategies. You fix retrieval for one question type and break it for another. The issue is that you can't patch institutional knowledge debt with a better embedding model. This is like trying to fix a hoarder's house with a better filing system.

And what nobody talks about is that even with perfect retrieval, you’re constrained by context windows. This is definitely getting better but you’re always going to be trading off (at least for next 12-18 months) comprehensive context against some form of constraints (context, pricing limits etc.)

Intelligence without knowledge is just expensive guessing

Understanding this truly takes lots of doing the AI deployments in enterprises 👇:

Human expertise is valuable because humans compressed years of knowledge into intuition. They don’t retrieve documentation to answer questions all the time. They just know.

AI doesn’t work that way computationally - every answer needs explicit context retrieved fresh. No traditional human form of intuition, no compression, no shortcuts. Intelligence without internalized knowledge is inherently expensive and fragile.

Every interaction made without hardwired knowledge costs money - not just the API call, but the entire context assembly as well. Search your vector database - compute cost. Retrieve documents - storage and processing. Rank and filter - more compute. Assemble into context - 5k tokens before the AI thinks.

That $500 pilot becomes $15,000 monthly at scale. The context tax is real and unavoidable.

Knowledge is also political

Deciding what goes in the knowledge layer is also political. Sales wants competitive positioning emphasized. Legal wants compliance disclaimers. Marketing wants brand consistency. Customer success wants accurate timelines over optimistic ones.

When marketing says you “work with all major platforms” and engineering says “we support these three integrations,” which is authoritative?

The dirty secret is that companies don’t have a single source of truth because different groups benefit from ambiguity. Sales can promise features “on the roadmap” without committing. Marketing can claim capabilities that technically exist but aren’t production-ready. The reason sales doesn't document is the same reason they'll resist AI: the ambiguity is a feature, not a bug. Pinning things down reduces flexibility.

Making this explicit forces conversations organizations avoided for years. The AI project stalls not from technical problems but because nobody wants to resolve underlying ambiguity.

So how are some companies making it work so far?

Companies succeeding aren’t boiling the ocean but rather picking very narrow domains where knowledge is manageable. Instead of “answer any question,” they start with “help sales reps with pricing questions.” The knowledge layer for pricing is finite - 50 documents that change quarterly. They can keep this current.

They’re realistic about accuracy, build human review for important decisions and accept the AI will sometimes be wrong and design workflows that catch or mitigate errors.

They (and the leaders in the company) invest as much in knowledge management as AI, create ownership for the knowledge base, build update processes and treat documentation as a product requiring ongoing investment.

Most importantly, they stop calling it an AI project. They call it what it is: a knowledge management project that happens to use AI.

GenAI deployment is exposing what companies ignored for years: terrible knowledge management. Information scattered across incompatible systems. Documentation contradicting itself. Nobody knowing what’s current. Critical knowledge only in people’s heads.

This was always a problem. You got away with it because humans navigate ambiguity through relationships. AI can’t. It needs explicit, structured, current, consistent information.

GenAI is forcing companies to confront their knowledge management debt. The bill is higher than anyone expected. The demos work because oftentimes they use curated information in controlled settings. Production fails because reality is messy and nobody solved the underlying knowledge problem. We’re not in an AI deployment crisis. We’re in a knowledge management crisis that AI made impossible to ignore.

i have said this before as well - companies that succeed won’t have the best models or biggest budgets. They’ll be the ones that finally do the unglamorous work of organizing and maintaining their institutional knowledge.

The AI is the easy part. Everything else is hard.

Take project management for example - Microsoft project and Basecamp existed and worked fine for traditional project planning. But engineering teams doing agile development needed something quite different - sprint planning, story points, burndown charts, continuous deployment tracking. The initial artefacts of existing tools were built for waterfall, not iterative development. So I saw teams build their own: custom jira plugins, homegrown dashboards, internal sprint management systems.

By 2012-2013, enough companies had built similar solutions that entrepreneurs recognized the pattern. Atlassian evolved jira to support agile workflows. Asana and Monday.com launched with native sprint support. The custom solutions had revealed what the market actually wanted. This first cycle took roughly 5-7 years from widespread custom building (2006-2011) to mature packaged alternatives (2012-2014).

Then the cycle repeated: By 2016-2017, even these agile-native tools weren’t enough. Teams needed cross-functional coordination - linking github commits to jira tickets to production incidents to slack notifications. So they built custom integrations again: bots, webhooks, Zapier workflows, internal dashboards pulling data from five different tools. The pattern emerged again, and by 2019-2020, companies such as Linear, Height, Shortcut launched as “engineering-first” tools with native git integration and workflow automation built in. Another 5-year cycle.

For decades, this is how SaaS evolved through a predictable cycle: customers built custom solutions to fill gaps, entrepreneurs spotted patterns across these custom builds, and new packaged software emerged to serve the market. It was methodical and slow. That world is gone. AI is compressing these cycles from years into months - or in some cases even weeks.

The AI compression

AI hasn’t eliminated this evolutionary cycle but has dramatically accelerated it and changed how it manifests. Here’s what’s different now:

• Micro-SaaS explosions are happening in weeks, not years. Someone tweets “I built a GPT wrapper for sales emails” and within days, fifty similar apps launch. The market that took years to develop now consolidates to 2-3 winners within months. Look at AI SDRs for example: companies were building custom AI email workflows in early 2023, and by late 2023, 11x, Artisan, and AiSDR had all launched as packaged products. Six months later, companies are already building custom layers on top again - proprietary data enrichment, vertical-specific messaging, multi-channel orchestration.

• Configuration is becoming the new customization. You don’t need to build custom software anymore - you configure AI behavior through prompts and context. But this creates new standardization opportunities. Someone will package “the 50 best Claude prompts for sales teams,” people will customize those for their specific needs, and someone else will package those vertical-specific versions. The cycle runs faster because the barrier to both customization and packaging has collapsed.

• The cycle is oscillating continuously instead of proceeding in clean stages. Take tools built on Claude - companies build custom workflows, share what works on Twitter, others package those patterns into templates, users immediately extend those templates with their own modifications, and the cycle repeats weekly. Companies and their users are iterating together in real-time, over weeks instead of years, with each side learning from the other continuously.

• Distribution is becoming the moat, not product differentiation. When anyone can spin up an AI sales email tool over a weekend, Lavender, Instantly, and Smartlead all do roughly the same thing. Custom solutions using Claude and a CSV file work fine technically. But companies buy Lavender anyway not because it’s uniquely capable, but because enterprises trust known vendors. The cycle shifts from “build better capabilities” to “build trust and integration ecosystems.”

The fundamental insight remains true: packaged software emerges when enough customers want the same thing. But “enough customers” now means dozens instead of hundreds, and “emerges” means months instead of years. The cycle hasn’t disappeared but rather fractalized into multiple layers iterating simultaneously, each moving at AI speed.

So, what happens when building becomes free?

We’re not just seeing faster product cycles now but also watching the line between using software and building software disappear entirely. When you can describe what you want in plain english and have it exist seconds later, the old startup question “what should we build?” stops making sense. The hard part isn’t building anymore. It’s getting people to pay attention to what you built.

Software is becoming so easy to create that the code itself barely matters. What matters is whether people trust you enough to use your version instead of building their own.

Think about why salesforce still dominates CRM despite countless competitors with better features - not because salesforce has the best UI (umm!) or the fastest performance. It’s because your sales team already knows it, your CS team has dashboards built in it, your revenue ops have years of data there, and your finance team’s commission calculations depend on it. Switching would mean retraining 200 people, rebuilding 50 integrations, and risking your 2026 pipeline during migration. The switching cost is so high that even a meaningfully better product can’t win.

This is what “becoming the place everyone agrees to meet” means in practice. Products win by accumulating gravity - more users means more integrations, which means more consultants who know the tool, which means more templates and best practices, which means more new users. Once this flywheel starts, it’s almost impossible to stop.

The same logic applies to trust - when your procurement team evaluates AI tools, they’re not just comparing features. They’re asking: Will this vendor exist in two years? Will they keep our data secure? Do other enterprise customers use them? Can we get them SOC2 certified? Will our auditors approve this? A startup with better AI might lose to an established vendor simply because the buyer needs to justify the purchase to their boss, and “nobody ever got fired for buying [established vendor]” still holds true.

This dynamic creates several specific implications for what comes next:

• Vertical software might disappear. Why would a hospital buy “AI medical scribe for radiology” when they can take Chatgpt Enterprise and load it with radiology protocols in an afternoon? The value shifts from vendors who hard-code industry knowledge into software to platforms that make it trivially easy to add any context. Doximity and Athenahealth spent years building healthcare-specific features. Now a general AI platform with the right prompt library might be good enough.

  

• Professional services will become way more valuable than software. If the code is commoditized, the humans who configure it capture more margin. Look at what’s happening with Zapier and Make - the platforms are cheap, but companies pay consultants $200/hour to design the right automation workflows. As AI makes building easier, implementation and strategy consulting could become more lucrative than selling licenses. The Accentures of the world might matter more than the SaaS vendors.

  

  
  

• Integration access will become the real moat. When twenty AI SDR tools use the same underlying models, the winner is whoever has the deepest access to salesforce, outreach, linkedIn, and zoomInfo APIs. The product moves beyond AI to having OAuth connections to 50 enterprise systems and the ability to read context from all of them. This is why salesforce and hubspot are building AI features aggressively: they already own the data pipes.

• Software will become ephemeral and generated on-demand. Instead of maintaining one product for thousands of customers, why not generate a custom version for each buyer? Imagine an agentic layer that spins up a bespoke CRM for your specific sales process, generates it fresh when you sign up, and throws it away when you churn. Software starts looking more like consulting deliverables than traditional SaaS - built once per customer, not built once for everyone.

• Compliance timelines will end up becoming the biggest bottleneck. In regulated industries, getting SOC2, HIPAA, or FedRAMP certification still takes 12-18 months no matter how fast you ship features. First movers who clear compliance hurdles get 12-month head starts that are almost impossible to overcome. By the time competitors get certified, the market has already moved to the next thing. Harvey (legal AI) and Nabla (medical AI) are winning because they got through compliance first and not because they have better models.

• Community becomes uncloneable. I love this one! When your product can be replicated in a weekend, the community around it can’t be. Notion’s 10,000 template creators, airtable’s consultant network, figma’s design system libraries - these took years to build and can’t be copied by a competitor with better features. The software becomes the excuse to join the community, not the product itself.

I believe that this evolutionary cycle will keep going. But when evolution happens this fast, we’re not watching slow adaptation over years - we’re watching new species appear every week.

The companies that survive won’t necessarily be the best builders or the fastest movers. They’ll be the ones that understand what actually matters has shifted: from “can we build this?” to “do customers trust us enough to use our version instead of the fifty others launched this month?” Building the product is table stakes now. Everything else - the integrations, the compliance certifications, the consultant networks, the community - is what’s going to determine who wins.

Here’s what actually happened:

• Relational databases in the early 2000s couldn’t efficiently store unstructured relationship data, so CRM platforms adopted stage gates from traditional sales methodologies as the core data model. We invented discrete stages - MQL, SAL, SQL, Opportunity - because that’s what our systems could process and what aligned with how databases needed to structure information.

• Sales teams couldn’t engage with thousands of inbound leads simultaneously, so we created lead scoring that assigned points (50 for a whitepaper, 100 for pricing page visit), and later progressed to more sophisticated scoring, as a prioritization mechanism, even though these scores often didn’t correlate well with actual purchase intent.

• Marketing automation platforms had no way to generate personalized content at scale, so we created segmentation frameworks and called them “buyer personas.”

These were reasonable engineering solutions to real constraints. The problem is we forgot they were engineering solutions.

We optimized everything around these constraints. Lead scoring became increasingly sophisticated - ensemble propensity models with demographic, behavioral, engagement, firmographic, and third-party signals (guilty) - but it remained just a prioritization mechanism for scarce sales capacity. Nurture tracks became elaborate multi-touch sequences, but they were still batch processing. A VP of Engineering at a fintech company and a CFO at a healthcare provider would both get the same lead score and enter the same nurture track, receiving identical emails over six weeks even though one cares about technical architecture while the other cares about ROI.

We knew this was suboptimal, but our systems couldn’t handle more. Platforms slowly evolved - we added personas and channel mix, built dashboards to show funnel by those dimensions - but these were incremental and siloed improvements within the same constraint-based framework.

With what I’m seeing at Twilio and elsewhere, I’m hopeful we’ll replace this narrative soon.

AI systems can now maintain complete contextual memory for thousands of accounts simultaneously - every interaction, signal, and conversation across years. They engage at whatever velocity each account needs and generate genuinely personalized narratives. The technical limitations that necessitated the funnel are disappearing.

What I’m most excited about is the shift to continuous relationship orchestration. Instead of “this account hit grade A, route to SDR,” we’re seeing systems that understand complete account context and determine optimal next actions dynamically:

• One account needs a technical architecture discussion because their engineering team is evaluating alternatives and their previous vendor implementation failed due to integration complexity.

• Another needs CFO-focused ROI content because they just entered budget planning season and historically make purchasing decisions in Q4.

• A third needs implementation case studies from their specific vertical because their new VP of Engineering is particularly risk-averse after a bad competitor experience.

• A fourth account that’s been quiet for 6 months suddenly shows API documentation traffic from multiple IP addresses - their dev team is actively evaluating, even though no one filled out a form.

The system knows all of this not because someone manually updated Salesforce, but because it’s maintaining continuous context across every touchpoint.

What should we start measuring soon?

Sales and marketing leaders still need to run businesses, forecast revenue, measure productivity, and justify budgets, don’t they? The question isn’t whether we measure, it’s what we measure.

Here are my top metrics and ideas that I think should slowly replace the traditional funnel metrics:

1. Stakeholder coverage: Are we connected to the right people for this account’s decision process? For enterprise deals, you need procurement, IT, security, finance, and business stakeholders. Coverage metrics should show gaps in relationship mapping. Having a heatmap that shows % of accounts with 1/2/3+ contacts is pretty ‘90s. So is adding random contacts to Salesforce from your whitepaper downloads list.

2. Account engagement depth: Not “did they download something” but “how complete is our understanding of their buying context?” This should get measured by some sort of context completeness scores - do we know their technical requirements, budget constraints, decision timeline, key stakeholders, and past evaluation patterns?

3. Intent signal strength: This is already established in most of the larger B2B/SaaS companies as some form of lead scoring model, but would be interesting to have more 3rd party signals go into a real-time composite score - based on actual buying behavior - industry changes, company’s org structure, technical documentation access, multi-stakeholder engagement, pricing page visits, API evaluation activity, competitive research patterns. Sort of signals that actually correlate with purchase intent.

4. Time-to-relevant-engagement: How quickly can we get the right message to the right stakeholder based on their actual needs? This would likely replace “time through funnel stages” but would measure speed to value, not speed through arbitrary stages.

5. Account readiness scores: Dynamic assessment of buying signals across the entire account, not individual lead scores. Is there budget movement? Are multiple stakeholders engaging? Is there technical evaluation activity? This would tell reps which accounts to prioritize right now.

6. Pipeline quality indicators: Predictive close probability based on engagement patterns, relationship depth, and historical win rates for similar accounts - not which arbitrary stage they’re in. An account in “discovery” with strong multi-stakeholder engagement and clear budget might have higher close probability than an account in “proposal” with a single champion and unclear timeline.

7. Revenue per account engaged: Sort of ARPU (Avg revenue per user) but for each seller interaction: how much pipeline and revenue are reps generating relative to the accounts they’re working, AI-enabled interactions they are making? This would be a proxy to SQL-to-opportunity conversion but would measure actual revenue efficiency.

8. Context accuracy: How well do our systems actually understand each account’s situation? Best measured by sales feedback on AI-generated account insights, accuracy of next-best-action recommendations, and relevance of automated outreach. Over time, this can evolve to more sophisticated A/B testing with reinforcement learning from sales feedback.

9. Relationship velocity: How quickly are we deepening relationships and moving toward purchase decisions? Measured by stakeholder engagement expansion, technical validation progress, and commercial discussion advancement - not movement between stages.

10. Revenue influenced by orchestration: What percentage of closed deals had meaningful AI-driven engagement that advanced the relationship? This becomes the ROI metric for the entire system.

So, while traditional marketing would report “generated 500 MQAs this month, 20% converted to SQL/A.” The new approach would (very simplistically) report -

“Engaged 200 target accounts, buying committee coverage up 5% MoM, achieved meaningful stakeholder conversations with 45 accounts (22.5% interaction-to-meeting rate), identified 12 accounts showing strong intent signals (technical evaluation + multi-stakeholder engagement), sales is actively working 8 of those with average context completeness of 85% and 72% context accuracy”

From the Marketing analytics and RevOps folks, the job should become more like managing a trading algorithm than helping teams run campaigns - they should be setting parameters, monitoring performance across thousands of concurrent threads, and optimizing based on signals that actually predict revenue rather than executing pre-defined sequences and counting form fills. And no more lead scoring please.

What will stay the same is that buyers still need progressive trust-building, evaluation time, and consensus development. Complex B2B purchases won't suddenly become impulse decisions, even though we are seeing the buyer journey collapse into fewer screens and touchpoints. Enterprise software deals will still take months because you're coordinating across procurement, IT, security, finance, and business stakeholders - AI doesn't eliminate that complexity yet. We'll likely need agent-to-agent interactions between vendors and buyers for deal cycles to compress dramatically, and that's probably a 2028 story. For 2026, let's focus on getting the funnel metrics right while everyone else waits for AGI.

2025 went by too fast, and it was a big one. The global AI market hit $391B and forecasts now point toward $2T by 2030. Cursor went from niche to absurd growth, hitting $65M ARR with 6,400% YoY expansion. GPT crossed its three year mark (i know, right!) with GPT 5.1 dropping a month ago. World Labs started generating full 3D worlds from text. The tools jumped several leagues in a single year.

And yet, enterprise progress stayed weirdly slower relative to the foundational growth. That is what this year taught me - we unlocked insane front end and generation capabilities while the backend, the workflows, the operations, and the enterprise plumbing stayed stuck in 2024. We built great demos but not as great systems as we could have. We focused tons on generation, not enough on integration. We hyped autonomy while enterprises desperately needed reliability. The model layer evolved faster than the actual organizational ability to use it.

I spent this entire year building AI workflows across marketing, ops, engineering, and product. I watched agents break in every possible way, developers use AI daily but not trust it, non-technical teams unable to convert their knowledge into working instructions etc. Google’s DORA report showed ninety percent adoption but only twenty four percent trust, Stack Overflow showed sixty six percent frustration with agents that are almost right but not quite. That matches everything I saw firsthand 🥲

So instead of another hype post, here is the wishlist for next year - the infrastructure gaps, workflow gaps, a bit of cultural gaps (more on that in another post though). The things that actually broke in 2025 across the five stages of the real lifecycle: Build, Deploy, Distribute, Engage, Scale.

Build: the context collapse and the “build for non-programmers” problem

The build phase went through a total reset in 2025 - tools like Cursor, Replit, and Github Copilot made “type a sentence, get code” boring. Start of the year got Cursor’s 0.43 update strongly adopted with the composer Agent, Windsurf added voice interaction, Claude Sonnet 4.5 hit 75%+ SWE-bench scores.

But as i have mentioned in the past as well, generation was never the hard part - review was, still is. And as more low/no code tooling has evolved, allowing non-engineers to build applications, the problem has gotten much more severe. The cost to write code has almost dropped to near zero, but the cost to understand what got written went through the roof. I’ve seen folks in my team personally debug 600-line agent-generated orchestration logic where no one remembered the original assumption. That’s not development; but borderline archaeology.

The enterprise reality check from Google’s 2025 DORA report was sobering - 90% of developers now use AI (up 14% from last year), but only 24% trust it. Stack Overflow’s survey shows 52% of developers either don’t use agents or stick to simpler tools. We’re in this bizarre “trust paradox” - using tools we don’t trust because they boost productivity by 80%.

And even before you get to code, you hit the “translation gap” I kept running into all year. The people who know what the system should do - marketing managers, ops leads, customer success folks - still can’t turn that knowledge into prompts that produce working software. Gap Inc partnered with Google Cloud to embed AI across operations, but they’re the exception, not the rule.

For 2026, we need to solve this. Not with better generators, but with better reviewers. Here’s some of the big gaps i think would matter a lot -

• AI-native code review: Tools like Cursor’s Bugbot and CodeRabbit are pushing boundaries - Bugbot now generates PR summaries automatically and achieves 42% accuracy in detecting runtime bugs, while CodeRabbit hits 46%. Qodo (formerly CodiumAI) is my personal favorite for now, offering context-aware, test-aware, and standards-aware reviews that actually understand our codebase patterns very well. But i think what’s still missing is ensuring regression errors don’t leak through workng features and abstracting code into business context for reviews - who decided what, why did that choice matter.

• Guardrails that understand AI-written code: I love SonarQube - it remains a solid enterprise standard with AI-enhanced detection capabilities, while newer tools like DeepSource and Graphite evolving to modern PR workflows with AI-powered context management. The next step in my mind is continuous, contextual validation that goes beyond just linting - tools need to understand architectural decisions and team-specific patterns.

• Diffs that explain themselves: When multiple agents propose changes, I want to see not only what changed, but why, and what it affects downstream; crucial for iterative builds, especially as the codebase is refactored from upstream low/no code tools.

• Business logic abstraction: Still no good way for non-engineers to express “if X happens, do Y” at scale in plain language and have it generate maintainable logic without breaking something else. Specificity in scoping is hard. When released, i found the new MCP projects sponsored by GitHub copilot and VS Code teams in October very interesting - they’re building frameworks that let AI interact with tools, codebases, and browsers in revolutionary ways.

Deploy: the configuration explosion

Deployment used to be predictable - now every app is a mess of model endpoints, vector stores, auth layers, API keys, and observability hooks. Vercel makes it smooth for our standard Next.js setups, but the moment you need custom routing, compliance, or multi-region data handling, you’re in the weeds again.

Everyone’s building AI infrastructure like it’s the new arms race - which honestly, it kind of is, but getting “Infrastructure as prompt” right is one of big dreams to make upstream devs work - describing what you want (”a multi-region setup with SOC2-compliant storage and automatic rollback”) and letting the system generate the boilerplate to manage integrations. Amazon’s new Nova Act IDE extension is interesitng, Salesforce’s MuleSoft Agent Fabric for orchestrating AI agents across enterprise systems is also interesting, but there’s lots to be done. These layers in the stack would be very useful:

• Infrastructure-as-prompt: Everyone’s building demos, no one’s cracked the version that’s secure, predictable, and enterprise-ready - and fits into custom infra

• Verification-as-a-service: Microsoft’s MMCTAgent which can reason over hours of video and massive image collections is interesting - imagine that level of verification for generated code. Tools like Qodo’s test generation and CodeScene’s behavioral analytics are getting closer, but we need this as a standalone API any generator could call.

• Enterprise guardrails: Rollbacks, audit trails, compliance policies - every team rebuilds these from scratch, all custom-built. Such a waste.

• Data residency automation: Still no simple way to describe regional rules and have infra handle routing, caching, and storage automatically from a knowledge base. Lot of custom dev needed for separate instantiation and deployments

Distribute: the discovery layer inversion

This is the part most people underestimate. AI-native distribution doesn’t look like sales, SEO, or App store listings anymore. It’s about being discoverable by other AIs.. when someone asks an AI assistant, “what’s the best way to automate approvals,” the models’ answer is your new channel. That means your documentation - not your ad copy - is the entry point.

The October launch of GPT-5 with its 400K context window and multi-modal capabilities was a decent step up - being able to process text, images, audio, and video simultaneously - they’re not just reading your API docs, but understanding your entire product ecosystem. Baidu’s ERNIE 5.0 is also neat, claiming to beat GPT-5 on visual understanding benchmarks, while Google added Deep Research to NotebookLM, turning it into an autonomous research assistant.

Most of the docs online today are human-friendly and LLM-hostile. They’re full of adjectives, testimonials, and vague promises, but LLMs want clean schemas, examples, and integration specs. Some of the new MCP projects are addressing this - fastapi_mcp was interesting but slowed down, context7 pulls version-specific documentation straight from code into AI prompts. But there’s still a lot of missing standardisation across tools and interoperability. Some thoughts for this phase:

• Agent-readable documentation standards: We NEED a shared format for docs that AIs can consume - think JSON-like schemas, explicit input/output examples, and transparent auth steps.

• Programmatic capability marketplaces: App store built for agents, not people. Notion 3.0’s AI Agents with memory and connectors show what’s possible, but are too limiting (and i am not a big fan of the review system they have in place)

• LLM visibility ops: Meta bringing Llama to federal agencies shows how critical government and enterprise visibility is becoming.

• Procurement bridges: Enterprises will expect structured metadata for security, pricing, and compliance that their internal agents can parse when deciding which vendors to recommend.

Engage: so much that could be personalized, but should it be?

Every AI-generated app can personalize itself infinitely - which sounds great until you try to measure engagement. Traditional metrics like MAU or session duration don’t mean much when each user’s product behaves differently. Legacy tools like Customer.io and Braze (I love them both though) assume uniformity, and don’t know what to do when each user gets their own app logic.

According to Stack Overflow’s 2025 survey, developers are most resistant to using AI for high-responsibility tasks like deployment and monitoring (76% don’t plan to) and project planning (69% don’t plan to). The biggest frustration? 66% cite “AI solutions that are almost right, but not quite.” We’re personalizing the wrong things while avoiding the areas where AI could actually help.

Very soon, we’re going to see engagement handled directly by AI agents - personalized outreach, onboarding, and lifecycle management - all grounded in live behavioral data. Perplexity’s new app connectors and enhanced memory, along with Enterprise Max features, show where this is heading. I’d love to see some of these:

• Variant-aware orchestration: Engagement systems that understand product usage/engagement/variance per user and can adapt flows dynamically

• Agent-owned communication: WhatsApp rolled out message translations earlier this year - imagine agents that can communicate across languages and contexts under brand guardrails.

• Knowledge that stays alive: ElevenLabs’ Scribe v2 Realtime with sub-150ms transcription across 90+ languages shows what’s possible for real-time knowledge systems

• Rethinking metrics: The shift from “how many users came back” to “did this user achieve their intended goal.”

Scale: where all the generated code breaks

This is where everything that looked fine in dev blows up - code that worked for ten users collapses at a hundred. AI-generated code (so far) tends to optimize for “it runs now,” not “it scales later.” Current tools like SonarQube and CodeGuru help with static analysis, but they’re reactive, not predictive. The newer wave - Qodo with its enterprise-grade reviews, CodeScene with behavioral analytics - are getting better at flagging scalability risks before they happen.

The November LogRocket rankings show GLM-4.5 debuting at $0.35/$0.39 pricing with MIT license and self-hosting capabilities - 90.6% tool-use success rate beating Claude 4 Sonnet. The economics of AI are changing fast. When you can get frontier-level capabilities for pennies, the bottleneck isn’t compute anymore - it’s understanding what actually scales.

Then there’s multi-region deployment, consistency, compliance - all the enterprise stuff AI doesn’t understand yet. Oracle’s new AI platform for government agri risk forecasting and Suki’s nursing consortium for healthcare workflows show some interesting trends in sector-specific solutions emerging. But we need more general solutions:

• Predictive scalability checks: Tools that simulate real usage before launch and surface bottlenecks proactively. Qualcomm’s Snapdragon X2 Elite Extreme shows the hardware is there - we need the software to catch up.

• Data-policy compilers: Declarative frameworks that encode legal and regional constraints into routing and caching decisions automatically

• Continuous performance governance: Systems that enforce latency and cost budgets at PR time, not after users start complaining

• Security and provenance by default: Traceable lineage for every artifact or decision an agent produces - not optional, not bolted on later.

The obvious opportunities for 2026

A lot of the gaps I’ve called out above will definitely be tackled in 2026, especially the ones which have built a good foundation and will easily manage the distribution layer too -

• Dev tools for AI-generated code will expand far beyond generation. The shift to “review-first” development is already happening. Cline offers open-source BYOK (bring your own key) flexibility, while tools like serena provide semantic retrieval and editing capabilities. Qodo achieving enterprise-grade context awareness, CodeRabbit with 46% bug detection rates, Graphite with modern PR workflows - show that review and verification are becoming more valuable than generation itself, and will have several BIG evolution in the next 12 months

• Enterprise knowledge infrastructure will mature rapidly. Companies are already building AI agents for customer service, sales, and support. Google NotebookLM’s Deep Research feature that browses hundreds of sites and creates comprehensive reports shows the direction. We need model-agnostic middleware to allow non-programmers to manage knowledge

• Context engineering platforms will expand AI capabilities accessible to non-technical users. Microsoft’s Copilot Studio Wave 2 for no-code agent building is just the beginning. Stability AI’s Image Services on Amazon Bedrock deliver professional-grade editing as APIs. I am pretty sure good things will ship here.

• Operational excellence automation will abstract away complexity. GitHub turning Teams conversations into code with Copilot shows how seamless this can become. Amazon, Oracle, and Salesforce all launched enterprise AI platforms in last few months alone.

• Engagement infrastructure for adaptive applications needs a rethink. 75% of developers say they’d still ask a human “when I don’t trust AI’s answers” according to Stack Overflow. Building that trust layer is the opportunity.

What 2026 needs to deliver

Looking back at 2025, the pattern is clear: we built amazing generators but (almost) forgot about everything else. The AI value chain keeps getting more lopsided - the build stage gets easier while complexity cascades downstream into deployment, distribution, engagement, and scale.

The market will grow from $391 billion to that projected $1.81 trillion by 2030, but most of that value won’t come from better code generation. It’ll mostly come from solving the unglamorous problems - the integration nightmares, the trust gaps, the review bottlenecks, the scaling failures.

My prediction for 2026 is that the winners won’t be the companies with the best models or the fastest generation, but the ones who finally crack the “last mile” problems that 2025 exposed. The ones who build:

• Trust infrastructure that makes that 24% trust number climb to 80%

• Review systems that actually understand context and architectural decisions

• Deployment platforms that work with real enterprise constraints, not just demo apps

• Integration layers that let non-technical teams actually use these tools without breaking production

• Scaling intelligence that predicts and prevents the failures before they happen

2025 taught us that anyone can generate code, but 2026 needs to teach us how to ship it. And since everything is plateauing based on where the stack sits today, foundational companies will evolve to solve this, or go vertical-first (where they’ll surely make a lot of money, but maybe not solve enterprise problems)

Amidst all that’s happening, one of the uncomfortable question I keep coming back to is “if creation cost truly drops to zero and anyone can build software, should we even be building software the way we do today? If the constraint isn’t “can we build it” but “should we build it” - then what?”

Maybe a big part of 2026 won’t be about better tools, but about better judgment about when to use them and who should truly use them.

This is why retention is different from every other metric companies obsess over. Acquisition can be manufactured through Ads, content marketing, SEO optimization, and referral programs; expansion can be engineered with freemium upgrades, upselling/cross-selling, clever pricing; but retention asks a simple question: did you build something people actually want to keep using? It determines whether you are compounding or just backfilling losses. Acquisition can make you feel faster, but retention determines whether that speed has direction; whether each new user becomes a permanent part of your business or just a temporary visitor you'll need to replace next month.

The math is pretty obvious, but also makes this concrete - think of your user base as

where Ut is your current users, R is retention, A is acquisition, and V is virality.

At low retention rates, that first term collapses and you start from scratch every month. At high retention rates, the base compounds: each month builds on the last. E.g, consider two companies, both adding 1000 new users monthly. Company A has 50% monthly retention. Company B has 80% retention. After 12 months, Company A has 2000 users total - barely double its monthly acquisition despite a full year of growth. Company B has 8000 users. Same acquisition, 4x the result, entirely due to retention.

PLG makes this equation more brutal - the funnel is intentionally frictionless: no demos, no contracts, no sales reps filtering for intent. This is PLG's superpower - anyone can try the product in seconds, but it's also the harshest test. The same open doors that eliminate barriers to entry also eliminate barriers to exit. Students, hobbyists, competitors, and casual browsers all count in your denominator, making your retention curves look worse than sales-led businesses where reps pre-qualify commitment. But that harsh reality is actually useful - PLG shows you immediately whether people are getting value; if they're not, they disappear, and you see the truth in real time.

why teams abandon retention work

Retention optimization feels uniquely frustrating because it violates the fast feedback loops that make other growth work satisfying - launch a Facebook ad campaign and you'll see signups in no time, complete with click-through rates and cost per acquisition data; roll out a new pricing tier with annual discounts or clever bundling/pricing and expansion revenue appears in the next billing cycle. But ship an improved onboarding flow today and you won't know whether it actually improved 90-day retention until three months pass.

This delay creates a measurement problem that compounds over time - unlike acquisition, where you can run controlled experiments with statistical significance in days, retention optimization often requires making multiple simultaneous bets across different parts of the user journey. You might improve page load speeds from 4s. to 2s, simplify signup from eight fields to three, redesign onboarding with interactive tutorials, and launch behavioral email sequences all in the same quarter. When retention improves six months later, isolating which changes actually mattered becomes nearly impossible - not because the math is hard, but because the experiment data lives with different teams who tracked different metrics.

The systemic nature makes retention especially challenging organizationally - acquisition can be optimized channel by channel, e.g. Google ads has its own team optimizing keyword bids, facebook has specialists running creative tests, content marketing has dedicated writers tracking organic conversion rates. Each channel has clear ownership and measurable daily outcomes, btt retention emerges from the intersection of product design, backend engineering, customer success, content strategy, and email marketing. A user might churn because signup is confusing (design team), APIs are slow (backend engineering), they can't find help when stuck (content team), they never discovered key features (product marketing), or they hit javascript errors (frontend engineering). No single team can own retention because improving it requires coordinating across every touchpoint simultaneously.

To add to it, human behavior adds complexity that product optimization can't solve either - users change jobs, budgets get cut, teams consolidate tools, new management arrives with different vendor preferences. The 2022 economic downturn saw many PLG companies experience retention drops not because their products got worse, but because customers scrutinized every software expense more carefully. This creates false signal problems e.g. users might appear retained because they log in weekly to check notifications, but they're not creating projects or building anything meaningful.

Lastly, and this bit is fairly crucial, the organizational dynamics make retention work politically difficult - acquisition improvements generate visible dashboard spikes that executives celebrate - “Wow, our signups doubled Q/Q with the new campaign release”. Expansion ties directly to revenue growth that makes finance teams happy. Retention work is slower, less dramatic, and often requires saying no to exciting features so engineering can focus on mundane problems like reducing signup abandonment or fixing edge case bugs. These improvements don't generate press releases but quietly determine whether unit economics work.

Most retention problems are actually activation failures; users who never send their first message, build their first dashboard, or connect their first integration were never truly retained - they were just temporarily present. This is why successful PLG companies obsess over time-to-first-value, removing every unnecessary step from onboarding and personalizing flows so a hobbyist doesn't see the same experience as an enterprise buyer.

Expansion drives retention as much as revenue - when users invite teammates, connect integrations, or upgrade plans, they embed the product deeper into their workflow. Slack reported that teams with 2k+ messages sent had 93% retention rates, while teams with fewer than 2k messages had much lower retention. The difference isn't just usage but rather organizational embedding - once Slack becomes how a team communicates, switching away requires changing fundamental workflows for dozens of people.

measuring what matters

Companies track retention in different ways, but not all metrics tell the same story. The standard approach focuses on percentages - "our 30-day retention is 42%" - which captures whether users return but not whether they're getting value. Dollar-based retention sounds sophisticated but can be misleading for PLG businesses; a small startup might get massive value from your free tier while a large enterprise might pay thousands but barely use the product. Login-based retention is the most common metric but also the most deceptive; users might check in weekly out of habit without accomplishing anything meaningful. Feature usage retention gets closer to value but can optimize for the wrong behaviors - if you track users who create five documents per month, you might encourage busy work instead of solving real problems.

The most predictive retention metrics track completion of core workflows rather than raw activity - e.g. Figma measures users who share their first design with teammates, notion tracks users who create their first database. These behavioral milestones correlate strongly with long-term retention because they indicate that users have experienced the product's core value proposition.

the retention advantage

Retention buys you pricing power and competitive moats - when users depend on your product daily, they become less price-sensitive. Salesforce can raise prices because switching CRM systems is painful, slack can get to per member pricing for the same reasons; high retention creates switching costs that competitors can't easily overcome. Several pieces of research show that increasing retention rates by just 5% can increase profits by 25-95%. The math works because retained customers cost nothing to acquire and typically expand their spending over time. Companies with strong retention can afford to invest in longer-term bets because they're not constantly fighting to replace churned users. This is why retention ultimately determines market position - companies that solve retention can focus on product depth instead of marketing spend, build for power users instead of casual browsers, and create features that increase switching costs instead of just driving trial conversion.

There's a hidden trap in this apparent productivity boom: the cost to write code has collapsed, but the cost to review code has exploded. In the past, if someone submitted a 200-line diff, you knew roughly how they got there. Now, people paste in a vague prompt, and out comes a 600-line orchestration module with imported packages no one asked for and assumptions no one agreed to. Reviewing that output is like spelunking in someone else's hallucinated architecture. Every review turns into vibe debugging, where you're not fixing a bug, you're fixing a mood.

This mismatch between generation speed and review complexity leads to two dangerous outcomes. First, systemic fragility: codebases fill with low-context patches that work locally but struggle to compose globally. The AI makes choices no one remembers making. Second, architectural debt by accretion: teams conflate "code that runs" with "code that scales." Vibe-coded systems optimize for the constraints they have dealt with oftentimes resulting in momentary shippability, not maintainability. Try prompting Claude to generate a Seaborn plot for churn insights- you’ll get 500 lines of syntactically perfect code, followed by 100 minutes of debugging just to make it compose properly and make business sense.

The fantasy of spec-to-code automation imagines programmers as mere translators who mechanically convert requirements into implementation. But this strawman programmer doesn't exist in practice. Every competent engineer I've encountered actively participates in problem definition, challenges assumptions, and iteratively refines solutions through the act of building them. Simon Willison has a brilliant articulation on this topic (the entire thread is gold).

Local optimization vs global coherence

I really liked the concept of local optimisation vs global coherence when i first came across it (here). Extrapolating it to what we’re witnessing now, Vibe coding excels at local optimization: solving bounded problems with minimal dependencies where correctness is contextually obvious and the blast radius remains small - consider writing a webhook handler, formatting API output, creating SQL queries, or building a frontend that allows ingesting a bunch of user inputs, making a few OpenAI calls and recommending the best Cafes and Restaurants. The problem space is well-defined, success criteria are explicit, and validation is immediate.

Complex engineering represents a fundamentally different class of problem: achieving global coherence across multiple interacting components under shared constraints like scalability, security, and failure recovery. This isn't merely one of scale; it's a categorical distinction.

The core issue is the context explosion problem. While local optimization requires understanding a bounded problem space, global coherence demands reasoning about exponentially expanding interaction surfaces. Consider building a compiler where each decision creates cascading constraints: the lexer's token design affects parser complexity, which influences AST structure, which determines optimization possibilities. A locally optimal choice at any level might make global optimization impossible.

Vibe coding doesn’t do great here because it operates through pattern matching against previously seen solutions. But truly complex systems often require novel constraint satisfaction, finding solutions that balance competing demands in ways that have no direct precedent.

Engineering at scale is often constraint-oriented: you're not only teaching the system how to do something, but you're also defining what must be true (latency < 300ms, idempotent retries, zero downtime deploys). These constraints interact across components and force tradeoffs that can't be easily vibe-coded. They need negotiation, abstraction, and architecture, not only generation. Good engineers solve for it by exhibiting mechanical sympathy - an intuitive alignment between the software they write and the underlying systems. Vibe coding has no such sympathy. It can write valid Kafka consumers that don't understand backpressure, or spawn microservices without accounting for network costs. It treats code as text, not as behavior in a live system.

This explains why solopreneurs can thrive building profitable products through vibe coding while enterprise systems struggle. The distinction is fundamental: products optimize for user value and market success; software systems optimize for reliability, maintainability, and evolution. The solopreneur model works through problem curation, selecting challenges solvable via local optimization while outsourcing global coherence problems (or, in a lot of instances even ignoring those, shipping demos that work on local machines and look good on AI created landing pages) . Crucially, solopreneurs can afford exploded review costs because they're reviewing their own AI output, personal context that doesn't transfer to teams where code review becomes reverse-engineering someone else's AI conversation.

Beyond code generation

The misconception stems from conflating code generation with software engineering. Code is the artifact, not the activity - real software engineering emerges from the dialectical relationship between problem and solution domains, where implementing solutions reveals new problem aspects.

I remain deeply optimistic about AI's potential to accelerate software delivery and help more people ship products quickly. But the timeline for truly autonomous software engineering is slightly longer than current hype suggests. The reasons are fundamental: mechanical sympathy can't be pattern-matched, constraint satisfaction requires domain expertise that emerges from years of operational experience, and architectural judgment develops through repeated exposure to system failures and recovery.

Obviously, we will train the models to build sympathy in due time, but even then some aspects of software engineering will never disappear: the need to understand how code behaves in live systems, the ability to reason about failure modes that haven't been documented, and the creativity required to find novel solutions to unprecedented constraint combinations. I don’t think these are implementation details that better models will eventually subsume. They're the irreducible core of what makes software engineering an enduring human discipline.