Full-Stack AI Orchestration: Modular Agents, Observability, and the Edge

So welcome to New York, if you folks are here from New York. So let's start with the talk. Thanks for coming to join. So my name is Jamal O'Garro. I am an engineer at Netflix, currently in the data platform organization, working on the experimentation platform team. So any A-B testing experimentation that you may be randomly assigned to, I am the team who basically makes that happen. I've been on a few teams at Netflix. I've been in infrastructure engineering, platform engineering, data science and engineering, and now I'm in the data platform. I've been there for about a little under four years or so, so got to see a good bit of the company. Before I joined, I basically spent my entire career working in finance, primarily building algorithmic trading and systematic trading strategies and software. Not too far from here in JC. So more personal about me, I'm a hip hop head, I'm a sneaker head, I'm a Yankees fan, Giants, Rangers, and die-hard true blue, true-blooded Knicks fan. Let's go, Knicks. First photo is me on the top of the Netflix office in Los Angeles. The second is me on top of a volcano in Hawaii, repping the Knicks. So it gets real.

Alright. So let's go ahead and set the stage for this talk. Mainly we're going to we're here to talk about artificial intelligence, just like the big thing happening right now. Everything is AI, AI everywhere. And us as JavaScript engineers, we're probably in probably one of the best places to like start embedding some of this experience to the users. And I realized that my screen is actually flashing a little bit. Let's see if I can get that. So apologies. Alright. So I'm going to give a little bit of a background on like what AI is for our purposes. Here's a literal textbook definition, but not here to read textbook definitions. We're going to say for our purposes, an AI system is basically just a software that knows how to reason about and perform some type of action within a system. And if we take a step back and see like what are the main areas of artificial intelligence? We see that it's a pretty broad field, right, that contains machine learning as a subset.

That contains machine learning as a subset. We're basically trying to take data and like have our programs learn from that data. And if we go a little bit deeper, we're going to focus here on our talk is deep learning, where you have this very nice construct that you may have heard or seen, called the artificial neural network, which looks like a tree of life if you flip it one way, depending what kind of stuff you're into outside of outside of work. Or is basically just a simple algorithm that basically takes inputs and does a really good job of like training these things here, called these hidden layers, to try to find optimal ways to approximate some type of function. That is really good for either predicting data, classifying, classifying some type of data or target. And over the years, there was a change to that architecture called the transformer.

I think some folks in Google released a paper called Attention is All You Need, where they added some like pretty interesting and nifty tricks to the architecture to basically create this type of structure that's really good at performing like sequential predictions and analysis, basically. And it turned out that it was actually really good at predicting large sequences of text from a very large corpus. And what that did was gave us gave birth to all these cool large language models like Chachi, BTE, Grok, DeepC, Claude, Gemini, that we're all probably using today and trying to figure out how we can embed them within our production systems. I think the funny story here is that Google released the paper, but OpenAI implemented it first. And they had the first move advantage to get Chachi, BTE out there and open up the floodgates. So we look back at the LLM spectrum, where does it where do they sit? It basically sits right here as a subset of deep learning, right?

Now let's talk a little bit more about agents, which we're going to focus on today. And basically for our purposes, an agent is just simply a intelligent piece of software that knows how to interpret natural language. It can make decisions. It can do things like interact with API, query a database, get context from a user, have like a full fledged, like live conversation, like you probably see within Chachi, BTE. Typically, like they're built using other large language models. They can also be built from other agents. So we're going to be talking about that today. Like how do you build an agent of agents that can be composed of many different large language models that can perform the best, that is the best tool for the job. Some of the main capabilities that you get are the ability to call tools. So tools are like simple, like special skills that you can give to an agent or large language model. So think about calling an API, querying a database, right? Just knows how to do that and do it well. You can define it as a function.

You can define it as a function. And your language model knows how to call it, how to access it and get data from it to perform its task. They also have a concept of memory. So you probably use like a cloud code or things like that. You know, you have to watch out for like your context when they're getting too large. That's like the memory part of it there.

But also with agents, we have a shared state, particularly when you look at the program we're going to look at today called LandGraph. You'll see how that memory is modeled as a state. And if you're familiar with React, it's very similar to that. And one of the most powerful parts of these are these AI's. They have this planning and reasoning capabilities that makes it very, very powerful for building out these dynamic systems that we're going to talk more about today.

So those systems are called agentic systems. It's basically just any software powered by AI or agent. The main thing is that they differ from like your plain vanilla AI system. We're just going to call a chat GPT and get a response. Is that these agents have reasoning capabilities where the flow is not linear. So you're not just getting input from one large language model and passing it through like in a feed forward nature. These things could be cyclical where they can take different branching and different approaches based off of like the context they have in their state, which makes them very dynamic and also very hard to actually maintain a production as a result.

So with that being said, with the background there, let's talk about some of the interesting stuff. So we're gonna talk more about how do we build some of these agentic AI systems for production. Right. So as a quick show of hands, I would say, how many people here have used a large language model powered application? Right. Like everybody. Right. So how many people in the audience have built a large language model powered app? Right. Whether for fun. OK. So less hands.

So last question. Keep your hands up. If your answer is yes to this. How many folks have actually deployed one of these systems and had it run reliably for like months? OK. We got one person. So I'm probably going to bore you and don't heckle me. But now I'm just playing for it. So I'm probably going to bore you here. But then again, too, it's probably something we can learn. So the main thing here is that building agentic AI systems is hard. Right. It's like Vecna would say you already lost.

If you were like in Stranger Things right now, that would be him trying to plant that seed in your mind. But if you're like me or like our boy Hopper here, you know, carrying a flamethrower, you're going to be like, but why? There has to be a way that we can actually get over this hump and actually build true tried systems that can work in production. And I have to worry about a lot of a lot of the unpredictable nature of some of these are language models. So I'm here to say that some of the main challenges with building these systems, I guess you get some you can summarize them in like these three bullets here. There's definitely more than this, but these are some of the main ones I would say is that back in the day when we thought about AI engineering, it was really about, OK, how do you train a model? How do you compress it? How do you quantize it? Maybe embed it in the browser or mobile application to make inference faster. You do some offline training to update your model ways and things of that sort and figure out how to do that without having downtime for the user.

There's definitely more than this, but these are some of the main ones I would say is that back in the day when we thought about AI engineering, it was really about, OK, how do you train a model? How do you compress it? How do you quantize it? Maybe embed it in the browser or mobile application to make inference faster. You do some offline training to update your model ways and things of that sort and figure out how to do that without having downtime for the user.

But that's more like that linear flow where you're probably trying to perform one specialized task. But now we're like these new models that can do many different things. They have reasoning capabilities and there's no way to predict what they're going to do. We have to take a different approach. Right. So right now, you're actually trying to like take something that has some type of intelligence that can do whatever it wants to do in the system. You can probably constrain it by some amount, but you have to be able to figure out how can you build a system around that you can trust.

So think, for example, if you're trying to embed this into like medical devices or use it for things like law enforcement, where if you get it wrong or your model hallucinates, it can have very dire consequences. You want to make sure that you're protecting yourself against that. And what I'm here to say is that the biggest problem is like the hallucinations are one thing, but it's just one small part of the problem. I'll say if you look at if you look at these systems and you try to scale them, there really are at its core a distributed systems orchestration problem.

And then why do I say that is that we're using these large numbers model systems, right? They're mostly going to use tools to try to call some type of API, try to go to a database. They're interacting with the user and they can perform differently depending on what kind of prompts they get or what data they receive or they can hit an API and it could timeout or it could fail. Right. And that could be a single point of failure for your whole agentic flow. Right. If the user needs to get some information from some critical source and API is not available, like the agent probably know to like retry. Maybe it does. Maybe it doesn't. Maybe it gives up and just decides to hallucinate to give you some data so it can move forward. Right. Because all they want to do is accomplish the task in the best way that they can do. All the issues that like token users can become expensive if they're not managed properly.

And the main thing we're trying to figure out is how can we make our systems resilient with all these problems we're trying to solve. Right. So I want to propose a modern enterprise stack. Just taking some pretty well-known tools off the shelf and composing them together to try to create a system that's basically going to be robust. It's going to be scalable. You're going to have an efficient architecture that allow you to actually like trace through, see what your models are doing, see what tools are calling, what impact does it have on your system. It's going to give you the ability to have retries. If your agent tries to make a call, it's going to know how to retry it a certain amount of time. It's going to give you that durability and also like manage state between your system.

So this stack that I'm going to cover a little bit more today is primarily three pieces. There's LangRaph, LangSmith, and Temporal. LangRaph. Have you anyone hear of a Lang chain before? And our LangRaph. Yeah. So basically it's made from the lang chain, folks. It basically allows you to model your graph as kind of like a model, your agent as a graph. So it's like a DAG basically that lets you. But it gives you a really powerful structure to like model your agents in that way so they have more flexibility.

Well, if you use Lang chain, it has more of that linear, you know, get a lot of this model, get an input, perform some work, get an output and pass it forward. There's no like going back in between the sequences there.

Then there's LangSmith, a reality tool that we're going to look at that basically allows you to see every single path that your agent takes as it goes through and performs some kind of action. So if you if your user gives your agent a prompt and say there's a router agent in there that routes it to a particular specialist agent and it gets routed to like 10 other agents along the path, maybe things were well, maybe things went wrong. You have full traceability. So what happened there?

There's another tool called Temporal, which I use pretty extensively in my line of work, which basically gives you and guarantees like durable orchestration of workflows. Here we're looking at like the AI agent, like I kind of call it like this, this modular monolith. And I say that because the idea here is that because you're building a essentially a large graph, right, is that you can just keep building and building more specialist agents, specialist skills, giving them more tools, more ways they can interact with each other over time where it can just grow separately to like any other party system that wants to interact with this, like a mobile app or UI text to speech voice interface. It just lives it.

It can just grow. You just keep building its brain and get smarter and smarter as you extend it with more agents in the system. The nice thing about that is that each agent is focused on one particular thing, one very specialized task, and it does it really, really well. So there's less chance for it to make mistakes and cause issues. And these agents are working together and perform a large brain for your system.

The cool thing about this modular architecture is that you basically can take very, very, very complex problems, break them into smaller pieces, have the agents work on them and they can all come together to solve the larger problem. The link graph is a tool that we can basically use to achieve that. I'm going to give some background here. I'm going to show some code very, very quickly. So forgive me for boring you after lunch. Nobody's sleeping yet. So, you know, I guess you're doing all right.

Unless you define your agents as a graph, that's the whole control flow. The main parts of it, you have a state. The state is basically just like some shared data that gets passed between your system and it can be accessed by your agents. They can also update them. So you think about React. It's very similar to that. You have some kind of state object and you have different functions that can operate on it and then produce some type of side effect that updates the state. And then those two constructs in line graph are nodes and edges.

So like your nodes are like your primary logic for your agent. That's going to perform your transformations, get some data, perform some type of side effect. Right. And then your edges basically direct the flow of where your agent is going to go next after it gets some type of data.

And then the nice thing about this structure is that you get to have these cycles that I mentioned where you don't have to worry about going linear. You can basically cycle through. So here's an example from the Lang chain docs where you can see here you have a user. Sorry, this is a little bit difficult to read, but I'll try to zoom in some.

So you have a user. The user has an input where they want to generate a chart of the average temperature of Alaska. Right. So that kind of goes into the research node. The research node is going to then go through to this router. It's going to say, hey, I'm going to make a call for some tool to get back some information. It's going to do some research. It's going to get it back.

It's going to say, hey, I have some information. Go back to the router. The router sees that it has a continue stage. It was sent from the researcher. So it passes to the chart generator says, hey, I need to generate a chart of this information. The chart generator can say, OK, perfect. I have enough information to go back to the router. If the info is good, you can give it back to the user or maybe it needs more money. I'm sorry, no more money. Sorry. See where my head is at here being back, back downtown. Back on Wall Street now.

Think I might lose my money. Got to get the P&L. All right. So it needs more information so it can go back to the researcher and this loop can go on a cycle until it's done. Right. Is when it's going to actually go back to the user. So you can see how this is pretty powerful, where if you are stuck going in one direction, you would never have that feedback loop here that would basically give you the ability to have these agents work together and to produce a better output.

Some of the benefits of this approach is that, like I said, each node is independent. You can fully test it. It also gives you that conditional routing based on the state. You can reuse the same nodes for different agents. So if you have like an agent who knows how to do research of a very particular topic very, very well, you can reuse that anywhere you want in the system. It's just a function that takes some input and gives you an output. Right. So is this a pure function in that in that in that regard? And the nice part with LangSmith, you have full observability into the system.

So is this a pure function in that in that in that regard? And the nice part with LangSmith, you have full observability into the system.

So I'll quickly just go through LangSmith really quickly, because I want to get to the code and just be mindful of the time, is that what LangSmith is basically like a like a cloud infrastructure given to you by the folks in LangChain that allows you to basically tap into every call, every action that happens inside of your your agent's call flow to be able to have full traceability into what's happening.

Here's a screen of what an actual trace looks like. We're going to look at a live one when I show the demo in a second. But the idea here is that here on the left, you're basically seeing all of the different agents, what they're doing, what they're calling, what tools they're using and what the whole flow looks like. You also inspect the inputs and you could also see things like how many tokens were used. What does it cost? What's actually latency associated with the actual operation? So you have really nice visibility to see like where some bottlenecks are.

What happens if you build your large model, you put it into production, but then it times out after 15 seconds waiting for an API call. So at that point, you're pretty much dead in the water because like all the work you've done to that point is lost. All the context you build is probably gone unless you save it somewhere manually. You have to start over again. You probably don't have retries. If you tell your model to retry, like I said, it could probably get an infinite loop where it's not smart enough to know that it can't go any further or it might even make up some data just to go forward, which you probably can't catch. Right. Unless you're like really like inspecting the data and then your state's not persisted. Right. So the one big thing about these these agents, they have state that they can all update and they can read from.

So at that point, you're pretty much dead in the water because like all the work you've done to that point is lost. All the context you build is probably gone unless you save it somewhere manually. You have to start over again. You probably don't have retries. If you tell your model to retry, like I said, it could probably get an infinite loop where it's not smart enough to know that it can't go any further or it might even make up some data just to go forward, which you probably can't catch. Right. Unless you're like really like inspecting the data and then your state's not persisted. Right. So the one big thing about these these agents, they have state that they can all update and they can read from. But if you blow up in the wild, right, and you don't have anything to back it up, then you're done. You start the whole process all over again, which can be pretty expensive regarding like your token usage. So something to worry about or think about there.

So the next thing is temporal. So temporal is basically a workflow orchestrator that basically allows you to build durable workflows that are basically fault tolerant. If it blows up with an execution, you could always run back because it keeps a history of all the transactions that were run. And if you failed, for example, like in the example we had with the agent, it would basically replay everything. But instead of running running an operation again, it will pull it from like from the cache, from this history and then just apply it. So it gives like these deterministic workflows and or activities. And the main thing to think about are that we have workflows which are basically like the main orchestration unit that just like orchestrates all the different activities and actions that happen within it. So think about calling your agentic model and then the activity or all the things that that model is doing. Right. Performing research, performing, adding citations and going back and forth to get some consensus before giving back to you for my data and things of that sort.

And the nice thing about this is that before we were to use these systems in production without having these these two layers here, we're having what I'm having temporal is that you have two layers of durability at the graph level and at the two calling levels. So if you blow up during the graph execution, you can always recover and replay from that part of failure. And same thing with each individual tool call as well. So here's just some quick screenshots of what the temporal screen looks like. You can see all the activities and workflows. These activities here basically give you a timeline of how long has taken to run and also whether successful or they failed. They could also dig into all of the actual inputs and outputs that you receive. So in our case of the agent or each or each agent or node within our agent graph, you can see the inputs and actual outputs of every turn.

So you have that full history like there for you. So may benefits are like I mentioned, you have durable workflows. You have things like retries built into a durable system that's built for it. You could observe every action that's being taken in your system was being called. And also you can scale it because you run multiple workers in parallel.

And the last thing we're trying to say here is that if you're going to build this large agency framework, it should just live behind like some back end for your front end, because the idea is you can build this agent, grow it, you can get smart, gain more skills without having to worry about pushing or changing UI code. As a result, you can basically just have all of your UIs connect to the same BFF. As the model gets smarter, it acquires more skills. So like you usually can just see it getting smarter without even understanding all the complexity happening behind the scenes in the back end.

So very quickly, I'm just going to show this is I know this is hard to read, but this is an idea like what our POC looks like. The idea here, you have some kind of client, in our case, we're just going to curl this Express server. The express server does everything it basically does. It has some security, some routing that's in there. The main thing is that as it gets requests, it's going to start triggering our temporal infrastructure, which is going to go ahead and take that and start sending information over to trigger our laying graph, which is represented here. And then what happens is that each step of these nodes in this graph, it will then trigger their own separate temporal workflows that have their own activities. So like if anything fails here or if the activity fails or the workflow fails, they can restart and resume exactly where they left off without having to worry about damaging the whole system.

So let's very quickly go into this demo. I'll just very briefly just show you some of the code. So this here is like a simple express application, as I mentioned. And you see here is broken down to like you have your agent section. So everything in here is where you would define like your actual graph. So here are your nodes and your edges. So one thing here is a guardrail node. That guardrail node basically is like you just saying that you're creating a node in the system that makes sure that you're not sending back like personally identifiable information. There's not like harsh language that's in there. You're not doing anything anything wrong. And this node is supposed to make sure that nothing basically breaks as like a response formatter that's in there.

As you see here, they basically just async functions that take the state. They perform some type of action and they return that state back. Right. For some changes in some metadata, which is very similar to like if you're using React, how a reducer would probably work. It looks a lot like that. And then here we have this edge that basically just says that when we receive a message coming from one of these particular agents, we know where to navigate a route to base off of some of the logic like which looks like that screen that we kind of showed you a second ago with the message.

So let me just try going to the code. I have on GitHub. You can look at it. But the idea here is basically is that this is basically what it is. And then if you look into the BFF as a simple React server, sorry, as a simple express server, then our temporal workers are defined here. And basically what happens, they each know when it calls this tool, it just calls a temporal activity. So I'm going to just show you right now that this thing is actually working because if I'm lying, I'm flying. Right. So let me just make sure that I'm over here telling you guys the truth. So I'm just going to curl over. You can read this like it says the next fan. So right here we have three agents. When I can check odds, when I can check sports facts and the one I can just perform some arbitrary research for you.

So I'm going to ask it a couple of questions. We're going to trace it through the system. So here this one says verify the claim that Steph Curry has made over 300, three thousand and five hundred three points in his career. And the New York Knicks are the team he scored the most points against. Right. And we see here we get back some information. We go back to response. It says the message claims reporting Steph Curry's career stats are accurate. Blah, blah, blah. And it says the Knicks are the team that Steph Curry has scored the most points. Again, I don't know if it's true or not. It could be hallucinating. The model that's used here is like this flash. So you get all that metadata here as well.

But the cool thing is that say if I wanted to see if there were a better model to use or a better path to take. I can go to Lingraph and I can see exactly what was sent and what the full path was. I can see exactly that called it's verify stats tool. It called it twice. Right. So I guess it was like just check and confirm. You can see exactly what it called, what it did. You can see here was making actual calls into Gemini. This is all using the Lingraph structure. And if I go into Temporal, for example, I can see here that this was actually called.

I guess like the main issue is I can see what the inputs were, the outputs were. So that was successful. If it failed and the same thing for each activity that was spawned as well. So we can see here that stats verification activity is actually passed in here. You get the full linears, how long it took. You can see exactly like what was passed in and what the result was.

So you can see you get that full traceability into your system. Also thing here, there's a there's a library called I think Tivili that can go through and make some of the searches. So what it does, it calls out behind the scenes. So you see here I'm on a free account and I incremented from 17 to 21 after making that call.

So I'll show you one more example where I'm going to just ask it the probability that the Miami Hurricanes, I'm a big college football fan. My team's not doing too well, but let's see if the Hurricanes are going to make the playoffs this year. Right. Anybody here Miami fan? OK, cool. Yeah, I'm with the Penn State. So, you know, we kind of had a bad season this year, but we won last week. Yes. Shout out to Coach Terry.

So, yeah. So there we go. So you see here based on a research estimated probability of the Miami Hurricanes making the CFP playoff this season is 95 percent. So that's definitely I'm not going to I don't know. I guess they're in there. Right. They're in there now. Right. Maybe I don't know. I'm not going to knock. I'm not going to knock the Hurricanes, but it gives you a disclaimer. So this is a guardrail baked in here where it always has to put a disclaimer about all the odds that it sells you.

So this is a guardrail baked in here where it always has to put a disclaimer about all the odds that it sells you. That's for educational purposes only. And that there's like different things that went into it. So it says right here, analysis for education purpose only should not be used or considered betting advice. Odds are probabilities and sports and things of that sort.

So very quickly, I know I've got to run, but I'll just swing back over to the slides. And then I'll just show you like some of the enhancements we can have made to this system is that there are ways to make it more robust by adding more complex aging architecture. So here we just created some nodes of agents that do specific things. And we had some edges that would redirect different agents based on the results that they get.

But we can do things like have this agent supervisor and hierarchical agent team. We can have a supervisor agent who is a bigger model, like, say, Opus, for example, who can do the reasoning and planning of tasks and then give it to smaller models like Sondra. Cool. To say, hey, I do the thinking for you. All you have to do is do the work. Here's your plan to execute it. Right. That's been found to be a way to actually improve the performance of these models.

And then same thing with I have a hierarchical agent teams and have a multiple independent models that have to argue with each other and come to a consensus. It's like all these really cool things that the research says you can do to get better performance out of using multiple models instead of one.

Another thing too you can do is dynamic large language model selection. So you can use any model under the sun that does the best for your task. You can look at Langsmith to see like what the performance is and make adjustments there as well. There's also agents that can optimize your tokens. They can basically have max tokens.

You can do things like tell it that it shouldn't go. You know, X amount of tokens. If it does, it can compact your conversations automatically. And if you use cloud code, you see it does some of the stuff also for you for free. But it's kind of like a best practice baked into this. So that can be used to optimize your costs. And then the other things like scaling security considerations also as well.

So key takeaways. And then I'm done. Appreciate your patience here is that we use these large language models in production. Right. There's a bunch of things that can go wrong that you're probably not thinking about it once you got your first chat GPT API set up and you're, you know, making requests. And you're about the budget of a billion-dollar company. There's like your system has to be resilient to failures, things that can fail across the board. And then these models are great, but they're not good at being resilient to cast those issues on their own and then self-heal. Maybe you can train them. But if we do have systems in place like land graph to give you that traceability to what the model is actually doing. And then temporal to give you that durable workflows and activities.

So anytime that your agent calls an external service or goes outside of your core system, you can be guaranteed that is going to like at least be durable. Should definitely make you sleep, you know, easier at night. With that with that in mind, again, Langrath makes it very easy to like debug your model. You can see exactly what it puts it out, what the outputs were, whether to call, why did it call something, why they didn't call something. Gives you a very nice paper trail to go back to debugging. And the nice thing is that you can basically, you know, put everything you see in this example here. Everything is in a Docker container. It's all Docker compose. It's all running down from Postgres to Express to temporal. It's all just there. You deploy all at once. He's like app runner or something like that. And you can just get this like ever-growing smart brain that you and your team are building over time. And I think you have used like observability tools like Langrath and Langsmith and temporal. You can get one step closer to having a more robust system.

So I want to thank you all for your time. So thank you so much for this great this great session. And I think we had a few questions coming in on the Slido. And don't forget, folks, the Slido is a great place to ask questions. So I believe. Yeah. Well, so one thing is sort of around the Netflix scale. Right. Not all of us have the same kinds of problems that Netflix engineering might have. And so one question Anonymous asks is how do you Landgraf and Temporal handle the Netflix scale of agent calls? How does the UX feel when you're trying to do that much? Yeah. So full disclaimer, like we're not using this in production. This is something I'm thinking about probably putting out there. I would say for like the main customer facing Netflix application, I think you definitely have to do a lot of like your typical performance engineering to make sure that you're handling requests properly. You're making sure that you're handling your timeout. You're not you're avoiding things like a thundering herd situation. You're not like blowing up your systems or other systems as well. So there's more things to think about. And Netflix is a lot of moving parts and also like it's higher stakes because of because the customers like where I sit within experimentation, we're building more of a platform. So it's probably like less of a concern in that regard in terms of how many requests that we're getting or how many I guess like how many tokens we're probably using. But if it were like for the main Netflix application would be a totally different approach that you would take to solve it from the way I'm probably proposing here is probably a little naive. Great, great, great. And I think we have a bunch of other questions coming in. But one, for example, is about your choice of using typescript instead of Python, which one often sees in the agent back end code. So the question is, why did I use typescript and not Python? Because this is not a Python conference, right? Didn't expect that one. I'm a Pythonista, but I also write a lot of JavaScript and Node and a little bit of Kotlin and Java. I'm more of a polyglot. But at work, I would do this stuff in Python. But however, because I'm a JavaScript, I've been writing Node for a while. I'm very passionate about about this space. And it's really cool and powerful that these tools are actually built for us JavaScript.

Right. So I wanted to really show that if you think that you're blocked from like going deep into this stuff because you don't do you don't write Python and you don't want to do Python or R, that these things are here in JavaScript. This is all JavaScript across the board. Right. There's no Python here at all. It's all Node. So you want to start building this architecture. You can build it today on the Node stack and there's nothing stopping you from doing it. Right. You heard it here first, folks. You can do it all with JavaScript.

So let's give it. I think that's it for our Q&A time. But there'll be more Q&A with Jamal up there afterwards. So, please, huge round of applause for Jamal. Thank you so much. Thank you. Thank you. Come talk to me. I'm happy to chat.