The New User Is an Agent: Rethinking Product Design for Human + AI Collaboration

Nihal Kaul at UXDX Community: Attention, Trust and Intelligent Brand Experiences. Video: https://youtu.be/KyIlRwjeEaY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

A user that never sees your interface

[00:00:08] Hey everyone, thanks for joining. Before I introduce myself, I wanted to start with a question that has been on my mind a lot lately. Think about the last product you shipped. Think about the user research you did, the personas you built, the onboarding flows you designed. Now ask yourself: did any of that work account for a user that never sees your interface? Because that is the reality we are heading into, and for a lot of products it is already here.

[00:00:41] We are entering a world where the user on the other end of your product might be a person, or an agent, or both working together. And the uncomfortable truth is that most of our products were never designed for this. Our UX patterns assume someone is looking at the screen. Our metrics assume a human is generating the signal. Our onboarding assumes someone who learns the way people learn. When agents show up in your product, and they already have, they break those assumptions. They skip your onboarding. They fail silently instead of filing support tickets. They distort your analytics without you even knowing.

[00:01:19] Here is a number that puts it in perspective. In 2024, bot traffic surpassed human traffic on the web for the first time, and 51% of all web requests are now automated. So the question is not whether your product needs to work for agents; the question is whether you are designing for it intentionally or just letting it happen. This is what this talk is about. I'm going to share a practical framework and real examples from companies like Intercom, GitHub and Stripe that had to rethink their products when AI agents became active users.

[00:01:53] Here is what we will cover. We'll first start with why this matters right now, with some data that might surprise you. Then I will introduce a mindset shift, from thinking about users to thinking about actors, and three differences between how humans and agents interact with a product. From there I will share a three-layer framework called the dual audience design lens, which has three layers: surface, structure and strategy. Each layer gives your team something concrete to work with.

[00:02:30] Then we will look at three real-world case studies: how Intercom discovered its CSAT metric was lying to them, how GitHub built entirely new design primitives when Copilot became a coding agent, and how Stripe created a new financial primitive because AI agents cannot hold credit cards. We will wrap up with five questions you can bring to your team tomorrow and three things you can do this week, so you will leave with actionable insights. My name is Nihal Kaul. I work at Revscale, where we think about this stuff every day. Let's get into it.

Why this matters now

[00:03:19] Let's start with this: your next power user won't be a human. Right now, across thousands of SaaS products, AI agents are already showing up in workflows, not as some future trend; this is actually happening today. Think about it. In customer support, AI agents are reading documentation, triaging tickets, classifying them by urgency, and responding to customers before a human even logs into the dashboard. In procurement, bots are navigating B2B portals, comparing pricing across vendors, and submitting purchase orders without a person even being involved. And in design, copilots are pulling from component libraries, assembling screens and generating variants based on usage data. These are not edge cases. This is becoming the default way software gets used.

[00:04:15] So why should we care? Why does this even matter right now? Because if your product is not designed with agents in mind, three things are probably already happening, and you might not even realize it. Here's a stat that should make everyone in this room uncomfortable: in 2024, bot traffic surpassed human traffic for the first time. 51% of all web requests are now automated. That is more than half.

[00:04:43] The first problem is that agents break your UX. They skip onboarding flows. They ignore your modal dialogs. They click on things humans would never click on, and your carefully designed user journeys fall apart when the user cannot see the screen. Second, they corrupt your data. Silent, repetitive errors pile up because there is no human noticing something looks off. Bad inputs get created at scale and nobody flags the problem.

[00:05:13] Third, and this one is sneaky, they distort your metrics. In a real example, someone filtered bot traffic from a single Google Analytics property, and reported sessions dropped by 42% and users dropped by 48%. Almost half the signal was noise. So if you're making product decisions based on data like that, you're optimizing for ghosts.

From users to actors

[00:05:37] The mindset shift. What do we do about this? It starts with a reframe: we need to stop thinking about users and start thinking about actors in general. The old model is simple: user equals human. Everything we design assumes a person who can see the screen, read the copy, feel the friction. That model has served us well for decades, but not going forward. The new model is different. An actor is anyone or anything that triggers actions in a product. That includes humans, and it also includes agents. Here is the important part: these two types of actors have fundamentally different needs. They have different failure modes and different feedback signals. If you design only for one, you are leaving the other to break things.

[00:06:28] The three key differences. Let me get specific: there are three differences that really matter in practice. First is intent expression. Humans browse, right? They explore. They click around to figure things out. They rely on visual cues and trial and error. Agents, on the other hand, call APIs directly with structured requests. Your user interface is a conversation with a human; your API is a contract with an agent. Very different interaction models.

[00:06:58] Second is error handling. When something goes wrong, humans recover using context clues and visual hints. They read the error message and try something different. They try to work their way around it and see if that leads them to success. But agents fail silently or get stuck in loops. Think about that for a second: what does the word "intuitive" even mean when the user literally cannot see your interface?

[00:07:29] The third one is feedback loops. Humans complain. They write support tickets, they post on social media, they tell their friends. Agents just stop working. They do not complain. Your NPS score will never catch an agent that churned. It just disappears from your data, and you have no idea why.

The dual audience design lens

[00:07:50] Let's get into the dual audience design lens. This is the three-layer framework that I would like to introduce, which your team can start using this Monday. There are three layers in the dual audience design lens, which I categorize as surface, structure and strategy. The goal is to give you something concrete your team can start using when you get back to work: not just theory, but practical insights that you can take and start implementing this week.

[00:08:25] The layer at the top is the surface. That's the first layer, and the question is simple: who is actually touching your product right now? The first step is an audit. Look at your current workflows and find where agents are already showing up, even when nobody planned for it. Look for browser extensions that are autofilling your forms or scraping your content. Look for integration platforms like Zapier that are consuming your webhooks, often set up once and completely forgotten about. AI assistants are summarizing your dashboards and reading your documentation.

[00:09:07] Here is the key question for your team: can you tell the difference between a human session and an agent session in your analytics today? I believe most teams cannot, and that is exactly where you need to start. So start at layer one, which is the surface, and start with an audit.

[00:09:28] Layer two is structure. This is about designing for both consumption modes at the same time. Humans need scannability and visual hierarchy so they can find what matters quickly. They need progressive disclosure that reveals complexity only when they are ready. They need contextual help that meets them where they are. Agents, whereas, need structured, machine-readable data with clear schemas. They need semantic markup and consistent labels so they know what each field means. They need predictable, stable patterns that do not change without versioning.

[00:10:10] But here is the interesting part: the overlap between these two sets of needs is bigger than you think. When you add clear labels, consistent structure and accessible content to make things work for agents, humans benefit too. Good agent-friendly design is often just good design.

[00:10:29] Layer three is strategy. This is where the framework becomes operational: three concrete practices that you could add to your process right away. First, write agent user stories alongside your human ones. When you are in your design sprints, brainstorming with the product team, this could come in very handy. Think of the generalized aspect that we brought in earlier: don't think about users as equal to humans, but think about actors in general, which could be humans and agents. Something like, "As an AI assistant, I need structured output so I can summarize this for a user." Give these the same weight you give human stories in your backlog.

[00:11:18] Second, you could create agent personas. Just like you build human personas, you build agent ones. Define what permissions an agent type gets, how much autonomy it has, and what guardrails keep it in check. Think about roles, scopes, failure modes and escalation paths.

[00:11:39] Third would be to build observability around this. You want deep analytics and deep observability, instrumenting your product and analyzing when an agent is using it versus a human. You want to track agent-specific metrics like API call patterns, error rates and throughput. These are the metrics that make more sense for agents. You cannot improve what you cannot measure, so building observability right into your platform would go a long way.

Case study: Intercom's CSAT problem

[00:12:12] I would like to introduce some real-world examples. These are real-world case studies from top product-minded companies, starting with Intercom, a well-known customer support platform. These are not hypothetical examples; these are documented cases from companies that you know. Intercom has the Fin AI agent, which is their automated AI customer support agent, and it started resolving over half of customer conversations automatically. It sounds like a success story, right? But they discovered their core metric was lying to them.

[00:12:53] Traditional CSAT surveys had response rates as low as one in 12 customers. The people who did respond skewed toward extreme opinions. And here is the kicker: customers scored AI support more harshly than human support. When Intercom evaluated every conversation comprehensively instead of relying on surveys, they found something very, very surprising: human agents actually scored 10% lower than CSAT suggested, and AI agents scored 14% better. So this metric was distorting the picture in both directions.

[00:13:30] They had to invent a completely new metric called CX Score, a customer experience score that evaluates every meaningful conversation, not just the ones where the customer fills out a survey after the conversation is completed. The lesson is that your existing metrics were designed for a human-only world. When agents enter the picture, measurement systems break first, and you might want to start thinking from first principles. Put your customers at the forefront, work backwards from there, and see whether these metrics still make sense. And when I say customers, I mean users in general, and again, going back to the general point, users are not equal to humans; they are also agents.

Case study: GitHub Copilot as a coding agent

[00:14:21] The next example is from GitHub. GitHub had to invent entirely new UX patterns because AI became an active participant in developer workflows. Those dimmed inline code suggestions you see when you use Copilot, that ghost text, was a deliberate design choice. They chose it over pop-ups because, as the design team put it, tiny distractions disturb developer flow.

[00:14:47] But the bigger shift came when they made Copilot a coding agent. Developers could now assign GitHub issues directly to Copilot like it is a team member, and the agent creates a branch, writes the code, pushes commits to a draft pull request and assigns human reviewers. This is all being done autonomously. Think about the product design implications of that. They had to build guardrails. The agent can only push to branches it created. The person who triggered the agent cannot approve its pull request. Session logs expose the agent's reasoning at every step.

[00:15:27] They even created configuration files inside repositories that only AI agents read: a whole new layer of information architecture. That's what GitHub came up with. By March 2026, Copilot had completed 60 million code reviews, growing 10x in under a year. The lesson is clear: you need to design the handoff, not just the automation. Build guardrails so agent action and human judgment work together, with clear controls and complete transparency.

Case study: Stripe's shared payment tokens

[00:16:01] The third, and a very interesting, example is from Stripe. I find fintech very intriguing because it is compliance-heavy and highly regulated. This is a very tricky example, and kudos to Stripe for the way they pulled it off. Stripe created an entirely new financial primitive because AI agents cannot hold credit cards. Think about that. The entire trust model of commerce is built on the idea that possessing a credential means you are authorized to use it. But "when an agent acts on behalf of a user, trust cannot be inferred. It has to be explicitly granted, scoped and enforced in code." That is a direct quote from Stripe's head of payments.

[00:16:47] Their solution was shared payment tokens, which are programmable tokens scoped to a specific business, limited by time and amount, and revocable at any time. They also structured all their documentation as plain-text Markdown, because AI agents can consume it efficiently; they can read text efficiently in Markdown format. And they built an agent toolkit with restricted API keys: an agent can create payment links but not list customers. These are all granular controls that are baked in. This already powers Instant Checkout in ChatGPT, where people can buy from Etsy sellers directly in conversation. The lesson is that agent-aware design is not just a UX problem; it is an architecture problem. Trust must be coded, not assumed.

Five questions and three things to do this week

[00:17:42] Here are some clear questions that your team should be asking right now. I would like to leave you with five questions. These are the conversations I think every product team should be having; bring these back to your next product review or sprint planning session. One: what percentage of our users are actually agents, and do we even know? This is easy to identify by baking in the observability we spoke about earlier. Second: are our product metrics measuring human satisfaction or agent throughput? Another interesting question. The third one: when an agent breaks our UX, whose bug is it? Is it ours, or is it theirs? Fourth: are we designing guardrails, or just hoping agents behave themselves?

[00:18:34] The last one is: what does onboarding look like when the user does not need a tutorial but needs a spec? Rather, it needs a technical spec so that it can understand your API contract and the underlying data structure that is in place, so that it can interact with the product in a much more efficient manner. These are the new product discovery questions for 2026 and beyond. They should sit right alongside "who is your user?" and "what problem are we actually solving?"

[00:19:04] Some closing takeaways, and here is my closing thought. The products that win will be bilingual: fluent in human experience and agent interaction. Not just API-first, not just AI-native, but genuinely designed for a world where every workflow might have a human, an agent, or both.

[00:19:26] Three things you could do this week. The first one is audit. Go find where agents are already in your product. Check your API logs, your webhook consumers, your browser extension usage. I promise you will be surprised; you might have agents already inside your product. Second, add one agent persona to your next sprint. This is a good one to start with, a very actionable one. Just one. You can define its role, scope, failure modes and some guardrails, and one persona is enough to shift the conversation within your team.

[00:20:03] The third one is instrument. Start distinguishing human versus agent traffic in your analytics. This should be your baseline; you cannot make informed product decisions without this data. It could also be the case that certain products, in the case of Stripe or GitHub, have more agent and bot activity on their platform than normal humans do. These are the trends that we have been seeing recently. And lastly, thank you, everyone. That's it from me, and thank you for your time. If you want to continue this conversation, feel free to ask questions. I would love to share, and to see what your team is thinking about. And that's my LinkedIn if you would like to connect.

Q&A

[00:20:56] Host: Excellent. Thank you very much, Nihal. That was a great walkthrough of, well, for me, the shocking 51% stat. I didn't know that we had already passed the threshold of bot traffic. As Nihal said, if you have any questions, please do write them in on whichever platform you're watching this on, and we'll put those questions through to Nihal. I'm going to start with the first question. As you were saying it, I was thinking, how will I be able to check in my logs that there's bot traffic? There are some obvious ones, when the bots are declaring themselves. But what I think is happening, and what I've been seeing a lot, is people using tools like Playwright, where essentially they're getting the bots to open real browsers and do real clicks. Is there a way to identify that side of the bot traffic, versus the robots that come in and scrape your site?

[00:21:59] Nihal: Yes, that's right, that's a really good question. There is one way to do that, which Playwright and a lot of these browser automation tools already provide. There is something called browser fingerprinting, which can make out and differentiate agentic behavior from human behavior. Bot behavior won't be exactly like a human's, in the way that a human takes a pause and explores the product or your website and takes certain actions, because bot activity is rather scripted. It goes into the product and tries to look for certain fields. Let us say a bot is trying to fill in a particular form with certain fields: there's the way that it types, the way that the text is being input into these fields inside the form.

[00:22:53] These frameworks, like Playwright and other browser automation tools like Selenium, also have a lot of capabilities that can differentiate between a bot and normal user behavior. That is why, if you go deep into browser architectures, there are different strategies for this, and browsers have implemented browser fingerprinting strategies around it. And a lot of these product analytics tools, like PostHog for example, are bringing in new features that can help with this.

[00:23:33] Host: That's great. That was going to be my follow-up. Are the analytics companies doing this, or does everybody have to figure it out themselves?

[00:23:41] Nihal: Yes. The analytics companies are trying to stay one step ahead, and they have already started thinking along these lines, because there are a lot of companies that have in fact started to build products that keep agents, not humans, as their primary user base, which is very, very interesting. Analytics companies are trying to bake this in. Take Mixpanel, for example; a lot of these large incumbents are thinking in this direction. A lot of large developer logging platforms, like Datadog for example, are also bringing in tools that can help you differentiate, bringing in that distinguishing capability so that you can identify that these actions were taken by a bot or by a human.

[00:24:42] Host: Yeah, I can see that being incredibly valuable, as you were saying, because they're going to go down different paths; they won't be the same.

[00:24:49] Nihal: Yes.

[00:24:50] Host: On your point about guardrails, one of the challenges I always have is connected to what we just said there. Their behavior is likely going to be quite different from a traditional user's behavior on your platform. So how do you start thinking about it? What I always come up against is the unknown unknowns. If I'm not used to thinking in that way, how do I build effective guardrails?

[00:25:16] Nihal: Right. I think here comes the point of thinking from first principles. You keep your customer at the forefront, and you think of your customer as an actor, right? It could be a human or it could be an agent. We just keep it generalized and call them actors, who are the users of your product. Think about the general customers, like humans, for example. Certain things that you would not want humans to do within your product, the same principles would apply to an agent. But for agents it works differently, because an agent is not someone who sees the visible aspect of your product; rather, they're communicating with your product through certain API contracts, through a technical specification document.

[00:26:12] So you need to have those guardrails not from a UX perspective but from a technical specification perspective: these are the roles that you can attain, these are the things that you can do, and these are the things that you cannot do, the things that the product doesn't have or doesn't allow you to do. You build those guards around it, and you could create scopes. You could create certain escalation patterns, so that if the agent does certain things like this, you can identify that this is agentic behavior and try to stop that behavior right there.

[00:26:52] This is also very analogous to how Stripe created a new token format for agentic use cases. Agents cannot have credit cards, and in order for a human to have a credit card, there's a process behind it: you have a Social Security number, and you have credit bureaus doing a background check. But for agents there's a lot of programmatic involvement and communication, so Stripe came up with this new type of token for agents, and they have scopes, roles, escalation pathways and guardrails baked into the tokens themselves. So if an agent has assumed a particular token, the agent will only work within the guardrails, the scopes and the rules that are defined in that specific token.