Build with Perception Agents — Emile Baizel & Shruti Arora, Amazon AGI Lab

Read the talk

Build with Perception Agents

Emile Baizel and Shruti Arora connect visual feedback, a coding agent and browser verification, then explore how spoken conversations and recorded UI feedback could enter the same workflow.

From a talk by Emile Baizel and Shruti Arora

At a glance

Ideas worth remembering

  • Visual annotation deterministically exports JSON and an agent-friendly prompt; a coding agent performs the requested edits.

  • Visual verification checks the rendered site against design artifacts and Gherkin user flows, then generates a report.

  • Agent Bridge supplies the missing extension-to-agent handoff. The workshop's Apply Changes integration adds localhost permissions, button wiring and SDK-based verification.

  • Bee conversation data can feed the same editing workflow, with an Apply step before changes and verification afterward.

  • The duck podcast example captures the practical value of checking the browser after a coding agent claims success.

Reliability includes the cost of checking the work

“If my agent works fifty percent of the time, it doesn't work at all.” Emile Baizel opens the technical case for perception agents with a customer's practical objection: debugging unreliable automation can consume the time it was supposed to save. At Amazon AGI Lab, where Baizel leads a solutions architecture team, customer engagements feed both product feedback and evaluations used in model training. Shruti Arora turns that concern into the workshop's concrete task: make a website change, then check the rendered result.

Three priorities frame the work:

  • Collaboration: an agent should understand the user's objective and communicate how it plans to achieve it.
  • Perception: it needs to understand the environment where the work happens, beginning with browsers and extending toward other visual screens.
  • Reliability: successful automation must survive real tasks without handing its savings back through debugging. Baizel describes reinforcement learning in simulated environments informed by external customers and internal Amazon teams.

Amazon Nova Act supplies the browser automation layer. Natural-language instructions drive navigation, search and form filling, with human involvement available for approvals or situations where the agent gets stuck. The use cases presented include filling forms across different websites, searching and extracting information, shopping and QA. The attraction of form filling is avoiding a separate deterministic script for every site's layout.

The AWS console exposes execution trajectories and bounding boxes around elements the agent examines or acts on. A custom computer-use model performs inference; an MCP server and a skill make Nova Act available to other agents. These interfaces serve different needs: the browser performs the work, while trajectories make its actions inspectable when the outcome needs explanation.

0:120:43
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:12 · section reference included

From clicking a button to understanding a screen

Computer use can start with an instruction as simple as clicking a blue button in the right corner. Perception adds a harder ambition: understand what the screen means well enough to work in an unfamiliar interface. Baizel's analogy is an old Yahoo or Hotmail email client. Someone who has never used that particular client can often work out how to send an email because years of screen use supply transferable expectations about controls and workflows.

That ambition has two practical consequences. First, screen-based work can reach applications without an API for the task. Second, the screen becomes a shared reference for collaboration. A person can point at an element and ask for a red background instead of writing paragraphs to identify its location. Human-like understanding remains the direction of travel here; the workshop demonstrates a narrower combination of visual feedback capture and browser checking.

Two open-source primitives divide that work. Visual annotation captures requested changes and exports a JSON file plus a prompt for a coding agent. The export is deterministic: it performs no model inference and is not tied to a particular model. Visual verification gives the coding agent a way to check the site against design artifacts and workflows described in Gherkin files, such as login or checkout flows. Capturing an instruction and judging its implementation are separate jobs.

5:376:07
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:37 · section reference included

Turn frontend feedback into inputs a coding agent can use

Arora grounds the primitives in a familiar frontend review. An engineer builds from Figma designs while coordinating with another team. Reviewers run the site locally, notice that a heading's color feels wrong and leave comments in Slack or a shared document. The team still has to agree which feedback to accept; afterward, someone must translate those decisions into code changes. Passing the accepted feedback directly to an agent aims to reduce that translation work. The suggested reduction from days to hours is a workshop scenario, rather than a measured productivity result.

How can a reviewer identify what should change without describing the whole page? The Chrome extension offers three parallel annotation methods:

  • Draw on the page: mark the area associated with the feedback.
  • Pick an element: select the element being discussed.
  • Drop a pin: place a location marker, like a pin on a map, and attach the annotation.

The annotations can be downloaded for a teammate or supplied with the generated agent-friendly prompt. Exporting the feedback alone does not edit the codebase; the coding agent must still be instructed to act.

Verification needs a reference for what the page should do and look like. Arora describes checking colors, font sizes and user flows against design files. On its first run, the UI verification tool performs a one-level crawl, examines links and content, and generates user flows in Gherkin syntax for subsequent verification. That supplies a starting set of flows from the existing site; its scope is limited by what the crawl discovers.

A verification run reads the design documents, specifications and flows, opens a browser, exercises those flows and generates a report. This gives the feedback process an observable ending: a person can inspect a report about the rendered application after the code changes. The workshop's next challenge is to connect those two primitives so that collecting feedback, applying it and checking it no longer require separate manual handoffs.

10:0010:30
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:24 · section reference included

The challenge: repair a podcast landing page with one button

The hands-on scenario starts with a podcast landing page and accepted peer feedback: the hero title is too large, the accent color lacks impact and some buttons are oversized. The intended result is a connected workflow: annotate the page, press a button in the extension, let the coding agent apply the changes, run UI verification and receive a report. The available pieces are the Chrome extension, UI verification skill, Nova Act SDK and Nova Act MCP server.

The workshop setup requires a Nova Act API key, Chrome, an AI coding agent, Node.js, npm, Python and Git. The demonstrated Nova Act MCP server runs on macOS or Linux. Arora also identifies uv/uvx as part of installation, with pip offered as an alternative. These requirements belong to the workshop environment described in the recording.

Participants choose between an easy path with explicit wiring instructions, estimated at fifteen minutes, and a medium path with more integration work left to solve, estimated at thirty to thirty-five minutes. An installation question also clarifies an easy source of confusion: the Nova Act skill and the UI verification skill are two distinct skills, even when both are listed for the same coding client.

19:2219:52
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

18:35 · section reference included

Agent Bridge connects the extension to code changes and verification

The missing connection is straightforward: a browser extension and a running coding agent do not automatically know how to send work to one another. Agent Bridge takes the annotations and prompts the coding agent to apply them. The workshop adds an Apply Changes button to initiate that handoff; the standalone annotation primitive does not include it.

The extension changes are concentrated in two files:

  • manifest.json: add host permissions for the localhost connection used by the integration.
  • content.js: add the button and its wiring, start verification and expose the generated report.

There is a consequential implementation distinction in the walkthrough: although the earlier explanation describes invoking the verification skill, this button integration runs verification through the Nova Act SDK.

Where does the new control enter the existing extension? Arora points to the marked insertion location in content.js, around line 261 in the workshop copy, near the code that appends the Export button. The supplied block creates the Apply Changes control and connects it to verification and a clickable report. The useful distinction is between exporting feedback for later use and adding an action that carries the feedback into the editing workflow.

What crosses each connection, and what supplies the verification criteria? The diagram separates the annotation handoff from the design documents and user flows used to judge the resulting site. A code change starts the next stage; the specifications supply information to that stage.

For the live example, Arora selects a published-date element, asks to change it to June 29, saves the annotation and presses Apply Changes. The integration opens the coding agent in the background. Agent Bridge had been tested with Claude Code and Kiro; using Cursor or Codex would require editing the bridge to accept and route the button's requests. Support for a skill in a client therefore does not by itself establish support for this particular bridge.

The workflow exposes CLI logs and Nova Act execution logs, including the screen regions involved in decisions. Arora observes the button change to Run Verification and explains that the run traverses design and user flows before producing a report. Slow Wi-Fi interrupts the walkthrough before a completed result for the date edit is established, and the session moves to another feedback source.

Feedback drives editing; specifications guide verification

Chrome extensionediting — Capture annotations; Apply Changes initiates the handoff.
Agent Bridgeediting — Pass annotations as a prompt to the coding agent.
Coding agentediting — Apply the requested code changes.
Design documents and user flowscriteria — Supply appearance expectations and workflows to exercise.
Browser verificationchecking — Inspect the changed site; this integration uses the Nova Act SDK.
Verification reportchecking — Expose the result for inspection.
The workshop button connects the annotation export to a coding agent through Agent Bridge. Verification then examines the changed site using separate design and flow inputs.
Read the diagram as text
  • Chrome extension. editing — Capture annotations; Apply Changes initiates the handoff.
  • Agent Bridge. editing — Pass annotations as a prompt to the coding agent.
  • Coding agent. editing — Apply the requested code changes.
  • Design documents and user flows. criteria — Supply appearance expectations and workflows to exercise.
  • Browser verification. checking — Inspect the changed site; this integration uses the Nova Act SDK.
  • Verification report. checking — Expose the result for inspection.
  • Chrome extension → Agent Bridge: Send annotations.
  • Agent Bridge → Coding agent: Prompt the coding agent.
  • Coding agent → Browser verification: Run after applying changes.
  • Design documents and user flows → Browser verification: Provide checking criteria.
  • Browser verification → Verification report: Generate results.
25:1225:42
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

24:50 · section reference included

Use a design conversation as the feedback input

Giovanni's Bee integration changes how feedback enters the workflow. Instead of selecting an element and typing a request, a team discusses design changes aloud. Bee is presented as a wearable assistant with a microphone activated by a button and an LED indicating listening. The integration retrieves conversation data and feeds it into the workshop's perception-agent workflow.

The setup uses a Bee device or a test account with a simulated conversation, the Bee CLI to retrieve conversation data, the workshop server and a bridge listening for Bee conversations. This preserves the downstream editing machinery while replacing the feedback input. A preloaded design conversation lets participants try the connection without first recording their own meeting.

What can a person inspect before those words become edits? In the demonstrated flow, a panel presents the conversation transcript, important points and Bee's API response. The example requests two concrete changes: make the title red and replace a brain emoji with a robot emoji. Selecting Apply sends those requests through the normal workshop flow, changes the site and then runs Nova Act verification.

The Apply step remains a human handoff between captured conversation and code changes. Giovanni describes roughly two or three minutes of conversation processing, but uses the prepared demonstration because of slow Wi-Fi rather than completing a live wearable run. The example shows how a new feedback channel can feed the same edit-and-check sequence; it does not establish unattended interpretation of an arbitrary design meeting.

32:1032:40
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

31:59 · section reference included

A duck podcast tests the difference between a claim and a checked result

An audience example turns the podcast page into something deliberately goofy: a duck podcast with retro NES styling and duck jokes. The participant sends the requests through the annotator and then runs the verification workflow. The joke quality is debatable—“pretty bad,” in the participant's assessment—but the icon request exposes a useful failure mode in coding-agent work.

What changed after the agent said it had made a duck icon? The participant distinguishes the coding agent's completion claim from the subsequent verification report, which he says confirmed the change. His familiar frustration is that an agent can announce an edit that never visibly appears. Here, checking the rendered site supplied a second observation after the code edit. The account supports a successful workshop example, without establishing a general detection rate or the report's individual assertions.

37:3337:44
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

36:26 · section reference included

Conversation capture expands into backlog and project planning

The next participant, introduced as Jeffrey, proposes using a Bee conversation summary to build a development backlog. The intended input combines a discussion of requested features with the code in a locally cloned GitHub repository. That repository context would help turn the discussion into relevant backlog items, and the Atlassian MCP would put them into Jira. The test harness was still being built: the default sample conversation did not match the repository, so a relevant conversation first had to be inserted.

Ryan's existing internal tool, Sidekick, addresses a related question: after collecting ideas and discussing projects, what should someone work on now? A shared inbox captures thoughts, emails and newsletter material. A Getting Things Done-style project tree organizes strategy, what completion looks like, tasks, next tasks and references. An MCP connection lets the founders discuss that project context with Claude and ask how their next actions should serve the strategy.

The proposed Bee connection would send meetings and ideas into Sidekick's capture inbox and use them to update strategy. Loading problems prevent a complete live demonstration. Arora then asks the important integration question: where do perception agents fit? Ryan identifies product design as the bottleneck and proposes using visual annotations to send descriptions through Sidekick or the team's own agent to improve their products. Conversation capture would supply planning context; visual annotation would supply concrete UI feedback.

39:1040:01
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

39:10 · section reference included

Recorded UI feedback could carry diagnostic context into the bridge

Jonathan's concept returns to a specific frontend problem: nontechnical colleagues can identify a UI problem without supplying detailed acceptance criteria. A recording can preserve what they were looking at and saying. He describes Jam MCP as a source of recordings, console logs and network requests, with an existing local AI harness available to consume that information.

The proposed path sends Jam MCP information into a proxy, has an LLM call Nova and routes the requested UI implementation through the local harness. His examples concern changing an investor schedule or relocating a score. Compared with a bare text request, the recording and diagnostics could carry more of the circumstances surrounding the feedback. This remained a concept with initial mocked tests; Wi-Fi prevented getting the actual Jam MCP connection running during the workshop.

47:0247:11
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

46:40 · section reference included

The ending points toward shared visual workspaces

The final audience exercise broadens the possibilities again. Selected ideas include agentic end-to-end product testing, a thinking canvas for brainstorming and planning, and a canvas where a human and a perception agent work on UI design together in real time. These are proposed uses, rather than additional demonstrated integrations. The shared canvas idea makes the collaboration ambition especially concrete: the interface itself becomes a place where both parties can contribute.

Arora closes on the need for tools that support the visual part of human-agent collaboration. The workshop gives that direction a small, usable shape: identify something on the page, express the desired change, carry it to a coding agent and inspect the rendered outcome. Annotation makes the request easier to convey. Browser verification gives the team something to examine after the agent says the work is done.

50:0350:57
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

49:59 · section reference included

Read the complete timestamped transcript
  1. 0:12

    Hello, everyone, and thank you for coming to our workshop, Building with Perception Agents. Uh, my name is Emile Baizel. I lead a team of solutions architects, uh, within Amazon AGI Lab, and our team is focused on two things. The first is working with some of our earliest adopter customers who wanna work with some of our early models and products to help them get into production. And the second part is closing the feedback loop from our customer engagements, uh, building evals for our research team to train our models on,

  2. 0:43

    and bringing product, uh, and engineering feedback to those teams as well. And I'm joined by one of our stellar solutions architects, Shruti Arora, who's gonna be running the workshop today.

  3. 0:56

    Uh, just a bit about what we're gonna be talking about today. I'll be giving a quick overview of the Amazon AGI Lab and talking about the first product that we shipped last year, Amazon Nova Act, and then we'll get into Perception Agents, and that's what the focus of today's workshop is, and then we'll get into the workshop.

  4. 1:16

    So a bit about the lab. So we are a frontier research and product team that combines startup speed with the scale and the resources of Amazon. And we are really focused on building knowledge work agents that can perceive, reason, and act in a variety of different environments to complete real-world tasks. Um, our offices are in San Francisco and Boston. We've got a few other talks going on throughout the week. We have a booth at the expo, so stop

  5. 1:46

    by to collect some swag, meet some folks from the team, and hear some of the talks there.

  6. 1:52

    So I wanna share a bit about our approach and how we think about agents

  7. 1:58

    across three different ways. So the first is around collaboration. So we really think about building agents that are teammates much more than just a black box. And when we say teammates, we really want an agent that can understand what our goal is, our objective is, and can share how they're thinking about achieving that goal, and, and then grounding all of that in actual customer, uh, use cases. And so we work very, very closely with a large number of customers

  8. 2:28

    to really help ground all the work that we're doing with agents. And the second is around perception. So agents need to understand their environment. And so for us, because it's a perception-based agent, the environment spans multiple devices. So we started with browsers last year, but you can imagine any visual screen is an environment for our agent to carry out knowledge work in, so mobile devices and also computer use is the other one.

  9. 2:59

    And the third one is reliability, and we have a great customer quote that said, "If my agent works fifty percent of the time, it doesn't work at all." And that's because you're either not gonna run it at all, or if you do run it, you're gonna end up, uh, debugging it and spending all this time, and you're gonna basically do away with all the gains that you're getting from that agent. And so we spend a lot of time building and training our models in, uh, simulated environments for reinforcement learning. Um, and again, a lot of those are based on real-world, uh, use cases, which we get from not only

  10. 3:29

    our external customers, but a lot of internal Amazon teams that are carrying out a lot of, uh, knowledge work.

  11. 3:38

    Cool. So with that backdrop, I wanna talk about the first product that we shipped last year. So Amazon Nova Act is a first-class AWS service that allows developers to build and run reliable browser-based workflows at scale. So using natural language, you can drive a browser, uh, workflow to populate a browser, navigate, search with it, fill out forms, and call a human in the loop if you need a human for a expense report

  12. 4:08

    approval or if you get stuck or other things like that. And there's kind of four primary use cases which we've seen customers adopt this for. The first is form filling. Uh, so if you have to do that at scale across a large number of different websites, and you don't wanna write a prompt for each single website or write like a, like a, like a, a deterministic script for each single site, you can use that, uh, Nova Act for that. Uh, search and extract if you wanna, uh, do research and get

  13. 4:38

    data from a lot of different websites, shopping and QA. So a bit more on what we launched. Uh, the-- Let me just get through all these. Uh, so it's a first-class AWS service. So if you go into the AWS console, type in Nova Act, you will see Nova Act there. And from the console itself, you can see all of the, all of the trajectories. So it's a very easy way to see everything which your agent has done, the bounding boxes around all the elements which it's looking at, and it's trying to take

  14. 5:07

    actions on there. And then behind the scenes, we have a custom computer use model, which is, uh, doing all of the, all of the inference there. This year, we launched, uh, an MCP server as well as a skill, and you're gonna be using those in the workshop, and that's for your agents to be able to use, uh, Nova Act very easily. And then we've got human in the loop and tool use. And we also have a playground. So if you go to the Nova Act homepage, um, it's a no-code way to just see Nova Act in action there. Now,

  15. 5:37

    looking ahead, and the topic of today's workshop is Perception Agents. Now, why do we feel there's a need for Perception Agents? So, uh, for those of you who are not familiar with the term of computer use, uh, that's basically the way for an agent to take an action on a computer screen, right? So you see a blue button in the right corner, and you tell your agent, "Hey, go click this blue button over here." Very important, very powerful. It's very important for, uh, automating workflows. But we feel that there's another half of that, which is the

  16. 6:07

    agent actually understanding what it's seeing on the screen itself. Not just using that as a sort of blind, uh, screen that it can just go and click on elements there. And we really want this agent to be able to understand screen just like a human would, right? So if I showed someone a, uh, email client from, like, the late nineties that was, like, a Yahoo email client or Hotmail client or something which you'd never seen before, you would probably be able to figure out how to send an email from that even though you've never used

  17. 6:37

    that client before. 'Cause we've got this collective understanding of thousands and thousands of hours of using these screens that we kinda intuitively understand how to use these things, and that's really where we're trying to get to with these, with these agents. Uh, and the second one is these agents don't require APIs in order to work, right? So if you think about a lot of knowledge work, um, it's a lot of humans using screens that just don't have APIs, and that's why there are people who are doing these things.

  18. 7:07

    And we want these agents to be able to carry out the same work across a variety of sites as well. And we want the models to see the screens the same way that we do because that really facilitates the collaboration, right? So rather than typing up paragraphs for what you want the agent to do, uh, on this screen and describing the screen, uh, you can just point, click, and describe changes that you want, and that's what you're gonna do in the workshop today is you're gonna click on a couple elements and say, "Hey, I wanna change the background to red," and that's it, and

  19. 7:37

    then you just have the agent go, go and do that.

  20. 7:43

    And, uh, to, to start with, we've open sourced two perception agent primitives, and you're gonna be using these in depth in the workshop today. Uh, the first is visual annotation, and so what this lets you do is on any webpage, you can point, click, and just describe changes that you wanna make. And when you're done with that, you click Export, and it exports out a JSON file with all the changes that you want and a prompt, which you can give to your coding agent along with that JSON file to say, "Hey, go and make these

  21. 8:13

    changes and do that." So importance, uh, to, to note, this has nothing to do with inference. This is purely deterministic. It just outputs JSON, doesn't have-- it's not tied to any model or anything else like that. The second part, uh, the second primitive, which we've launched, is visual verification. And if you think about a, a site that you have, you've got certain CSS styles and designs which you want your, your site to adhere to. Uh, you've got different workflows which you want your site to support. Maybe you have, like, a checkout

  22. 8:43

    flow or a login flow or something else, and you can describe those as Gherkin files. And so you can have visual verification, this, this skill, um, run by your coding agent against these design artifacts that you have, against these Gherkin files, and make sure that your site is adhering to those. And again, this is something which you're gonna use, uh, in the workshop today. And again, these are all open source, available today, and, uh, yeah, that's what we're gonna do in the workshop. So I think at this point

  23. 9:13

    I've spoken enough, and I am going to hand it off to Shruti, who is gonna kick us off on the workshop.

  24. 9:23

    Do just parts of that.

  25. 9:24

    Okay. Thank you. All right. Can you all hear me okay?

  26. 9:29

    Yes.

  27. 9:30

    Okay. Welcome. Uh, thanks, Emile, for, uh, that wonderful introduction to our, uh, Amazon AGI Labs and the products that we launched, we released, uh, earlier in May this month-- this year. So as he mentioned, we are going to be doing hands-on workshop, but hands-on on, like, whatever we release, the UI and visual annotator and the visual verification. I

  28. 10:00

    have a short demo here, uh, but before we dive into the demo, I just want all of you to, like, step into this role play here. Uh, just, just bear with me. Um, so imagine you are a front-end engineer, and you are building a web application. You have, uh, a design team, and you are taking inspirations. They have these Figma files that you are, uh, building against. You are also collaborating with a sister team

  29. 10:30

    that they want to put in a piece of their, uh, information on the webpage that you are building. So if you are-- If you think about it, that you have the designs, you'll probably take, like, uh, four to five, six weeks to, like, build the designs and build everything code base and actually build that website. Now, in the third week or, like, fourth week around that time of your building process, you actually think, "Oh, maybe I should, like, go back and, like, verify if this looks

  30. 11:00

    fine, if everything looks okay with the rest of the team," and you are constantly collaborating, right? So you are checking if, if the work that you have done is something that is, that is what you want to ship. Um, so you send your code base to-- You share the GitHub or however you are doing your, um, GitLab or whatever, uh, you have your code in. And you-- They run that, this, this web server locally, and they open up the website, and they say, "Oh, this, this

  31. 11:30

    feels off. You know, the header, heading should be probably not in red. I sh- I want to switch it back to something." Um, and they provide these feedbacks. Probably they will do it in, like, a Slack message or in a shared doc, for example. Uh, and then once you get those feedback on that, uh, on your website, you would, um, then, like, go over one of them. You'll disagree, agree, uh, to some of them, come to a middle ground, and finalize

  32. 12:00

    this is the feedback you want to incorporate. You have to go through all of them and one by one then, and start making the changes. Uh, now with coding agents, I guess it'll take maybe over- Which used to take maybe a week or it can like reduce to like maybe a few, few days. Now think about if you had the ability to take their feedback directly and pass it to the coding agent without you, your supervision, and just like once the changes has been done,

  33. 12:30

    that's when you interfere and say, "Oh, this looks good. All the changes have been incorporated." How would that reduce the time? Maybe few hours, you just start, um, collect the feedback, send it to your agent and go for a coffee break, come back and all the changes have been merged. So this is exactly what, uh, Emile was mentioning, uh, that we have a Chrome extension that we are calling as visual annotator. Um, there are three ways to annotate. You can

  34. 13:00

    see here, it's either you draw on the page or you pick the element, or you drop a pin as you would drop a pin on a Google Map, say, and provide your annotations. And once you have your annotations, you can download these and send it to your team who needs to make the changes. Or even if it's you who's make the changes, who's making the changes, then we provide a AI-friendly prompt that you can send it to your agent and it's going to change automat-- like, well, you have to instruct the agent to like

  35. 13:30

    change the code base.

  36. 13:33

    So this was the visual annotator. The next, um... Oh. The next, uh, primitive that we launched is the visual verification skill, and when I say skill, it is actually a skill that you can install on Claude or Kiro P- Kiro Power. And, um, you would see these verifications, as Emile mentioned, these are these design files that have, against which you will be running your

  37. 14:03

    visual like, uh, verification against. Like if, does the design colors look fine? Is the font size right? Is the user flow right? But one thing that will come to your mind, like these design specs, these flows, how are these generated? How are, how, how are you gonna build that? So not to worry, we have a solution for that as well. When you run UI verification for the first time, the, there will be a, a deep, um,

  38. 14:33

    uh, one level, uh, surface crawl that will be done by the UI verification tool on your website to go and check what are the links, what are the content, and based on that, it's going to create these user flows that are in terms of, in Gherkin f- uh, for syntax that the UI, UI verification is going to use when it's going to run the verification next. So let me just play that, play the demo here. Um,

  39. 15:04

    so you can see, you just like call the tool. It's going to go through the design docs, specs, uh, spe- specs, and the, uh, user flows. Uh, go through it. It's going to open up the browser, run through the design, uh, flow, user flows, and then generate a report. So this, these are the two tools that you will get hands-on in this workshop. Uh, so I'm gonna jump to what we have, how the workshop has been

  40. 15:34

    laid out as of now. First, as I mentioned, two, uh, hands-on. The second thing that's what we are trying to do is, these are the two primitives, of course. Perception is not just these two primitives. How would you wire these two primitives up for a particular use case? There is a scenario that has been, um, given in the workshop. We are trying to make this fun, so please try it out yourself, um, and see, like it's like a game day.

  41. 16:04

    You would see there are like certain hints for the, to solve the problem, what the problem is, what the end goal is. So everything is laid out in the workshop. Uh, it's a GitHub link. We will share that with you, uh, in a bit. Uh, so how will you basically wire these two things up? Uh, the sec- the next thing we have are, um, sponsors for the prizes. We have certain contests around at the end and, um, thank you the Bee team for sponsoring the prizes for the, uh, for

  42. 16:34

    the, uh, event. And, um, we will have a way how you can, instead of typing or like annotating on the screen, what are some other ways, cool ways of making sure that there are some annotations that you want to do or like feedback that you want to provide about a webpage or a designs. So Bee team will show you how you can do that beyond just typing in your feedback. Finally, there are...

  43. 17:04

    Well, before that, we have, after you finish the workshop, we also have like three different options for bonus challenge. We will have plenty of time for you to try out these tools in a particular use case that you want to. Um, maybe some, uh, you want to try wire it up with Bee, um, and see how that run, how you would probably wire it with any other, uh, form of, um, feedback that you would essentially get from your team. Or if you think that, hey, this is really cool,

  44. 17:34

    I want to build something that I want to show to my team on Monday, like the following Monday. So go for it and show, if you're brave enough, come in front, come at the stage, show your use case, demo your use case, and you'll get a Bee device. The final part is, uh, we are gonna do a little fun exercise where, uh, once you have a good understanding of these two primitives, uh, you can think of like multiple ways of how you would use it on a

  45. 18:04

    daily, on your day, day-to-day. And we will s- you will submit these ideas of like, "Hey, I think this will be really cool for me to use this," and we will have people vote on for these ideas. And the top three ideas Will get a Bee device, and I think we also have one for, uh, crowd favorite. So with that, I'm gonna jump into the workshop. This is the link for the workshop.

  46. 18:35

    Uh, you can type in, it's pretty, uh, it's, it's available on GitHub, so you can type in Perception Agents Workshop. You will probably get the first GitHub link. Um, in the workshop, we also need you to pl- um, have, use a No- Nova Act API key. So there is a piece where in the workshop we have obfuscated the first three letters. So that is on the screen here. So you can

  47. 19:05

    like copy-paste these three letters, A-C-E, that stands for ACE, and, uh, you're good to go with the Nova Act API key.

  48. 19:17

    So let me just

  49. 19:22

    pause this. So in the workshop, you would-- the README will basic- point you to the WORKSHOP.md file. And here is the scenario that I was talking about. I'm gonna read it out from here. "You are a front-end, uh, developer preparing to ship a landing page for a podcast. Uh, yesterday you demoed the page, uh, to a few peers, and they provided some feedback. The hero title feels too big. The accent color doesn't pop up the way you... it should. Some buttons are

  50. 19:52

    oversized, um, and a few small things that you s- are slightly just off. So you are on board with those feedback, and today you come in fresh and are ready to incorporate those changes." So what do you have at your disposal? The Nova Act Chrome extension, the UR- UI verification skill. You have the Nova Act SDK and the Nova Act MCP server. These are the tools that you have at your disposal to basically, uh, implement the

  51. 20:22

    solution, uh, where you would essentially, uh, build, build this entire loop by itself. Like, you just annotate, and automatically you would just hit a button on, in the Chrome extension, and, uh, all the changes will be applied. The UI verification will run, and you have a report by the end of it. Um, so this is the challenge, and there are a few

  52. 20:51

    prerequisites. So, um, the, you need to have an, uh, macOS or a Linux too, because Nova Act MCP server runs on macOS and Linux. Uh, you should have Node.js installed. If not, you can install them. Uh, npm, Python, uh, Git, Chrome browser to basically test it out because it's a Chrome extension, and then, um, an AI coding agent. So if you have Claude, that works great. We also have Kiro integration, so if you don't have any co- coding,

  53. 21:21

    um, agent, you can install Kiro and start playing around with it. Um, and lastly, we have the uv, um, that's the uvx. That's basically to install. If you don't want to install uv or uvx, then please raise your hand and we can help you install using pip. Um, so that's, that's that. And the workshop is laid out for, I think the setup should be about five to seven minutes. Uh, then you can

  54. 21:51

    like start playing around with those skills, like gets a good understanding of how would you use the Chrome extension, how would you use the, uh, UI verification skill. That's what has been explained here. Uh, to solve the challenge, you have, um, about fifteen minutes in. If you want to go that route, like I want to go step by step, and I'm just gonna go scroll down really quick. Yeah. So choose your path. I have this workshop designed in two levels.

  55. 22:21

    Uh, b- you remember I said like I want you to have fun. So two levels. If you want to go for a challenge, go for the medium route. If you feel that, uh, I just gonna like, uh, follow the instructions and get the workshop done, feel good about it. So yeah, we have an easy mode where you'll have exact instruction what you, what should be done. And you will have these two primitives wired up by the end of the hands-on. Um, so fifteen minutes we are expecting the easy path, um, and then

  56. 22:51

    thirty to thirty-five minutes for the medium. Once we have allocated the fifteen minutes time, I will come up and show you where you would like essentially, um, add your code so that, uh, you can wire these two primitives up, uh, and you can see the entire thing come into live in action.

  57. 23:12

    And we also have a bonus challenge. If you finish early, you can start with the bonus challenge. Uh, but before that, we will have the Bee team, Giovanni, um, in some time to like present.

  58. 23:27

    First-

  59. 23:27

    After, yeah. Yeah, sure thing.

  60. 23:29

    So, um, I saw that you had, as I was installing these, um-

  61. 23:34

    Mm-hmm.

  62. 23:35

    What is it? The Nova Act UI verification skills. Um, it, it said that there were some default clients that are always supported, and they include like Codex and Claude Code. But then below that, there are these additional skills, and one of them is also Claude Code. So I'm just curious, like are there two different things going on there, um, or are those the same? The, the, the fact that there are two different Claude Code skills.

  63. 24:01

    Yeah. So there are two skills. One is the Nova Act, uh, skill, one is the Nova A- UI verification skill. So that's why you must be seeing both of them. Yeah.

  64. 24:13

    So I'm gonna give you the time here to

  65. 24:20

    I'm gonna bring up the slide back. I'm gonna ask Emile to pop up here. Uh, slide back on the GitHub repo, and so that you have the, uh, API key handy if you have to change. Feel free to, like, raise your hand if you have any questions. We have our great, awesome team supporting the workshop. There you find them, see them waving. So, uh, reach out to either of us and, uh, we will pop by you to help. Have fun.

  66. 24:50

    Okay, I'm just gonna try to walk through the solution so that...

  67. 24:58

    Okay.

  68. 25:05

    So, uh...

  69. 25:10

    Okay.

  70. 25:12

    So this is the step-by-step instructions. You can see that we have the Chrome extension, we have your agent s- uh, AI agent running. Uh, if you want your coding agent to, like, automatically apply the changes from the extension, you need a bridge, because there's no bridge between them. How would the extension, like, send the prompt to the coding, uh, coding agent? So for that, we have built, uh, something called Agent Bridge

  71. 25:42

    that will automatically, uh, take the annotations and appl-- give, prompt it to the coding agent. That's where it'll start applying those changes and then running the UI verification skill. So, um, essentially in the extension, we don't have the Apply Changes button in the, in the primitive mode, but I, for this workshop, I have built in-- we have built this, um, Apply Changes

  72. 26:12

    button in the Chrome extension. Um, I'll walk you through that in a bit. Uh, so for the Chrome-- for, for this entire thing to work, you need to make changes in, like, two files. The first file is, um, the manifest.json file in the Chrome extension, where you essentially add the, this line for the host permissions to start accepting requests from the local host.

  73. 26:43

    Uh, and then you add this, this piece of code. It's a huge, like, piece of, chunk of code here. Um, and you can... What this part, uh, does in the extension is creates an Apply Changes button, wires it up with the extension, uh, makes sure-- makes, makes the UI verification run, uh, in using the Nova Act SDK instead of the skill, uh, and starts, uh,

  74. 27:13

    generates a report that you can click on and then view the report. Um, so this piece of code is, goes in this file. That is the, um, let's see, content.js in the extension, and it needs to be added around, like, line two sixty-one, uh, between this append child export button, just before. And I think I have hashed, uh, there's a comment there, add code

  75. 27:43

    here, in that file, and that's where you would, like, paste this code. So once you have that running,

  76. 27:55

    now you would see this Apply Change button here in the extension. Um, I think, uh, Emile was testing this, so he changed this to, like, FIFA World Cup. Why not? Um, so I'm gonna select one of these and I'm gonna refresh the extension again.

  77. 28:20

    Let's see.

  78. 28:25

    Annotate current page. Uh, I'm gonna try to change the published date.

  79. 28:34

    Change

  80. 28:37

    to, today's June twenty-ninth. Okay. And save it. And this is the extension. Apply changes. So in the background, it's gonna open up your coding agent. Uh, it's been tested on Claude Code and Kiro, as I mentioned. So if you are trying Cursor or, or Codex, the Agent Bridge is something that

  81. 29:07

    you would have to edit so that it can accept these Apply Changes button, uh, like, requests. Um, so in a bit it'll start applying the changes, and you will see certain logs that pop up as well in the repository. Um, that is the key, the CLIs logs, as well as when the verification runs, Nova Act has these logs, uh, that gives you exactly what the, uh, model was thinking and

  82. 29:37

    what part of the screen it was trying to make a decision on. And you can see that the button changed to Run Verification now, so it's running the verification step.

  83. 29:48

    And in a bit, it'll also generate a report that you can see. So this is where you basically apply the changes and go grab a lunch or, like, a break, and then come back and just see, uh, the verification report once you're back.

  84. 30:05

    Gonna give it a minute because it's going to go through all the design flows, all the user flows, and then generate a report, so it takes a bit of time.

  85. 30:19

    Let's see if I can pull up the repo.

  86. 30:24

    Oh, shoot.

  87. 30:30

    I think

  88. 31:35

    the Wi-Fi is super slow, so...

  89. 31:41

    But, uh, I think maybe in the meantime, I can have Giovanni come over on the stage and show you a cool way to annotate your webs- web pages instead of, like, just going and typing stuff on the web, on the web page that you're working on.

  90. 31:59

    Hello.

  91. 32:00

    Oh, the prime.

  92. 32:01

    Oh.

  93. 32:02

    Can we have... Okay.

  94. 32:04

    Yeah, on the... Can I see the slides?

  95. 32:07

    The slides? Yes.

  96. 32:10

    Yeah, just give me one second. Hello. Hi, everyone. I'm Giovanni. Uh, I was thinking to... Imagine you are in to the, your design meeting just talking about the design modification that you wanna do to that website, and then automatically your perception agent, agent is able to modify the website. This is something that you can do right now with the workshop. And this, why? How? Using the Bee wearable devices. So

  97. 32:40

    Bee is a device we have in Amazon, uh, you can buy. It's like in some bee.computer website. It's a wearable, it's your AI assistant. So it just have all... It has a microphone, so you can activate this with the button, and then it's gonna listen for your conversation. No worries, there is a L- L, uh, L- ID that's will be on if it's listen to your conversation, and then all your conversation are in your private cloud.

  98. 33:11

    After the AI agent that is running Bee is able to gives you suggestion about whatever conversation you had. So what I did is like integrating with this, this agent, the Bee agent, with the perception agent that we had for the workshop. So getting the input, listening from a AI convers- from a design conversation. Uh, I don't see the video.

  99. 33:38

    Yeah.

  100. 33:38

    I'm gonna... Ah, this one. Yeah. Thank you.

  101. 33:44

    You can achieve this with three simple step. So first of all, yes, you have to have a Bee. And I have one with me that you can use it right now, or we can have a test, a test account to download, uh, that you can use to get the conversation, a simulated conversation. Then you need to install the Bee CLI. It's a CLI that is able the... It's gonna allow you to get the data for your conversation, and it's in the workshop, the instruction to download the Bee CLI by just a npm command. Then you start the server

  102. 34:14

    of the workshop, and then you start the bridge, listening from Bee conversation and applying that to the perception agent. Then you just enable your Bee device. The LED is on. You say something like, "Oh, I wanna change the title color to red. I wanna change the emoji. Instead of a brain emoji, I want a robot emoji." And on the right side, you will see your conversation, your transcript of the conversation, and even the most important points. Here you can see the

  103. 34:44

    response API, the, the, the API response coming from the Bee. You can open the panel and check. And then you can just, like, select Apply, and here is gonna be the normal flow of the perception agent workshop. So it's gonna change the color with the color that you just said. It's gonna change the emoji. And after the modification of the website are applied, it's gonna run even for you automatically the

  104. 35:13

    verification phase on Nova Act. So we have a test account that you can use with a preloaded conversation, preloaded design conversation, that is like just talking about, "Oh, we change the color, we change the emoji," something like that. And you can, after you install the CLI, and you log it in with a Bee account, with a test device, with a test account, you just click on the bottom button, the bot- the button at the bottom. Uh, this is the verification page you can check.

  105. 35:44

    But otherwise, if you wanna test the Bee device, we can, like, you do... We can, uh, just use mine, and we show you around if you want it. Like, we can actually sim- like have a conversation about the design, and you can see that it's actually applying this after, like, two or three minutes of elaborating the conversation. The Wi-Fi is a little bit slow, so that's why I didn't do the live demo. Uh, yeah, and then in the end, there it, it, there is the verification report that you can check. The Bee devices are also our prizes for the, for the challenge, so yeah.

  106. 36:14

    You're gonna have one if you win the challenge. And we also are at the booth today and all the week. So yeah, let me know if you wanna integrate Bee, and I'm here for you.

  107. 36:26

    So Bee device, if you want to come Up on the stage. Um, we have 10 minutes for you to, like, explore these two primitives. Think of an idea that you want to probably use it, and if you wanna come up, you'll get one of these devices. Um, so yeah. The, if ... Just get creative, I guess. Hey, everyone. I have Jed with me, who built something really cool, and he

  108. 36:56

    would like to show it to everyone. Jed, come up on the sta- stage.

  109. 37:01

    Yeah, hi.

  110. 37:02

    Yeah.

  111. 37:03

    Hi.

  112. 37:03

    There you go. Jed.

  113. 37:04

    All right.

  114. 37:05

    Oh.

  115. 37:05

    Yeah, yeah.

  116. 37:05

    Yeah.

  117. 37:05

    What am I doing? Where am I going?

  118. 37:07

    Oh, I called Jed, but yeah.

  119. 37:08

    Oh, I, I-

  120. 37:09

    Yeah

  121. 37:09

    ... my name is Jeff, so I thought I was-

  122. 37:10

    You are... Sorry. I'll have Jeffrey next-

  123. 37:13

    Okay

  124. 37:14

    ... to show something cool as well.

  125. 37:16

    Oh, okay. All right, this, this was just goofy, but it was actually an, an, an interesting, uh, uh, little funnel here is, is, uh, with this annotators going through and-

  126. 37:29

    Can you put that in the

  127. 37:30

    Oh, you can't see it.

  128. 37:33

    Change it to a duck podcast.

  129. 37:40

    There you go.

  130. 37:41

    There we go.

  131. 37:44

    So just turn... asked, asked it to turn it retro, NES, uh, do some duck jokes, and, uh, went back and did the verification funnel. Um, it's probably, uh, as what I was telling them, is probably r- r- really interesting to me here is to watch this, this, uh, great AI said, "I made it a duck." Uh, you know, "I, I made a duck icon," but, uh, y- often, as everyone here likely knows, is you don't

  132. 38:14

    actually see that happen. But then it, it went through and did the, the entire verification funnel, came back with the reports saying, "Yep, it's done. I did it. I actually did it." So that was cool.

  133. 38:28

    Can you scroll through the history so we can-

  134. 38:29

    Oh, yeah

  135. 38:30

    ... what else

  136. 38:33

    it did?

  137. 38:34

    I had it, I had it just do, asked it to do some jokes.

  138. 38:39

    Which it's pretty bad at.

  139. 38:45

    That's amazing.

  140. 38:45

    There you go.

  141. 38:53

    Oh, because you came up with a cool demo. Would you like to step forward?

  142. 39:01

    Oh.

  143. 39:01

    As promised, you win this-

  144. 39:03

    Oh, thank you

  145. 39:04

    ... Bee device.

  146. 39:10

    Up next, we have Jeffrey, who wants to come and present what he did.

  147. 39:20

    You can just...

  148. 39:26

    I have a, I don't-

  149. 40:01

    Yeah, so I'm still building a test harness to actually be able to show this, 'cause the default Bee account has a, a sample conversation that isn't relevant to the thing. So this is just, this is just something trying to, uh, bring the Bee to life. So the idea was to have access to the Bee CLI, um, and collect the summary of a, of a conversation, which was, uh, a discussion of, of, uh, backlog features that would be added to a, uh, repo that you're working on, right? So you're working on a

  150. 40:31

    specific, uh, GitHub repository that's, that's, that, that's cloned, and then, um, uh, what's gonna happen is your conversation is gonna be used in context with, uh, all the code that's, that's there. It's gonna build a backlog based on the summary, and it's going to use the Atlassian MCP to put that into Jira. So that's the, uh, that's the, uh, idea here. And so the key thing that I'm just building right now in the background is, uh, the, uh, the test harness to insert a new

  151. 41:00

    conversation that's relevant to the, the repo. So that's it.

  152. 41:07

    Pretty simple and, uh, yeah. Anyway.

  153. 41:12

    That's awesome. Thank you so much.

  154. 41:14

    Yeah, thanks. Thanks. Great. Thanks very much.

  155. 41:17

    So here you win your Bee device.

  156. 41:19

    Great.

  157. 41:19

    I know you wanted to go and get it, but-

  158. 41:21

    Yeah, yeah

  159. 41:21

    ... you won it.

  160. 41:22

    Thank you very much.

  161. 41:30

    So, oh.

  162. 41:32

    You have a question?

  163. 41:33

    Giovanni told me-

  164. 41:37

    Ryan, who's gonna present next.

  165. 41:43

    Hello, everyone. Excited to be here.

  166. 41:54

    Let me see. Start mirroring. So I was, I was late to this session, uh, because the other session ended at 3:00. So, um, I came up to, uh, Giovanni. Hold on me me, Shift + B key right here.

  167. 42:12

    Oh, perfect. That's fine. So I came to Giovanni. Um, currently wearing a Bee hat. I currently attend, uh, Wharton, uh, Business School. My cluster's mascot is a bee. I am one of three people who care that the mascot's a bee. Um, so you can imagine my excitement when I came to this conference and saw we were presenting about a Bee device. So naturally, being late, being a Wharton grad, I went and asked if I could have a free Bee device. Uh, Giovanni said, "Do you have an

  168. 42:42

    idea to share?" So I, I'm currently working at an AI upskilling startup Um, I am not a huge fan of Linear. Apologies to anyone who works at Linear. I just need a better way of understanding what should I be doing any time during the day, going from capturing an idea, discussing with my co-founder, and then updating a project repository. So this is a natural use case for the Bee device. So we have a internal tool called Sidekick. Emphasis on internal because there is no

  169. 43:12

    design. Um, in my co-founder's defense, he did tell me to, uh, tell Claude to make it look pretty, no mistakes, and this is the best it did, so, um. But how it works is we have a, a joint inbox. Um, you can ignore the Go Touch Crash SF. I just see all these billboards and, um, it gets me concerned. Uh, that we send emails jointly to, uh, [REDACTED], and these are all the different

  170. 43:42

    inputs we have, um, thoughts throughout the week, newsletters. I don't know if anyone here s-subscribes to an AI newsletter. Um, see something interesting, we send an inbox. And we are big believers in getting things done, which was a, uh, mode for knowledge workers organizing their projects, tasks, developed by David Allen in twenty ten. And oh, if the Wi-Fi works, you could be able to see it. Um, sorry, that did just work off the screen.

  171. 44:13

    One second. So the getting, the getting things done tree shows all the projects, and under each project it has, uh, the strategy, has what the, what completion looks like, tasks, next tasks, references. And we've built an MCP so we can sit and talk to Claude and strategize on, "Hey, this is what we're thinking on this project. What do you think we should be doing?" All to solve the need of when you're working after you have a meeting of like, "What should I be doing right now to tie to my ultimate

  172. 44:42

    strategy?" So how we imagine this to work with the, uh, Bee, uh, device, as Giovanni, uh, informed me, there's an MCP, would be capture our different meetings or different ideas, have it sent to our capture inbox, and then use that to update our strategy. Um, I wish this was, was loading because... Let me see. Oh, that's why. My phone's... See, that worked. Um,

  173. 45:10

    yes. You know, I'm now O for eleven for live demos. Um, but that is, that is my concept of the Bee device. I'm looking forward to using it and sharing on LinkedIn how much I love the Bees. Uh, go Bees. Buzz buzz.

  174. 45:28

    Thank you.

  175. 45:34

    How would you, uh, go and integrate the perception agents into your, uh-

  176. 45:41

    Oh, I-- actually, I have an answer to that too.

  177. 45:42

    Okay.

  178. 45:43

    So as I've actually emailed myself and Sidekick to discuss later, my co-founder, is, uh, we developed a lot of product offerings b- such as Sidekick, um, different tools for learning, um, the whole mission of making sure everyone knows how to adjust to the upcoming workforce displacement. But the bottleneck right now is product design, of building something that users can understand exactly what to do. So we would use the annotation feature of the perception agent to then, um,

  179. 46:14

    send that description either through Sidekick, through our own, like, agent we have running to, to make improvements, but then to close that loop of development.

  180. 46:22

    Oh.

  181. 46:22

    So yeah. So if AGI would love to sponsor Ossian- ... um, I will give you my card, and we can talk later. So thank you.

  182. 46:30

    Awesome. Thank you so much for coming up and demoing. And here, as promised, a Bee device.

  183. 46:35

    Thank you. I appreciate it.

  184. 46:40

    So as we are wrapping this up, um, just, Emile, I'm just gonna...

  185. 46:47

    We are gonna put up a survey on the bo- on the screen. Uh, it's something that we...

  186. 46:56

    Yes?

  187. 46:57

    So the time's up.

  188. 46:59

    You want to-- Oh, okay.

  189. 47:01

    Like one minute.

  190. 47:02

    Okay. There is, uh, Jonathan who wants to present as well.

  191. 47:11

    Uh, so mine's more of like a concept than... I didn't have time to build everything, um, but I'll just kind of walk through it.

  192. 47:30

    All right, so I was kind of looking at the, uh, the proxy for the Bee and trying to figure out how are we getting the information from the CLI. Oh, it's not, it's not sharing. Oh, there we go. All right. So I was trying to figure out, uh, how the proxy actually works and how we're getting information from the Bee, and, uh, besides just doing transcripts, uh, transcription, could you pull different data from different sources? Could you pull it from an IoT device for whatever reason? Um,

  193. 48:00

    and what I started to come up with is, uh, at the company I'm at, which is a finance company, we have a lot of non-technical people, and not only do we have to get our, uh, criteria in, but we also have like a l- lot of UI, UX, um, that we have to try and capture, and we don't always get it in like the best details, uh, for acceptance criteria. So I've been pushing the team to use, uh, Jam MCP, which basically allows you to do a recording, captures all the

  194. 48:30

    console logs, captures the network requests, and then, uh, feed that information. Um, we also have-- I built an AR- AI harness, so we can pipe this information to it. So really the architecture kind of looks like this, where very similar to like the, um- The CLI, you could actually take the Jam MCP, pipe that information into the proxy, have the LLM go out to, um, Nova, and then actually take the UI, uh, implementation.

  195. 49:00

    So if you're saying things like, "Oh, I wish this, uh, would say, you know, uh, this investor schedule needs to go like this, um, or this score should be, uh, a research level score and be in a different location," uh, we'd be able to actually pull that information from the MCP, send it over to Nova, and actually make the changes on the AI harness that is running, uh, locally. So you could do the proxy the same way, um, but through a different device.

  196. 49:31

    Um, did some initial tests. It looks like it works even through just some mocking, uh, but wasn't able, with the Wi-Fi, to get, uh, the fig-- or the Jam MCP up and running. But that'll be the test when I get home. So, thanks.

  197. 49:54

    Thank you so much, and-

  198. 49:56

    Appreciate it.

  199. 49:56

    There you go.

  200. 49:59

    So right now, we have

  201. 50:03

    fifteen more minutes that will close the workshop. Um, we will put up a QR code on screen. If you feel that you have a great idea and you don't wanna come up and talk to us about it, you can submit these ideas here, and we'll do a... Oh, there it is. We will sub-- we will vote on those ideas, and the top three ideas will get a Bee

  202. 50:32

    device. So if you have an idea, please put it in those, the poll.

  203. 50:43

    Just, uh, give me a second.

  204. 50:47

    There you go.

  205. 50:48

    You guys see that? Yeah.

  206. 50:53

    So we want them to scan the QR code and enter-

  207. 50:57

    Yes

  208. 50:57

    ... an innovative idea using what we've learned today.

  209. 50:59

    What would you use this perception be, all the things that you saw today, all the things you played around with today? What do you think would be a good use case for you that will help you make your life easier on a everyday basis?

  210. 51:19

    We saw a bunch of ideas now, s- and if you think you had one, you're feeling a little shy, there's a chance to win another device.

  211. 51:33

    So what do you think? Five minutes, and then we'll-

  212. 51:35

    Five minutes, and then we will-

  213. 51:38

    This site.

  214. 51:38

    Yep.

  215. 51:42

    Cool. Voting's closed. Ah.

  216. 51:44

    Let me fix that.

  217. 51:49

    Okay, I stopped the poll now. So all of them, great ideas. I was reading through them, and I was discussing with Emile there, like, so hard to pick. Is, isn't it, Emile?

  218. 52:08

    So, we have

  219. 52:11

    the one with pixel judge. Can someone raise their hand who submitted that idea?

  220. 52:22

    No one? Pixel judge... Uh, what's that?

  221. 52:33

    That one.

  222. 52:33

    Okay. Um, the next one was the agentic end-to-end testing for a product. Okay. Come on up here.

  223. 52:48

    Do you want to have it?

  224. 52:50

    Here you go.

  225. 52:51

    Thank you. I'm very excited to, to use this. Yeah.

  226. 52:54

    Sweet.

  227. 52:54

    Awesome. Awesome. Awesome to hear that. Thank you.

  228. 53:01

    The reframe a l- a life thinking canvas for brainstorming and planning.

  229. 53:09

    Yep.

  230. 53:10

    That's you. Come on up here.

  231. 53:12

    Come on down.

  232. 53:19

    So we had decided we'll give away three, and

  233. 53:26

    one was not claimed, so we have -- we did actually circle down to four. The last one is build a canvas app where a human perception agent work on a UI design together in real time. Come on up here.

  234. 53:48

    Thank you, everyone.

  235. 53:53

    A huge round of applause for all the winners here.

  236. 54:00

    Can we go to the last slide?

  237. 54:04

    Like, the thank you slide.

  238. 54:05

    Thank you slide.

  239. 54:12

    Okay, so I just want to wrap the session up with, uh, something like a key takeaway. The first, the most important thing of this workshop, you can all imagine, is the way human and agent collaboration is happening is changing. So we need tools that will make the visual piece of how the, um, human and agents are collaborating, and this is what a step next to building

  240. 54:42

    perception, perception agent is. So you can get started with Nova Act, if you haven't already s- you know, looked at the GitHub repo. It's available. You can scan this QR code. It's an SDK. And also we have a blog post by our team that you can look it up explaining how, what we are thinking about perception agent at large. So with that, thank you everyone, and we also have a feedback, um,

  241. 55:12

    QR code up. If you think you like the session, you like Emile, you liked me, you like Ji- Giovanni here, who presented, please leave us a feedback. We appreciate all your presence here. Thank you so much.