Agent Output Is Not UX: Rendering Layer Your LLM Pipeline Is Missing - Bala Ramdoss, Amazon Lens

Talk transcript

1. 0:01

   I asked my AI assistant to help me reserve a table at a popular restaurant. Here's what it gave me.

2. 0:09

   Now, it's not wrong. The phone number is there. The hours are right. It even knows the walk-in oyster bar at the front. The model did the real work, but look at the outcome.

3. 0:24

   I have to do my research and work towards actually booking that table. Like, we have been here for a while. Now, imagine if you were to build something like this for your customers.

4. 0:35

   What would you want it to do? Same answer rendered like this instead. A date, a time, a couple of taps, and then you're done. The agentic product you're building already has all the tools to support your customers' needs.

5. 0:53

   The only thing that you need to focus on is the layer between the model and something that a human can interact with.

6. 1:00

   That layer is what I'm gonna talk about. The models and agents are here to stay, and we should learn how to make it friendly to the humans.

7. 1:09

   Hello, welcome to my talk. I'm Bala Ramdoss. I have been building customer-facing apps for over a decade, and the past six years I have spent, uh, building Amazon Lens.

8. 1:22

   Amazon Lens is our suite of camera features powered by AI. It enables you to shop using images, screenshots, and barcodes to discover visually similar products. If you have Amazon app installed, I encourage you to try.

9. 1:37

   This talk comes from my experience building, um, customer-facing products that are in millions and millions of mobile devices. Uh, quick dis-disclaimer before I go further, I am giving this talk on my own.

10. 1:50

    The opinions in this talk are mine and not my employer's.

11. 1:56

    When you think of building UX for an agentic AI, obviously ChatGPT comes into mind. How do you draw these cards? How do you choose carousel versus list? How do you craft this so the human can understand and interact better?

12. 2:12

    When you attempt to build something like this, you run into a wall. There are problems that need to be solved from the very early stages of your system. Is that experience going to be snappy or slow?

13. 2:26

    Do we get all the information at first or one thing at a time?

14. 2:32

    And how do you scale this for mobile apps where versions and device capabilities are fragmented? Like if you notice, none of these problems are due to the model itself.

15. 2:42

    The model does its job well. Um, these are delivery problems, and they live in between the model output and what's on the screen. That is the layer that decides whether your product succeeds or not.

16. 2:56

    So, uh, for this delivery problem, if, if you had asked me about, uh, about this layer two years ago, I wouldn't have had a name for it. I'd built a couple of AI features by then, and every single time, I solved this part from scratch.

17. 3:12

    A bespoke pattern shaped around whatever system I was in. Uh, there was no shared vocabulary for any of it.

18. 3:22

    What gets me is that this thing now has a name, Generative UI, and there's an open spec for it, A2UI from Google. Instead of the agent handing you a raw text or HTML, it describes the UI as data, a list of components, and the client renders them with its own native widgets.

19. 3:43

    A problem I used to solve alone is becoming something teams get to start from, and that's exactly what I'm excited to dig into.

20. 3:52

    Um, normal API returns data, uh, and the client decides how to draw it. Like, your model is good at tool use, uh, coding, and even other complex tasks. It can do UI too, and that is what the Generative UI is about.

21. 4:08

    And it's, it's a spectrum. Uh, CopilotKit, a company that does this primarily, lays out, um, uh, in three rungs. At the bottom, uh, we have controlled. The model picks a pre-built component, like a product card.

22. 4:25

    It never invents anything. In the middle, um, declarative. The model composes UI, uh, from a catalog, uh, date field, a time field, or a submit button. Um, that's where A2UI sits.

23. 4:41

    And at the top, it's fully open-ended. The model generates a novel UI on the fly, like, uh, MCP apps. The higher you go, the more, uh, your client has to trust whatever the model hands it.

24. 4:56

    Uh, most production mobile apps live in the bottom two rungs because, you know, that's where you stay safe, and that's what we'll focus on.

25. 5:06

    Um, adding to the complexity of UX building, m-mobile apps play an important part. Um, on the web, if a renderer breaks, you know, you ship a fix, and it's live in minutes.

26. 5:18

    Uh, mobile apps cannot do that. Like, you're looking at hundreds of millions of installs, and you don't control, uh, when any of them update.

27. 5:28

    So when a client meets a content type it's never seen, it doesn't gracefully degrade. It crashes, and it keeps crashing for days or weeks, um, in the hands of people who haven't updated.

28. 5:41

    So one rule holds everything that follows for mobile clients. You cannot meaningfully patch the client.

29. 5:48

    Um, how does this system look when you zoom out?

30. 5:53

    Um, here's a whole simplified pipeline. Uh, version-aware context phase that feeds the model. Uh, yes, that is context engineering. The model outputs typed UI intent, uh, that flows through a BFF, Backend for frontend, and to a client renderer that draws it and, uh, falls back safely when it cannot.

31. 6:17

    We'll break it into three patterns. Pattern one, the rendering contract. Pattern two, streaming. Uh, that's the flow in between them. Pattern three, uh, the BFF that sits in the middle.

32. 6:30

    Uh, we'll take them one at a time, starting with the contract.

33. 6:35

    Uh, the contract is all about making the model be aware of what the client capabilities are. You ensure it, it stays true to the client that the model is trying to draw the UI for.

34. 6:48

    Um, what it ensures is that the onus is not on the client or the rendering layer to infer what to show by looking at the token output.

35. 6:59

    Um, you also maintain a repository of version map with the capabilities. For example, you introduced a new flight, uh, card UI in version two dot oh. Uh, make sure to surface it to the model only from version two dot oh onwards, um, when you build the context.

36. 7:20

    The takeaway here is that the model is going to choose the CX, and you provide the right information in its con-context.

37. 7:29

    Um, let's take a look at this example. And this, this is usually the hard part of building the system.

38. 7:36

    This is the model-facing half of the contract.

39. 7:40

    Uh, y-you don't want the model to send back text. Like, you want it to stream, uh, blocks of UI components. Um, a conversation block for what it says in text and a UI block for what, what it wants the client to render.

40. 7:58

    The contract even encodes layout rules. In this example, o-one to three flights, a swipeable carousel. Four or more, a vertical list. The model picks the intent. And notice what the model never does.

41. 8:16

    It never invents a component. It chooses from a fixed menu that you provide to it. Obviously, it won't be in the millions. It would be a handful. It turns out that it gets significantly harder as you scale your features to more surfaces.

42. 8:34

    I'll let you think about how to engineer that context to make sure the model succeeds in, uh, picking one.

43. 8:42

    So, uh, that's the contract. Now, let's move on to the streaming part. This was eye-opening to me when I first encountered it. Traditionally, apps make an API call and wait for something to happen.

44. 8:58

    When LLMs are involved, um, this pattern becomes ineffective, as often the latency is higher due to the model themselves. And on top of it, there are tons of additional checks to ensure safety and whatnot.

45. 9:12

    And we also introduce a new layer that it's gonna be a little bit complex to do the dynamic UI.

46. 9:20

    Um, streaming helps here, uh, by not making the client wait for the whole response. It renders things in chunks at a time.

47. 9:31

    Take a look at the illustrative example when you have to surface information one chunk at a time. First, you show a skeleton, then partially filled it, then complete it.

48. 9:43

    It may take three to four seconds, uh, to get there, but the wait is bearable.

49. 9:50

    That kind of changes what you measure for an app, right? You stop chasing the total latency, which we have done for over a decade.

50. 10:00

    You start chasing time to first chunk, you know, the first useful thing that your user sees.

51. 10:07

    For this reason, the traditional loading spinner won't work for AI features.

52. 10:13

    Sometimes you have to get creative and design your feature around it. This may not work for all, but here's a product example. When you know it's going to take time to render something, keep the user engaged.

53. 10:26

    The Lens Live allows the user to focus different things, um, tap on an object that they are interested in while they wait for the results.

54. 10:36

    Uh, if you don't have the full screen in your control, you can show the thinking CX, but please use it sparingly. The overall AI users have, uh, moved out of the forgiving phase, and now they expect to know what is happening.

55. 10:53

    Now that you have a way to stream back different states, you know how to show what your agent is doing. Um, here's an example I copied from Gemini. When, when it starts to work on a task, it gives a glimpse into what the agent is doing.

56. 11:08

    Even though it takes 10 seconds, I'm okay if I know what's happening and, uh, be able to trust the agent's final output.

57. 11:18

    We have covered streaming. Let's move on to the final and most important part, your new BFF. Pattern one was about how UI gets picked. Pattern two was about how the chunks are delivered.

58. 11:33

    Pattern three is all about how the chunks become meaningful UI elements.

59. 11:39

    This is a concept of server-driven UI, and it's a spectrum of server control, and the more the server controls, the more you build. The BFF is a subset of it and decides how to render.

60. 11:53

    It owns the platform-specific rules like Android versus iOS, that kind of stuff. Uh, it also helps the client to make less decisions and draw what's handed to it. That's the whole idea.

61. 12:08

    The BF- BFF doesn't just ship layout. It does a little more. In addition to the format and context, it does the hydration and adds actions.

62. 12:23

    Every rendered element carries an action payload to handle what, what a tap does, what the deep link it opens. It, it could even name the impression metric to log.

63. 12:34

    It carries this conversational context across turns, so the next response know what came before.

64. 12:42

    And the good thing about this is that you can actually do this to your existing apps. You can reuse the existing CX units you already have. Uh, the flight row, the product card, the components your app already shipped in production.

65. 12:58

    You're not building a new agentic look into your app, and that's a good way to build for humans. Same brand, same density, same familiar feel. It looks and feels native.

66. 13:13

    And that brings to our takeaways. One, the models are highly capable already. You feed a properly typed, versioned contract so it can pick and choose the right CX.

67. 13:29

    Two, stream into typed components, not text. Let the user know what your agent is doing.

68. 13:38

    Three, let the BFF absorb the model output so the client can stay dumb and safe.

69. 13:47

    No-- none of these are about the model. The model was fine.

70. 13:52

    This layer is what ships the product. Bringing back to where we started, your agent output is not the CX. You build on it. Thanks for watching. If you'd like to learn more or connect with me, here's a QR code.