# Building Single-User vs Multi-User Agents: What Actually Changes ## Метаданные - **Канал:** Sam Witteveen - **YouTube:** https://www.youtube.com/watch?v=lLz_Kzy-tSw ## Содержание ### [0:00](https://www.youtube.com/watch?v=lLz_Kzy-tSw) Segment 1 (00:00 - 05:00) So, a common scenario I see is someone's just built a really cool agent demo and then they've shipped it and then suddenly they start finding out things like user 37 has broken it with an edge case that nobody anticipated and user 112 is already using it in a way that it's basically cost $90 just to run their tool calls. Then you find suddenly that once you've got past your thousandth user, they're accidentally seeing each other's memory. And the big difference here isn't about a single agent versus a multi- aent. It's about a single user system versus a multi-user system. This ends up being a totally different way of engineering. And in this video, I'm going to talk about single user agents versus multi-user agents. some of the key things that you need to take into account when you're designing and architecting these systems and some tips and experiences that you can actually take from different frameworks that are already out there. So let's start off with the definitions. A single user agent is basically an agent that is used for one primary user and this is basically something like open core. People have been spinning up Open Core instances like crazy over the past month or so. And yet for most of them, it's really just one user that is actually using this. And this kind of system has its challenges for sure, but they're very different than when you're designing for lots of users. So in a single user agent, you'll often find that things like state is really kind of intimate and personal. Can often just be a simple markdown file, right? You don't need to worry too much about the speed. The entire computer's resources are allocated to one person. You find out things like memory in this case can be deep and personal again because you're using markdown files for this kind of thing. And you can also get away with a lot of things of where you've got workflows that can be quite fragile. And this is often down to the environment that you're actually running it in. you're generally going to have some kind of controlled environment that is usually going to be on for you 24/7. So if we look at in how people are running open claw, they're generally either running it on their sort of local machine with a Mac mini or something like that or they're running it through a VPS where it is up 24/7 for that particular user. And the key things that these single user agents basically optimize for are things like depth of customization. They're things like personalization. They're all about you allowing it to have exactly how you want to have it without having to make any compromises. And often you will see in people's open clause systems, they're using two, three, four different models. They've got hundreds of skills going on in there. They've got their system doing lots of different API calls. And also if they're using some kind of system which is an all you can eat buffet from an LLM whether that's codeex or now it looks like claude code has banned all of that. But in that kind of system people generally don't really care about being efficient with token usage. Now even if you've got a single user agent system that doesn't mean it's just one agent. You might have multiple sort of backend agents that are doing things but they're all generally going to be used just by the one user. You can kind of think of this as like cooking for yourself at home, right? You tend to not be efficient about the process. You tend to take a lot of care, perhaps redo certain parts, and everything is optimized generally by the user for what it is that they want. Now, multi-user agent systems are actually quite different. These are basically made for many concurrent users. So, you can think of this as like a multi-tenant system that's going on here. When you're dealing with something like state now, you have to think about isolation and keeping each user's state secure and not contaminating the other users that are there. So very quickly, things like markdown files are just not that effective for this kind of thing. You've also got to now start looking at dealing with things like rate limits and cost controls and even things like load balancing of when you're going to have sort of peak periods with a lot more users than other times where you've only got a small number of users in there. Whereas the single user agent system optimizes for customization and depth, the multi-user agent system is optimizing much more for width, for concurrency, for guard rails, for protections. And where you might have your own personal agent where you don't really care too much about observing traces and auditing and things like that, observability and auditing are table stakes for multi-user agents. And so the analogy here is that a multi-user agent is kind of like running a restaurant kitchen where you're going to have lots of things going on at the same ### [5:00](https://www.youtube.com/watch?v=lLz_Kzy-tSw&t=300s) Segment 2 (05:00 - 10:00) time and it's not just about one dish at a time. So this distinction is really important to understand that it's not about one agent versus many agents. It's about one users's world versus a shared world where you've got isolation going on in there. Your agent core is kind of like the brain that most frameworks focus on. They're often going to have steps like planning and reasoning. You're going to have things like tool calling. some kind of memory system in there. skills, etc. And the agent harness you can kind of think of as being like the factory floor. This is what makes everything sort of survive real world users. This is the isolation. This is your authentication, your permissions. This is all about cost controls and quotas. This is about observability and tracing in here. And so you can think about single user projects as being coreheavy and light on harness and multi-user systems being much more about getting the harness right first. And then those cores can almost become a plugin that runs under that harness that you've got there. So what are some of the things that break when you go multi-user? Well, one of the most common is some kind of state collision. So this is where two sessions are sort of sharing some kind of memory key or you have some kind of catch that is leaking context from one user to another user. And this is very common in what we're sort of seeing lately of where people are trying to have systems that learn from one user and then take that learning and apply it to multiple users going forward. The danger there is that you have these caches that basically leak context in a way that sort of breaks privacy and can cause a whole bunch of different issues. Another issue that you see quite commonly is if you're allowing users to set up their own versions of sort of tool access and authentication, you have to be able to trace everything that goes on. see, okay, were the right authentications used for the right user in this kind of case and you have to deal with things like user consent and audit logs going through this. The other big issues that you face when you go multi-user is the whole sort of idea of a cost explosion. So single-user agent systems, people kind of tolerate inefficiency. They don't mind when something goes wrong. They know that maybe they didn't prompt it right that they weren't able to get the right skill to activate and stuff and they will basically keep going at it themselves. multi-user systems, you need to be aware of things like that and you need budgets and quotas to prevent things from going wrong. And also, you need to think about graceful degradation for when things go wrong. Another big factor that can go wrong very quickly with multi-user systems is things like latency. So, the average latency of using an LLM is not so bad when you're a single user and you're the only one making all the calls, but that can balloon out massively when you've suddenly now even got 20 or 30 users making calls at the same time. You need to look at things like cues. You need to implement retries and timeouts. You need to be able to have fallback systems. And then of course lastly, you've got all your safety and abuse stuff. With a single user agent that you're building yourself, you don't really need to worry too much about guard rails. You don't need to worry about that because you're building it for yourself. You don't need to worry about things like prompt injection. But with multi-user systems, suddenly prompt injection can become a really serious issue. And you've also got to be on top of things like tool misuse and how people are actually using your system. Every tool that you implement in a multi-user system sets up new security issues that you need to take into account. So while it's tempting to look at things like open claw and sort of think that okay agents are solved we've suddenly got all these agents that's just not how it's going to work when you're going to a multi-user system. And while the temptation is often to use just something like open claw or even something like clawed code if you've got a single user system, those are not going to scale if you're building a very specific kind of agent for multi-users. So in this video, I've focused on what the actual differences are between single user and multi-user agents, and I've highlighted some of the challenges that you're going to face. What I'm planning to do is over the next few weeks do a few different videos that cover some of the key aspects of building multi-user agents. And they include things like picking an agent framework or should you actually even use an agent framework at all, picking where you're going to actually serve your multi-user agents. And each of these things has really big consequences for whether your agents are going to scale or not scale. So hopefully this video has made it clear about what a ### [10:00](https://www.youtube.com/watch?v=lLz_Kzy-tSw&t=600s) Segment 3 (10:00 - 10:00) single user agent is, what a multi-user agent is, and going forward I can break down some of these patterns so that we can look at them in more detail. Anyway, I'd love to hear from you in the comments. Let me know what you're sort of finding. I think most of the videos on YouTube are really focused on people building things with clawed code or with open claw at the moment for agents where it's a single user system, but this is actually quite different than what I see with sort of corporate clients and stuff. So anyway, as always, let me know in the comments what you think, if there's anything specifically you want me to cover. Like I said, I'm going to do a video about different agent frameworks, breaking down what you should be looking for. I'll be giving a talk at Google's Cloud Next conference in April all about the patterns of successful agents. If you happen to be in Las Vegas, come along to that. But as always, if you found the video useful, please click like and subscribe and I will talk to you in the next video. Bye for now. --- *Источник: https://ekstraktznaniy.ru/video/22370*