{
  "video_id": "fGSpr8bHxcM",
  "channel_slug": "deeplearningai",
  "channel_handle": "deeplearningai",
  "title": "AI Dev 25 x NYC | Tyler Slaton: Build User Facing Agentic Applications with AG UI",
  "duration_seconds": 1675.0,
  "url": "https://www.youtube.com/watch?v=fGSpr8bHxcM",
  "upload_date": "",
  "transcript": "Hi everyone, my name is Tyler Sllayton.\nI'm a founding engineer at Copilot Kit\nand I'm currently allin with the company\non agent user interactivity.\nSo what is copilot kit before we get\nstarted? Well, C-Pilot Kit is the\nframework for building AI co-pilots,\nwhich are userfacing agentic\napplications. We're open source. We have\n30,000 GitHub stars, 200,000 weekly\ninstalls, and we're growing week over\nweek. We work with hundreds of uh we\nwork with Fortune 100s, unicorns,\nstartups, and really everyone in\nbetween. And we're used by 10% of the\nFortune 500s. Finally, we're the company\nbehind the AGI protocol, which is one of\nthe fastest growing TypeScript AI\nprojects.\nSo, quick uh agenda today. We're going\nto be going through really five points.\nWe've already done the introduction, so\nactually we're going to go through four.\nUh the state of AENTQI,\nAGUI, AentQui patterns, and then what we\nsee at Copilot Kit as on the horizon. So\nto get started, let's take a look at the\ncurrent state of Agentic UI.\nAt Copilit, we're really fortunate to be\nable to talk with many people that are\nbuilding aic applications, both in\nenterprises, in the open source, and\nkind of anywhere in between. As we\ninteract with these people, we've\nnoticed that there's two core use cases\nthat we've seen that people are trying\nto build in today's AI ecosystem. And\nthese are really SAS co-pilots where\nyou're trying to take some agentic\nuh agentic workflow and funnel it into\nan existing SAS application to make that\nSAS application easier to interact with.\nAnd then there are productivity\nco-pilots where you want to work\nalongside a user to get some core work\ndone. So let's take a look at both. So a\ngreat example of a SAS co-pilot is the\nBreeze assistant inside of the HubSpot\nCRM. You can ask it questions and\nqueries about your data like for example\nwhat was my what were my sales last\nmonth and it'll give you an intelligent\nresponse based off the data that it has\ngrounded within.\nA great example of a productivity\nco-pilot is a little bit different\nthough something like cursor where you\nand your agent are interacting together\nto get some work done.\nBut there's kind of one challenge that\nwe've seen as we've been building with\nthese this community. It's that agent\napplication agentic applications are\nreally complex. But why is this? Well,\nagents break the request response\nparadigm that we've established over the\npast 30 years of the internet. In\nstandard non-agentic applications, you\nget a request, you submit a request, and\nthen you get a response, and that's it.\nWith aentic software, they're long\nrunning processes that require streaming\nas a result to get good UX. You can't\nbuild an aentic application if you don't\nfocus on streaming. They also take\nstructured and unstructured input and\noutputs. Think things like text, but\nalso different modalities like voice,\ntool calls, images, and even state\nupdates, which we'll get to. They\nrequire composition. So, as you go\nthrough a complex process, maybe through\na supervisor pattern, they require\nhandoffs to different sub aents. and\nyour user very often wants to be aware\nof what's actually happening in that\nsituation.\nAnd as we'll get into, you can also do\nnon-deterministic UI patterns that make\nit really hard with existing response\nrequest or request response paradigms to\nget consistent results.\nSo what can we do? What did we do at\nC-Pilot kit to solve this problem?\nThat's where we created the AGUI\nprotocol which is the agent user\ninteraction protocol for connecting\nagentic backends and frontends.\nSo let's take a step back and let's look\nat the current protocol landscape\nbecause there's a lot of protocol\nthere's a few protocols as we see it but\nthere's a lot of protocols out there in\nthe Aentic ecosystem. The three as we\nsee it main ones are NCP, A2A and AUI.\nAs you can see here, these are all\nflowing into and out of the agent. So,\nhow are they complimentary to each\nother? Well, first of all, we see MCP as\nthe model context protocol, which is\ncontext like tools, context like\nresources, and context like um prompts.\nThose go into your LLM and can augment\nthis generation. A2A is for two agents\ncommun communicating together or\nmultiple within a mesh and it has\ndifferent concerns um than what AGUI\ndoes which is AGUI is really the agent\nuser interaction protocol for you know\nclients and servers. So let's talk a\nlittle bit about that architecture\nfirst. Um AGUI is an event-based\nprotocol again for connecting agentic\nbackends and agentic front ends.\nBut what is copy and how does it fit\ninto this? Well, Copilot kit is a React\nconsumer, a React UI consumer of AGUI\nstreams. So any AGUI server that is\nemitting AUI events can be can can be\nconsumed by Copilot kit and you can\nbuild UIs on top of that creating agent\nuser interoperability where your agents\ncan be interoperable with your UIs.\nSo we've had a really great adoption of\nthis. first came to agent frameworks\nwhen we released this about six months\nago. We had a great partnership with\nLangchain and Crew Aai and we also\nlaunched a UI when we open sourced that\nprotocol uh with MRA, AG2, Agno and a\nfew others.\nA few weeks ago, we also released our\ncollaboration with Google where the\nGoogle team collaborated and created an\nAUI integration with alongside of us.\nAnd just this week on Wednesday, we also\nreleased collaboratively with Microsoft\nuh thenet agent framework and Python\nagent framework integration where their\nteam actually contributed to their\nframework aui integrations which they're\ngoing to be extending into things like\ndifferent clients in the .NET ecosystem.\nAnd it had a really powerful reception\nover the last 6 months. We went from\nzero installs of AGUI to 151,000 each\nweek. Our star counts are now at 10,000\nas well on AGUI. And across the\necosystem, it really struck a nerve and\nreally lit a fire to continue agent user\ninteractivity.\nLet's talk a little bit about how it\nworks. So, AUI is a set of 16 standard\nevents that are optimized for agent and\nuser communication.\nThey're transportless in the sense that\nwe can communicate over HTTP,\nwebsockets, WebRTC, and any form of\ntransport. And it has a client server\narchitecture where the clients are\nthings like React and the servers are\nyour agents. If we take a look at this\nuh architecture diagram, which may be a\nlittle bit small, so I'll just narrate\nover this. We can see we have AGI\nmiddlewares and we have AGI servers.\nWhat's the difference? So an AGI\nmiddleware is a server that already has\nan existing streaming protocol that is\nconverted into at runtime AGUI events so\nthat when you consume and uh when you\nconsume input and output that is a\nstandardized interaction. AGI servers on\nthe other hand are natively emitting AGI\nevents and natively receiving AGI\nevents. If we take a look, it might be a\nlittle bit small, but there's a couple\nof things I really want to point out. On\nthe example AGUI stream on the right\nhand side there, you'll see that there's\na run started that happens with a thread\nID and a run ID. Thread ID being a uh\nthread ID capturing the entirety of a\nconversation, whereas a run is one\ninteraction that triggered an agent. We\nhave a text message start, but you see\nthere's no content there. It's actually\njust a role of assistant. The content\ncomes through deltas. And this is what\nAGUI is great at which is efficient\nstreaming of structured data like\nmessages like state. And we'll talk\nabout these things at the end there. You\ncan also see just to put a cap on it a\nrun finished that says that this\nexecution has completed which lets us\nknow we are ready for the next input.\nSo with that in mind, with AGI in the\nback of our mind, with Copilot in the\nback of our mind, I want to talk about\nuh design patterns that we have been\niterating on and implementing at\nC-Pilkit with both our ecosystem as well\nas our CL our customers.\nSo as we see it, generative UI is huge.\nIt's a huge pattern. We're going to talk\nabout it. And there are three main kinds\nof generative UI. Static, open,\ndeclarative.\nOkay, that's great. But you know, let's\ntake a step back. What even is\ngenerative UI? This is UI, some\ncomponent, some visualization that your\nagent is transmitting to your user. And\nthis can be done in three as we see it\nways. So let's talk about static UI. You\nprobably already interact with static UI\npretty frequently today. This is where\nyou are mapping generated data to\nexisting components in your codebase. It\nallows for deep control over the UI\ngenerated by your agents. And it lets\ntool calls and agent state be typical\ntargets for user components, userfacing\ncomponents. This example, this is a\npretty minimal one that's pretty common,\nwhich is just a weather component where\nthe agent is returning a static result\nof 38 degrees Fahrenheit in New York\nCity.\nLet's take a look at some of the code\nthough. On the left hand side you can\nsee there is a dummy agent framework\nthat I built writing in written in\nPython. And on the right hand side is\nsome copilot kit code. You might see\nthis new v2. Uh this v2 is actually our\nnew interfaces. So if you've used\ncopilot kit before we are releasing a\nnew set of interfaces that will make it\neasier for you to build a interactions\ninside of your applications.\nLet's take a look at a couple things\nhere. On the left hand side here I've\ndefined get weather which is a tool. I\nbind that into my agent as a tool and\nI'm using the new GPT51 model. Then I\ncall agent.agui.serve.\nThis is a pretty common pattern with all\nof our integrations where they create a\nserver for a UI to be emitted within\ntheir framework. On the right hand side,\nI have two things that I import. One is\nco-pilot shots. Another is use render\ntool. And this is that mapping of static\ndata generated by the LLM.\nOh,\nokay. Just went to sleep. Hope you guys\naren't asleep. Okay. Um, so this is that\nstatic mapping of UI from the back end\nto or of data from the back end to UI on\nthe front end. So that's what the use\nrender tool is doing. It's just\nregistering a component called weather\ncard for the argument of location and\nthe result of temperature and we can map\nthat into our co-pilot chat component.\nThen result is something that looks like\nthis where I can have a chat with my u\nagents. I can ask it what's the weather\nin New York City. It's going to return a\ncard with that result. And on the right\nhand side here, if you've ever used\nCopilot Kit before, this is actually our\nnew design language that you'll be\ngetting out of the box with our V2\ninterfaces.\nYou can also do this with another\ninterface that we're shipping with\nCopilit V2, which is the use agent hook.\nSo the use agent hook is built on the\nparadigm of AUI where you want to just\nconsume that raw stream and interact\nwith that agent. So, Agy ships with a\nvariety of clients if you saw earlier\nlike React, but those are also language-\nbased. So, what's actually happening is\nReact is consuming the TypeScript\nclient. That TypeScript client has an\nabstraction for running your agent,\nproviding it context, providing it\nmessages, and it also has a middleware\nconcept where you can have full control\nover the agentic request life cycle.\nOn the left hand side here, what this\nuse agent doing is actually quite clever\nwhere it's creating a clone, a readon\nclone of on your front end of that agent\nwith the same exact interface that you\nwould use with that TypeScript agent,\nthe same exact interface that we use to\ncreate co-pilot kit, but it lets you do\nit in a headless way. And so now you can\nprogrammatically execute your agents,\nyou can programmatically add messages,\nyou can do time travel, you can reload\nmessages, you can also do generative UI,\nwhich you can see here. We have a\nmessage.contents, which is the text, and\na message. which is the component to\nrender.\nSo there are some pros and cons to this.\nFirst, the good. It's really simple.\nIt's really simple to understand as\nwell. And it has it gives you really\nfull control over your UI, which will\nkeep your designers really happy. And\nit's great for the common paths, the\ncommon treaded paths within your\napplication that your users commonly go\nbecause you have great granular control\nover what that UI looks like and how it\nis structured.\nSome cons, really high coupling between\nthe back end and the front end. Your\nagent team needs to be aware of your UI\nteam and your UI team needs to be aware\nof your agent team because these two\nneed to communicate the tools and the UI\nthat can be rendered within otherwise\nyou'll get very generic UIs for your\ntool renderers as similarly your\ncodebase grows linearly with the\ndifferent use cases you'll have.\nSo let's talk about some other ones.\nOpen-ended what does open-ended mean? So\nopen-ended is basically where the agent\nreturns some fully open-ended content.\nThis can be an iframe or this can be raw\nHTML that we actually set within our\nchat. And very often when we talk with\npeople, this is what they're thinking\nabout when they think of generative UI.\nSo why isn't it prevalent today? Well,\nit's starting to be. So this is where\nthings like MCPUI and the chat GBT apps\nSDK come in where it is returning to you\na link to an iframe that you can embed\nwithin your chat and through the iframe\nprimitives within the browser you can\nactually interact within and out of that\niframe. So you can get some interaction\nhere where you have um some UI\nand this is generated either by a server\nor fully by an agent.\nSo, let's talk about the pros. Really\nlow coupling between the front end and\nthe back end. You can literally render\nanything from your agents inside of your\nUI. This is great. So, now we can have\nour agent teams go and build UI for our\nfront end. So, let's talk about a bit of\nthe cons. The UI may vary unpredictably\nin the sense that your agent team may go\nand build some UI that it thinks looks\ngreat and fits great into the UI uh\nfront ends, but it's uh common use cases\ncommon use cases may suffer because\nthere's no longer that coupling. So\nthere's no longer that communication.\nIt's pretty difficult to style you. It's\nreally hard to style the internals of an\niframe. When it's HTML, it's also\nsimilarly hard because of structured\ndata that you have no awareness of\nwhat's actually taking place. Has some\nsecurity and performance concerns.\nperformance mainly that you're rendering\na bunch of DOM objects within the within\na chat and it's typically a web first\nexperience. So when you get into native\nenvironments where you don't have access\nto something like a DOM becomes really\nhard.\n[clears throat]\nSo moving on from that, this is the last\none and this is one of the more emerging\nones which is declarative UI. And this\nis a semiopen spec for designing\nconstrained UIs that the agent can\ngenerate driven by a declarative spec.\nIt's somewhere in between static and\nopen-ended generative UI and it\ntypically describes it's typically\ndescribed by cards and widgets with\nrecurrent elements. Let's take a look at\nan example.\nSo in this example, this is open JSON\nUI. This is a spec that is emerging at\nthe moment where you have a card that\nthe agent generated but it doesn't have\nany specifications of what that card\nlooks like. Right? We also have an image\nwith an airline logo and a size some\ntext value and then in it closes out\nthat markup and it can result in\nsomething that looks like the bottom\nright. What's actually happening here\nthough is that in your UI you are\nmapping this generation from the agent\nto a component library. Think about shad\ncm or any component library you may know\nlike radics for example. These are\ncomponent libraries that have really\nstructured ways of rendering UI. And now\nwith this approach your agent has the\ncapacity to go and generate any\ncombination of those elements together.\nOkay. So this is great. So it lowers the\ncoupling again uh between the front and\nthe back end. It can accommodate a lot\nof common use cases and it gives us\nreally extensible rendering um and ways\nto render and ways to swap out our\nrendering within our UI. But it can't\nreally accommodate fully custom UI\nneeds. It's really constrained by the\nspec. So whatever this is in the spec is\nall that your agent can generate. And\nsometimes it can get into some weird\nsituations where it's trying to get\nsomething but it doesn't have the exact\ncomponent that it needs. So it does some\nweird UIs to get around that. So your UI\nmay vary unpredictably. So some of your\ncommon use cases may suffer. So you have\nto do a lot of context and prompt\nengineering around that to make sure\nthat it doesn't try to smash its head\ninto a wall.\nSo what does AGUI support? We just\ntalked about three of these. Um well\nAUI's whole approach is to embrace,\nextend, and innovate on. So, we've\nalready embraced in our we've already\nembraced generative UI uh for static\ngenerative UI fully. You can go and do\nthat with copilot kit right now. We also\nhave great support for open-ended UI\nwhere you're able to through projects\nlike MCP UI render that within the\ncopilot channel. And as the JSON\ndeclarative or sorry, as the declarative\nUIs come through and the declarative\nspecs come through, we will also fully\nsupport that as well.\nOkay, let's move on. Take a quick step\nback. We're still in design pattern\nland. We just talked about generative\nUI. Let's talk about state. So agents\nare these stateful OB uh agents are\nthese stateful pieces of software,\nright? LMS are stateless famously.\nAgents are typically stateful. They're a\nstateful abstraction on top of LMS to\nallow us to do a lot of interesting\nthings like memory, like message\nhistory, like persistence\ncan be messages that are in that state,\nbut it could also just be structured\ndata. Right? Think about a chart. Chart\nis structured data. We could also put\nthat into our state. Um, we could put\nuser preferences into our state.\nUh, finally, it can be generated, but it\ndoesn't necessarily have to be. This can\nbe statically programmed in your UI if\nyou're familiar with any agent state.\nThis is very easy to do. It's just code\nat the end of the day. Let's take a look\nat this within the confines of Copilot\nKit's new V2 interfaces. So, here on the\nleft hand side, we have that madeup\nagent framework. I have uh I've created\nthe same 5.1 model. I bound in some\ntools that I haven't defined for the\nsake of brevity. But I have this new\nthing here which is the state schema.\nThat state schema has a name string.\nThis is going to be the user's name that\nI want to store as I go through and\nexecute um some interaction in the UI.\nAgain I call agent.au serve and then we\nget routed to the front end. On the\nfront end again I called that agents and\nnow in my agent I now have state coming\nthrough. I can call agent.state.name\nand I can read that state on the front\nend. But this is birectional where I can\nalso on the front end send an update to\nthe agent to update that state. In this\ncase I've updated my state schema to\nsomething like a counter and as I click\nthe button on the right hand side that\ncounter will go up and the agent will be\naware of that state. And you can imagine\nand start to visualize how this might\nscale like for example into a canvas\napplication. Who here's used Vzero\nbefore\nlovable anything like that? Keep your\nhands up if you used anything that's\nkind of like those things. Great. So\nthat's what's really happening behind\nthe scenes is you're having a stateful\ninteraction with that uh agent, that\npiece of software, right? What's\nhappening there? Um well, there's a\ncouple of things. On the lefth hand\nside, I have a document, right? Let's\nimagine something like I'm writing an\nemail.\nI also added a new tool in here called\ngenerate document that will be able to\nlet's imagine for the sake of brevity be\nable to update that state. Now on the UI\nside of this I can have the agent render\nI can have a rendered version of that\nagent's document and I can also have the\nuser edit that document. So I have a\ncollaborative experience kind of like\ncursor where the agent's writing\nsomething and then I can edit it and\nthen I can edit it and then ask the\nagent to update it. So what does this\nlook like in act in in an actual\nexecution? Let's get into a quick demo.\nSo this is a application I wrote for a\nworkshop that we do uh in the San\nFrancisco Bay area with the Pyantic AI\nteam. So behind the scenes here, we're\nusing the Pantic AI integration and we\nare just going to be talking with this.\nI've had some internet troubles today.\nSo let me just make sure that this is\nlive.\nLooks great. Cool. So I said hi to this\nagent and this is a simple to-do\napplication, right? It's minimal for the\nsake of um a workshop. So, we're just\ngoing to talk through pieces of it. The\nfirst thing I want to do is ask it to\nadd a to-do list to build a website.\nGreat. Done. It's there. Now, what if I\nwant to move that to completed\nit? Um,\nhey, what's the state of my current\nto-dos for the website?\nIt's going to\nSorry, it's supposed to get it. It\ndidn't. Can you get your state?\nUm, there it goes. Cool. And now it\nlearned, hey, actually I lied. It is\ndone. So, what happened there was I\nmoved the state over and then I asked\nthe agent, hey, can you get your to-dos\nagain because you lied to me. And then\nnow the agent is aware of that to-do. I\ncan also ask it to uh change the theme.\nThis is a pretty novel one, but I'll\ntalk about what's cool about this. So,\nwhen I set the theme to purple, this is\nnot a normal tool call. What's actually\nhappening here is this is a front-end\ntool where on the front end, we've\ndefined a tool schema. We've passed that\nto our agent and we've asked our agent,\nhey, when I when when relevant, please\nexecute this action.\nBut it doesn't get executed on the back\nend. The execution actually takes place\non the front end where we have complete\naccess to the DOM. So I actually called\nsome react state right here to edit that\nfor my entire application where you see\nthis nice purple transpire across the\nentire application. I can also ask it to\nyou know move the first to-do into\nprogress. I'm just going to start to\ninteract with the agent in some more\nnovel ways. I implemented this action\ncalled fully send it which is basically\njust going to take all of my to-dos mark\nthem as done. And this is a human in the\nloop interaction. I really want to zoom\nin on this because we'll talk about it a\nbit more in a second where I am asking\nthe agent to do something. the agent\ngoes and does it and it asks me or ask\nme for permission before it does it. So\nin this case I I hard programmed hey\nwhen you call this tool fully send\nalways ask me before you do it. So there\nit goes. Awesome. And it's aware of that\nstate. So it's going to go ground itself\nin that state again. Great. Fantastic.\nSo that's a quick example of what you\ncan envision with a canvas application.\nVery minimal. But you can scale this up\nto really complex workflows like the\nvzer, like the lovables, like the\ncursors of the world.\nSo what's on the horizon as we see it at\nCopilot Kit? Well, first we believe that\n2026 is going to be the year of voice\nagents. Um, why? Because voice is\nextremely intuitive and conversation can\ncontinue as work happens within your UI.\nIf you remember earlier, I might have\nsaid, you might have heard me say that\nAUI is a transportless protocol. What's\ngreat about this is that we can also\nsupport things like WebRTC where now we\ncan provide that into the entire\necosystem of AGUI.\nAnd we're all in on it. Next up is agent\nsteering. The more autonomous the agents\nbecome, the more important the midrun\nsteering becomes. This is because as\nautonomous agent go and do work, they\ncan very often get off task or very\nslightly make adjustments through their\ntask that ultimately lead to the wrong\nanswer. And agent steering is the answer\nfor this.\nFinally, and this is where we're going\nall in uh from a product perspective is\nself-improving agents where we have all\nof these signals of human edits. We have\nall these signals of approvals or\ndenials. We have all these signals of\nwhat your agent's doing and how your\nuser receives that. You're collaborating\nwith your user. You're getting their\nedits and you're getting that feedback\nas signal. And then you can use that to\nimprove your agent over time in what\nwe're calling automatic RLHF or\nreinforcement learning on human\nfeedback.\nSo what are some conclusions that we can\ndrive?\nFirst, agents are becoming real. 2025\nwas very much the year that agents\nbecame real. In 2026, we're going to be\nrefining them. agents change how we\nthink about UX and how we think about\nUI.\nGenerative UI is an essential pattern in\nthis where we can provide user context\nthat's no longer text based.\nAnd fin and finally, voice modality will\ngrow and it's going to grow fast in\n2026.\nFinally, auto RL auto RLHF will provide\nagents with learning at scale in your\napplication where human intelligence can\nbe used to train your agents.\nSo I really appreciate everyone that was\nmy time. Um I've been Tyler Sllayton and\nif [applause] Yeah. Thank you.\nThat was a really fascinating talk.\nOkay. Uh we will take one maybe two\nquestions but we are moving into happy\nhour after that so the conversation can\ncontinue.\nThanks for the presentation. Uh can you\nbring your own design system?\nCan I break my own design system?\nYes. What do you what do you mean by\nthat?\nSo let's say if we already have a design\nsystem where we have opinion opinions\nabout the button and stuff like that\nin copilot kit. Absolutely. And with a\nUI absolutely absolutely because it's\nall just raw data that you can map\ndirectly into that UI.\nOne more question.\nCould you could you please elaborate\nsome on why you think uh voice modality\nis become going to become the big thing\nin 2026? Like are you imagining\nlike product development uh is going to\nbecome a collaborative thing? It could\nbe happening like within a Google meet\nfor example like is that going to be the\ninput to the like the next lovable or\nhow do you see that? Um I see uh these\nagent interactions we see at copilot kit\nthe agent interactions as taking place\nnot only through text but also real time\nthrough voice. So all the generative UI\nI just I just mentioned to you can be\nsurfaced in real time by an agent. This\nis already supported with the top models\nlike Gemini real time and open AI where\nthey also have support for tool calls\nwhich supports everything we just showed\nwhere you can do generative UI on these\nthings and you can collaboratively have\na conversation with your agent. You can\nsay, \"Hey, can you get me a booking at\nuh this restaurant that I want to go\nto?\" It can then render a component to\nyou and have a conversation, but as\nthat's happening, you're not waiting on\nthe agent to respond to text. It can\nhave oversight over what's taking place\nand you have a continued conversation as\nthat longunning process is taking place.\nSo, as we see it, voice is really a\nmodality by which you can communicate\nwith agents. Maybe that's in a Google\nMeet. But real I I really feel and we\nreally feel that voice is going to be a\nreally convenient way for users to start\nto adopt and interact with these\ngenerative platforms.",
  "transcript_chars": 27092,
  "ingested_at": "2026-05-15T10:44:57.975047+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 3864,
    "like_count": 64,
    "channel_id": "UCcIXc5mJsHVYTZR1maL5l9w",
    "categories": [
      "Education"
    ],
    "tags": []
  }
}