How I Run My Company with a Fleet of 30 AI Agents

0:00the agents that we're going to be going through today. Every tile over here is a stateful autonomous agent that runs from the repository and that works in its own sandbox. And all of these agents are collaborating with each other when they're solving kind of long-tail tasks and the projects. Essentially, the system is designed around the fact that every agent has its own responsibility area, its own accountabilities that are

0:23clearly defined. And it is stateful. [music]

0:34All right, let's build. Thank you everyone for joining today. And today we're going to be talking about an interesting topic. I want to open up a little bit of a door into how we do things in terms of running our own company with the help of the multi-agent system and the actual production and talk through mainly the principles and the ways that I am setting it up to make sure that those agents actually doing productive work, that they're making less errors, fewer errors, and actually, you know, doing something productive and

1:04useful. So, what I want to start with today, and we usually do that every workshop, is a bit of a refresher for what Trinity is as a system, as a harness. [clears throat] I will just honestly quickly go through our landing page for that because it's one of the probably best places to explain that as it's sort of animated. So, Trinity as it stands is the runtime for production agents. It's essentially a sovereign system, sovereign meaning that you can put it within your own environment and protect it with the walls of the VPN system so that nobody from the outside can access that and so that you can own your actual

1:43agents. And it allows to host and run a lot of those different agents. Mostly they are closed code based, but we also in Trinity we support Gemini CLI and Codex. And the now we're actually working on more of the open source harnesses as well to add over there. Now the system is open source. There is an enterprise version of the system as well with some more functionality necessary for compliance, but you can go

2:09to GitHub and get the system. Now as I said it is running inside your perimeter, so all of these agents that I will be showing you and that you will you are running yourself are not visible from the outside unless you want them to and that's one of the core premises I think that this type of systems should be owned by by the companies and by the

2:27people who are working on them. And it's quite easy to get started with that because essentially it deploys and runs in sort of autonomous mode agents that are created in your regular cloud code type of tools and code X and Gemini CLI just gives them the runtime and gives them a way Well, actually let's scroll down and see what it what it actually does cuz I'm

2:50running ahead of myself a little bit. Now every agent has its own sandbox essentially its own computer that it can use depending on what it really needs to do. And every agent over here is a GitHub repository and that means that they're version controlled and we can always roll back to any particular point of every agent and that's the way they run and orchestrate within the Trinity being in its own individual separate the sandbox and within its own GitHub

3:17repository. Now they work as a team and that aspect is what we're going to be talking about today at length and essentially you know they're capable of exchanging messages, but in the controlled fashion meaning that there's permission layers layers several layers of permissions where you as the creator of the agentic system can define which agents can talk to which other agents and what is exposed to them

3:39etc. etc. Then all of those agentic systems or most of those agentic systems they run Cornelius which is the original sort of design of the second brain approach that that is the agent on top of the knowledge base that owns your unique perspectives, whether yours or your company, and can be used by other agents or by yourself in order to extract real nuggets of unique ideas and approaches from places you didn't expect. We'll go back to Cornelius. If you haven't seen it before or don't know how that works, essentially it's a brain behind a lot of the operations and it's persistent and it's improving over time as it's gets

4:19more knowledge from how it operates and how agents operate in the world. Now, you can control and that's actually one of the approaches that I use. I could have full control over my agents even from my local cloud code since the system is exposing massive MCP servers and you can run a copy of your exact agent on your local cloud code, for example, and then when you made some changes into that, deploy that to Trinity as a

4:43production. And everything you do over here is actually designed and built around the concept of how this built in enterprise software. So, you have all the guardrails, all the permissions layers, all the controls over users as well as over agents on what they can and cannot do. And everything is tracked in the audit trail and this audit trail cannot be edited. It's tamper-proof by design, which is quite important so you can recover what has been happening with

5:12your agents, what they've been doing. It runs on schedules. It supports other primitive in the system that are related to looping and finding out of different tasks and other primitives that agents are typically using this type of harnesses. That is also supported. Every agent can be shared in Slack, in Telegram, in Microsoft Teams, and through web links, etc. And collaborate with your users, your clients, or your team. Today, I will show you how that works in case of collaborating with the team

5:43specifically. [clears throat] Some teams are using that for just their internal automation. Other teams are using to deliver those agents to their clients and serve these agents through the web, through one of those channels. Right. So, we've gone through a quick overview and here is how the actual Trinity system looks like. This is the fleet of the agents that

6:08we're going to be going through today. And I will do my best to explain how that is set up and what are the principles used here. A very quick overview before we dive into more conceptual work. So, as as mentioned before, every tile over here is a stateful autonomous agent that runs from the repository and that works in its own sandbox. And all of these agents are collaborating with each other when they're solving kind of long-tail tasks and projects. And that's I guess the idea because essentially the system is designed around the fact that every agent has its own responsibility area, its own accountabilities that are

6:45clearly defined. And it is stateful. It's not ephemeral, as in it doesn't show up and then disappear. It has state, it has experience and if designed correctly, then over time it gets better and smarter in the things that it does. I promised to you to very quickly touch on the Cornelius, which is this agent,

7:05second brain. And essentially, this is the brain behind the operation of all of those agents. It consists of thousands and thousands of interconnected thoughts, ideas, and insights about the world, about decision-making, risk management, and of course about our business, our market. And that all is happening automatically, as in there is a process in which this agent consumes the information, new information, interprets this information, stores this information in this sort of

7:33interconnected map of things and ideas. And then there's a special retrieval approach that is a combination of the regular rug, rough rug, and a few other approaches that are quite interesting, but they're technical, so I'm not going to go into all of the details. If you are curious, Ernelious as an architecture is also open source, and it's available on GitHub over here, so you can just go ahead and check it out. But now I want to [clears throat] switch to a little presentation and we'll be back in Trinity, of course, but first concepts. So, it's a kind of an easy thing to make to make agents work when there's only one

8:15agent or, you know, they're disconnected. It's easy. The other thing is when you have a fleet of these agents and you need to make them work together, and that's exactly what this little presentation is about to explain how I'm thinking about that and how I'm setting that up. So, the first thing I introduced you may have already noticed is a hierarchy in the relationships of those agents. Every agent has an a one responsibility, and I usually it has one owner in terms of the person in in the team who owns this agent and develops it, and this owner is usually the owner of the department that

8:49this agent is working in. And it is based on certain shared foundations such as the canon, which is like a shared source of truth for the agents, a library of skills that these agents are sharing, and the ledger that tracks what happens with those agents, what they do, how they operate. That's just like a kind of a kind of base picture. There's more to that, but I think it's important to at least get that part across as a message. So, the way I'm designing this type of systems is that yes, I have an orchestrator, and this is usually the point of entry for myself. And if we go

9:26back to the system for a second, this chief of staff agent over here is the orchestrator and the main project manager. And actually, essentially, this is the only agent that I work with one-to-one in most of the cases. Because in the way it is designed, it is aware and familiar with every other agent that reports to it. And their [clears throat] capabilities, their teams, their assets, and their systems and stuff like that. So that it can effectively operate with those agents and give them the tasks. And by the way, just finance manager just launched to do something as you can see it's blinking active. I don't know what

10:04it is. Could be a schedule, could be a command from our chief of staff. I don't know. And yeah, so it is important to give, you know, these agents shared layers and shared tools. So I want to dive dive into that. But before we do that, one more principle. It's a convention. It's kind of naming convention that works

10:22quite well for us over here. So as you can see in the system, we can name this agent as we like. We can rename it to whatever. But they all have these little slugs on how they called. Usually it matches the name of this agent repository. So this one is Corbin internal, this is Tom marketing ops, and this is our marketing agent that is managing what is that? Like nine other agents. And what I wanted to talk to you about the naming and the slugs used over here is this. I basically made this little convention that every material that belongs to this agent or every endpoint

10:59has the same sort of slug. And it is reusable across the board. So as you can see there is a channel Tom marketing operations. The name of the channel matches exactly this this slug over here Tom marketing ops. And within that, I can tag this agent. Can you say something kind? And yeah, as you can see the agent

11:22picked up and started working on that. And now it's going to be back to me with some message. And we can actually see this working right here. This is the execution that is currently in progress for this agent. And it responded in a thread, so, you know, giving us some good vibes over here. Right. And we also do the same sort of

11:44approach in this shared source of truth. So, as I mentioned, underneath all of these different agents, there is one shared canon, as we call it. It's essentially a source of truth. And this canon is nothing more than just a GitHub repository. Here's this repository and here's how it looks like. And what you may notice is that the names of the folders essentially are identical to the names of the agents with some differences, but that's at least the idea to keep them

12:11over here standardized. And if we go into each one of them, they do have the information related to their facts and profiles and various type of policies that those agents may have that are identifying how these agents are collaborating with each other. And that's the whole idea behind the canon, behind the source of truth for this fleet, that we're giving them this like one one essential repository where they they are exchanging information in

12:42the version controlled type of manner. So, let me go back to presentation and hope that from that point this box over here, the canon, makes sense to you as a system where these agents are exchanging persistent information that is file-based. And that's one of the mechanisms that they work. So, in this case, the finance agent is putting some information in the in the canon in the canon. And the slug slug for this agent is identical and the owner who owns this agent, which is usually a different person depending on the department, is responsible for how this agent is working and how it is

13:22develop developing. Now, what's important, as well as with people when we build the org structures, it must respect the hierarchy. And this is done intentionally because every one of these agents are working at a different level of abstraction, if that makes sense. And Corbin, in this case, the chief of staff, it really doesn't

13:43know much about the marketing operation. Tom is splitting the work and managing the work in between all of those different marketing departments for the content production, for the advertisement, for website management and and the rest of the stuff. And yeah, they do not jump through the levels. That gives us the right control over the hierarchy of what is happening. In many ways, actually, representing the traditional approach of shaping the departments. So, when the writer does something, it sends the report to the manager, and then the manager assembles the reports and sends it back to the

14:18orchestrator, to the chief of staff. Managers, those who are dedicated as managers over here, the chief of staff and Tom marketing ops and some other agents over here, they do have their own project management capabilities. And the way it is designed here, and I thought that kind of okay, it makes sense. So, let's If we're working with hub repositories anyway, let's keep working with those GitHub repositories to manage the projects that we work with. So, this chief of staff, it's not only connected to the repository, but it also actually has a whole bunch of, as you can see, open issues that are assigned to different types of projects,

14:57depending on what needs to be done. But sometimes there are also projects that I'm helping in there, and it gives me like a system of record where to track the changes and the progress on all of the different projects that could be running within the company. Actually, it's not just the GitHub issues kind of standardized GitHub issues lists with labels and stuff like that that it operates with, but it's also a set of folders inside manager agent that is helping you to persist the data that are

15:28related to this particular project. Now again, GitHub is far from being the only necessary storage for this type of agents. Like they depending of what they do, they are using other storages such as Google Drive in our case and CRM systems and the rest of it. So that you know, GitHub is not limiting that from that standpoint at all. For project management, it ended up being quite a useful tool to actually make use of this sort of exercise. So the projects are managed in GitHub in a very transparent way. I can always go and look and see what is the status of the different tasks on the projects that it is

16:03managing. And all of this hierarchy and the map, there is a special set of skills embedded into the schedules of those agents that are doing agent profiling and agent reconciliation and enforcing agents to also double-checking and validating that actually do what they said they are doing, which is very important, and that they are updating the materials and reconciling the materials they are controlling. So for example, this chief of staff has as a fleet manager has a bunch of skills that are profiling the fleet and reconciling the fleet, talking to the rest of the agents to have them provide information or validating the GitHub repository itself when that needs to

16:46happen. And by the way, maybe it's the right time to also mention these guys because these are in the category of helpers and they are not attached to any particular sub manager or mid-level manager. They're essentially, you know, each talking individually to chief of staff when it's necessary and they're more of helper type of agents than agents responsible for a particular area. And over here you can see like there's a very useful open source intelligence agent, there's a PR strategist, there's a lab, which essentially is just uh you know, agent specifically designed to run certain experiments in inside its

17:23own sandbox inside its own container. For example, you know, being in Portugal near the fire season season made this little agent that monitors the fire risk in the critical areas, but it has nothing to do with with the company. It's just like, you know, I put it here because it can talk to Cornelius when evaluating those risks and it was easier. So yeah, shared truth lives in Canon. Facts and positionings and prices and policies, which is important to live

17:51over there. And the changes are usually going through the human gate and the human needs to approve for those before they, you know, before they are ending up there and that specifically goes towards policies. Some of the things that agents can share themselves, but not all of them. There is a there's simply a convention on how this shared storage is used by the agents and when the humans

18:14are involved. But first, we're going to permission permissioning layers. So as it says, by default, the agents over here, when they're created, they are not seeing anyone around. They are isolated and you need to be pretty conscious about how you're sharing these permissions because the permissions layer is essentially how we control for the safety of the system and for the really coherence of this whole system together. So as you can see, the chief of staff it has access to a whole bunch of agents over here. But if you if we go to, let's say, this fire alarm thing, it only knows about chief of staff and Cornelius and

18:56receptionist and that's it. And that's intentional, obviously, and there's also a nice interface over here. There you go. So this one is permission matrix, but there's also a racing matrix that is embedded inside the agents. As a characteristic of the of the orchestrator as an agent of Corbin, for example, it has special skills that are designed in order to know which other agent is

19:24responsible for what. And I know some of you may be asking, "Okay, what are those special skills and how do I get them?" Let me get to that in in a minute. I just want to finally go through this little presentation. So, yes, everything is closed by default. We're opening that as a conscious step. And yeah, obviously, if if we're seeing that nothing is used if the channel is not used, we're closing that down. Kind of a reductionist

19:53approach a little bit as well. And then, that's a bit of a Cornelius information over here. Agents have access to the second brain on the various type of topics when they need strategic consultancy or something. To be honest, I think in most cases, it is most useful at the very least when this second brain is used by managers. So, either chief of staff or marketing

20:16operations or financial operations, etc. It is particularly designed in our individual case to be good at decision-making under uncertainty and it can give the right frameworks about that. It also knows about our market. So, when competitor analyzer is working, for example, it is loading the insights that it found into back into the Cornelius and Cornelius is kind of storing and updating that within its own

20:42brain. Yeah, we mentioned that every agent is a repository. So, it is relative I want to stop here for a second to talk about new agents. So, orchestrators and managers over here, such as the chief of staff, they have a capability, a technical capability to create new agents. And they can, you know, create ephemeral agents within the system to just do a certain work and

21:08switch it off. But more often than not, what happens is that I work with this agent individually to create a new agent with the use of skills. Again, I will show you what what skills I'm using for that and where you can get those. This recently happened with this PR strategist as we started working with a company that is helping us with PR and we essentially working with them to develop this agent and make it

21:34good at what it does. And so, what happened is that I worked with Chief of Staff to create this new agent and to deploy it over here. And all of that is has been done by by the agent itself, of course, under my review and seeing what it is actually doing. And once it's there, it enters the testing stage where essentially we're limiting to what it can really do. As you can see, it's not autonomous right now. The auto switch is off because we are in the phase of testing that. And so, that means that it will sit in this sort of state for a little while for maybe a

22:10week until we feel comfortable with the quality of the outputs that it does. And maybe we then we'll probably turn it into autonomous, which means that it will have all its own schedules running and producing the actual useful output. In terms of the best practices, one of the things that I needed to make sure in this fleet for that to work effectively is that every agent supports its own state, which means that when they are making certain changes in inside their own GitHub repositories, essentially their files, that they are actually committing those changes and that they are regularly pulling those changes from the GitHub because some of the folks who

22:50are working with these agents are working with them on their own local machines and there's nothing bad about that at all, simply because it's essentially the same exact agent. So, for example, this Trinity product manager that actually runs uh a product for us, this one is also a GitHub repository. And I'm mostly It's a private, of course, a GitHub repository as it as it should be. And I'm mostly working with this agent on my local computer, and then I'm syncing it back into into Trinity. And also it has schedules to do the sync up automatically itself. And in addition to that, this chief of staff, it has schedules to kind of

23:33sync the whole fleet of the agents to the head. Let me see if I can find it over here. Canon freshness past. So, this one is taking care of the source of truth of the Canon reconciliation. Then we have this weekly fleet profiling, and here is the one for the daily fleet sync to head, which means that essentially bring all those agents that you were aware of to the latest version of what is happening inside your system, what is happening in their

24:04inside their repositories. So, and and this like, you know, essentially it all comes down to like in designing this schedules, packaging them into the actual playbooks, into the actual skills, and running them on on a good schedule to make sure that this whole fleet is working together as a unified system. We do retire agents from time to time. I think I even have an example over here

24:30with one of the recent retirements. Yeah, so this data room agent has been retired. It really needs to be updated, but it was an experiment to provide like a data room files from inside the agent. So, we didn't need that, we just switched it off. And essentially decommissioned. And we do have a human gate over here. Actually not one human gate, but several human gates that require the approval. We have a separate

24:58section for operations here. And this is where agents are sending their operational issues that they need to resolve to me as an operator, either to inform me or to ask for some input or to ask for approval on certain things that are essentially kind of operational in more of a technical sense. But when I'm talking about the approval chains that are happening in business value chain, let's put it this way, then we're talking about different mechanisms. So I get approval chains in my Telegram for the chief of staff because it's integrated with Telegram and I'm using that as one of my main channels for communicating with this

25:38particular agent in Slack and in other places. And the skills that this agent runs are actually designed in a way to be gated and well, some of them, of course, the important ones. Which means that it cannot accomplish work until it actually gets an approval from me. So even if it's running like a long-term task over here and in the middle of a task it finds out that it needs my approval, it stops the task and goes to

26:05me for the approval. Through, again, the channels that I named. I need to make a little bit of more clear cut between the operations endpoint, which is more, again, sort of DevOps thing, and the business task approval chains. But one way or another, things are going through the human gate. And what I found that I am the biggest bottleneck in this whole setup because these guys can be sending me, like as you can see, I have, I think it's just for the last couple of days. Yeah, well, about 3 days. I haven't cleared this operations pipe. Not over here at the very least. Because, you know, I'm not

26:44getting there, so these agents could be staying blocked on certain things longer than, you know, I would want to for the optimal operation. But that really means that I need to figure out how to operationally split those things between our team members so that it wasn't focused on myself in approving everything. Yeah, so this one is talking about the ledger and the ledger is really a few things over here. It's the tamper proof audit trail as well as some of the GitHub mechanics, but essentially the idea is that we should very clearly and transparently see what these agents are doing. And in the system you can

27:22drill down to every individual execution and see what happened there. You can go to operations and you can open executions and review everything that happened and go down to the level of details that that you want. And I'm showing that quickly because I'm not sure what kind of sensitive information they may be exposing there. I hope not much, definitely not the keys because those are filtered out from the

27:47execution logs if they end up there. It's also one of the little security features of the system. Right. I mean essentially that's it. So just to summarize what we have just seen. So we get the hierarchy, the hierarchy that is a similar and actually mirroring accountability maps within the company where every you know agent has its own owner and they are responsible

28:12for sort of the same thing. And then we have projects that those agents can manage. We have a source of truth, one truth that is human gated in some ways and not human gated specifically dedicated to agents and other use cases. We have a brain in a form of Cornelius, the brain behind the operations. We have permissions that allow us to split who can do what. We have a life cycle managed through the app repository and other skills. We have gates for approval

28:42and of course the ledger. The only last thing that I didn't show you and I promised I would is skills. We have this documentation website, which is updated with every release that we're having pretty much every other week, I would say. And over here, you can go to plugins. We have created this plugin marketplace for quote-unquote type of agents. It's super easy and straightforward to install. And essentially, what it does, depending on what agents you choose, I'm going to be

29:14focusing on this agent dev plugin. It has a whole bunch of these different skills that would allow you to create playbooks, which are kind of glorified skills essentially. Add different kinds of memories, add pipelines, add orchestrator agents. So, when you run this add orchestrator skill from this plugin, it will make your agent an orchestrator of the fleet and accordingly will add a whole bunch of skills of its own over there. You can see this add canon skill, which essentially creates this GitHub repository that would be shared between them. And yes, we have this agent fleet analysis and agent fleet migration that

29:53we were talking at the last workshop. But essentially, those plugins is where you can find everything you really need for agents to start working with Trinity. If you never touched Trinity before, there is a special Trinity plugin. And uh it has this one little new skill here, start here. And this start here plugin, it's like literally you run these three lines in your quote-unquote and you're all set. It will take you through the process step by step to get the most recent code, deploy the instance, deploy your first agent there, connect to that through the MCP, and everything else. So, it's like literally step-by-step guide to get from

30:33point A to point B. And I just wanted to also announce that in the next couple of days, I think before the end of this week, we going to drop a new release of the software, which is going to be 0.9. And among a thousand different things that we include there, like this by department splits and hierarchy, calls and orchestration and better orchestration and extended analytics and the library of new library of skills, new library of agent templates and agentic systems, we are going to be dropping that together with the release, but also we going to drop this new

31:12workspace. And this new works workspace functionality is essentially a universal page that is designed to be something like ChatGPT or whatever is the chatbot that you got used to, where you can talk to any of the agents or several of those agents that you have access to. And that's the key. I mentioned to you that every agent over here can can be configured to provide access very granularly. Let's take this marketing one. So, we can see that there's like a few people that have access to this

31:44marketing operations agent. And as long as you have access to the agent, you will see this agent over here, and you will be able to set up chats for those agents together, two, three, five, 10, whatever of them to discuss certain topics. So, that is all coming out in 0.9 in a couple of days. So, yeah, feel free to star us on GitHub and watch the repository for the release. And also subscribe to this YouTube channel, which is where I'm posting all the different updates with

32:17regards to the system. And in the meantime, if you guys have any questions, feel free to drop them into the chat, and I would be happy to respond to them. Do we have SOC or ISO compliance? So, we as a company, as Abililty AI, are at the final stages of the SOC compliance. I think we're going to have a report. I

32:41don't know early fall, I would assume. And I think it's SOC and ISO, but I need to double-check that. But in terms of the system itself, that's a very interesting question because essentially, let me show you here at the main Ability AI page, which is also, by the way, run by an agent. As I mentioned, we have an open-source version that is Apache 2.0 and free to use for everybody. But then we have an enterprise version, which is designed specifically to fulfill the needs of the companies that need compliance. So we're essentially giving all the different tools that you would need to go through compliance with this type of system,

33:17SSO, and data retention policies, and the DevOps agent on the at the advanced level, and things like that. So essentially, if you in your company need the system that will go through compliance, that's exactly when you when you need this type of system with us. Thank you for joining us today. It was a pleasure, and I hope you got something useful out of that. If you're watching that on YouTube, please feel free to subscribe, and let me know what you think in the comments below, and come to

33:47our next workshops. Thank you.