Cloud-Hosted, Multi-Agent Workspaces (or: Gas Town in the Sky)

Speaker 0: Testing. Alright. Alright. Great. Well, thank you all for letting me do this quick demo. Speaker 0: I'm going to be showing you this, multi agent workspace platform that I've been building called Shinzo. The idea is that, Cloud Code and OpenClaw solutions are great when you want to work on, coding tasks locally with your agents. When you want to run them without the terminal, remotely, with their own file system, there isn't really a great infrastructure solution for that yet. And so today, I'm going to show you how I've been building this multi agent workspace solution so that you can run agents, in a collaborative workspace and share messages with each other, files, tools, etcetera. So the first thing I'm going to do is actually so I have a a command that, I'm gonna run through my local cloud code instance to, contact my other my executive assistant agent to, encourage them to have a conversation with 2 other agents and then report back to me via my, Discord channel that I've connected to my executive assistant. Speaker 0: And so this is sending the request to the platform through a local MCP server that I have set up. And on the executive assistant page, we can go to the messages. And right here, you can actually see the live messages that the agent is sending, to the others. And so right here it says, hey, EA. Austin here. Speaker 0: I have a task for you. And so that is a message that the executive assistant is going to receive. You can see the session in progress, right here. So we have some, you know, completions for the agents for handling that response. And if you go back to the message page here, in a second, you should probably be able to see that the EA will send some requests to the other agents, so that they can actually have that interaction. Speaker 0: Now in addition to the messages here while I'm letting that run, we also have support for accessing, file systems, which are unique and containerized for every single agent. So every agent has its own memory file. It's your ability to add skills to it, other files and folders Speaker 1: and and Speaker 0: coding projects. You can also add, schedules and triggers if you want to have messages that run the agent on workflow automatically. And then beyond that, you also have, integrations for MCP servers. So if you want to connect your agents to other tools, you could do so that way so you don't have to keep the credentials on the same instance as the agents. So all of this together just to say that, these are all different features that attempt to solve for the problems that I've seen with people trying to build multi agent systems. Speaker 0: So that includes things like, again, isolation from, credentials to make sure agents only have access to to tools you want, being able to run them remotely without having to keep your terminal open, being able to receive messages through messaging apps that you use with your other coworkers, and all of these other configuration features that make it as easy as possible to deploy and run agents and and see exactly how they're operating with each other. And let's see how those messages went. Oh, it looks like it didn't actually go through. So I'll have to follow-up later on that. But in general, you can see some of my, prior agent conversations that I've had between agents. Speaker 0: So for example, my head of engineering has had some previous discussions with head of QA to handle different issues, for recent PRs. They've also had interactions with head of infrastructure to help deploy it. And so for my own for my own, development, I've been using these agents every day to essentially rip through different features and PRs and be able to build up the platform itself. Great. Speaker 1: Thanks, Austin. So dive deep. Hard questions. You know, bring it out of Austin. This is a really interesting platform. Speaker 1: Who's got a question? Go on down there. Speaker 0: How much would you pay this head of engineering? So I mean, well, we can talk about the the inference count. So, I have spent, well, let's see what the tokens look like. So I have put about, 3.6 mil or 3,600,000,000, tokens into this, across different models. Asana 4.5 is the most popular. Speaker 0: Asana 4.6. In general, like, the output I'm getting from these I feel is, you know, it's not quite there yet, but it's almost equivalent to an actual employee that has the ability to store context and preserve its own memories, be able to, you know, respond with you respond with, previous session information and keep that kind of short term and long term memory at the same time. But of course there are always going to be further improvements before we get to the place where we can actually replace people with real agents. Speaker 1: How how does the memory work? How does the memory work? Speaker 0: Yes. So, each agent runs on a continuous long running session. And so whenever you send messages to it, it will tap those onto the existing session. When it reaches the, compaction limit for a session, it'll do the typical summary and then compact down. And then the first thing that I have my agents do as part of their, post compaction work is actually reread a memory file to get the, recent context that may have been missed from the summary compaction. Speaker 0: And that kind of helps the agent kind of refresh its own memory, and this is a memory file that it can also update so that it keeps its own, kind of long term, facts in check. Speaker 1: So, have you are you just deploying straight out of, like are you reviewing anything manually here, or does your head of engineering just push to prod as So No. No. Speaker 0: Is ready to go? Yeah, so I do review all the code, and typically I'll have several rounds of feedback for my agents. Let's see if I can Speaker 1: Yeah, here is a view that's running on GitHub, or is it using a different 1? Speaker 0: So, I don't have any reviewing agents right now. I would love to look at having some some automatic reviews done. Right now, all of the, features that I have, I just review myself and have several rounds of feedback for each. For example, this 1, you know, the agent will produce the initial 1. I'll review it, add some notes, and then I just tell the agent on Discord. Speaker 0: I just link them to the PR and say, hey. I've got these updates. Please provide feedback and and update it yourself. And then after that, ask head of QA to review it. And then when it's all done, have head of infra deploy to staging for testing. Speaker 1: Okay. Cool. Any other questions? Yes. We have another 1. Speaker 2: Hi. I've seen a lot of such, multi agent systems, but they look pretty cool, but then they take much more time and they just throw, like, a lot of fluff and, you know, not really accurate outward. What's the performance difference you see from a single agent Carsten? Was it multi agent? Is it actually better or it just looks cool? Speaker 0: Yeah. So I mean, there's the the looks cool part is something that I'm trying to push away from this platform. I want this to be functional and useful. Only use multi agents when it makes sense to use several agents. And so that's why for my own agents, I actually have these had specifically determined by me because I felt like each of these business units made sense to have its own, functional agents with its own context. Speaker 0: And so 1 of the advantages of this is that each agent has its own unique context, that you can see based on the memories that it keeps. And so let's see if I can pull 1 of these up. For head of engineering, for example, the main memories that it keeps in place are things like, procedures, code base, reports, and repos. And then for each of those, it has its own sets of, you know, instructions and guidelines all related to developing code. But then when you go to a different agent, for example, my, we'll go to head of UX, The actual memories that it keeps, are very different from that. Speaker 0: Let me see if I have any others here. Yeah. So executive assistant, we can pull this 1 off. So executive assistant, is very, you know, high level focused. What's the set of teams like? Speaker 0: What are the messaging, protocols? What is the general structure of my workspace? What are some general workspace management rules? And so I found that it's helpful to separate and compartmentalize all of the context of the business into these functional units the same way that you would with people instead of agents. Speaker 1: That's great. Thanks, Austin. Let's give a round of applause. Thanks. We've seen lots of orchestrators actually go down the path of having very specific agent profiles.