Onboarding was designed for a world where the only way to learn a product was to look at it.

Tooltips. Checklists. Tours. All of it assumes a user clicking through a UI, one screen at a time, following a path someone else laid out in advance.

That assumption is dissolving. Not because tooltips got worse — because the way people expect to interact with software changed underneath them.

Five shifts are driving it. Each one is backed by data, not vibes.

1. People want whichever is faster — chat or click

Conversational interfaces have gone from support-widget afterthought to a default way of using a product. That doesn’t mean chat is replacing the UI. It means users are impatient with whichever option is slower in the moment, and expect to move between both without friction.

• The conversational AI market is estimated at $17–19 billion in 2026, growing more than 20% a year across most forecasts — Azumo

• Close to 1 billion people worldwide were already using AI chatbots as of 2025 — Azumo

• 85% of customer service leaders said they’d explore or pilot customer-facing conversational GenAI in 2025 — Gartner

The practical effect: some users type, some click, and most do both in the same session depending on which gets them there faster.

Onboarding built entirely as a silent, click-only UI layer — or entirely as a chat-only flow — optimizes for one preference at the expense of the other. Neither is what users actually want. What they want is to never have to think about which mode they’re in.

2. Software is going hybrid, and the personalization bar went up with it

The Model Context Protocol is the infrastructure story behind this shift.

• MCP went from roughly 100,000 SDK downloads in its first month to about 97 million monthly by March 2026 — a ~970x increase in eighteen months — Knak

What that enables in practice: a chat agent and a visual interface sharing the same context, instead of running as two disconnected systems. The agent can see what’s on screen. The UI can respond to what was just said.

That hybrid model only works if what sits underneath it is personalized — and the demand for that is well documented well outside software:

• 71% of consumers expect personalized interactions and 76% are frustrated when a company fails to deliver one. Faster-growing companies drive 40% more revenue from personalization than slower-growing peers — McKinsey

• 80% of US consumers are more likely to purchase when brands offer personalized experiences — Deloitte Digital / Meta

Onboarding isn’t exempt from that expectation. A generic five-step tour, shown identically to every signup, is now the exception users tolerate — not the standard they expect.

3. AI remembers now, and users expect it to

ChatGPT, Gemini and most major AI assistants have shipped some form of persistent memory over the past year — carrying context from one interaction into the next instead of starting cold every time.

• 85% of CX leaders say memory-rich AI is critical to genuinely personalized customer journeys

• 81% of consumers want an agent to pick up where a previous conversation left off

• 74% get frustrated when they have to repeat information they’ve already given

— Zendesk, CX Trends 2026

For onboarding, this changes what “personalized” can mean at all.

It’s no longer which persona segment is this user in. It’s what has this specific user already done, what did they ask last time, and what do they still need — carried forward automatically, instead of re-derived every session or re-explained by the user every time they open a support chat.

4. Attention is shrinking, and AI is partly why

This one cuts against the other three. Even as expectations for depth and personalization rise, patience for getting to the point keeps falling.

Gloria Mark’s research at UC Irvine — one of the longest-running studies of attention on digital devices — tracked the decline:

• ~2.5 minutes average sustained attention on a screen, early 2000s

• ~75 seconds by 2012

• Under 60 seconds in more recent measurements

— UC Irvine Informatics · recent coverage

Part of what’s driving that compression is AI itself. When an assistant answers a question or completes a task in seconds, a five-step tour that used to feel like a reasonable investment now reads as friction.

Users want the outcome, not the walkthrough — a preference AI trained into them everywhere else, then carried straight into how they judge your product on day one.

5. And underneath it all: the adoption problem SaaS never solved

Here’s the part that doesn’t get said enough. Full-platform adoption — getting users to actually find and use what’s been built, not just the two or three features they stumbled into on day one — has been unsolved for as long as SaaS has existed. Not for lack of trying.

• 80% of features in the average software product are rarely or never used, per Pendo’s research across hundreds of customer accounts

• Public cloud software companies have collectively sunk an estimated $29.5 billion in R&D into features that then go largely untouched

— Pendo, Feature Adoption Report

Tooltips, checklists and release-note emails have been the industry’s answer for over a decade. The numbers above are what that answer produced.

It isn’t a discovery problem a better changelog fixes. It’s that nobody has had a scalable way to say the right thing to the right user at the right moment, for every feature, continuously — instead of once at signup.

That’s exactly what a hybrid, memory-aware, always-available agent is positioned to do differently. Not just at onboarding, but for the life of the account. The four shifts changing what a new user expects in week one are the same four that make it possible to keep surfacing value in month six and month twelve.

What This Means for How Onboarding Gets Built

Put together, the five shifts point the same way:

• Users want the fastest path to an answer, whether that’s a click or a prompt — not a forced choice between them

• Chat and UI have to share context, not operate as two systems that happen to sit on the same page

• They expect the product to remember them, not just segment them

• They have less patience than ever for a static path built with none of the above in mind

• And the real prize is bigger than onboarding — most of what gets built never gets used, and this shift is a genuine opportunity to fix it

Onboarding stopped being a flow you design once. It’s becoming a system that reads context and decides what to say next — and it doesn’t stop at day one.

Onboarding in the Era of AI: FAQ

Is chat replacing onboarding UI? No. Users move between both within a single session and pick whichever is faster for the task in front of them. The failure mode is forcing one mode on everyone, in either direction.

What makes onboarding “AI-native” rather than just having a chatbot? Shared context. The agent can see what’s on screen and what the user has already done; the UI reflects what the agent just did. A chatbot parked in the corner of an app has neither.

Why does AI memory matter for onboarding specifically? It changes what personalization means — from which segment a user belongs to, to what this particular person has already completed, asked about, or skipped. That’s the difference between a tailored path and a persona-shaped tour.

Do shorter attention spans mean onboarding should just be shorter? Not shorter — more targeted. The problem isn’t length, it’s spending a user’s limited attention on steps they don’t need.

What does this have to do with feature adoption? The same capabilities that get a user to first value in week one — live context, memory, an agent that’s always there — are what let you keep surfacing relevant features in month six. Onboarding and adoption stop being separate problems.

Want to see this working on your own product? autoplay.ai · Quickstart docs: developers.autoplay.ai

Subscribe now

Share

Customer success is going through the shift sales and marketing already went through. As the work gets automated by agents, a new hybrid role appears to build, connect and monitor the automation.

Call it the customer success engineer. Part CS, part builder.

It isn’t a rebrand, and it isn’t a CSM who learned some SQL. It’s a set of responsibilities that didn’t exist two years ago, showing up inside CS teams for the same reason a near-identical role showed up in go-to-market first.

The GTM Engineer, One Beat Earlier

Go-to-market hit this first. Once AI tooling got good enough to draft outreach, enrich leads and route signals between tools, someone had to actually build and maintain those systems.

Not a rep. Not a RevOps hire. Someone comfortable enough with APIs, automations and prompting to wire the stack together — sitting inside a function that used to be almost entirely non-technical.

The role existed because the work changed faster than the skill set. Knowing how to run a great outbound sequence stopped being the ceiling. Someone had to build the system that ran a hundred versions of it.

CS is at the same inflection point now, a beat later.

Why the Same Shift Is Hitting CS

Agentic support isn’t plug-and-play. Standing it up — and keeping it good — is real work, and it never stops being work:

• Configuring objectives and guardrails per segment. What “good” means for a free-trial user isn’t what it means for an enterprise admin, and the agent needs to know where it hands off.

• Connecting behavioural and account data so it reasons from live context, not a static script.

• Monitoring where it’s quietly wrong. Catching the confidently bad answer before a customer does.

• Keeping it current every time the product ships.

We wrote about the management side of this in August — defining good, setting guardrails, reviewing performance. This is the other half. Someone has to build the thing being managed.

None of that is traditional CS work. None of it is traditional engineering work either.

The tooling has already noticed. Support platforms like Pylon are noticeably more API-first than the CS tools of five years ago — built assuming someone on the CS side will want to configure and extend the system, not click through a settings page.

The second front is workflow automation. It’s increasingly normal to see CS teams building their own connected flows: a call gets transcribed, an AI workflow drafts the follow-up, updates the CRM and runs sentiment on the conversation, with nobody touching each step.

A lot of these are stitched together directly with tools like Claude, by people on the CS side who picked up enough fluency to build it rather than file a ticket and wait two quarters.

The person who can do both — understand what good customer success looks like and build the system that delivers it — is the customer success engineer.

What the Role Actually Does

In practice it clusters around two things.

• Running the agent. Defining what it handles versus escalates, by segment. Reading real conversations to find where it underperforms. Adjusting guardrails as the product and the customer base move. Judgment work wearing a technical hat — the instincts a good CSM already has, applied to a system instead of a call.

• Building the automation layer. Wiring together what used to be manual handoffs: transcripts into CRM updates, sentiment into health scores, follow-ups drafted instead of typed. Increasingly with AI tools and SDKs directly, rather than waiting on a point solution that does exactly this one thing.

Neither is CS as usual. Both need enough technical comfort to build something, not just request it.

Why This Wasn’t Possible Two Years Ago

This isn’t a staffing trend. It’s downstream of what the tooling made possible.

Building a custom automation used to need a dedicated engineer and a slot in someone’s backlog. Now a person with CS judgment and a working knowledge of how to prompt and chain AI tools can build a meaningful piece of it themselves.

The bar dropped far enough that CS-native people can clear it without becoming engineers.

The Part Most Teams Will Get Wrong

Here’s where the GTM parallel earns its keep.

The instinct will be to solve this with a hire from engineering. Someone technical, dropped into CS, told to own the agent. It’s the obvious move, and it mostly doesn’t work.

The scarce input was never the ability to call an API. It’s knowing what a good outcome looks like for a specific customer at a specific point in their lifecycle — which questions signal risk, which silence means churn, when the agent should say less. That’s a year of pattern-matching inside a function, and it doesn’t transfer in an onboarding week.

GTM engineers overwhelmingly grew out of revenue teams, not out of engineering. The direction of travel is the whole point:

It’s easier to teach a strong CSM to build than to teach a strong engineer what a healthy account feels like.

What This Means for CS Teams

• Hiring shifts, but not toward engineers. Alongside traditional CSM skills, you want a few people who aren’t allergic to APIs, automation tools and AI workflows. Comfort, not credentials.

• The role sits inside CS, not alongside it. Not an engineering headcount bolted on. An evolution of the CS skill set — the same way GTM engineers emerged from within revenue teams.

• It compounds. Every automation one of these people builds hands time back to the rest of the team for the commercial, relationship-driven work that was always the point of the job.

The function doesn’t get bigger. It gets denser.

What that person should build first — the three automations worth doing before anything else — is the next one.

The Customer Success Engineer: FAQ

Is a customer success engineer the same as a support engineer? No. A support engineer handles technical customer issues directly. A customer success engineer builds and maintains the systems — agentic support, automation workflows — that the rest of the CS team runs on.

Do they need to know how to code? Not in the traditional sense. Most are building with AI tools, SDKs and low-code workflows rather than writing software from scratch. Comfort with APIs, prompting and connecting tools is the actual requirement.

Should we hire an engineer into CS instead? Usually not. The technical half is teachable in weeks; knowing what a good customer outcome looks like takes a year inside the function. Build the role from your existing CS team.

Why is this emerging in CS specifically now? Because agents got good enough to absorb a real share of CS work, and the bar to build that automation dropped far enough that CS-native people — not just engineers — can clear it.

Is this the same trend as the GTM engineer role? Yes, a beat later. As AI absorbs more of a function’s day-to-day work, a hybrid role emerges from inside that function to build and maintain the automation.

Want to see this working on your own product? autoplay.ai · Quickstart docs: developers.autoplay.ai

Subscribe now

Share

Agent-Led Growth — Issue 01

If you’ve spent any time in SaaS go-to-market circles this year, you’ve heard the term: Agent-Led Growth. It’s being positioned as the successor to Product-Led Growth, the way PLG replaced sales-led motions a decade ago.

There’s no accepted definition yet, which is part of the problem. Here’s mine — and why the conversation is still one layer short.

The Core Idea

PLG made the product the engine. Sign up, try it, find value without a rep.

Agent-led growth is the layer on top. Instead of the user learning the product well enough to reach value on their own, an agent inside the product works out what they should do next and either shows them or does it for them.

The product should be doing the work of understanding the user and telling them what to do next — not the other way around.

The output is one next best step, personalised to that user. Getting it right means grounding it in three streams, not one:

• What they do in the UI — the screens they open, the actions they abandon.

• What they say in the chat — the questions they ask, and the ones they ask twice.

• What the agent does for them — what it suggested, what it did on their behalf, whether it landed.

Hold all three in one place, and you can answer the question that actually matters: given what this person has done, and what they still haven’t, what’s the one thing to put in front of them next?

Why “Self-Serve” Stopped Being Enough

PLG solved distribution. It never solved what happens after signup. Complex B2B tools still hand a new user a dashboard, a settings menu and a blank canvas, and call that self-serve.

At Autoplay we think of it as three walls every user hits:

• They don’t know what they don’t know. They’re not sure what to ask, or which part of the product matters to them.

• They don’t ask for help when they’re stuck. The friction never surfaces, because nobody on your team knows it’s happening.

• They only want guidance that’s relevant to them. A tour that ignores their goal and their progress isn’t help. It’s noise.

Static onboarding hits all three at once. Documentation nobody reads, videos nobody finishes, tours that walk every user through the same steps. It’s built for the average user, and the average user doesn’t exist.

What Actually Makes Onboarding Agent-Led

The label gets applied loosely — usually to a chatbot bolted onto a legacy UI. Three things have to be true at the same time.

• It has to be grounded in the whole context. Account fields — plan tier, signup date, company size — are guesswork. But live UI behaviour on its own is only a third of the picture. Without the agent’s own history, it can’t tell a step someone skipped from a step it completed for them.

• It has to know what “done” means for that user. Onboarding isn’t one checklist; different users need different subsets of it. The agent needs to know which workflows are finished — by the user’s hand or its own — so it isn’t re-explaining or skipping.

• It has to turn that into one next step, at the right moment. Not a summary of someone’s activity: a single recommendation. And proactive help at the wrong moment reads as intrusive, so is now the right time has to be part of the system, not something bolted onto a chat prompt.

Miss one and you have a chatbot with better marketing. This is the gap agentic onboarding is meant to close.

Where the Conversation Is Still One Step Behind

Of those three streams, almost nobody builds the third.

The current excitement is about agents generating things for users — a dashboard, a report, a first draft. Useful, but it treats “the agent acted” as the finish line. It isn’t. It’s a new event in the user’s history, and the agent has to be able to read it back.

Without that, you get an agent that repeats a suggestion the user already dismissed, contradicts its own last recommendation, tells someone to go and do a thing it did for them yesterday, and can’t tell a helpful intervention from an ignored one.

Personalisation that reads user behaviour but never reads the agent’s own history isn’t closing the loop. It’s guessing twice.

What This Means If You’re Building

• Behavioural context beats account context — and behaviour means all three streams. Plan tier tells you who someone is. It doesn’t tell you they’ve opened the integrations page three times, asked about SSO twice, and let the agent wire up Slack for them.

• Completion state is per-user, and it counts both routes. A step the agent finished on someone’s behalf is done, even though they never touched that screen.

• Agent memory is infrastructure, not a feature. Retrofit it, and you’ll be doing it the first time a customer complains the agent keeps repeating itself.

That last one is what I’ll cover next: what it takes to track not just what a user is doing, but what the agent has already done for them — and how that changes what it should suggest.

Agent-Led Growth: FAQ

What is agent-led growth? An AI agent inside the product does part of the work of getting a user to value — reading what they do in the UI, what they ask in the chat and what it has already done on their behalf, and using all of it to suggest their next best step.

How is it different from product-led growth? PLG made the product the acquisition engine but still assumed users would teach themselves. ALG adds a layer that reads live context and intervenes.

Is it just a chatbot in the product? No. A chatbot answers what’s typed. An agent-led system also sees what the user is doing, knows which workflows they’ve completed by either route, and decides when to step in.

Why isn’t account-level data enough? Plan tier describes who a user is, not what they’re doing right now. Friction happens at the level of a specific action on a specific screen — including one the agent took for them.

What does most of the industry get wrong? Treating the agent’s action as the end of the process. Without a record of what it suggested and how the user responded, it repeats itself and can’t tell useful help from ignored noise.

Want to see this working on your own product? autoplay.ai · Quickstart docs: developers.autoplay.ai

Subscribe now

Share

There’s a fashionable claim going around: SaaS is dead. Business applications are just CRUD databases with business logic bolted on, the argument goes, and once agents absorb the logic, the app becomes optional. The agent becomes the interface.

It’s a clean story. It’s also missing the part that actually makes software useful.

What Chat Is Bad At

Chat is genuinely good at expressing intent, asking an open question, and getting something done without knowing which menu it lives in.

It’s genuinely bad at three things:

• Scanning — nobody reads a paragraph to find a number they could see in a table in half a second

• Precision — dragging a slider, reordering rows, adjusting an axis. Chat can describe it. It can’t beat touching it.

• Comparison — three options across three replies is worse than three options side by side

A chat-only spreadsheet isn’t more human. It’s slower, in exchange for feeling conversational.

What UI Can’t Do Any More

The opposite failure is the one most existing software still has.

• Rigid navigation assumes every user wants the same path

• It can’t act for you — a UI shows you where the button is. It doesn’t click it.

• It can’t explain itself — when something’s confusing, the screen just sits there

This is the gap agentic onboarding closes at small scale. It’s a preview of the shift happening to software generally.

Two Products, Converging From Opposite Ends

The useful evidence isn’t theoretical. It’s what’s already happened to products built from each starting point.

• Claude started as chat. It’s an AI model you talk to — about as chat-native as software gets. It still ships a full UI, and you still have to use it. Billing. Organisation settings. Who’s on the team and what they can reach.

  
  Not because the chat isn’t good enough. Because those things are deterministic. You need to see the seat count, not be told it. You set a spend limit and watch it save.
  

• WebinarGeek started as UI. Setting up a webinar there recently, the chatbot was genuinely good — it even handed back a list of tasks to work through.

  But building the reminder sequence in chat would have been miserable.
  
  Editing a registration page, swapping a banner, moving a send time — those are edit-and-check loops. Change one thing, look at it, change it again. A UI does that in seconds. Chat turns it into a negotiation.

One product grew a UI. The other grew a chat layer. They arrived at the same shape from opposite directions.

The Real Difference Is Bounded vs Unbounded

Here’s what those two examples are really showing, and it isn’t typing versus clicking.

A user interface is a set of constraints. The constraints are the product.

When WebinarGeek puts a form in front of you — title, date, registration questions, reminder sequence, follow-up email — it isn’t just collecting data. It’s telling you what a good webinar is made of. The fields are a checklist. The order is a method. You end up running a competent webinar largely because the software made it difficult to run an incompetent one.

Nobody wrote that down as a framework. It’s dissolved into the screens.

Claude has no such shape, by design. It will help you plan a webinar, write a novel, draft a legal argument, or waste an afternoon. The range is close to infinite, and the guidance is close to zero. It has no opinion about what “done well” means in your particular domain, because it isn’t a product about your particular domain.

That’s the actual axis. Not conversational versus visual. Bounded versus unbounded.

Constraints Are a Feature

This runs against the instinct that flexibility is always better. It isn’t.

Don Norman’s central argument in The Design of Everyday Things is that good design makes the correct action obvious and the incorrect action difficult. Constraints aren’t what’s left over after the design work — they are the design work.

A second, older usability principle does even more damage to the chat-only vision: recognition over recall. An interface shows you what’s available. A chat box requires you to already know what to ask for.

Which produces the line that matters:

A UI tells you what you didn’t know you needed. Chat waits for you to ask.

You cannot request a reminder sequence you don’t know exists. You cannot ask about the mobile safe zone on a banner image if nobody ever told you banners have one. A blank text box is infinite and, for anyone who isn’t already an expert, that’s the problem rather than the pitch.

Which Is Better Depends on Who’s Using It

The honest version of this argument has a variable in it.

• Experts want the canvas. They know what good looks like. Rails slow them down. For them, chat is liberating — say the thing, skip the six screens.

• Everyone else needs the rails. They don’t yet know what good looks like. The interface teaches them, one required field at a time.

And here’s the part product teams forget: every user is a novice at the beginning. Expertise is the thing your product produces, not the thing it can assume.

On day one, nobody knows what your software is capable of — which is precisely when an unbounded text box is least useful and an opinionated path is worth most.

Two Layers, One Conversation

So the future isn’t replace-the-UI-with-chat. It’s a UI and a conversational layer on the same product, each doing what it’s structurally better at.

• The UI layer holds the framework — structure, state, precision, the encoded opinion about what good looks like

• The chat layer holds the intent — do this for me, explain what I’m looking at, what now?

The UI keeps you on a path that works. The chat gets you unstuck when the path isn’t obvious.

The Handoff Is Plumbing, Not Design

For this to work, the two layers can’t be separate products bolted together.

The chat layer needs to know what’s on screen, what the user just clicked, what state the UI is in right now. The UI needs to reflect whatever chat just did — instantly, with no refresh and no re-orienting.

That’s the difference between a chatbot parked in the corner of an app and an agent that’s actually aware of the product around it.

The Part That Doesn’t Get Easier

Here’s the catch: every agent is working from context that’s already slightly out of date.

State changes faster than context gets delivered. Context lives in more places than any one system can see. Every new tool in the stack is another source the agent doesn’t automatically have.

Better models make agents better reasoners. They don’t make them better informed.

More on that in the next post.

So No, SaaS Isn’t Dead

Back to the fashionable claim.

The reasoning goes: business applications are databases plus business logic plus a UI. Agents absorb the logic. Therefore, the UI — and the company selling it — becomes redundant.

The flaw is in the first step. The UI was never just a way to reach the database. It’s where years of accumulated judgement about what a good outcome looks like got encoded — which fields matter, in what order, what you’re not allowed to skip, what you should be looking at right now.

Strip the interface, and you don’t get the same product with a better front end. You get a very capable assistant with no opinion about your domain, waiting for someone who already knows what to ask.

The database survives. The agent arrives. But the encoded expertise has to live somewhere — and where it lives is the interface.

SaaS isn’t dying. It’s growing a second layer.

Half Chat, Half UI: FAQ

Will chat replace traditional UI? No. They do structurally different jobs. Chat handles intent and action; UI holds the framework — structure, precision, and the encoded opinion about what a good outcome looks like. The shift is toward both layers working together.

Why is a UI better for following a proven process? Because a UI is deterministic and bounded. The fields, the order and the required steps are a method the product’s makers already worked out. Chat is unbounded by design — enormous range, no built-in opinion about what “done properly” means in your domain.

Isn’t a chat-native product proof that UI is going away? The opposite, so far. Chat-native products keep adding UI for billing, settings and permissions. UI-native products keep adding chat. Both are converging on the same split from opposite ends.

Is SaaS dead now that agents can do the work? No. The claim assumes the interface was only ever a way to reach the database. In practice, it’s where domain expertise is encoded. Remove it, and you have a capable assistant with no view on what good looks like in your industry.

What should teams building software do now? Keep the framework in the UI, put intent in chat, and invest in the live connection between them — rather than treating context as something wired up once during setup.

Subscribe now

Share

What grows to fill the space is more commercial - managing risk, driving expansion, and increasingly, managing the agent that’s now doing the teaching. Not a subtraction. A role shift, on both sides.

The Core Shift: From Product Teacher to Business Partner

A meaningful share of every CS conversation has quietly been product teaching in disguise - a user books time with their CSM not for a relationship check-in, but because they’re stuck on something the product should’ve made obvious.

• The tell: screen-sharing. A call to show where a setting lives, a Loom walking through a feature - product education done manually, by someone whose real value is commercial judgment.

• It’s reactive. Help only comes when a user finally asks, not the moment they get stuck. It arrives late, and it doesn’t scale past one CSM’s calendar.

• An agent fixes the timing. Give it live context on a user’s actual progress, and that whole category of conversation mostly disappears - handled in real time, inside the product.

What’s left for CS isn’t “did this person learn the product.” It’s the questions that always mattered more: Is this account healthy? Is there a champion who’ll fight for renewal? Is there risk a usage dashboard won’t show? Is there expansion we haven’t surfaced?

What Time Actually Gets Freed Up

Worth being honest about what this time was going to - it wasn’t strategic.

• The same “how do I set this up” questions, asked by different people, forever

• No judgment required, no account history, no commercial context — just product knowledge

• Exactly the kind of knowledge an agent holds consistently, at any hour, for any number of users at once

What Fills That Time: Higher-ROI, More Commercial Work

Freed-up time doesn’t sit empty. It moves to the work that was always more valuable and always harder to get to:

• What an account is planning, what else they’re evaluating

• Where the relationship could expand

• Who inside the account will actually champion renewal

This is customer success in the fullest sense - and it scales worst when a CSM doubles as the help desk. Remove the help-desk half, and the commercial half finally gets the attention it needed.

The New Responsibility: Managing the Agent

Delegating onboarding isn’t a one-time handoff. Someone defines what “good” looks like, and someone checks the agent is actually delivering it. Four ongoing jobs:

• Define “good” - and for whom. A free-trial user needs something different than an enterprise admin rolling out to 200 people. Success criteria per segment, not one objective for everyone.

• Set guardrails. What it can and can’t say, when it hands off to a human, where it stays conservative instead of confidently wrong - judgment CS already has, applied to a system.

• Analyze and improve performance. Where it’s driving activation, where it’s ignored, where the advice technically works but reads badly. Closer to coaching a new hire than debugging software.

• Keep it current. When a feature ships or changes, someone tells the agent where things live now. Left alone, it goes stale like a static help doc - except confident, stale advice is worse than none.

That work sits with CS, not engineering or product - they’re the team that knows what a good outcome looks like. Part of the role starts to look less like “answering tickets,” more like “managing a teammate.”

The Role, Restated

Agentic onboarding doesn’t shrink customer success - it re-weights it. Away from repetitive product teaching, toward the commercial judgment that protects and grows revenue, plus a new layer of responsibility for managing the agent now doing the teaching.

The team gets smaller in one dimension and more senior in another.

Agentic Onboarding & the CS Role: FAQ

Does this mean fewer customer success roles? Not fewer - different. The repetitive work shrinks; the commercial and agent-management work that replaces it needs more experience, not less.

Who’s responsible for the onboarding agent once it’s live? Increasingly, CS - they’re best positioned to define a good outcome and catch it when the agent gets something wrong.

Does this change what skills CS hires need? Over time, yes. Product knowledge still matters, but commercial judgment and comfort managing an AI system become more central.

Is this just CS becoming “more technical”? Not exactly. Less writing code, more defining objectives, reviewing outcomes, and knowing when to step in - closer to managing a junior teammate than an engineering skill.

Subscribe now

Share

Knowing when to hold back, step in, or leave someone alone entirely - that’s the whole philosophy. An agent with perfect product knowledge that interrupts at the wrong moment is worse than one with average knowledge that waits for the right timing.

The Retail Store Analogy

Two kinds of stores exist.

Store A: A salesperson greets you at the door as soon as you walk in - “What are you looking to buy today?” You’re a bit overwhelmed - you reply “just looking” and walk out.

Store B: Nobody approaches you right away. You wander, touch things, browse. The sales rep observes you - what you stop at, what you pick up. Then they step in with a personalized suggestion: “I saw you checking out those tops - we’ve got a bigger collection just over here.”

In-product onboarding should always feel like Store B. We build ours around these four rules.

Rule 1: Let Them Explore First

The moment someone lands in a new product, they need time to look around on their own terms before an agent says anything.

• The agent watches for the first 8–30 seconds, silently

• It’s collecting signal: what they clicked first, what they lingered on, what they opened then backed out of

• Only once that window closes does it speak — shaped by what it just watched

Not this: “Need help getting started?” - generic, works for anyone. This: “Looks like you’re exploring the reporting tab - want me to show you how to build your first dashboard?” - specific, earned by observation.

Rule 2: Two Cool-Down Periods, Not One

Most onboarding tools treat “wait time” as one fixed number. It isn’t — it depends entirely on how the last suggestion landed.

• Accepted help: a good sign, but not a license to pitch the next thing immediately. Give the user room to actually use what they just accepted.

• Declined help: a real signal. This cool-down runs meaningfully longer, and it compounds: repeated declines should turn proactive suggestions off entirely for that session.

Treating every “no” like the first one is how proactive help turns into nagging.

Rule 3: One Next Step at a Time

Remember your end users are overwhelmed with information and doing a million things at one time - Make their life easy!

When the agent steps in, it should offer one relevant call to action for the user to do. Not a list, not “here are three features you might like.”

• Everyone’s already managing more information than they can process

• A menu of options isn’t help - it’s more cognitive load with good intentions

• One clear suggestion is actionable; a list is just more to read and process

How it flows: agent offers one suggestion → user acts, ignores, or dismisses it → only then does the agent decide what comes next → repeat.

Rule 4: Let the User Choose How To Execute Help

Not everyone wants the same kind of help - it also depends on the task at hand.

Three modes:

• “Show me” - a guided tour. The agent highlights where to go; the user does the clicking.

• “Do it for me, but let me watch” - a browser agent performs the action visibly, step by step.

• “Just handle it” - a direct API action, completed in the background. No walkthrough, just the result.

These aren’t UI preferences - they’re levels of trust. A new user usually starts with “show me.” Someone who’s watched the agent get it right a few times might graduate further to just “do it for me”. The agent shouldn’t assume, or rush anyone into more autonomy than they’re ready for.

Putting It All Together

Every rule here is the same idea, at a different moment:

• Earn the right to speak before you speak

• Read hesitation as a real signal, not an obstacle to push past

• Never mistake “more help” for “more helpful”

• Let the user set the pace of trust

The best in-product onboarding doesn’t feel like onboarding. It feels like someone who noticed exactly what you needed, at exactly the moment you needed it - and who leaves you alone the rest of the time.

Philosophy & Best Practices: FAQ

Why wait 20–30 seconds before offering help at all? Acting before someone’s explored what you have to offer reads as intrusive, no matter how accurate the suggestion is. The window lets the agent observe real behavior instead of guessing.

Is the cool-down the same whether someone accepts or declines? No. Accepted help gets a shorter cool-down. Declined help gets a longer one - real space before trying again.

What happens if someone keeps ignoring suggestions? The cool-down keeps extending. Repeated declines can turn proactive suggestions off entirely for that session.

Why only one suggestion at a time? Onboarding competes for attention against everything else the user is juggling. One clear next step is actionable; a list is just more to process.

Does this mean the agent should almost never interrupt? Not never - but every interruption has to be earned by real context, not defaulted to. Restraint is a feature, not a limitation.

What are the three guidance modes? “Show me” (guided tour, user clicks), “do it for me but let me watch” (visible browser agent), and “just handle it” (background API action). Users should be able to choose.

Should new users start at the most autonomous mode? No. Trust builds gradually - most start with “show me” and graduate as the agent proves itself.

Discover how to build your own onboarding agent:

https://developers.autoplay.ai/quickstart

Subscribe now

Share

Traditional onboarding is sending users a video they never watch, documentation they never read, and a product tour they close before it even starts. Agentic onboarding is different: it’s a personalized experience that gives each user exactly what they need, when they need it - and doesn’t waste time telling them what they’ve already figured out.

Most onboarding tools already automate sending. Agentic onboarding automates the judgment - what to send, to whom, when.

Two Halves of Onboarding: Outside the Product vs. Inside It

Onboarding splits into two categories, and agents help differently in each.

Outside the product - welcome emails, drip sequences, sales handoff notes, setup guides.

• Asynchronous and scheduled

• Doesn’t need to know what the user is doing right now

• Easy to delegate - agents can draft, sequence, and personalize it from data collected between sessions

• Low-risk, and most tools already do a version of it

Inside the product - the part that actually teaches someone to use the product while they’re in it. This is where most tools quietly give up.

• Some products drop users in with zero guidance

• Others front-load a tour, checklist, or wizard

• Both are static - they don’t adapt to what this user is doing, has figured out, or is stuck on

That static gap is what agentic onboarding closes.

Why In-Product Onboarding Has to Be Real-Time

A tour doesn’t know you’ve already used the feature it’s explaining. A checklist doesn’t know you’re stuck on step 4, not step 2. A chatbot doesn’t know anything happened unless you go ask it.

In-product guidance only works if it’s built on what the user is doing right now:

• What they clicked

• What they skipped

• Where they paused

• What they haven’t touched yet

Without that live visibility, “in-product onboarding” is just a script with better timing. Sending the right email at the right time is solved. Catching a user about to give up on a feature they haven’t found - before they do - is not.

How Agentic Onboarding Actually Works

Give the agent the right context, and let it act on it. That means connecting three things that usually live in separate tools:

1. Behavioral data - from product analytics already tracking clicks, drop-off, feature usage

2. An AI agent - reasoning over that data live, not retrieving canned answers

3. A delivery layer - the support/chat interface already in the product, where the agent can act

Most teams already have #1 and #3. What’s missing is the connective tissue - a way for behavioral signal to reach the agent mid-session, so it can decide what to say and when.

That connective layer is the actual unlock. Not a smarter chatbot. Not another tour builder.

It also scales better than static rules ever could. A checklist can react to one or two conditions before it’s unmanageable to maintain. An agent can weigh a user’s full behavioral history, plan tier, what they’ve mastered, what similar users struggled with, and their last five actions - all at once - to pick the single next best move.

Why Delegate Onboarding to an Agent at All?

Because the current system burns the wrong kind of time.

• 60–70% of customer success ticket volume is repetitive “how do I do X” questions

• That’s not relationship-building or strategic work - it’s the same answer, given by a human, over and over

• Every one of those tickets is a signal onboarding already failed once: the user didn’t discover the feature, didn’t get proactive help, had to stop and ask

Delegating the teaching layer isn’t about replacing CS - it’s giving them their time back for the work that actually protects and grows revenue: expansion signals, renewal risk, account strategy. That’s commercial work. Explaining where a button is, is not.

Why Should You Build an Onboarding Agent?

It’s not the right investment at every stage. But it starts to make sense once these show up together:

• You’re scaling. The gap between great onboarding and what you can deliver per account widens with every signup.

• Free trials live or die on it. If users don’t reach real value before the trial ends, it generated a signup and failed at its actual job.

• Attention spans are shrinking. Tolerance for docs, tours, and videos keeps dropping - permanently.

• CS has no live visibility. They’re working from tickets and check-ins, not a real-time view of usage.

• Help only works in the moment. The instant someone hits friction is the only moment help is useful - before or after is guesswork.

• Inboxes aren’t where users are looking. A perfectly timed email doesn’t help someone stuck inside the product right now.

These aren’t six separate arguments - they’re one: user volume, the speed users need to succeed, and their shrinking attention have all outpaced manual - or even scripted - onboarding.

What Shouldn’t Be Delegated

Agentic onboarding is a lever, not a philosophy. Keep these human:

• High-stakes or emotionally loaded moments - a frustrated enterprise customer mid-escalation doesn’t want a bot deciding what happens next

• Strategic or commercial conversations - expansion, renewal risk, account strategy need a person who understands the relationship

• Anything where trust is the product - in regulated or high-touch industries, the first human interaction can matter more than the fastest one

The goal isn’t removing humans from onboarding. It’s freeing their time from the parts that never needed a human, for the parts that do.

Agentic Onboarding: FAQ

Is this the same as a chatbot? No. A chatbot answers when asked. Agentic onboarding proactively decides what a user needs based on real-time behavior - often before they know they need help.

Do I need to replace my existing tools? Usually not. Most teams already have the behavioral data and a support/chat interface. Agentic onboarding connects the two.

Is this only for complex products? It’s most valuable where users get stuck silently - which correlates with complexity but isn’t limited to it. Simple products with low feature discovery benefit too.

Does this replace customer success? No. It removes the repetitive, low-value “how do I use this” volume, freeing CS for higher-value, revenue-protecting work.

Subscribe now

Share

It sounds clean. It sounds powerful. It's actually a step backwards for most users.

Here's why.

The blank page problem

A chat interface puts the entire burden of exploration on the user.
To get value, you have to know what to ask. And most users - especially new ones - don't.

This isn't a failure of intelligence. It's a failure of context. When someone opens your product for the first time, they have a vague goal and almost no mental model of what your product can actually do. A traditional UI scaffolds that gap.

Navigation, feature pages, empty states, tooltips - all of it quietly communicates: here's what exists, here's what's possible, here's where to start.

A blank chat box communicates none of that.

"Users don't know what they don't know" gets exponentially worse

In a traditional UI, discoverability is built into the surface.

A user stumbles across a feature because it's sitting in a menu. They click something they didn't plan to click. That accidental discovery has real value - it's often how users find the thing that makes them stick.

In a chat-only interface, nothing is stumbled across. You get exactly what you ask for, and nothing else.

The user who asks the right questions gets enormous value. The user who doesn't - which is most users - gets a fraction of what the product can do and eventually leaves.

The irony is that the more powerful the product, the worse this problem gets.

More capabilities mean more things a user could ask for and won't, because they don't know how to ask.

Onboarding doesn't get easier. It breaks.

Traditional onboarding exists to close the gap between what a user knows and what a product can do. It's a guided introduction to possibility.

In a chat-only world, that gap doesn't shrink - it becomes invisible.

There's no tour to take, no checklist to complete, no empty state nudging you toward your first action. Just a prompt.

Most users will type something generic, get a generic answer, and conclude the product isn't that useful. Not because it isn't - but because nothing showed them where to look.

What the data already tells us

Users discover less than 15% of a product's valuable features on average. That number was measured in products with full UIs, onboarding flows, and in-app guidance.

Remove the UI entirely, and that number doesn't go up.

The fix isn't a better chat interface

A smarter LLM doesn't solve this. A better prompt placeholder doesn't solve this. The problem isn't the quality of answers - it's that users aren't asking the right questions in the first place.

The fix is proactive guidance. Instead of waiting for users to ask, the product needs to know where the user is, what they've done, and what they should do next - and say it first.

Chat interfaces that succeed will be the ones that don't wait. They'll watch behavior, detect the gaps, and reach out before the user realizes they're stuck.

That's not a chat interface anymore.

That's an onboarding layer built on top of one.

Subscribe now

Share

There are three useful ways to make Fin more proactive, each requiring more setup than the last.

Before getting into the levels, here is the difference it makes in practice:

Without session context

User: I can’t change my plan.

Fin:  Here’s how to change your plan: [help article link]

With session context

Internal note: User visited /billing, selected Pro plan, 
submitted checkout, hit a payment validation error.

User: I can’t change my plan.

Fin:  It looks like the payment step didn’t complete — the card validation failed.

      Try re-entering your card details or use a different payment method.

What Fin depends on

Fin is not a static chatbot. Its behavior depends on the sources you give it and the instructions you configure.

You can make it answer from help center articles, product docs, internal notes, and other structured inputs. You can also decide which sources matter most in a given flow, which documents should be treated as primary, and how Fin should respond when sources conflict.

For example, billing docs might be primary inside a checkout flow, while general onboarding docs are secondary.

The limitation is usually not the model. It is what Fin can see. If Fin can only see the user’s message and your docs, it can give a good generic answer. If the conversation also includes the user’s product activity, workflow, and recent actions, Fin has a better starting point.

The two common Intercom setups

Most teams start in one of two places.

Some configure Fin mostly inside Intercom: Workflows, routing, articles, canned replies, and outbound messages.

Others take a more developer-led approach and connect Intercom to internal APIs, user data, and custom logic.

Both are useful, but neither automatically gives Fin live product context.

Level 1: URL and page targeting in Workflows

The simplest way to make Fin proactive is using Intercom’s Workflows to trigger a message when a user visits a specific page. No custom events, no API calls, just URL rules and a workflow.

In the Intercom workflow builder, set your trigger to “Customer visits a page” and add a page rule:

• URL contains /pricing: triggers for any URL with /pricing in the path

• URL starts with https://app.yourproduct.com/billing: targets all billing subpages

• Exact match: triggers only on one specific URL, including query parameters

You can also layer in time on page as a condition. For example: trigger only if the user has been on /pricing for more than 60 seconds. That is already better than firing the chatbot the second someone lands on a page.

At the end of the workflow path, add a “Let Fin answer” step. When the user replies to the workflow message, Fin takes over and handles the conversation, pulling from your help docs, product articles, and system prompt instructions.

This gives you basic location-aware and timing-aware support with no code. The limitation is that the workflow is still based on a page rule. Fin knows where the user is, but not much about what they did before or after that page view.

Level 2: Event-based triggers

If you are tracking custom events in Intercom, you can use them to trigger messages, a step closer to behavior-based proactivity.

Track events via the JavaScript API:

window.Intercom(’trackEvent’, ‘selected-plan’, {

  plan_name: ‘Pro’,

  billing_cycle: ‘annual’

});

Once that event is tracked, you can create an outbound message in Intercom that fires every time the event is recorded. In the message rules, set “When” to your event, then configure frequency to avoid over-messaging. For example, at most once per hour per user.

You can also filter by event metadata. For example, only trigger the message if billing_cycle is annual, or layer in a “Where” rule like Current URL contains /checkout.

To keep Fin in the loop, add “Let Fin respond” as a follow-up action on the outbound message. When the user replies, Fin picks up the thread.

This is better than URL targeting. You are reacting to things users actually did, not just where they are.

But there is an important limitation: event-based messages use events as triggers, not as context.

You can manually define an event like selected-plan and trigger a message when it happens. But that does not mean Fin understands the sequence of events that led up to the conversation.

The event can start the conversation, but it does not become part of Fin’s reasoning unless you connect that event data back into the conversation as context.

That is the difference between event-based triggers and real-time session context.

Level 3: Real-time session events

The goal is not just to trigger a chatbot response from an event. The goal is to make the user’s recent product activity available as context inside the Intercom conversation.

That means connecting session events as a data source for the conversation, not just using them as one-off triggers.

You do not need every raw event. You need the actions that help Fin or the support team understand what the user was trying to do, what happened before they opened chat, and where the workflow broke down.

The pattern has four parts:

1. capture product events

2. link the product session to the right Intercom conversation

3. write useful activity into the conversation as internal notes

4. summarize and clean up older notes so the thread stays readable

This is where a tool like Autoplay can help. Autoplay provides an SDK for sending real-time product activity into chat and support tools. For Intercom, it handles the session linking, buffering, internal note writing, redaction, and summarization.

The pipeline looks like this:

Product events (PostHog)

→ Autoplay links the session to an Intercom conversation

→ Autoplay writes internal notes into the conversation thread

→ Those notes become context inside the Intercom conversation

Internal notes are the bridge. They let you put product activity into the Intercom conversation without showing it to the user. The support team can read them, and Fin can use that context depending on how your Intercom workspace is configured.

In practice, you should write only the product actions Fin or the support team need, not raw sensitive input values.

1. Capture product events

You need a stream of product activity: page views, clicks, form submissions, errors, and workflow events.

Autoplay uses PostHog-compatible capture for this. You add the snippet to your frontend, identify the user after login, and pass the fields Autoplay needs to connect that product session back to Intercom.

2. Link the product session to the Intercom conversation

Product events only help if they end up in the right thread.

Autoplay uses Intercom webhooks to know when a user starts or replies to a conversation. The key webhook topics are:

conversation.user.created

conversation.user.replied

Once Autoplay links a product session to an Intercom conversation, that mapping is kept stable so later events continue going into the same thread.

3. Write internal notes into Intercom

Once the session is linked, Autoplay writes product activity into the conversation as internal notes.

Those notes are visible to the support team, but not to the user. They give Intercom a live picture of what the user is doing in the product, for example:

[1] User clicked Sign up button on the pricing page

[2] User clicked Confirm plan button on the checkout page

[3] User submitted payment form on the checkout page

In practice, you should only write the product actions Fin or the support team need, not raw sensitive input values.

4. Buffer events before the conversation is linked

Sometimes product events arrive before Autoplay knows which Intercom conversation they belong to.

In that case, Autoplay buffers the actions. Once the session is linked to a conversation, the buffered activity is flushed into the right thread.

5. Summarize and clean up older notes

Raw action notes are useful, but you do not want the Intercom thread to become a wall of events.

Autoplay can summarize the session after a configurable threshold of actions and redact older raw notes. The summary is written back into Intercom as a cleaner internal note:

The user navigated to the pricing page, selected the Pro plan,

submitted the checkout form, and hit a payment validation error.

They later returned to billing settings.

The summarization step is separate from Fin. Fin and the support team then have that summary available inside the Intercom conversation, depending on how your workspace is configured.

For the full implementation, including the snippet, webhook setup, session mapping, note writing, redaction, and summarization, see the Autoplay Intercom integration guide.

What this changes

With session notes in the thread, Fin and the support team have context before the user explains the problem.

If someone opens chat and asks “why can’t I change my plan,” the conversation already has a note showing they visited billing, selected Pro, submitted checkout, and hit a payment validation error.

Instead of asking the user to retrace their steps, the team can read the session summary and pick up from there.

Picking the right level

Most teams do not start with real-time session context, and they do not need to. URL and event triggers cover a lot of ground and are worth setting up properly before adding anything more complex.

But if your support team regularly spends time asking users to retrace their steps, or if Fin is giving technically correct answers that miss the actual workflow the user is stuck in, that is a signal that session context would help.

The Intercom docs for URL targeting, event-based messages, and letting Fin follow up after Workflows are good starting points for the first two levels.

If you want to add the real-time layer, the Autoplay Intercom integration guide walks through the implementation: webhooks, session mapping, note writing, and summarization.

Subscribe now

Share

That makes this a useful moment to explain a design choice that sits underneath it: why our real-time architecture started with PostHog.

Autoplay is not a reporting layer. It is infrastructure for turning live product behavior into model-readable context. The SDK is the public interface to that system. You connect your app, stream real-time user activity into your service, and receive typed payloads that can be embedded, stored, retrieved, and passed into agents or copilots. In our docs, that flow is explicit: browser activity enters the Autoplay connector pipeline, gets extracted, normalized, and optionally summarized, then arrives over SSE or push webhook as typed payloads your application can use directly.

That architecture needs a specific kind of event layer.

It needs broad browser-side capture with low frontend burden. It needs identity and session continuity. It needs an event model that is simple enough to ingest at scale but expressive enough to carry useful context. It needs a clean way to route that stream into your own infrastructure in real time. It needs enough structure that downstream systems can reason over it programmatically. And it needs pricing that makes dense behavioral capture practical, not something you immediately start trimming.

Those are the reasons we started with PostHog.

That phrasing matters. We do plan to support other analytics layers over time. But when we were building the first version of this architecture, PostHog was the cleanest fit for the problem in front of us. It gave us the best starting point for building a real-time behavioral backbone that could power agents, copilots, memory systems, and retrieval pipelines, not just dashboards.

The architecture we actually run

In our standard setup, a customer installs posthog-js in the frontend, initializes it with their Autoplay API key, attaches a product_id, and identifies the user again after login with their application user ID and optionally email. That gives us the behavioral stream, the routing key, and the identity bridge we need for session and conversation linking. Our quickstart also uses a two-minute session idle timeout so the stream stays aligned with how we package live context downstream.

From there, we configure a PostHog webhook destination pointed at the customer’s Autoplay connector. That is the important boundary in the system. Before that point, you have events. After that point, you have context.

Autoplay takes the incoming stream and turns it into something agent systems can actually use. We extract raw browser activity into normalized actions, label those actions in natural language, group them into sessions, and optionally summarize the session into compact prose. The SDK then exposes that as typed ActionsPayload and SummaryPayload objects over SSE or push webhook. Those payloads are designed to flow straight into vector stores, memory systems, copilots, and RAG pipelines.

The path looks like this:

1. posthog-js captures browser activity.

2. PostHog ingests the events and attaches user and session context.

3. PostHog forwards selected events to the Autoplay connector.

4. Autoplay extracts, normalizes, labels, groups, and optionally summarizes the session.

5. autoplay-sdk consumes the resulting stream over SSE or push webhook.

6. Your service embeds that context, writes it to memory or retrieval infrastructure, and passes it into a model.

7. The model decides whether to stay silent, answer reactively, or trigger proactively.
   
   

That is the architecture we use ourselves. But the more useful point is that it is also a pattern other teams can adopt. If you want support systems that know what the user was doing before they opened chat, copilots that react to real workflow state, or memory systems that update from product behavior instead of only from text conversations, this is the kind of event backbone you need.

Why the event model mattered

The core unit in PostHog is an event: a user or distinct_id, a timestamp, an event name, and a JSON-like property blob. Those properties can include text, booleans, numbers, dates and timestamps, arrays, and nested objects. That sounds basic, but it is exactly what made the model useful outside dashboards. It is flexible enough to carry product-specific context, and typed enough to stay understandable as the system grows.

That flexibility also matters operationally. Teams can define event schemas, manage event definitions, and group properties so structure stays consistent and discoverable over time rather than drifting into a mess of ad hoc payloads. Events can also be enriched with user properties, group properties, and custom metadata, which matters because downstream analysis is rarely based on a naked click stream. Useful systems usually need organization-level context, user state, workflow identifiers, route keys, and product metadata attached to the underlying behavior.

That is what made PostHog a strong starting point for us.

If you are building agent systems, the raw requirement is not “have events.” It is “have events that can be turned into state.” You need enough flexibility to attach product IDs, route keys, workflow hints, or metadata without fighting the schema. You need enough structure that your application can reason over the stream programmatically. And you need enough consistency that models are not being fed an ever-changing mess of telemetry. PostHog gave us a strong base layer for that, and then Autoplay does the second half of the work by turning that event stream into typed actions and readable session summaries.

Why capture quality mattered

If you are trying to build on top of behavior, instrumentation burden matters as much as event quality.

PostHog’s web SDK automatically captures pageviews, pageleaves, clicks, input changes, and form submissions for common interactive elements by default. That meant teams could get broad behavioral coverage quickly rather than spending weeks manually instrumenting every workflow before they could test anything useful. For our use case, that mattered because the captured stream is not the final product. It is the substrate we transform into agent context. The faster you can get a high-coverage stream, the faster you can start turning real behavior into something your models can use.

This is one of the biggest reasons it made sense as our starting point. A product team, support engineering team, or platform team can start with the same behavioral stream they already want for analytics, then use that same stream to power runtime systems. That means fewer duplicate SDKs, fewer competing schemas, and less drift between what the dashboard says happened and what the copilot thinks happened.

Why routing mattered

A lot of analytics products are good at collecting events and surfacing them in charts. That is not the same as being comfortable in the middle of a live product system.

For our use case, the event layer had to be adjacent to runtime. It had to let events move outward in real time into our own pipeline, not stop inside a reporting product. PostHog’s platform explicitly distinguishes between public capture endpoints and private query endpoints, and supports real-time destinations and webhooks in its broader product surface. It also supports transformation and enrichment patterns at ingestion time, which helps keep downstream data clean and structured before it reaches the systems that actually consume it.

Its public POST-only endpoints, including event capture at /i/v0/e, are not rate-limited, while private authenticated endpoints are rate-limited separately. For many analytics endpoints, the documented limits are about 240 requests per minute and 1,200 per hour. The query endpoint allows up to 2,400 per hour. Other private read and write APIs are capped around 480 per minute and 4,800 per hour per API key.

That separation is exactly what you want when the critical path is capture and forwarding, not dashboard queries.

In other words, if you are building agents, copilots, or internal systems that need the behavioral stream while the session is still alive, the shape of the API matters. You do not want the useful path to depend on a reporting endpoint. You want ingestion to feel like infrastructure. PostHog was a strong fit for that, which is why we started there.

I am also deliberately being precise here on latency. We treat the stream as effectively live in practice, which is what matters for our architecture. I am not making a hard benchmark claim here about exact milliseconds, and I am not claiming exact queue behavior for other vendors without controlled benchmarks. The important point is architectural: PostHog was designed in a way that made real-time capture and routing practical for our first version.

Why sessions and replay mattered

Single events are useful. Real user workflows are sequences.

PostHog supports both event capture and session replay. That mattered because teams often need both views at once: the granular stream for live state, and the session-level view for validating friction, detours, hesitation, and workflow breakdowns.

Session recordings are a separate unit from standard analytics events. They are stored and priced per session or recording, not per event. They are also more expensive per item than standard analytics events, which makes sense because they are a denser resource. PostHog’s pricing treats session replay as a separate resource, with a free tier and then tiered per-recording pricing beyond that. Product analytics events are priced separately, starting at roughly $0.00005 per event after the first 1 million monthly events, which are free.

Architecturally, that distinction is useful.

The high-volume event stream is what powers real-time state and downstream decisions. Session replay is the denser, slower path you use to inspect complete workflows, validate behavior, and build better models of how users actually move through the product. It helps you see detours, friction points, hesitation, and navigation patterns that matter when you are trying to understand real workflows instead of isolated clicks. If you care about product-aware AI, having both event-level and session-level data available in one stack is a real advantage.

Why pricing was part of the technical decision

Pricing is not a procurement detail here. It shapes what you can build.

If your event layer is too expensive, teams start deleting the very signal that makes behavioral systems useful. PostHog’s usage-based pricing keeps the basic model simple: the first 1 million product analytics events per month are free, then pricing starts at $0.00005 per event and decreases with scale. That is about $50 per 1 million events at the starting paid tier. Session replay has its own free tier and tiered pricing by recording, and those recordings are priced separately because they are a different resource than standard analytics events.

That mattered for us, but it also matters for anyone experimenting with real-time support or product-aware copilots. You need enough behavioral density to make the model useful. If every additional event feels like a billing risk, the system gets blind very quickly.

It also means startups and early-stage teams can get a meaningful amount of signal before the event layer becomes a real cost center. If you are capturing tens or even hundreds of thousands of events per month, you are still working in a pricing model that feels like infrastructure, not something that forces aggressive under-instrumentation on day one.

Where the SDK fits in

This is also why we launched the SDK in the shape we did.

autoplay-sdk is not another analytics SDK. It is the interface to the transformed stream. It consumes the connector over SSE or push webhook and hands your application typed Python objects, not raw JSON blobs. ActionsPayload gives you session ID, user ID, product ID, ordered actions, counts, and an embedding-ready .to_text() method. SummaryPayload gives you a prose version of the session when you want compact context instead of a full action list. The SDK also supports async and sync clients, push and pull delivery, Redis-backed buffering, and per-session concurrency isolation, so a slow downstream job in one session does not block another.

A simple frontend setup looks like this:

import posthog from ‘posthog-js’

posthog.init(’YOUR_AUTOPLAY_API_KEY’, {

    api_host: ‘https://us.i.posthog.com’,

    person_profiles: ‘identified_only’,

    session_idle_timeout_seconds: 120,

    loaded: (posthog) => {

        posthog.identify(posthog.get_distinct_id(), {

            product_id: ‘YOUR_AUTOPLAY_PRODUCT_ID’,

        });

    },

})

// after login

posthog.identify(user.id, {

    product_id: ‘YOUR_AUTOPLAY_PRODUCT_ID’,

    email: user.email,

})

And then the downstream service consumes the live stream:

import asyncio

from autoplay_sdk import AsyncConnectorClient

STREAM_URL = “https://your-connector.onrender.com/stream/YOUR_PRODUCT_ID”

API_TOKEN = “unkey_xxxx...”

async def on_actions(payload):

    text = payload.to_text()

    embedding = await embed_api.create(input=text)

    await vector_store.upsert(id=payload.session_id, vector=embedding)

async def on_summary(payload):

    text = payload.to_text()

    await vector_store.upsert(id=payload.session_id, vector=await embed(text))

async def main():

    async with AsyncConnectorClient(url=STREAM_URL, token=API_TOKEN) as client:

        client.on_actions(on_actions)

        client.on_summary(on_summary)

        await client.run()

asyncio.run(main())

The point is not just that this works. It is that customers do not need to build the interpretation layer themselves. PostHog captures the live behavioral stream. Autoplay turns it into typed, LLM-ready context. The SDK makes that context easy to consume.

That is useful whether you are building with Autoplay specifically or thinking about the general pattern. The better the event backbone is, the less custom interpretation code you need to write yourself.

What this enables in practice

This is not just good for us. It is useful for a lot of teams working close to product behavior.

A support team can build a copilot that already knows what the user was doing before they opened chat.

A product team can build a proactive assistant that notices repeated no-progress behavior and intervenes at the right moment.

A growth or onboarding team can track whether someone has actually completed a workflow, not just visited a page.

An engineering team can update user memory or retrieval systems from real behavior instead of only from text inputs.

These are the kinds of use cases our docs are built around: real-time events first, then memory, then golden paths, then trigger logic that decides when to proactively help and when to stay quiet.

The key point is that they can all share the same behavioral stream.

That is the real architectural benefit. You do not need one telemetry layer for analytics and a second completely separate telemetry layer for runtime AI. PostHog gives you the capture, identity, sessioning, and event backbone. Autoplay turns that stream into typed, model-readable context. The SDK exposes it in a form developers can use directly.

The real reason we started with PostHog

The shortest version is this:

We did not need a tool that was only good at telling us what happened last week.

We needed a tool that could sit in the loop between user behavior and system response.

That meant the event layer had to capture enough detail without heavy manual instrumentation, preserve identity and session continuity, support a flexible but typed data model, allow enrichment with user, group, and product context, route data outward in real time, remain open to programmatic consumption, support both events and sessions, and stay affordable enough to use as infrastructure.

PostHog had that combination.

That does not mean it is the only analytics layer we will ever support. It means it was the right place to start.

At Autoplay, that is what let us take a live behavioral stream, turn it into typed LLM-ready context, and use it to power agents and copilots in the moment. But the more general point is this: if you want product data to do more than describe the past, you need an event backbone that is comfortable powering systems outside the dashboard too.

That is why we started with PostHog. And that is why the setup is useful for our customers as well.

Subscribe now

Leave a comment

So we built a pipeline to go deeper, ingesting sessions at scale, extracting structured intent signals: what workflows users were attempting, which tasks they completed, where they stalled. We built TERRA, a framework to understand the relationship between user actions and the ideal “golden path” through a product, model completion rates per workflow, and understand intent at the session level.

Then the obvious question was: why are we only looking at this after the fact?

The Problem With Reactive AI

Most AI copilots wait to be asked. A user opens the chat, types a question, gets an answer. It’s a slightly smarter FAQ, but it misses the majority of users who never open the chat. They hit a wall and quietly leave.

Take a PLG onboarding flow (e.g. SMSPs). New user signs up, no guided tour. They need to connect their Instagram account, upload their media, before they schedule their first post. They reach the auth screen, get confused, click back to the dashboard thinking they’re done. They try to post. Nothing works. First session. Often their last.

Your chatbot has no idea any of this is happening. Your support team can fix it, but only after the user is gone.

What the Data Stack Gets Wrong

You already have the data. LogRocket shows the user left the auth screen after 8 seconds. Amplitude shows a drop-off at onboarding step 3. Segment has a connect_instagram_started event with no completed match.

You know they left, where, and when. But none of these tools know what the user was trying to do, and without intent, goal, and progress, you can’t trigger action. You can’t tell your chatbot to intervene. You can’t send the right email. You just watch the funnel.

The gap isn’t in data collection. It’s in the layer that turns raw activity into something an AI agent can reason over.

Introducing the Autoplay Proactive SDK

Today we’re launching the Autoplay Proactive SDK- streaming what your users are doing, in real time, as clean, structured, LLM-ready context directly into your agents.

Not raw telemetry. Structured payloads: the page the user is on, what they clicked, what they’re trying to accomplish, where they’ve stalled. Autoplay sits between your product and your copilot, it doesn’t replace Intercom or Zendesk, it gives them eyes.

Pull: smarter answers when users ask. User asks “how do I schedule a post?” Without Autoplay, the chatbot returns a generic setup article. With Autoplay, it knows they reached the Meta auth screen 4 minutes ago and left without completing it, and delivers the exact missing step.

Push: intervention before they ask at all. Autoplay detects the missed step the moment it happens and fires your copilot: “It looks like Instagram isn’t connected yet, here’s the one step you need.” User completes the flow. Schedules their first post. Stays.

The Three-Layer Model

The SDK is a progressive build-up. Each layer makes your copilot meaningfully smarter.

Layer 1: Real-time events (available now.) Every user action is captured, processed (extraction → normalisation → optional LLM summarisation), and delivered as a typed payload. Your agent knows what the user is doing right now without waiting for them to describe it.

Layer 2: User memory (coming soon.) A per-user knowledge profile, updated after every session: what they’ve mastered, what’s in progress, what they’ve never touched. Your agent stops suggesting workflows the user already knows and starts surfacing the actual gaps.

Layer 3: Golden paths + knowledge base (coming soon.) Record the ideal journey for any workflow using the Autoplay Chrome extension. Autoplay indexes these in a vector database. At inference time, your agent retrieves the ideal path, compares it to what this user has done, and surfaces the precise next step.

Where the user is now        ← real-time events
What they've already done    ← user memory
Where they should be going   ← golden path from knowledge base
                                       ↓
         copilot surfaces the single most relevant next step

Getting Started

Integration takes minutes.

See our full docs here.

Step 1 — Add the snippet to your frontend

import posthog from 'posthog-js'

posthog.init('YOUR_AUTOPLAY_API_KEY', {
    api_host: 'https://us.i.posthog.com',
    person_profiles: 'identified_only',
    session_idle_timeout_seconds: 120,
    loaded: (posthog) => {
        posthog.identify(posthog.get_distinct_id(), {
            product_id: 'YOUR_AUTOPLAY_PRODUCT_ID',
        });
    },
})

After login, pass the user’s email to enable cross-session identity linking:

posthog.identify(user.id, {
    product_id: 'YOUR_AUTOPLAY_PRODUCT_ID',
    email: user.email,
})

Step 2: Install the SDK

pip install autoplay-sdk

Requires Python 3.10+

Step 3 — Receive your first event

import asyncio
from autoplay_sdk import AsyncConnectorClient

async def main():
    async with AsyncConnectorClient(url=STREAM_URL, token=API_TOKEN) as client:
        client.on_actions(lambda p: print(p.to_text()))
        client.on_summary(lambda p: print(p.summary))
        await client.run()

asyncio.run(main())

Step 4 — Wire it to your copilot

from autoplay_sdk import AsyncConnectorClient, ActionsPayload

async def on_actions(payload: ActionsPayload) -> None:
    suggestion = await your_llm(
        system="You are a proactive product copilot. Suggest one helpful next step. Be brief.",
        user=f"## What the user is doing\n{payload.to_text()}",
    )
    if suggestion:
        await push_to_ui(payload.session_id, suggestion)

client = AsyncConnectorClient(url=CONNECTOR_URL, token=API_KEY)
client.on_actions(on_actions)

payload.to_text() is embedding-ready — pass it into your LLM context, upsert it to a vector store, or use it to trigger any downstream action: email, Slack notification, support escalation with full context attached.

Delivery is available as an SSE stream or push webhook. Both emit the same typed ActionsPayload / SummaryPayload objects.

What You Can Build

Reduce first-session churn. Detect exactly where users stall and trigger a contextual nudge before they leave in-app, chatbot, or email.

Eliminate generic chatbot answers. Every time a user opens support, your agent already knows what they were doing in the product 30 seconds ago.

The reboarding play. User has been on your platform three months but has never opened Analytics. Autoplay detects the gap. Copilot fires: “Want to see your best-performing posts?” Analytics adoption. Upgrade trigger.

Proactive upgrade signals. User hits a limit and starts exploring pricing — Autoplay detects the sequence and triggers your sales motion before they bounce.

Live-context RAG. Embed ActionsPayload events into your vector store in real time for retrieval grounded in what users actually do — not just your docs.

Join the Private Beta

Early access teams get the full SDK, a dedicated connector URL and API token, direct Slack support from us, and early influence on the roadmap.

→ Sign-up to our private beta access

→ Join our Slack workspace — drop a message in #just-integrated after you add the snippet and we’ll get your connector set up same day.

→ Read the docs

What We Believe

The future of AI in software isn’t a chat widget that waits. It’s an agent that knows — what this user is trying to do, where they are right now, what they’ve done before, and what comes next. Everything we’ve built — the session analysis, intent modelling, golden path framework, the pipeline from raw DOM events to LLM-ready context, was pointing here.

We think this changes the economics of onboarding, support, and activation. If you’re building AI-powered products and want your agents to actually know what’s happening, come build with us.

Built in New York. Questions? sam@autoplay.nyc

Subscribe now

The agent’s problem wasn’t reasoning, or understanding my prompts. It was that it used Airbnb badly. It treated the search like a structured query: enter constraints, get results, pick the best one. What I actually did looked nothing like that. I was moving around the map, zooming in and out, opening listings, closing them. I’d look at three places on the same street and decide the street felt off, shift the map slightly, start again. Photos did most of the work. You can tell fast if a place will feel cramped, if the light is bad, if it’s one of those apartments that looks good in the first shot and gets worse after. None of that is in a filter.

There’s also a constant re-ranking happening that you’re not conscious of. You see something slightly better and everything before it drops. You revisit a listing you’d dismissed and it moves up because the alternatives got worse. The agent had no access to any of that.

To know whether the agent did a bad job, you have to do the task yourself, at which point you’ve already done the job. You could give it better instructions, and send it back. But after 45 minutes of watching it search, who wants to evaluate its results, write new prompts, and send it through the whole process again? You either trust what it came back with, or it’s faster to do it yourself.

My session replay, every click, every listing opened and closed, every time I nudged the map, is a complete record of how the preference formed. It’s not noise, but a decision taking shape in real time, and it’s a better benchmark for evaluating the agent than checking whether it completed the booking. The question is whether it converges on the same kind of place and explores the same parts of the map. The ground truth is the process, not the outcome.

Most agent evaluation misses this. We keep asking “did it finish the task” when the more useful question is “did it make the same moves a good human would make.”

The Airbnb UI is built for humans. Visual, spatial, optimized for comparison. It evolved to match how people actually process and filter information. We moved from databases to spreadsheets to SaaS interfaces because each step was more legible to the way humans think.

For an agent, all of that is overhead. It doesn’t need a map. It doesn’t parse photos the way we do. What it actually wants is closer to a spreadsheet, 800 rows, clean columns, every listing queryable. The agent could reason over it directly without navigating a UI built for someone else.

Are we regressing? Is the right interface for an agentic world just a database with an API? Run a filter algorithm, return ranked results, done. That’s not a new idea, it’s basically what SaaS was before anyone put a visual layer on top of it.

The UI isn’t just a display layer for humans. It’s where intent forms. I didn’t know exactly what I wanted when I started; browsing was how I figured it out. The visual, spatial, comparative experience of Airbnb isn’t a nice-to-have on top of the data. It’s the process by which a vague preference becomes a specific one. Strip it out and you haven’t made the problem simpler, you’ve just removed the mechanism by which the goal gets defined.

The agent working from a spreadsheet would be faster and more systematic and would still pick worse apartments, because it would be optimizing against a goal that was never properly formed in the first place.

So where does that leave browser agents? The question isn’t whether they’ll replace humans doing this kind of task. It’s whether they can participate in the loop that makes the task work. The one where preferences shift in real time based on what you’re seeing, where the UI is doing cognitive work, not just displaying results.

What changes this isn’t better reasoning or better prompts. It’s agents that read UI behavior as signal: which listings got attention, which got skipped, what got revisited, and what got dropped the moment something better appeared, and use that to infer intent in real-time instead of waiting to be told what to optimize for. The UI doesn’t become redundant. It becomes the data source. The session becomes the instruction set.

That’s a different architecture than most browser agents are built on. And it’s why an Airbnb test is more interesting than it looks.

Subscribe now

Share

Most software, on the other hand, behaves like a well-meaning teacher. We smooth the edges, add a bit of animation, pare back the clutter, and assume that if the UI is clean enough, people will figure it out. For simple products, they do. You open a form, click a button, and the software behaves as we promised. The illusion of clarity feels real - until the product stops being simple.

Once a product becomes a real system (multiple roles, tangled permissions, messy data, exceptions, “it depends” logic), the user isn’t just navigating a product anymore. They’re trying to complete a workflow inside a living environment, with all its quirks and resistances.

That’s why so many AI copilots feel brilliant in demos and disappointing in real life. They can speak. They can explain. They can even suggest steps. But they never feel like they’re with you inside the product. They feel like they’re standing outside the room, talking through the door, while you’re inside, trying to keep control of something that’s already moving.

Most software does the opposite: it gives you options before certainty. It makes you hunt for context, then punishes you when you pick the wrong path. Add AI on top, and you don’t fix the problem. You magnify it - because the weakness isn’t the assistant’s language. It’s its blindness to state.

The UI isn’t going away. It’s just going to stop being uniform. People love saying, “Agents will replace UIs.” But I don’t think the UI disappears. I think it stops being static. The endgame isn’t a blank screen where you type commands. It’s an interface that reshapes itself around the moment: what you’re trying to do, what you’ve already done, what your role allows, what your team usually does, and what tends to go wrong at this step.

That’s why UX is more important than ever. It’s no longer just about aesthetics. It’s about the product’s ability to keep you moving when reality gets messy. And in any real system, reality will always be messy.

Here’s why copilots keep getting complex products wrong: in rich, evolving software, there is no single “correct workflow.” There are workflows, plural. One person’s happy path is another person’s exception. One team’s process is another team’s workaround. Power users don’t follow the docs. They discover patterns and combinations that the documentation never imagined.

So when a copilot is trained only on text (help center pages, macros, old docs, forum posts), it makes a quiet, dangerous mistake: it confuses “what’s written down” with “what’s possible.” That’s where you hear the false negative: “It can’t be done.” Not because the product can’t do it, but because the assistant can’t see the product. It can’t see your permissions, your UI state, the earlier steps you’ve already taken, or what just failed. It’s reasoning with a blindfold on.

And when you build “agentic automation” on top of that, the problem becomes personal. Now the agent is doing things that you, the user, have to debug inside a system you may not fully understand.

If copilots are going to work inside real products, they need to be grounded more like a cockpit than a manual. They need to quietly, constantly, and in real time answer questions like: What is the user trying to accomplish right now? Where are they in the workflow? What’s on screen and available to them? What state is the system in? What just changed? Are they progressing, exploring, or stuck?

Everyone rushes to the chat UI because it’s visible. But chat is only useful when it sits on top of product understanding. Otherwise, it’s just a very polite search box, pretending to be a companion.

For years, “good software” meant fewer clicks. The next era is about fewer moments of uncertainty. The most valuable products won’t be the ones that answer questions faster. They’ll be the ones that reduce the need to ask in the first place - by recognizing intent, tracking where you are in the workflow, and surfacing the next meaningful step at the moment it matters.

The interface becomes personal, not because it’s pretty, but because it’s aware. Aware of your context, your history, your role, and your confusion. And that’s the real shift: not conversation replacing clicks, but software finally meeting users where they are - instead of where the docs assumed they should be.

Leave a comment

Subscribe now

What stood out quickly was how the Leyton and Leyton CognitX teams operate. They are not trying to fit their business into SaaS tools. They build internal systems that match how they work, then start replacing parts of those workflows with agents.

This is a pattern I keep seeing. Strong teams move toward control. They want systems that reflect their workflows, not tools they need to work around. Once that is in place, the next step is obvious. Automate parts of the workflow.

The interesting part is where things break.

Building an agent is no longer the hard part. You can get something that looks good in isolation without much effort. The issue shows up when the agent runs inside a real product.

Internal tools are not clean environments. Permissions change. UI changes based on role and state. Data is inconsistent. There is rarely one correct path through a workflow. What looks like an edge case in theory happens all the time in practice.

So you end up with agents that can reason, but still make bad decisions. Not because they are incapable, but because they are missing context.

We kept coming back to a small set of questions. If an agent cannot answer these, it cannot be reliable.

What is the user trying to do.

Where are they in the workflow.

What is on the screen right now.

What state is the system in.

Is the user stuck or progressing.

Without this, the agent guesses. Sometimes it gets it right. Often it does not.

This is where Autoplay fits.

We focus on connecting behavior to intent and workflow context in real time. Mapping actions to tasks. Tracking how users move through workflows. Understanding what is happening on the screen during execution. Detecting when someone is hesitating or drifting.

That changes how an agent behaves. It stops reacting to isolated inputs and starts responding to what is happening in the product.

The week mattered because the conversations stayed grounded. Everyone focused on what needs to be true for an agent to work in production, inside a tool people use all day.

Internal tools make this possible. You control the workflow. You control the UI. You control how the system is instrumented. That gives you the foundation to build something reliable.

The takeaway for me is simple.

Agents do not fail because they lack capability. They fail because they lack context.

The next phase of agents will be defined by how well they understand the product they operate in. UI state, workflow position, user intent.

That is what makes the difference between something that works in a demo and something people trust in their day to day work.

Subscribe now

Share

SAP rival Odoo, is currently valued at $5.3 billion

Over the last decade SaaS became the dominant model for enterprise software. Every workflow became a subscription: CRM, HR, analytics, marketing, support. Entire companies built around selling access to a UI.

A combination of open-source software, AI agents, and better infrastructure is starting to challenge that model. Instead of buying software, companies are increasingly asking a different question:

Should we just build this ourselves?

One of our customers has done exactly this.

They replaced Salesforce with TwentyCRM. Their entire HR and ERP stack runs through Odoo. And their long-term plan is pretty simple: build most things internally using open-source software.

For years, building internal software was expensive, slow, and fragile. You needed a team of engineers just to recreate something Salesforce or HubSpot already did.

Now that assumption is breaking down.

And the data actually supports this shift. Today 83% of companies already use custom-built software somewhere in their operations, dashboards, internal workflows, automations, integrations , even though most still rely on off-the-shelf tools for standard functions.

At the same time, the global market for custom software development is roughly $43B today and projected to reach about $146B by 2030.

That kind of growth doesn’t happen unless companies are increasingly deciding to build more software themselves, and you can start to see this shift in the tools they’re choosing.

One of the clearest examples is open-source business software, especially platforms like Odoo.

Odoo has quietly become one of the fastest-growing ERP platforms in the world. What makes it interesting is not just that it’s open source , is that it behaves more like a software framework than a product.

You get accounting, CRM, invoicing, inventory, support, etc.

But the real point is that companies can modify it endlessly. Instead of paying tens or hundreds of thousands a year for multiple SaaS tools, teams can start with Odoo and customize the workflows they actually need.

The second signal is companies aggressively reducing their SaaS footprint.

A widely discussed example is Klarna. During its internal AI transformation the company removed over 1,200 external SaaS tools while automating large parts of internal workflows.

At the same time, Klarna deployed an AI assistant that handled 2.3 million customer conversations in its first month, doing the work of roughly 700 support agents while cutting resolution time from 11 minutes to 2 minutes.

The point here isn’t that AI replaces humans.

The interesting thing is that AI replaces software interfaces.

Instead of humans clicking through tools, agents interact directly with APIs and systems, orchestrating workflows across multiple products simultaneously.

When that happens, the UI layer, the thing SaaS companies sell, becomes less important.

But the easiest way I’ve found to think about this shift is actually food.

The food world has three basic models

• Restaurants

• Meal kits

• Grocery stores.

Each solves the same problem (feeding people) but in completely different ways.

And oddly enough, these map almost perfectly to how software is evolving.

1. Restaurants (Traditional SaaS)

Restaurants are the fully packaged experience.

You walk in, someone else cooks the meal, someone else designs the menu, someone else handles the logistics. Your only job is to consume the result.

Uber Eats and delivery apps pushed this even further. Now you can outsource cooking entirely.

This is basically what SaaS did for software. SaaS says: don’t worry about infrastructure, workflows, hosting, updates, engineering; we’ve already built the system. Just log in and use it.

Salesforce, HubSpot, Zendesk, these are restaurants.

And this made sense. Running your own software was like running your own restaurant kitchen, expensive and complicated. And in many cases, this is still the right choice. If something is truly best-in-class, it’s often cheaper to buy the experience rather than build it.

2. Meal delivery kits (Open-source platforms)

Then meal delivery services appeared: HelloFresh, Blue Apron, etc.

They changed the model.

Instead of cooking everything for you, they give you ingredients + recipes.

You still cook the meal, but the hard part, planning and sourcing, is done.

The model clearly resonated. The global meal-kit market is roughly $25–33B today and projected to exceed $70B over the next decade. In the U.S. alone it was about $10.4B in 2023 and is expected to more than double by 2030.

That’s what open-source platforms like Odoo or Twenty CRM represent.

They give you the structure of enterprise software, but let you modify it however you want.

You aren’t locked into someone else’s workflow.

3. Grocery shopping (build-it-yourself software)

Finally there’s grocery shopping.

You buy raw ingredients and cook everything yourself.

This used to be the equivalent of building internal tools from scratch, something only large tech companies could afford.

But AI agents are starting to change that too.

Agents can now write code, connect APIs, automate workflows, and operate software directly.

In other words:

AI is making building your own software dramatically easier.

The psychology behind these models is actually quite predictable.

Most people don’t cook every meal themselves, not because they can’t, but because of time, expertise, and convenience.

Restaurants win when people want simplicity.

Meal kits win when people want control but not complexity.

Cooking wins when people want full customization.

Software markets are starting to follow the same pattern.

For years SaaS dominated because it was the easiest option.

But as customization becomes easier (and cheaper) the balance starts shifting.

Companies are realizing something important:

They don’t actually want generic workflows.

They want software that reflects how their business actually works.

AI agents accelerate this shift even further.

Instead of humans navigating software, agents can execute workflows directly across systems, retrieving data, triggering actions, and coordinating tasks.

This changes the economics of software.

Traditional SaaS pricing is built on per-seat subscriptions.

But agents don’t buy seats.

They operate systems.

At the same time, even SaaS companies are moving toward agent-driven architectures. For example Salesforce now runs autonomous agents through its Agentforce platform, and its CEO has said AI already performs 30–50% of internal work inside the company.

That alone tells you something about where things are going.

So where does this leave SaaS?

Probably not dead.

Restaurants still exist. They’re just no longer the only way people eat.

What seems more likely is a shift in the software stack:

• Open-source platforms become the base layer

• AI agents orchestrate workflows on top

• SaaS products become components rather than destinations

Instead of logging into five different tools, companies will have systems that assemble themselves around their workflows.

The UI becomes optional.

The agent becomes the interface.

And software stops looking like products, and starts looking more like infrastructure.

One last thought.

The SaaS era optimized for distribution.

The next era might optimize for adaptability.

Software that can reshape itself around a company will always beat software that forces the company to reshape itself around the tool.

Which is why open source + AI + agents together feel like something bigger than just another technology shift.

It feels like the moment when building software becomes easier than buying it.

And historically, when that happens, markets change very quickly.

Subscribe now

Share

At first glance, it looks like that future is already here. New AI-native “replacements” for SaaS appear every week: AI CRMs, AI recruiting tools, AI design tools, AI everything. But once you actually use them, a pattern emerges: almost all of them lack robustness.

And robustness is the thing that matters most.

By robustness, I don’t mean polish or speed. I mean the ability to support real-world complexity: deep customization, edge cases, multiple stakeholders, evolving use cases, and scale over time. The kind of robustness you see in tools like CAD suites, professional photo-editing software, or enterprise CRMs. These tools work not because they automate everything, but because they let humans shape them endlessly around their specific needs.

Robustness is what allows software to scale horizontally and vertically. Instead of building a tool that solves one narrow problem extremely well, you build a system that can be adapted to many problems, and then further adapted within each of those problems. That’s why one piece of software can power thousands of companies, each using it in slightly (or wildly) different ways.

VCs understand this instinctively. That’s why, over the past decade, they’ve bet heavily on vertical SaaS; software that deeply understands a domain but still preserves flexibility. What we’re seeing now is the same bet being made again, just rebranded: vertical agents instead of vertical SaaS. The hope is that agents will finally be able to encode that flexibility automatically.

So far, they haven’t.

A big contributor to this problem is what people loosely call “vibe coding.” Yes, it’s impressive that you can spin up a prototype, or even a simple production app, in hours instead of months. But there’s a cost. Everything starts to look the same. The same layouts, the same interactions, the same mental models.

Vibe-coded software is limited by what the model thinks software should look and feel like. Which means that genuinely clever, opinionated, or novel UI/UX gets flattened into safe, repeatable patterns. That’s not just a taste issue; it’s a data issue. The model can only remix what it has seen.

As a result, most AI products end up differentiated by only two things:

1. The context data they’re plugged into

2. Minor UI variations on top of the same underlying interaction model
   

But here’s the problem: the moment you try to make that software more powerful, e.g. by adding features, supporting edge cases, or enabling deeper customization - you start removing AI from the critical path. You fall back to explicit controls, configuration, logic, and structure. In other words, software.

The most robust piece of software most people have ever used is probably Excel. At its core, it’s almost offensively simple. No opinions. No automation. Just cells and functions. Yet it works as both a backend and a frontend. You can model a business, run analytics, build workflows, or create something completely unintended by its creators.

Excel doesn’t succeed despite its lack of AI, it succeeds because of its raw, composable nature. AI can sit on top of it, but it’s not what gives Excel power.

This leads to an uncomfortable conclusion: a lot of AI today is being used to solve problems that don’t actually need to be solved.

Take AI in recruitment. In practice, most “AI recruiting agents” are just large language models wrapped around filters and keyword searches. Things that already exist and work very well with Linkedin recruitment or sales navigator. The pitch is that it feels magical the first time, type what you want, get results, but the magic doesn’t scale. It breaks down the moment you care about nuance, tradeoffs, or consistency.

They’re party tricks, not systems.

In these cases, AI doesn’t produce better outcomes. It just produces outcomes faster. And speed without robustness is rarely a long-term advantage.

This distinction matters a lot for how we think about AI at Autoplay.

Our AI features (golden path deviation, unsupervised clustering, hesitation detection etc.) are intentionally treated like functions. They’re closer to filters, tags, or functions/columns in a Google Sheet than they are to autonomous agents. Each one does something specific, deterministic, and composable. On their own, they’re not the product.

The product is the experience around them.

Autoplay should feel as robust as any serious analytics or product tool. That means our AI features must work in combination with non-AI features. They need to respect filters, cohorts, URLs, time ranges, and organizational context. They need to be debuggable, inspectable, and controllable.

Our first real mistake was leaning too hard into a semantic search / ChatGPT-style interface, asking questions like “Where do users get stuck?” That sounds powerful, but it’s fundamentally flawed. Without isolating control factors (specific cohorts, specific flows, specific dates), you don’t get truth. You get plausible answers.

And plausible answers are dangerous.

Real insight comes from constraint, not abstraction. Cohorts. URLs. Time windows. Comparisons. AI can help compute, surface, and suggest, but robustness comes from giving humans the tools to reason precisely.

The future isn’t AI replacing software. It’s AI becoming a primitive inside robust software. A function, not an agent. A building block, not the building.

And the companies that win won’t be the ones with the best demo, they’ll be the ones that understand that robustness is still the hard part.

Leave a comment

Subscribe now

Normally, when AI gets things wrong, it tends to hallucinate, confidently giving you answers that are completely off.

But this time, it wasn’t hallucinating. It was doing the opposite. It kept telling me what workflows “weren’t possible.”

Not wrong answers. Not made-up instructions. Just false negatives; the AI confidently claiming something couldn’t be done, even though it absolutely could.

This revealed a new problem: the co-pilot wasn’t actually reasoning about the product. It was reasoning about the documentation.

Co-pilots rely almost entirely on knowledge bases - documentation, forums, API pages, support articles - and those don’t always reflect how the products work.

This isn’t specific to PostHog.

It happens in every complex platform I’ve tried using a co-pilot with.

And the more I run into this, the more obvious the gap becomes:

co-pilots don’t understand the UI, the workflow, or the situation you’re actually in.

They understand text.

Here’s the breakdown of where things fall apart.

Co-pilots rely on documentation and forums, not the real product

Documentation tells you the “official” way to use a product.

Power users rely on workarounds, hacks, and discovering interesting combinations of features and workflows to achieve their own unique goals.

Docs rarely cover these.

So the co-pilot gives answers that are correct in theory, but too restricted to work in practice.

In my PostHog example, the co-pilot repeatedly said the workflow I wanted was “not yet possible” because the documentation didn’t describe that workflow.

I later explained the problem to a PostHog engineer, and he proposed a completely different approach.

Because he understood the actual goal (not the literal workflow I had described), he could see paths I didn’t know existed.

He wasn’t confined to the questions I asked. He wasn’t limited by my understanding of the feature set. He wasn’t restricted to what’s written down. He could reason across the product, not just answer inside it.

And when I asked the co-pilot how to follow the engineer’s instructions, it had no problem explaining the steps.

That’s the fundamental gap:

Co-pilots answer the prompt, humans answer the intent.

If it’s not written down, the co-pilot assumes it doesn’t exist.

Complex platforms can do far more than what’s written

Everyone who uses tools like PostHog, Datadog, HubSpot, Notion, Zapier, or Retool knows this:

There are a hundred things the product can do that are never officially documented.

You learn them by clicking around, testing settings, seeing how things behave under certain conditions, chaining features together, manipulating existing flows, and watching how the UI reacts.

This is the type of knowledge humans discover naturally, but co-pilots can’t access at all.

They don’t explore the UI. They don’t test. They don’t observe behaviour. They don’t learn from interaction.

Which means they fundamentally misunderstand how these products are actually used.

You can’t problem-solve with a UI you don’t understand

Documentation doesn’t always get updated. Old support articles don’t get replaced. Forum posts contradict each other.

The co-pilot is stuck in a snapshot of how the product used to work.

The deeper issue isn’t just that documentation gets stale, it’s that a co-pilot relying on static text can’t reason about what the product can do, only what the docs say it can do.

It has no ability to explore the UI, test different orders of steps, combine features, or try alternative paths to reach the same goal. So if the documentation only describes one “official” workflow, the co-pilot assumes that’s the only workflow that exists.

Humans do this instinctively. We try things. We click around. We chain features together. We change the order. We combine steps. We see what happens.

If you give someone a list of ingredients and one recipe, they’ll only ever make that one dish.

A real cook sees the same ingredients and immediately knows ten things they can make.

Full automation makes the problem worse

If the agent fully automates a workflow, and something is wrong (and something will be wrong) the user ends up needing to debug the AI’s mistake without understanding the underlying system.

This is especially painful when:

• the account has custom configurations

• the user has special permissions

• the data is messy

• the UI behaves differently for that workspace

• the workflow has branching logic

If something breaks, the user is blind.

This is the opposite of “help.”

Users don’t want to re-explain everything every time

Another practical issue:

If you repeat the workflow a week later, you don’t want to:

• rewrite the entire prompt

• specify every detail

• describe your setup again

• define the data sources

• re-explain the exact workflow

You want the co-pilot to:

• know your context

• remember your configuration

• understand your workspace

• and help you perform the next step

• not restart from scratch.

This is where UI understanding matters.

The context lives in the interface, not the prompt.

Co-pilots need to assist, not take over

Most people don’t want the AI to run off and complete everything.

They want:

• suggestions

• guardrails

• UI highlighting

• “this is where you went wrong”

• “this is the next step”

• partial automation

• shared control

Co-pilots should help with actions, not replace them entirely.

The real solution: let the co-pilot learn by interacting with the UI

The only way around all these problems is for co-pilots to understand software the way humans do - by using it.

Something closer to OpenAI’s Operator-style agents that:

• click through the interface

• test actions

• inspect elements

• understand actual UI states

• watch how the product behaves

• identify errors visually

• confirm steps through interaction

This would give the co-pilot access to real product knowledge, not second-hand descriptions.

The next generation of co-pilots won’t win on bigger models, they’ll win on better product understanding.

Until then, we’ll keep running into the same thing:

co-pilots that sound right but don’t actually help.

Share

Subscribe now

Every SaaS software company says they want their product to be more self-serve.

But inside most sales-led organisations, adoption still depends on people, account managers retaining users, success teams explaining workflows, and product managers wondering why users don’t find value without help.

The Hidden Comfort of Being Sales-Led

Why is there so much push back to becoming completely product-led?

Because great salespeople and CSMs can hide almost any flaw in the product. Customers never truly feel friction, they just message someone and the problem disappears.

Until it doesn’t scale.

At some point, you start hiring people not to grow the business, but to explain the product. You start mistaking hand-holding for success.

When that happens, humans end up doing what the product should be doing.

• CSMs teach customers where buttons are.

• Sales reps re-sell the same value every quarter because adoption never sticks.

• Product teams build from second-hand feedback and miss the real pain.

Everyone says, “We just need to improve onboarding.”

But onboarding isn’t the problem.

Dependence is.

A Product That Teaches Itself

A truly self-serve product teaches itself.

• It adapts when new users join a team.

• It re-boards when features change.

• It knows when someone’s stuck, and helps before they ask.

That’s the real test. Not whether users can “figure it out,” but whether the product can recover from confusion.

Customer success should be about helping users grow their accounts, not teaching them to click the right buttons.

If your CSMs are doing anything other than that, your product still has training wheels.

The Over-Correction Trap

A user gets stuck → you add a tooltip.

Someone complains → you add another setting.

A big customer asks for something → you build a feature.

Pretty soon you’ve solved for every edge case and made the core experience worse for everyone else.

Every product has a group of users who will always be confused. The trick is knowing when that’s a product problem and when it’s a growth problem.

If 80% of users are fine and 20% aren’t - that’s not bad UX, that’s an opportunity for education or automation.

If 80% are struggling, that’s a product issue.

Most companies never make that distinction. They just throw more people at the problem.

Why Product Signals Aren’t Enough

Funnels and events tell you what happened, not why.

A drop-off isn’t an insight, it’s a symptom.

What matters is intent – what the user was trying to do.

Because only then can you decide who owns the problem:

• Product, if the path itself is broken.

• Growth, if users don’t know the path exists.

• CS, if they know it but can’t connect it to outcomes.

Without that context, teams optimise blind, fixing symptoms and wondering why nothing compounds.

From Sales-Led to Self-Serve: Where to Start

1. Self-Serve Starts Inside Your Sales-Led Motion

Sales-led growth doesn’t disappear when you go self-serve, it evolves.

The best teams aren’t removing humans; they’re automating the moments around them:

• Onboarding emails triggered by real behaviour, not fixed sequences.

• Guidance personalised by intent, not generic feature tours.

• Friction detection before it turns into a support ticket.

2. The Hidden Cost of Re-Onboarding

Most companies nail the first 30 days. Calls, walkthroughs, check-ins.

But after that, things decay.

Teams change. The product evolves. New users join existing accounts.

The “how-to” knowledge lives in outdated Looms, slack threads and internal SOPs.

It’s not an onboarding problem, it’s a re-boarding problem.

CSMs become the product’s memory, constantly retraining users on what’s changed.

Self-serve companies solve this by detecting when someone new joins, recognising first-time patterns, and automatically guiding them to value.

Consistency shouldn’t depend on who’s still in the Slack channel.

3. User Goals Change, Your Context Should Too

Customer intent evolves.

The reason someone bought six months ago isn’t always why they use it today.

Without visibility into that shift, teams end up:

• Creating their own SOPs to make the product “fit.”

• Misaligning Sales, CS, and Product around outdated goals.

• Chasing the wrong problems because they’re anchored to old intent.

You can’t fix that with static CRM notes or funnel data.

You need to interpret what users are trying to do in real time, and adjust what you show or automate accordingly.

The best teams personalise not by role or plan, but by intent.

4. Product Signals + Sales Signals = Expansion

Sales-led teams are wired to watch the big picture, buying signals like company growth, new hires, expansion plans, or renewed budgets.

When you optimise around revenue metrics alone (logins, seat counts, contract size) you miss the product-side intent: understanding what users are trying to do before those signals ever show up.

A user might look “healthy” on paper but still be stuck in the workflow.

Self-serve maturity comes from connecting those two worlds, pairing the external business context with what’s really happening in-product, where intent-to-buy meets intent-to-use.

5. The Edge-Case Problem

Every product has edge cases, users who get 90% there, but not quite.

Product teams build for the majority.

CS and Growth teams live in the margins.

The key is scale:

• If 2% of users are stuck, it’s a growth problem.

• If 20% are, it’s a product gap.

You can’t know which without intent-level data, connecting behaviour, friction, and context in one place.

Before changing the product, isolate the cause:

1. Was onboarding insufficient?

2. Were expectations mis-set in Sales?

3. Is it the wrong ICP?

6. What Self-Serve Really Means

Self-serve isn’t about removing humans.

It’s about giving them context before they’re needed.

The best companies automate understanding, not empathy.

They:

• Detect intent, friction, and change.

• Surface insights to CS and growth.

• Automate guidance when it’s routine, and flag it when it’s strategic.

When that happens, humans finally get to do what they’re best at, helping customers grow, not teaching them to click.

Share

Subscribe now

It was called Clippit, or more famously, Clippy. The idea was decades ahead of the technology that powered it.

The arc matters because modern products are quietly re-introducing assistants, but with better timing, better intent, and better outcomes.

Why it started (history)

In 1996–1997, as Microsoft prepared to ship Office 97, it faced a problem: users were overwhelmed by menus, ribbons, and hidden features. The company wanted a “human” interface between people and software: a companion that could sense what the user was doing and offer help in real time.

Clippy was the result. Designed by Kevan J. Atteberry, Clippy was part of the Office Assistant, powered by early Bayesian inference models - primitive probability systems that guessed user intent based on small cues.

If a user typed “Dear …” → it likely meant “writing a letter.”

If a user opened the Tools menu repeatedly → they were probably “looking for a setting.”

Underneath, this was all logic trees and conditional probabilities - not natural language understanding. There were no embeddings, no transformers, no context memory. The assistant was running a static rule base embedded in Office, built on Microsoft’s Agent platform, a descendant of the Microsoft Bob project from 1995.

Clippy was a kind of hardcoded agent – an interface shell around structured rules, not reasoning. It looked alive, but it couldn’t really think.

Why it failed

The failure wasn’t because the idea was bad - it was because the technology couldn’t deliver what the interface promised.

• No real intent modeling. Bayesian triggers worked on single-word cues, not multi-step context. If you typed “Dear…” in a poem, Clippy thought it was a letter.
  

• No personalization. Clippy had no user memory - every interaction was the same. It couldn’t learn from you or adapt.
  

• Intrusive by design. It appeared automatically, often mid-task, because it lacked the subtlety to know when help was wanted.
  

• No feedback loop. It couldn’t improve or be fine-tuned; the model lived inside your Office install.
  

By 2001, Microsoft disabled it by default in Office XP, and by 2007, it was gone entirely.

The idea of software that knows when you need help went dormant for almost two decades.

The rebirth – and why it matters now

When LLMs emerged, they reintroduced something Clippy always wanted to be: context-aware.

Assistants like GitHub Copilot, Microsoft Copilot, and ChatGPT are powered by transformer-based language models – systems that don’t rely on keyword triggers, but on probabilistic reasoning across massive context windows. They can infer what you mean, not just what you type.

In 2025, Microsoft introduced Mico, a new Copilot avatar with expressive, real-time reactions and voice-mode presence - a modern, optional embodiment of help. A hidden Clippy Easter egg nods to the past without repeating it.

Press framing is explicit: Mico aims to succeed where Clippy failed - more empathetic, less intrusive, and tuned to today’s expectations for useful, collaborative AI.

How the assistant returns to software (done right)

Today’s copilots are powerful, but still reactive. They respond to language, not behavior.

If a user hesitates or gets stuck without knowing why, the copilot stays silent until prompted.

The next step is moving from assistants that listen to ones that notice.

Modern assistants should work in the flow and for the outcome. Instead of generic “Need help?” balloons, they watch for signals: hesitation, repeat errors, dead-ends, oscillation, or divergence from a known golden path.

When confidence is high - and only then - they surface a targeted nudge, a micro-guide, or an action.

Where this is heading, and what we’re exploring at Autoplay

At Autoplay, we’ve been developing Pinnie the Pin Pal.

• What it is. A proactive chat presence that infers intent not from text, but from behavior and context. It pops up only when users may be stuck or deviating from the expected flow.
  

• Where it appears. Anywhere friction concentrates: beside a disabled button, near a mis-configured form, inside a multi-step wizard, or inline on a page where users routinely stall.
  

• What it does. Offers the next best step, clarifies prerequisites, highlights the one control users keep missing, or links to a short, relevant walkthrough.
  

Pinnie is powered by TERRA, Autoplay’s framework for predicting user intent by combining UI understanding with user clicks to form a unified ontology for measuring and evaluating user goals.

It’s the same vision Microsoft had in 1997 - helping users reach value faster - but finally with the technology to do it right.

Why this is different from Clippy (and better)

• Inference over interruption. Pinnie uses behavioral signals (deviations, repeated back-and-forth, long hovers, rage-clicks) to predict intent and time help; Clippy relied on shallow triggers (keywords and canned heuristics).
  

• Context and control. Pinnie is subtle and optional, appears in place, and respects dismissals and user preferences. Clippy was on by default and hard to tune.
  

• Outcome-driven. Pinnie’s goal is path completion and adoption (finish a setup, export data correctly, publish the first automation), measured by golden-path completion and drop-off changes, not just “help opened.”
  

• Segment-smart. Behavior adapts by persona and journey stage (new vs. power user; admin vs. contributor), avoiding one-size-fits-all prompts.

Design lessons (Clippy → Pinnie)

1. Appear only with confidence. Low-precision prompts erode trust fast.

2. Help in place. Avoid modal hijacks; anchor near the friction.

3. Make it dismissible, and remember. Respect “not now,” and learn from it.

4. Short, specific, actionable. Offer the step that moves the user forward.

5. Measure behavior change. Track impact on completion, retries, abandonment, not vanity clicks.

Closing note

Clippy was an early, lovable misfire - a product of its moment and its limits. 1997–2007 taught the industry that help without context becomes an interruption. 2025 brings a different pattern: assistants that listen first, then assist. That’s the lane Autoplay (Pinnie) occupies - a context-aware, intent-informed guide that appears only when the product itself signals friction. The face isn’t the point; the moment is.

Leave a comment

Subscribe now

What happens when software stops waiting for us?

The history of software has always been about efficiency. Better UI, clearer workflows, faster time-to-value. Today, most tools feel good enough. The interfaces have converged into a shared design language; dropdowns, sidebars, dashboards. The cognitive tax of using new software is lower than ever.

But the irony is that as software became easier to use, it also became easier to build. Every product now looks and feels the same. AI code copilots have made shipping new features fast, but the end result is more homogeneity, not less. Everyone has the same design patterns - the same onboarding tours, the same chatbot in the corner of the screen, the same PLG playbook to “drive adoption.”

The next leap won’t come from prettier UIs or more polished onboarding. It will come from software that knows what you’re trying to do, and helps you do it before you ask.

That’s where proactive agents come in.

The Problem with Today’s Co-Pilots

Most “AI copilots” today are reactive. They’re powerful, but fundamentally dumb in context. They wait for you to tell them what to do, and then they execute it. They don’t observe, reason, or infer.

Even when they connect to APIs or automate workflows, they rely on prompting, which assumes the user knows what they want, how to phrase it, and how the system works underneath. That’s a big assumption.

Prompting feels magical the first few times, but it’s still the human doing the cognitive heavy lifting. You need to know how to frame the problem, which tool can solve it, and what parameters matter. It’s like having a brilliant assistant who can do anything, but only if you give them perfect instructions.

And that’s the paradox: prompting rewards expertise. It benefits people who already understand the system. For everyone else, it’s a new kind of friction, a UX regression disguised as progress.

We’ve seen this before. The earliest software required deep expertise to operate: command lines, nested menus, rigid workflows. Then came the UI revolution, which abstracted complexity away. Prompting reverses that, and puts the work back on the human.

So if the co-pilot still needs the pilot to fly, have we really changed anything?

Why the Future Is Proactive

The next generation of co-pilots will be proactive, not reactive.

They’ll observe what you’re trying to do, anticipate where you’re going, and suggest or act accordingly, like a colleague who’s already one step ahead.

Instead of waiting for a prompt, they’ll watch your behavior, detect hesitation, and know when to step in. They’ll understand the difference between someone exploring a feature and someone clearly stuck. They’ll see that you’re creating a campaign, not just editing a field, and they’ll know the typical next three steps because they’ve seen thousands of users like you.

That’s the future of software adoption, productivity, and support.

But it requires solving several hard problems that the industry mostly ignores right now.

1. Context Is Still Fragmented

Every tool defines the world in its own terms: “projects,” “deals,” “campaigns,” “workflows.” None of them talk to each other meaningfully.

So when an AI connects across them, it’s moving data, not understanding it. It can describe events, but not interpret goals.

We built TERRA at Autoplay to solve exactly this. It’s a unified ontology - a common language that describes how software behaves, what users are trying to do, and what efficient workflows (“golden paths”) look like.

It lets our models reason across apps and industries. To know that creating a “new project” in Asana, a “campaign” in HubSpot, or a “workflow” in ActiveCampaign are the same conceptual action - initiation toward an outcome.

Without that kind of layer, AI will stay narrow and reactive; task executors rather than intelligent collaborators.

2. Trust Is the Bottleneck

You can’t automate what people don’t trust.

If an AI acts without explaining why, users will override it or turn it off. For proactive systems, transparency becomes non-negotiable.

That means clear reasoning: “I noticed most users drop off at this step, so I simplified it,” or “I pre-filled this field because it matches your past patterns.”

The UX of automation is no longer just usability, it’s legibility.

People don’t need perfection; they need confidence that what’s happening makes sense.

Trust isn’t built through accuracy alone. It’s built through explanation.

3. Autonomy Needs a Dial

Autonomy is a spectrum, not a switch.

Too little, and the agent is annoying constantly asking for permission.

Too much, and it’s dangerous, making changes you didn’t consent to.

Proactive systems will need adaptive autonomy. They’ll start in observe-and-suggest mode, then gradually earn the right to act as they prove reliability.

Just like a human teammate, trust expands through consistent, predictable behavior.

4. Real-Time Grounding

Large language models are great with text but blind to state. They don’t actually see what’s on screen, which buttons exist, what data is visible, or whether an action succeeded.

Without real-time grounding, AI actions are educated guesses.

Proactive agents need to perceive the same reality the user does – live product state, current workflow, system feedback. That’s why grounding in UI understanding (not just API data) is so critical.

Without it, AI remains a clever autocomplete for your clicks.

5. Privacy and Access

To anticipate intent, agents must observe behavior. But observation at scale raises obvious privacy concerns.

Companies want automation, but they can’t afford invisible data flows. Users want help, but they don’t want surveillance.

The solution isn’t less context, it’s smarter context.

Local inference. Edge processing. Synthetic abstractions. Systems that learn patterns without storing personal data.

If proactive AI is going to work, it has to earn access, through governance, transparency, and clear data boundaries.

Where It All Leads

For years, “good UX” meant minimizing clicks. The next era will be about minimizing cognition.

The most powerful software will feel like intuition, where help arrives exactly when you need it, without you asking.

That doesn’t mean removing control; it means removing unnecessary translation. Users shouldn’t have to think in software logic. The software should think in theirs.

That’s the vision behind Autoplay.

We’re building systems that can see intent, hesitation, and deviation, and connect them through a unified understanding of how software works.

Because the real bottleneck in AI isn’t model quality; it’s context.

And the real opportunity isn’t faster execution; it’s faster understanding.

We believe the future of copilots is proactive - systems that act before you ask, learn before you teach, and adapt before you notice.

When that happens, software won’t just feel easier.

It’ll feel like it finally understands you.

Subscribe now