Why Every Agent needs Open Source Cloud Sandboxes

29:54You actually need to do changes on your infrastructure to make sure you know about all this data that's happening and moving one way or another. But yeah, I completely agree with you. This problem, we are not the first one that are having it. Do you use one of the usage-based billing providers? Orb. We are talking with Orb right now. Orb in? Meter? Open Meter is another one, I think, or Meter. Yeah, metronome. Sorry, metronome. East meter is the other one. We have been using Stripe usage, which has been a little bit sometimes rougher around the edges. Yeah, this is the thing. We shouldn't spend so much engineering on it.

30:36I want to outsource it because that's not our product. Someone else should be focusing on this full time. And it's actually pretty non-trivial to make sure you have everything right and you really don't want to make mistakes here. Is there anything that you're really looking for that would say like, okay, that's really what we want, that maybe Orb or Metronome haven't really adjusted for AI yet? I don't think this is AI-specific problem. This is infrastructure as you know it. For us, some things that didn't work when we look at some of the providers where like the cut they took from the revenue, for example, they take from you.

31:12So some of the pricings, I don't know what's the latest, but like, I don't remember which one was it, honestly, but I knew that pricing was basically they take a small cut from the revenue each month, which is basically like what Stripe does when you are processing payments. It's just like the value was really high. And then it's a lot about how hard it would be to integrate it. Like how much time we are spending on it. Because we know we don't want to build this in-house. It's more like, is the switch worth it, basically? I'm curious your updated takes. I know you had the Y is in usage-based building a bigger category.

31:47I'm curious now with AI, with token-based pricing, if you have updated thoughts on... So for people who don't have context, at Netlify, we went from relatively flat tier-based pricing to usage-based billing because that's basically how all infrastructure companies should eventually go because you have some whales who use a lot of infrastructure and some who don't use that much and you shouldn't charge the same for both of them. The fun insight was that you would think that at an IS, past company that revenue is like the most important problem to work on and directly impacts the company's revenue and valuation and all that.

32:28No engineers wanted to do it. And I was like, why? Like we actually looked around for a long time. We tried to hire and then we couldn't hire. So we ended up putting one of our most senior engineers on it. And she took a year to ship the whole building projects that was presumably a board level objective, which was like, hey, let's change from this pricing plan to this pricing plan. How hard can that be? Turns out very hard because you have to instrument everything. Even the things that you're like, I don't know if we'll ever use this. Yeah. That's exactly what I meant. That's why storage is free.

33:02The first thing is like, you need to know about everything that's happening inside a cluster. How big are your logs? Yeah. It's crazy hard. The pricing is like actually the, not the figuring out the business model, but the integration of it and implementation is actually a lot of engineering. Yeah, soft limits, hard limits. Do you cut off people once they bust the limits? Probably not because they get pissed at you. And then they also get pissed at you if you don't cut them off because then you send them a big bill. So there's no winning. Yeah, exactly. Also, additional problem that people are asking us, I want to run the agent for five hours and you can do that.

33:38And you might be a very early startup. So our goal isn't to cash you out. our goal is like you can use as much of e2b as you can and just grow but the more longer you run the sandbox is the larger is going to be your bill so i think that's like it doesn't really needs to correlate with how much product market fit you have for example how much users you have because with these agents they can work for a long time even if you are like pretty early stage company yeah if you have few users so sure i mean yeah i think but there's still a question of soft limit, hard limit, that kind of stuff. So just to answer your question on billing, and for those who are interested, we actually had the CTO of Orb send in a talk for our remote track for the New York Summit on what he thinks pricing for agents looks like.

34:25And I think basically you are reselling tokens, right? The base layer is coming from either your open model cloud provider or your closed model lab API, and you resell them. And a lot of them, some people have a lot of markup on them, like certain unnamed AI builders. And some people have negative markup on them. Like they are basically selling you at a discount. You should buy as much as you want because they are using VC monies to subsidize your thing. And I think that seems fine. People often, Simon Willison often asks for like, bring your own key solution where like, you know, I will have my control over like my relationships and my pricing and my credits with my LLM providers.

35:03But I want to use your app. So I'll give you my keys and then you use the keys on behalf of me. that doesn't seem to be as popular as I think as I understand it. I don't know if you've had that request. It's sort of like in crypto use your own hardware wallet always going to be less popular than just going with the thing that's Yeah, so literally Alex from OpenRouter is the only person who's implemented this and it's fine for individual use cases because there's a lot of free tiers for individuals but yeah, I mean I think pricing wise people are trying to move that discussion on like, you know, are you positive margin on your tokens or are you negative margin on your tokens?

35:43And there's some economic reality there, but they're trying to move that to the agent work, which is what is the value of the human labor you're replacing, which is a whole different thing, right? So like, instead of comparing on cost of goods sold, you're comparing on value delivered, and that is much higher. Yeah, I feel like if we could get to a good market on like bid ask of like work being done, and then you can kind of arbitrage how many tokens you need. But I think today the agents are so unreliable and unpredictable that it's hard to price ahead of time because you could price any software engineering task per task.

36:18It's like do a new bun, it's like$500 and then I can arbitrage that. But today there's no certainty of that. And I'm curious. Yeah, you would think like, also this is why I was very excited about Replit when they first launched their marketplace credit thing. I'm not, if Replit can't do it and I don't know if anyone can. Right. The other technical thing we talked about before is forking. You also mentioned it before, and sandbox checkpoints and things like that. Is it something you have today? And then what are people using that for? Like our example was the Cloud Plays Pokemon hackathon. Are there more enterprise use cases where you see people request forking and checkpoints?

36:56Yeah, we don't have this publicly now yet, but that's something we are working on to release somewhat soon. we have persistence which is like the prerequisite to call it. You mount a volume. Yeah, well mount a volume but also memory persistence which is very interesting. So you basically can pause the whole sandbox even when all the code is, you know, with all the context of the code execution and resume to it resume it later and come back to it I don't know, like two weeks later and it's still going to be there. But the continuous session time is limited to 24 hours, right? No, it's limited in the beta in 30 days.

37:34Okay. Do you mean, are you asking? I don't know, I was looking at your pricing pages. Are you asking about like when the sandbox is running? The sandbox can run up to 24 hours, but when it's paused, it can be paused for like a month. I personally think this is like one of the cases where you kind of need to show the developers why it's useful. And this is something I think is going to be very useful as the agents are getting better and LMs are getting better because you will be able to paralyze problem solving essentially. So you will, instead of having a single agent doing one thing, you might have multiple agents trying different paths.

38:09And if you imagine like a tree or a graph, every node is like a snapshot sandbox, like a checkpoint sandbox. And then from that node, you fork the sandbox and go to the next state. Eventually you find the right path, right? It's kind of like a, it's a tree search. So the forking and checkpointing solves the local state problem. It doesn't solve the remote state because that's something you can't really control, but it solves a local state for the agent and can then come back to a state and you don't need to replay the whole session or trying to force the LLM to do the same thing again. You have the chat history and you have even all the steps inside the second box that went to it.

38:55Do you feel like you want to help with the forking and then the re-merging? Because I think people understand the forking, but then it's like, okay, how do I monitor which of the leaves is successful? And then how do I merge that back into thing? Do you think that's something that you want to help people do, like kind of spread out, parallelize, and then find the winner? Or is that something people should do on their own? I think this is sort of like a framework discussion on top of E2B. So this is, we are looking at it. I think eventually we should go higher level and I don't know if framework is the right type of a thing.

39:34We like to in the team think about it as a toolkit. Instead of building opinionated framework how to build agents we give you a wrapper around the E2B that makes it really easy for the LMs to for example merge these states or navigate these three. So I think it will eventually move there. I think it's a good question to ask how it's going to look like. I still think like building a framework is very hard in the AI as things are moving very fast. Curious about frameworks. Do you see any rise in popular frameworks that we should be keeping tabs on? I don't know if this is an unpopular opinion, but people keep telling me LinkedIn isn't popular, but if you look at its stats, it has 20 million downloads per month.

40:21How can you have not popular framework when it has 20 million downloads? And it's growing, I think. I think there's a slight bubble. I don't know if it's like people in SF, but developers thinking blockchain isn't popular or used. There's one framework that's interesting. I think it's called Mastra from one of the founders of... Sam Bhagwat, yeah. He's in the Discord. Yeah, yeah, yeah. So that I like, which looks very promising. I also like it's like TypeScript first, which I thought is the right decision because as we talked about, like being more bullish on the product developers instead of like a Python machine learning type of a developer.

41:04I've seen a lot of more like a toolkits or I don't know how to call them. Like for example, Composio has been one that like gives you all the tools at once. There's been more tools like that, which is interesting approach. I think also browser-based stagehand is super exciting because in my head, it's not a framework it's like it doesn't necessarily like dictate how the agent should behave it just gives it the good tools to navigate a website and it's very elegant like it has I think they added like three methods by act see and something yeah there's three APIs yeah observe yeah observe we talked about it in that episode no it's cool actually I wasn't expecting that many names to come out but these are good names for people to know I would agree with most of them as they're in the conversation of tooling.

41:54A lot of people listen to us for like, oh, what's going on in SF, right? Yeah. Actually, it's a good question because when you ask it, I would expect to be a bigger framework boom nowadays because it would make more sense to build a framework now instead of 23 because things are a little bit more stable. The problem with frameworks is that the idea of frameworks should probably be that things aren't changing underneath your hands, which if you launch your framework in 23, it was. So that's not a fun thing to be at as a developer who's using the framework. I think things are still changing. I mean, things are 100 % still changing, but slightly, I would say like some things are clearer than N23.

42:35I don't think people realize, but like, I'll just say it out here, like chat confessions is dying. So like any framework that was built in that era with like no conception of real time, no conception of omnimodal or multimodal native things, they will probably not age very well. Yeah. Yeah, probably as we, like, what's the next after chat-based interaction with LM? You need chat completions and you also need reasoning with streaming. And the streaming interactions of agents is also not mapped out very well. But, like, all agent frameworks will have to adjust to that, basically. Good question to ask when thinking all about dev tools with LM.

43:13Is my dev tool more relevant as the LMs are getting smarter? And as people need less prompting? I'm, for example, like, really bad at prompting. but like I can get more work done over the years because the elements are getting better so that means like there's less need for prompt management type of thing yeah the talk from RAMP at our New York conference was basically about this like how do you set up your architecture so that you benefit from 10 ,000x improvements in models rather than every time you you know model improves you have to kind of throw out your existing workflows yeah the question we ask very often when thinking about the features and how to position ourselves in the ecosystem, essentially.

43:56We've gone 51 minutes without talking about MCPs, which is tragic. Yeah, how do you do that? You talk about AI infrastructure and no MCP. Right? It's kind of crazy. But since you mentioned the prompts, we just had the episode with the MCP creators and they were, I wouldn't say not frustrated, but maybe they hope more people will use the prompts and resources in MCP servers instead of just the tool costs. I'm curious if you've seen any fun use cases with remote MCPs on E2B or any other things like that. Yeah, MCPs, watching it very closely, but still undecided. Not what it is, but what to do with it.

44:36There's no MCP on your docs, bro. If you go to GitHub, we have an MCP server. Okay. But we've seen people using E2B to host MCPs. but then I would say I don't think you need E2B for that you can just probably you can run it it's not even optimized for it probably there are probably better ways to do that I think people are a little bit too much focused on the protocol side of it even calling it a protocol, I don't know it's just like a server server and client and there's some agreed so I guess in a sense it is protocol, but I see a lot of people comparing to email protocols and such, which seems a little bit far-stretched to me at this current moment.

45:29But maybe I'm missing something. I think it's a super interesting idea. I just haven't had the right insight about it yet. One last thing I wanted to add, because we have a bunch of users that added E2B, our MCP server, to their registries. So I think, at least at the moment, And what's more useful is higher order MCPs. I was talking with Henry from Smithery about it, that you know. And he was telling me exactly this concept. It's unclear who's using the MCP at the moment. Is it a developer? Is it an end user? Or is it another agent? If it's a developer, then it might make sense to have a sandbox, creation of sandbox in the MCP.

46:13If it's an end user, probably it's too low-level primitive, so you want some kind of higher-order MCP. Instead of us offering a sandbox, we would be offering a way to build a co-gen agent with MCP or something like that. Or run a co-gen agent that's using E2B MCP in the background. So I have more these type of unanswered questions in my head about MCPs. I mean, they are all running locally right now, mostly. I don't think there's many remote MCP servers yet. I know that people are pushing for it. It looks like there's more remotely, actually. I don't know. This is what I heard from people managing these registries of MCPs.

46:55Well, they're incentivized to tell you that. Yeah. I fully agree with that confusion about what to do. I do think that every DevTools company needs some kind of MCP strategy, for better or worse, as annoying as it is. I think it does start with having an API though, rather than like a SDK first experience, because then people can just wrap in whatever language that they want. And then you also, for you particularly, you might want to have a distinction in your strategy for MCP clients versus MCP servers, because those might be different things. And particularly, I like what you said about the higher order MCP for the end user who doesn't really care about implementation detail.

47:38I think that is fantastic for E2B, where the agents can just spin up an E2B instance in the background and they don't even know about it. Yeah. In the world, we have like mcp.e2b.dev. First, it needs to have figure out authentication. So the agent should just ask to have, I guess, account created for it, whatever it is, it's going to be. And then it can just like launch a sandbox, do the execution there, and you can come back to it a month later and the state is still there. So that I think makes a ton of sense. Then you can start building higher order things on top of that, which could be very interesting.

48:17I like what you said about having API first versus SDK first approach. I think this is very, very important for the LLMs. And that's how we are building our whole new dashboard, the infrastructure. So everything needs to be API controllable from public APIs for users because eventually the LLMs will want to control and get this data. Okay, so that's a big shift for you to be because you're SDK first. It has been underneath API base all the time, but now we will go more into it. And it was more like in terms of prioritization. So we needed to start with humans to get to LLMs and first build for human developer and then now building for like a LLM developer first.

49:02Yeah. I'll just call out that since we did the MCP episode, they announced their update to the spec that they added an off component to the spec itself. It seems to be just based on OAuth 2.1. And I assume that's the first easiest thing to do, but there's no effective distinction between an agent and an user. So we never had that. I think this touches more like a broader question of you have all the websites that has optimized everything for humans, but now you will have like agents visiting those websites like what are the incentives there you know like probably you as a website owner you want to know it's an agent because you spend so much time and money optimizing everything for humans so i think like the the dynamics in on the internet get might get really weird if you don't have a distinction this is a human this is agent yeah we we tried to record an episode with matthew prince ceo of club player yesterday and then we technical difficulties, but they're building a lot of that.

49:58You can see the stats. They mentioned, for example, used to be Google would be a 2-to-1 crawl to referral ratio. So for every two pages, they would read, they would send you one visitor. He said OpenAI is 250-to-1. So they'll read 250 of your pages and send you one person. And Anthropic was like 6 ,000 to one. So they'll read 6 ,000 pages before they send one person back to your website. So obviously we have Jeremy Howard who's been working on llm.txt to kind of have a separate interface. for that i think today people don't really curate the llm experience uh i think a lot of the llm txt that people are making is like automate it take a website and turn it into llm.txt but like that's not really what you want to do it's like how do you separate completely the two things you know like if you're e-commerce store the llm txt should have your own inventory and like one thing you know shouldn't have a search button i feel like obviously llm.txt is a good movement that improve the legibility of these doc sites for LLMs.

51:00But I feel like it's kind of like a halfway measure. Like, I think we've failed with agents if we are reshaping the human environment for agents. Like, there must be two of everything. What's your human side and what's your agent side? Like, no, like, agents should just be the human side. Like, why are we making any special dispensation for these things? Yeah, I think the monetization is the only thing. Like, too many websites are, like, ads-driven, kind of like... You need to look at it, right? Yeah, I think you need to change. Once we figure that out, I think you can use the same interface. But I think today, all these pop-ups, it's like, fuck man, stop popping.

51:32Bitcoin solves this. Yeah. I'm just kidding. But anyway, yeah. I don't know if you have a take on all this. I have a general rule that usually when something new comes out, people have this tendency to recreate the thing that already exists for the new thing. That's like the internet for agents versus you already have all the infrastructure for the old thing and probably might be easier to teach the new thing to use the old thing. I think it's very common coming from developers that it will be a perfect world when you have nice clear distinction between these two, but actually the world is super messy.

52:09So nothing comes to my mind that they will like end up that you have clear distinction between like two type of sort of entities or we created like a new internet for just mobile phones. you actually have both desktop website version and mobile phone version, right? It's much more always complicated and messy in the real world than having a nice clear distinction, which is something I think developers strive for just from working with code because you want this nice clear distinction, but humans are more complicated than that. So I think everything ends up being sort of mixed and you need to adapt to it.

52:47For sure. Yeah, I think we'll do this for 20 years and then we'll figure out the... Yeah, and probably it will be somewhere in between that you have like a world where agents are using human internet, but the internet changed because you have agents or something like that. This reminds me of some conversation that I think, I don't know who was making this analogy. Like in the mobile era, we had m.yourdomain.com and then we had www.yourdomain.com and now we might have like just lm.yourdomain.com and that's just the LLM experience. MCP. Oh yeah, way better, way better. Yeah, yeah. Consumes everything.

53:21Cool. We're just going to go through all the rest of the use cases. We can refer people to your website, but I'm very just, I always want people to have a good mental map of how, when they should go to E2B and like, or what other people are using E2B so that they don't miss out, right? So it's AI data analysis, data visualization, coding agents, generative UI, code gen evals, and computer use. Do you think that's like the sequence of most popular is data analysis, least popular is computer use? Most experimental is computer use. it still gets a lot of traction when you share the demos of it it's just Manus?

53:56Who else is doing this? I basically don't see anyone else when you see computer use, I imagine a graphical interface Manus, as far as I know isn't running that so, what do you also call it computer use, but without graphical interface because you are using the full computer but more from a code point of view but that's a different discussion I would say computer use is very exciting, but experimental from what I've seen. I think for real computer use, you really want to support more platforms than just Linux. Yeah, Windows, right? And then it might be more licensing battle than technical battle.

54:37Yeah, lawyers always win. We'll probably have Eric from Pig at some point talk about his movements on Windows. So that was going to go into evals. right? And also how that links to RFT. Yeah, just like, can you tell more stories about the OpenR1 projects, how you work with them, and any other academics that are working with E2B that you think could be possible for the research or model training use case, or fine training use case? Yeah, the way HuggingFace who built the OpenR1 project is using us is during the reinforcement learning, reinforcement learning step, where the R1 model, the open R1 model, has a training step where they give it a code problem and the model needs to generate and run code somewhere.

55:28Then you have reward function basically giving you zero or one, telling you if that was a good solution or bad solution, then you improve the model. So kind of like the feedback loop. They are using the E2B sandboxes to run many hundreds of these sandboxes, thousands of sandboxes per training step. So they can achieve like big parallelization. We started very fast. You don't need to use your GPU cluster for that, which is like very expensive to use for this type of workloads. And also, and that goes with the story that I mentioned in the beginning, is that you don't need to worry about like LLM actually like changing permissions in your cluster and then you can't access the cluster because everything is isolated and the secure from each other.

56:13So I think that's a very, very interesting use case because we've had a few other companies like reaching out and started using us this way, building models, foundation models. It's like when we started E2B, that wasn't the use case that we had in mind. But it's like makes total sense. If you, also if you think about like life cycle of an AI agent, like if you, it makes a lot of sense for us to be like from the earliest stage possible. And the earliest stage is probably model training. So this fits very, very, very nicely in that use case. We actually released a case study with Hugging Face that's on our website that people can read.

56:53Have you seen people also use that to evaluate agents they want to use, or is it mostly people doing training? We've seen people using E2B for evals. Yeah, that's what I'm thinking. It should be very easy to run Sweetbench and all these on E2B. Yeah, this is more foreshadowing, but we will be launching in the next couple of months a startup and research program for people and universities and researchers doing exactly these type of things. A different use case, but we, for example, work with LM Arena folks from Berkeley that are using us to compare models in AI app generation and we run the AI-generated app.

57:31He wrote that in the equation, right? Yes. I think that's only possible thanks to Alessio and I'm not joking because first he connected it and then he actually wrote it. Man, the things you have to do to win deals these days. He was already our investor. So I think that also shows it even in a better light because you clearly see a person who's not interested just to win the deal, but actually you know. To increase the value of the investment. How many VCs are actually fixing your buck in your code base? Let's make a YouTube short of this part so I can share it. You should put it on our landing page.

58:09Yeah, exactly. Awesome, man. So let's talk about, since you mentioned VCs, a lot of VCs that passed on you before because you only do code execution. It's kind of like a small market. I would love for you to maybe also paint the picture. So you just mentioned it's cheaper than the GPU cluster than Hugging Face has. Do you want to do GPUs in the future? You mentioned Railway. That was easy to do. Do you want to compete with Railway down the line? Where do you see E2B going? So GPU questions is an interesting one. GPU market is hard. You are competing on the compute internal, I think it's hard. Because eventually you will have competitors and everyone will be pricing it a little lower and no one is making any margin.

58:52So that's like, but it just opens new use cases for you. And for example, even with the data analysis, if you just run, I think it's Pandas code, there's a recent update. if you just run it on GPU it's like twice as much faster if we want to like do really big AI data analysis you need that so I think like GPUs for us and also if you want to like have LLM trained small machine learning models maybe you want to like build full games you really want to offer the full cloud computer but in cloud that's very elastic so I think GPUs are there on the roadmap I wouldn't say it's like the thing that we are immediately working on.

59:36But eventually it makes a lot of sense for us to offer this. And so what was the other question? On the, do you want to host the apps that you are building to? We are very well positioned that the LLM is doing all the development work with us. Then you need to deploy it somewhere. So it's like very natural next step. Eventually, we want the LLMs to deploy these services, apps that they are building and have them manage it. And developer is more like in the backseat, like looking at things if everything is working correctly. If your swarm of agents are working correctly. It also requires a slightly different infrastructure for deploying.

1:00:18But I think there's a big advantage in knowing what developers are building on your platform. And then, because then you can see like what's the ideal, even from technical point of view, you have all the insights that you need to actually effectively deploy it and kind of then cover the full life cycle of building the app. But now it's not built by the human developer, it's built by the AI. So TLDR, yes, probably down the road somewhere. We want to build essentially the new AWS, but for LLMs. So we're just going to move out and just to wrap up. One of the interesting things that I saw you do was you were originally check-based and I'll be very blunt when I first invested in the early round that you did I was like these guys know how to recruit in Czech Republic it's like a competitive advantage and then the next thing I know you're moving to SF your whole team you should show off to our office, that's hilarious actually I think you offered even your place to live for so why move to SF?

1:01:25Do you think that everybody in your similar situation should? Any pros and cons that you're experiencing? I think you can definitely build a DevTool company from Europe. I think it's a lot about question of how easy you want it to be in the earlier days. Especially if you're building like red ocean versus blue ocean waters. if you are building in a field that already exists and you have large competitors you are building something that's 10 times, 100 times better you probably don't need to be NSF eventually you probably will need some kind of US base because for sales and customers but you can very well build this from Europe I know great companies doing that because the knowledge is already among all the developers But I would maybe argue that it might be harder to find people that are comfortable with a fast iteration loop and changing things early on.

1:02:27You know, almost we are pivoting every week, every month. But the main motivation for us was we just wanted to be very close to our users. And it was clear after a few weeks that SF is becoming this AI hub. and what we used to do and we still do it sometimes but slightly less because of like not having that much time and resources but we just met with the customers that had problems and we just like implemented it to be for them like next to them like we made a PR. I call this the Collison installation. By the way I don't know if this is a known thing but do you know how many times they did that?

1:03:10200? Twice? Three times? Oh, long. I asked about like three years ago when I had a chance to ask a question from Patrick. Like how many times you did the installation? And he was like three times, but then after that, you probably don't want to do that because you want to automate things and focus on other stuff. But it's exactly like do the things that don't scale. Three times. Exactly three.

1:03:40but my whole point was that how many such users i can meet in prague in a week versus in san francisco in a week in prague it's gonna be probably one and then i can't meet anyone else for the next half of a year uh because i just don't have users in prague but all of my users our users were here so we could just keep repeating doing that again again i would even argue we did it too much we could have automated slightly faster, but it's very useful feedback that you can get. And you can then start moving much, much, much faster. So that was important. And I think also, eventually you are in the B2B business, even from the early days, and it's good to have good relationship with people.

1:04:26And just like meeting in person is just better than meeting over Zoom. Well, I mean, that's why we do this in person. But yeah, I mean, obviously I run a conference. I'm very sympathetic to people meeting in person, right? But I also want there to be some hope for people who are never going to come to SF that they can still get involved. That's partially why we do this podcast is to get them involved in the community. And I mean, we started a new office in Prague. Yes, you're hiring again in Prague. Yeah, and I think that there's really good talent in Europe, in Czech Republic, for example. I don't know, I can't speak for other countries, but I can imagine it's very similar.

1:05:04Once you have a clear idea of what your product looks like, then you can find a really good expert on a certain part of your infrastructure, on a database, and things like that, and just get top talent for that. The reason we didn't want to do it early on was because we kind of didn't know ourselves what we were building, and we had to figure it out in person with users here. But now we feel much more strong about knowing the roadmap for the company and for the product. And so it's much easier to hire people that have 8-hour difference from us and explain them what they are building. Even remotely, sometimes, if you are not there and you're just communicating through Slack.

1:05:49Just to wrap, what are the roles that you're hiring for? So we are hiring distributed systems engineers. We are hiring platform engineers, AI engineers. We are also hiring account manager and customer success engineer. So kind of all over the place, we see a lot of market pool and momentum being built up. So we want to double down and move even faster because we see all the potential of what we can do. And just want to kind of like you want to pour the gas on the fire on the spark. and that's how I feel where we are now at G2B. Awesome, man. Thank you so much for coming on. Yeah, thank you for having me.

1:06:28It's great.