12 mistakes we made building an agent platform for 100,000 employees

Hey, everyone. Good morning. I'm super stoked to be here. That was an awesome keynote, if not a little long. We're going to talk to you about a platform that we made today at TELUS called Gizmos, and we're going to talk a little bit about the mistakes made along the way. And funny enough, I've actually invited my two awesome colleagues here to talk, and you're going to get one extra mistake that I made that I'm correcting right now, which is bringing your team along for the journey. When you're making these amazing platforms, it can be so interesting seeing the impact that you can have in a company. But I always like to think about measuring it, like what happens when you leave, like what is the legacy that you leave? And so right now we're seeing a huge transformation in companies about how we build software. So if you're in this room, I imagine you're someone who's interested in building platforms. You're seeing the impact of platforms being built at your company, and it's really about everyone else. So I'm really excited to welcome to the stage Kevin and Andrew to talk about the mistakes we made building an agent platform for 100,000 employees. Thank you, thank you. Welcome. Good morning, everyone. I think I'm going to know the answer to this already, but quick show of hands, who here has built something with an AI agent this year? Keep your hands up if sharing it safely with your colleagues and a team was a pain. Right. Okay. So that's usually the hard part. So we built an agent platform, like Justin said, to make that part easy, especially for people who had never shipped anything before. Also for 100,000 employees. And we made 12 mistakes along the way trying to do that, at least 12 that we're willing to talk about. So technically we're the problem. I'm Kevin. I do developer advocacy at TELUS. Coding isn't usually my full-time job, but with AI it's quickly turning into that. I spend a lot of time with our builders and whatever's getting in their way. And I'm Andrew. I'm a software engineer, and I take sort of the meaty techy stuff underneath. So building out the infrastructure and our integrations with all of the cool tech that Cloudflare has created. Is the mic working for Andrew, by the way? No, eh? Hello? Mic check? Mic check? It's on. I think it's on. Oh, turn it off first? Okay. Classic three-finger salute. All right. Oh, there it goes. Cool. Yeah. So I'll repeat that. I'm Andrew. I'm a software engineer at TELUS, and I work on all of the cool meaty techy stuff underneath, integrating all of the cool tech that Cloudflare has built. So TELUS, in case you haven't heard of us, or maybe you have, which would be awesome, we are a proudly Canadian technology company that just happens to run a network. There's over 100,000 of us in over 45 different countries. We've also got four very different businesses. Telecom is what we're known for, but we also do health, farming, and digital services. We've also got 30 different ways for our team members to sign in. That's the scary one, and that one will come back later. So now, picture 100,000 of us all building stuff with AI. That's kind of where our problem started. Someone builds an AI prototype over a weekend. Honestly, these days, it feels more like an afternoon, and that's the easy part now. The hard part was sharing it to another team member. Now, all of a sudden, they need sign-in, a domain someone's approved, a security review, observability, and you just know someone's going to ask, so where does the data live? I even wrote an internal guide for this. Nine steps plus a 20-minute video, spin up a GCP project, get a Kubernetes namespace, wire up workload identity, write some Terraform, edit the Helm charts. This might sound familiar. Step one literally says, be patient, and when you finally get to the end, you're in dev. You're not in prod, dev. So yeah, we called that last mile. It was a hell of a long mile, and that's if you're a seasoned developer. A lot of our new builders who had never shipped anything before AI just never really made it to the end. So Kevin and I built Gizmos. So Gizmos, I like to call it an everything platform. Essentially, it's sort of a safe sandbox substrate where you can deploy applications, MCP servers, web apps, automations, anything you can imagine using Cloudflare's dynamic workers. We stand up SSO. We enforce RBAC and sharing policies in front of all the applications, and essentially we've created an unopinionated way for you to build. So we're compatible with every single agent ever. We've created multiple interfaces to make that easier and easier, so you can just ship directly into your organization in Gizmos. And we enable all of the Cloudflare infrastructure, such as databases provisioned on demand, KV, storage, et cetera, et cetera. And on top of this, because of Cloudflare, we have instant global availability. So if you have an international organization like Telus, it's not a problem. So that's Gizmos, and that's us. I handle all of the architecture. And I handle all of the community. And together, we make amazing tools. And maybe some massive enterprise-level calamities, but yeah. Okay. So 12 mistakes, and we'll take turns. Kevin, you will actually go first, because you made the first one. Yeah, I did. So you've probably all seen this one. Step one, draw some circles. There we go. Okay. Step two, draw the rest of the owl. Honestly, for a while, that's how we treated onboarding onto Gizmos. So actually, one question. Can I get the font size for the speaker notes, just one down? Yeah, perfect. Okay. Awesome. So yeah. So step one, build a prototype in Google AI Studio. And step two, export it as a zip and drop it into Gizmos. We handle the plumbing and the security scans. Less than a minute later, you've got a secure URL. You can share it with anyone at Telus. Upload a zip, get a subdomain. I said that a lot, and I was pretty proud of how short it was. Then I started sitting with folks while they tried it. Mostly people who had never deployed anything in their life. And almost every time, they get stuck on the zip. Like, where do I even get one? Or it's not working for me. It wasn't them. Their agents just didn't know how to build something Gizmos could deploy. Like, AI Studio would decide your little to-do app needed an express server, which our zip upload did not do. So we ended up moving a starting line. We wrote an LMS.txt and a skill so any agent could learn the platform and build for it. Then we went a step further and built Gizmos Studio. Now, Gizmos Studio is open code running in a Cloudflare container. So you get one per person. So people could build right inside Gizmos and never even have to touch a zip. So my lesson learned here was meet people where they build. But more importantly, watch someone try it before you call it easy. And that was my first mistake. Andrew, yours cost a little bit more money. Indeed, it did. So I let everyone use the sledgehammer on the fly. And I'd like to start this one with a quote. With great power comes great responsibility. Uncle Ben. Unfortunately, if your users do not understand the power that they yield, there will be no responsibility to be had. If you give somebody a new way to OCR a document, no matter how expensive it is, they will be running thousands of instances every single morning scanning all of their documents. So that's why it's important to listen to that little finance guy on your shoulder whispering in your ear these three words. Metering limits and billing. You got to do it eventually. And this is a lesson that we learned a little too late. And it gets scary when you see that bill on your doorstep and you're like, oh, that was a day. Yeah, so Andrew's mistake cost us money. My next one just straight up locked people out. So you remember those four businesses? Yeah, we are basically a bunch of companies in a trench coat. Health, digital, KUDO, all of these from the outside looks like one company. But from the login page, it's 30 different ways to sign in. And I found that out the hard way. Now, when we first built sign in, it was one button. Sign in with Google. Because that's how I logged in. Seemed reasonable. Then gizmos got popular. And when your platform gets popular at a company like ours, you find out real fast how many people can't get through. This was one of the earliest messages from a user. KUDO has its own workspace. And that was news to me. Then Telus Health showed up. And they're not on Google at all. And it just kept going. More than a dozen Telus domains I didn't even know existed. And if you're a new builder to all of this, you don't know what an identity provider is. You just know the button doesn't work. So what do we do? We ripped out that Google button and we rebuilt sign in with better off, which is an open source off library. Now there's only one box. You type in your email. Gizmos works out the best way for you to get in. Passkey if you've got one. Google if your company is on it. And if neither, we just email you a link, which is sent straight from a worker with Cloudflare's email service. And honestly, the whole fix was just an email box, which looking back is probably what we should have started with. So people could finally get in now. Andrew, tell them what happened when they all did. Yeah. So similar to what Kevin said, when your platform gets popular fast, every single stone becomes unturned. We bolted on scalability too late. When you have a demo to thousands of people and they join all at once as we did a few times at Telus, you will find every nook and cranny full of termites that won a platform launch. So in the age of AI and like with everyone here has probably messed around with goal loops or just sending Claude on a performance journey, scalability can be achieved relatively early. And if you're going to blow up from 1,000 to 10,000 users, as these vibe coding platforms often do, you should account for it early. So we're proud to say that Gizmos is now very performant. Yeah, Andrew, and 10,000 users and every one of them leaving stuff behind somewhere, which brings me to our closet. Everyone's got that one closet. Everything fits for now. Now, full disclosure, nobody wrote any part of Gizmos by hand. It's all vibe coded top to bottom. And when you ask an agent for analytics, it puts it wherever's handy. And for us, handy was the closet. Every click, every page view, every deploy went into the same D1 database as our whole platform runs on. Nobody really decided that. It kind of just happened. Then Andrew built this little app. He called it the scary line. And it shows us how close our database is to D1's 10 gig cap. And for the first time, that was when we actually opened the closet door. Almost half of what was in there was analytics events. Now, to be fair, we were at less than a percent of the cap at the time, but we could have said, you know, that's a problem for future homework. But we didn't. And a few days later, the events moved out into analytics engine, which is built exactly for that. But it doesn't end there. A few months later, we found out we weren't counting people properly anymore. Analytics engine samples, which is great for counting page views, but not for counting people. So we ended up moving people counting back into D1. And our numbers jumped like seven times. Turns out way more people were using gizmos than we thought. Today, about 10,000 people a month. Now the scary line says about 7%. And none of it is analytics. Mostly a list of every app version anyone's ever shipped, which is, yeah, another closet altogether. But honestly, if I picked where the data lives, before I even knew what questions I wanted answered and should have been the other way around. Anyway, that's my closet. And Andrew's was a whole marketplace. Yeah, so community marketplaces are incredibly difficult. If any of you have built community marketplaces in the past, whether it be like for agents, MCP servers, etc, you probably come to realize that 90% of your catalog will eventually go completely untouched, whether it be random unused dashboards, agents on top of old documents, to do apps, so so many to do apps, and Hello World's zero through 100. We are not claiming to have solved this problem at gizmos. But one of our main goals is to make this manageable. We've introduced a ton of features for organizations for administrators to feature specific apps that are common across the org. We're bringing in teams so you can see specifically what your team uses every day to get their work done. We have stars, we have usage metrics to push up the apps that are popular. Our goal is or our core tenant now for marketplaces is this isolate what you see to what you need in order to get your work done, especially in the age of just the sheer amount of software being produced by Yeah, and so so Andrew's problem here was seeing way too much. Meanwhile, mine was the opposite. I couldn't see anything. Everyone that knows the it's fine meme, and everyone that's run a platform has been that dog. We were that dog for a while and we didn't even know it. But about a month after we opened gizmos up, someone posted this this channel, scream face five minutes later, internal server error. And my reply was, hang on, everyone. Dana is working on adding some instrumentation. Now, Dana Harrison is our principal site reliability engineer, he was adding tracing so we could finally see inside the platform. And by the way, the way we wired it ended up breaking every call a gizmo made out to the Internet. Every one of them came back to 500. So yes, we actually took gizmos down by adding the very thing that tells us when gizmos is down. Now, that's how it went for about the first five weeks. If something broke, our users found out and they told us on Slack and there was no way to check if whether it was gizmos or them. And for a user that's new to all of this, you're gonna think it's you. Right. And now in June, we ship the status page. It runs on its own worker on a cron trigger every five minutes. So when gizmos goes down, the page about gizmos going down doesn't go down with it. So fun fact, for a while, our status page is actually reporting outages that weren't really happening. The checks just happen to be running from the other side of the world like Europe or Singapore, but we fix that too, eventually. And so if you're building a platform, ship the status page from day one, not the day after your first outage. So trust me on that one. And while all that was going on, Andrew was on a bit of a spiritual journey. Yeah. So I went looking for the one true God of software tooling. So if any of you watch Fireship or any of these channels, you saw frameworks dropping day after day after day, there are literally an infinite amount of works, whether it be front end, back end, MCP, runtimes, like Dino, BUN, Node, Rust, Go, Elixir, WebAssembly, runtimes, on and on. There are so many tools to choose. This isn't to say that learning these tools isn't fun, and that your specific application might benefit from adopting that framework or that runtime or that tooling. But it is to say this, don't rewrite your project for the 10th time. And this is a note to myself. Not all tools are made equal, but almost every single tool will get you where you needed to go to begin with. And in the age of LLMs, you can honestly probably just push your framework to do that extra thing you needed, or just rewrite everything from scratch in the next couple hours. I really like this quote that I've heard going around. It's a little ominous, but also kind of cool. Everything is everything now, which is to say that there's really no moat between software. You can just pull in the parts you like and push out the parts that you don't. Yeah, so Andrew, you get a framework, you get a framework, everyone gets a framework, right? And Andrew's right, like you can really make anything work now on your machine. And every developer in this room has probably said this at least once. I just happen to be saying it to the whole company. See, a lot of our most experienced AI developers live in cloud code, myself included. And when we rolled out cloud enterprise out to the rest of the company, I just assumed everyone will use cloud code as well. Now, back in April, somebody asked if we could make gizmo skill available to everyone. And my answer is, of course, it already is, and loaded locally on your machine, which was true for me. Turns out people were trying to deploy from everywhere, cloud desktop, cloud co-work, a browser tab. In June, someone in co-work asked, how do I deploy? They wanted to avoid the terminal. And honestly, most of our new builders had never opened one up. So why would they, right? And and to be fair, we didn't leave them there. We got gizmos.run allowed in cloud co-works sandbox, pointed it at our LLMs.txt, and it worked. Then they found the same trick also worked in a regular cloud desktop chat session as well. And so they never really needed a terminal, we were just really used to one. And in August, we shipped a gizmos connector right inside, right inside quad. It's an MCP running on the same worker as gizmos, no terminal, no install. So now, before I tell anyone where to go, I actually asked them where they're actually working in. And which is kind of funny, because we were also asking everyone to come work in one more platform. Right, Andrew? Indeed, we were. So I built a new platform to replace all of the other platforms. I know everyone here, if you're involved in software, you've seen that XKCD standards comic where it's like, we need one more standard to replace all the other standards. And now you have 15 standards. So yeah, we did this with gizmos. gizmos is sort of a platform to subsume all the other platforms. But in a way, this was sort of our goal. It's one platform to support all of the other platforms. So gizmos is aimed to be truly a platform to support all the other platforms. And which separates it from other platforms we run in the past, which were primarily purpose built for one thing or another, whether that be APIs, agents, or some specific resource. So fingers crossed that I don't do this again. But honestly, we might be seeing gizmos to Electric Boogaloo in 2027. If you give me too much time to think about it. Okay, Andrew, quick question, though, who actually wrote that platform? Claude. Okay. And remember, when I said, you know, none of gizmos was written by hand. Still true. And so here's the thing with vibe coding, right? And many, you probably already know this, it's really, really easy to get carried away. We let AI write gizmos, all of it, code works, you ask for a feature, you get a feature, you ask for another one, you get another one, right? And just keeps going. And like two of our busiest commit days in August was 157 commits over two days. And if you looked underneath, you would have found three different ways of doing the same thing. Wrappers around wrappers and comments, oh my god, so many comments, it read more like a diary than code. And so this is where Justin comes in, right? Justin, you heard from earlier, Justin Watts. He is one of our distinguished engineers. And back in August, Justin asked to be our chief refactor officer when gizmos went big. We gave Justin the job a little early. Three ways of doing things became one 18,000 lines of comments gone in a single day, all in almost 100 ,000 lines of gizmos deleted. So all hail our chief refactor officer. And look, you know, none of this means vibe coding is bad. We still vibe code everything. And would we do it again? Hell yes. But we just booked the refactor before the bloat, or you know, book Justin early. So we all got carried away. And Andrew, you got a little lost. Yeah. So Kevin and I actually wrote our list of the 12 mistakes we made completely separate. And this was our one mistake that we both wrote down. And this is one that I think all of us are falling into getting lost in the vibes. So with the new era of models, especially like Opus 5.5, and Astra, it's really easy to hand over the reins completely. And it can feel great to have any of your requests instantly manifested in front of your eyes. However, you still need to know what you're trying to build. If you only give your agent the outcome, you really stand no chance of actually validating the thing that you've built. You've basically made slop. So don't become like the guy up here. Don't make slop. Yeah, we've all made slop. We've all made slop. So you can attempt to get your agent to output all sorts of artifacts in the hopes that it might be able to download some sort of understanding into your brain of the system that it has manifested. Diagrams, design docs, funny gifs, like the one we have up here, interactive documentation, you will get a map of documents that make it feel like you understand your system when really you're just being taken along for the ride. So it's still a good idea to sit down and actually architect how you want your system to behave from the beginning. Like using AI to suggest methodologies, tools, that's all fine. But you should try to wrestle with your tools hands on just a little bit so that you can sleep a little easier at night. So our goal at Gizmos is to do this work well, so that the non-technical people who reside on top of Gizmos don't have to worry about the platform that they build on and can do just completely vibe coding safely and feel like they are truly sandboxed. So all this to say, there's a big difference between being told information and actually going out there and learning it yourself the hard way. Yeah, which is kind of the whole talk, right, Andrew? And we learned all these 12 ourselves. So you can just be told, right? And if you only remember one slide from today, you can make it this one. My six, which are user tested, mostly on our users. And mine all learned the hard way. So 12 mistakes in total. And one thing that we would do differently for each, none of them were that expensive. We just happened to learn them the very expensive way. So if you want to hear something crazy that every single one of those 12 mistakes, so the login, the closet full of data, all of them happened in the last six months and were solved in the last six months. So this journey has been extremely quick. Building a platform used to take years. But honestly, we built one in a single season. The lessons just come a lot faster than they used to. Yeah. And you know what, it's I mean, it's working. 15,000 people have used Gizmos. It's about 15% of our company. And last month, nearly half a million Gizmos views. So we must have done something right. So here's our bet is that we think platforms like Gizmos are the next generation of software and specifically enterprise software. No more apps, but a safe sandbox place where any kind of software can be deployed and monitored. So agents are about to write a lot of software, we need places to put it. So if any of these 12 sounded a little familiar, come find us or scan one of these. We'd love to hear which ones you're living through right now. And if you've got a 13th mistake, please come after and tell us because we are I think Justin said we had a 13th mistake, maybe 14th now, right? 14th mistake. If you have a 14th one, please let us know because we are going to make it very soon. Yeah. And if you want to see what we built, it's gizmos .run. Fair warning, there may be a wait list. We're still working on that last mile. All right. And so with that, thank you for everyone for coming. I guess we'll, any questions? You have time for questions? Anyone? No? Do you? Sure, sure. What was the wildest thing you've seen being built by a builder that maybe not in the usual type of builder? An unusual role of a person? Maybe, what happened? So the question was, what was the wildest build we saw that was not within a gizmos shape? We have a lot of like non-conventional developers, if this is what you're asking. We have people who are like store managers selling telephones in Nova Scotia that are building out entire internal social media applications and automations for running their like daily tasks. Our sales teams have been building out like these crazy agent farms that go out and make like insane marketing plans. I clicked through that app the other day and it was like so many numbers and I was like, I don't know what's going on here, but there's like 500 people using it every day, so it's cool. Yeah, and what's crazy is that like we built a platform, but people are actually building platforms on top of this platform, right? So it just kind of iterates and keeps going. Anyone else? Sure, I think maybe a mic. All right, I wasn't expecting a mic, but how did you guys enable trust and security while you wipe-coded this whole app, which is available to so many users now, and what are you doing to maintain and ensure that there's consciousness? Sorry, I didn't quite catch your question. It was how did we... Enabling security and privacy and making it, doing it consciously that it, even if it breaks, and how is the data secure? Like, because it's going to be a lot of data in there. A lot of users will be concerned about the safety of the app, which is wipe-coded. So what are you guys doing there? Yeah, so we have a single hot request path for every single gizmo and we lock it down extremely tightly. So we're even talking about, at Telus, putting things like TailScale in front, so it's like straight up on a VPN separate from the Internet. But as of right now, we have a whole system of like checking which org you belong to. Every single gizmo deploys on its own domain, so there's nothing cross-domain. And we have a whole system of like auth redirects to make sure that browsers are isolated completely. So we have a lot of measures. The goal is to build out like sandboxing as strong as possible, so every app feels like its complete own experience. Thank you. A few in the back, one more on this row. Just out of curiosity, how did you determine how much budget to allow each of these gizmos to run? Because as we do this, we're like, do we give it X dollars or Y dollars? And so we've got to start somewhere. So how did y'all figure that out? Yeah, good question. So isolates are extremely cheap. We got our bill for like the last month, and it is like basically pocket change. So really, the only thing that we have been focusing on billing for is our AI usage. So we have enabled a binding to use, we have like an AI proxy we ship and tell us, and so we let people consume that through gizmos. And this, we have been building out like tons of systems. As I talked about with our metering limits and billing, we have a ton of dashboards and chargeback and all of those things built into our org. Sure, yeah, go for it. Hi, thanks for the presentation. Maybe I go back to the bloating. The gentleman here asked you the question about the widest application that was built. I'll just loop with the security question and sanity. What was the shadiest thing that was built out of these 1,000 apps? And subsequent question, how did you guys, or when did you guys start considering governance and controls? Shadow IT or shady, call it how you want. That's a good question. Shadiest thing. I mean, I'm sure there's lots of shady things happening, but... Yeah, I think, so right now I tell us we are working through how we actually manage our data privacy. So this is like a big focus of gizmos. We're a Canadian company, we have a bunch of legal compliance things that we have to meet in terms of where we store our data. So we have had to go in sometimes and be like, yo, you can't do that here. And this happens. But in general, people have actually been pretty safe, which is actually, I think, one of the most interesting parts of this kind of platform. You would expect a lot of people to misbehave, but actually most people are pretty aligned. Yeah, and we, which I didn't cover really here, is we have a community Slack channel as well for gizmos internally at TELUS. And everyone, Justin always says, everyone is welcome, but everyone must participate as well. So part of that is actually sharing what people have built, what you've built, and then also asking the right questions. Is it safe for me to build XYZ app on this gizmo? Now, what we typically tell our users, our internal team members, is that if you are dealing with sensitive information, maybe don't put it in gizmos just yet. We're still working on those avenues to make that a lot safer. But for anything else like, you know, a dashboard or like a to-do list app or something like that, perfectly fine. I'm sorry? They will ask that on Slack, and yes, we have actually a workflow in our Slack channel as well that automatically answers and takes all the input from our previous threads as well. Yeah? Sorry? Yeah, so we do secret scanning every single time you push a gizmo to our platform. We scan for secrets, and we also run like the newest Gemini variant through it to be like, is there anything here that looks really obviously bad? And we will flag it ahead of time too, and we'll be like, hey, okay, these are the things that we flagged. You can send that to your agent to have it fixed and then redeploy. Yeah. Yeah, part of it as well with our gizmo studio, you can like loop back. So like security issues, you click gizmo studio, and then it fixes them and then pushes them back out. So a couple more questions. Gentleman in the green. Hey, thanks. This is kind of a continuation of the performance question on tokens cost. So when you find that an app is hitting the token limit, do you find that the developers on your team are coming in to refactor things or combine apps that are getting popular, or is that putting pressure on a team to help build these apps? Yeah, so I think when it comes to like limits on API keys, I think that resource scarcity makes people more creative. So this is something we're definitely leaning more into, trying to like put restraints on people. For a lot of time, we have been very open and cavalier, and we're like, let's just see what people build. So yeah, we're in sort of a mix of two camps. It's like we want people to build things that are exciting and then eventually reign it in. So I guess this is something we're like slowly enabling at gizmos. Yeah, I mean, and we are fostering, you know, a kind of a culture of experimentation as well within the company. So again, you know, it's a lot of that community sharing, you know, and helping people as well, you know, throughout the process too. A couple more questions. Yeah, gentleman in the red. Hi, thank you for your presentation. I was curious to know what kind of identities these agents run. Do they run as agentic identities, or do they assume the same identities of the human that's setting them up? And how do you manage access between those agents? Yeah, so good question. At Telus, we are very much interested in agent identity. We've been looking at integrating the like on behalf of RFCs. So basically providing like an agent identity as they operate. So you can do like sort of the cascading permissions. And it's like I have authorized my agent to do this. It has permission on this system, so on and so forth. So this is something we're currently integrating to gizmos and we're building foundationally at Telus. One more question. Yeah, so I'm curious. How are you connecting or are you thinking about connecting to a data warehouse? Being able to pull larger big data systems that you're already fetching metadata for that you can then do analysis inside of a gizmos? And then also are you supporting the gizmos to communicate with each other via like secure connections? Yeah, so yes to both. So to answer your first question, the idea with gizmos is there are sort of two shapes of workloads. And Cloudflare supports both of these. So there are isolates, which are essentially all of your IO bound apps, any of your crud apps or web apps. But then there are also containers, which allow you to ship more hefty applications. So if you want to do data analysis, if you want to connect your data warehouse, pull a bunch of stuff in, do a bunch of crazy work there. The idea is to enable both shapes. So both like the CPU bound and IO bound tasks through different deployments. Your second one about connecting gizmos. This is actually a feature we have in our platform. We call it custom bindings. And the idea is you can ship a gizmo as a binding that other gizmos can consume with a whole permissions engine built on it. So you can say like I'm only allowing this gizmo with this user to access it. So, for instance, Kevin and I shipped the first one, which is like a user picker from the entire Telus organization with the hierarchy in mind. So it shows everyone's roles and like who's under them and all that kind of stuff. Yeah. So any gizmo that needs access to our internal team member hierarchy can use that custom binding and easily just leverage that straight out. It's like an API marketplace, but kind of isolates. Yeah. OK. Well, I think that's it. Thank you very much. Hope you enjoyed it.