Multi-agent Claude Code at scale: building Parthas at Intercom

Alright. Hello, everybody. I'm Marvin. I'm the host here from the Intercom AI, and I'm gonna talk to you all about a system I've been building in the house. AI do need some slides because there's so much stuff in there that, I will not go through it without, but I have a like demo as part of it. And yeah. So, basically, I build an Agent Integration system. And, basically, the idea is that with AI now, you can code at what I say is the speed of thought, where, like, basically, you just say what you wanna do, and it happens for you. And there's, like, a bunch of people who have setups that work like that. And it can be really great, but it can also be very brittle. And AI Agent are famous at, like, doing things right most of the time and then catastrophically messing each other up. And so, basically, the idea of the system I build is how can we make this work in a way where, like, that is not a Product? And the system isn't open source, so I'm gonna spend a lot of time mostly talking about, like, the principles behind City, so that, like, Nano hopefully learn something, what I also learned, and maybe build your own. At this point, with AI, that's actually not that hard anymore. But yeah. So, basically, I think there is basically 2 different approaches in most agent orchestrators. There's, like, the agents maintaining agents approach, like, for example, with Gastown, where, like, all agents talk to 1 another, which can be really easy to set up but also very nondeterministic because each agent decides how to follow each worktrees. And it can be, like, very tricky. And so I follow a very different approach, like a much more systems design approach where, like, software that handles the orchestration parts and the agents do what they're good for, which is actually, like, doing the thinking and writing code and discussing with you. But I also don't want to just have, like, a pipeline where you put in specs and get out code. I want my goal is basically to keep the engineer in the center, basically. Yeah. And so the idea is that, basically, there's, like, you have 1 agent you talk to who then helps you write specs and manage the system, and everything else is controlled with software. And, basically and the idea is to push up, the context. So, like, a lot of things Fin, like, if you watch an agent chat, there's so much stuff that usually you don't care about unless it's, I don't know, exceptional, basically. So the idea is to bring to the user only the things that are actually worth paying attention to. And so AI of like pushing you up on, like, a higher abstraction level to, like, focus on, like, the high level systems desire. And yeah. So the big unlock, in my opinion, with this is to coordinate things Fin software. Like, for example, in my system, I don't let agents open PRs. I don't have agents monitor GitHub to see if CI fails. All of that is, like, set up in software, which then lets the agent know if they need to do something. And that just saves tokens, saves time, and also makes things much more deterministic. And this determinism is then what allows you to massively parallelize as well. SWE, yeah, using the agents for thinking and using the software for, like, the bookkeeping and orchestration. And I found that, basically, if you start with, like, a safe subset, like, for example, never actually set up, like, dangerously Operations, I build the whole thing having permission checks and everything on and then build systems that over time make that less of a pain and learn the things that are okay versus the things that are not okay. And it turns out that if you approach something like that, you're preventing agents accidentally destroying your system or routing around what your workflows actually are. And in the end, it makes you faster because you don't spend time recovering from an agent breaking the flow, basically. Claude yeah. So this is AI a fun little systems diagram I have. Like, it's CLI, the way I build it is I have, like, a Go binary that runs AI a SQLite and, like, a server and whatever. And I actually embed, like, a, bugs binary in the Go binary to run, like, Claude code headless SDK, to, like, have, like, little, like once off things for, like, summarizing plans and stuff like that. And the Go side also then syncs with, GitHub, for example, manages different TMAC sessions and also has, like, a GraphQL web dashboard. So I no longer need to actually look at the terminal. The web dashboard manages everything for me. And, basically, the system started off with, like, a really simple worker plan where, like, you discussed with this 1 agent plans, which then get created into, like, little, like, tasks, basically. And then a worker picks up the tasks. And the first thing it does, like, of course, like, research tool a plan mode, which is then something you review because, like, that plan is the single highest leverage stopping point where you can still double check the work. And after that plan, the agent goes fully through, commits. It Sponsors second work tree with, like, a reviewer who goes through the quality gates. They go back and forth until the review is API, and then the system opens a PR. And then there's, like, a whole bunch of, like, if 1 of my coworkers posts review comments, the reviewer is told, can tell the worker to fix things. And so it can happen that CLI AI the time I look at the PR, it Fixing CI and addressed my coworker's Community, and it's ready to ship, which is honestly pretty magical. And all of that just world. And I know it just works because the software handles all of these bits. And I then went a bit Bitterlich. And now I build, like, a research pipeline where CLI AI have, like, 1 agent that AI, like, okay. We have this more vague kind of topic. And as 1 agent, which basically is like, okay. I break this down into different research Analog, and that then farms out into a whole, like, set of agents who are all exploring their own different topics and building that and, like, collecting notes. And then all those notes get compiled back by that 1 agent who then crosschecks them and, builds, like, a set of facts from all the different research AI. So Windows, like, condenses it and passes it to the next agent who then condenses those facts into, okay. What should we actually do? And then after that whole thing, like, maybe, like, 30 minutes of coding spent, basically, then that last agent presents you a summary and interviews you on what you actually wanna do. And if it turns out that what you want to do is different, that agent can go back and research more. Banana, again, the concept here is at each layer, you're, like, abstracting a way and each agent is focused on 1 specific coding. And maintaining that single focus and context management is really valuable in this. And, like, all of this is hopefully just ideas for how you can build your own orchestration pipelines with similar concepts. And so now I Nano to show you, like, a little live demo. I'm gonna actually probably zoom in a little bit. Next. So CLI, I have APIs, so this is my bridge here. You can see AI can see all, everything that's there. I can look at all my projects. For example, I have here, like, 1 of my agents, for, like, the demo purposes tool it to, like, escalate. And escalate is like an escape hatch. Like, hey. Something in the system is weird. And then the agents just like, yeah. Here, for demo purposes, something is weird. And then I can tell it how to resolve it or look into it. And I have, like, this other 1 here that, currently, it worktrees. It has, AI, City SQLite, a CLI, an order to, like, add a new, Intercom rule, which it then there's CLI each order has, like, a well formatted, problem statement, which is really important. Then I have, like, some validation to, like, verify compared to, like, what the original idea was, how good well does the plan AI, how obvious is City, basically tool call out things that might seem good bugs aren't actually that helpful, or, like, changes that the person made. Then there's, like, a summary of the plan because, like, the AI agent plans are usually very, like, implementation tools, and you don't want to read what AI changed. You Nano to see what is the actual key part of this. And then when you're happy with all of this, you can basically just say approved plan and then the worker will start. And if I go here Brian this is Sonnet I'm sorry that this is gonna look bad, but this is like a debug terminal where you can basically see that there's a worker right now starting to do implementation. And so you can see all of this is just happening automatically. Here's, like, an example of a research pipeline that I have started earlier where, like, the proposer basically briefs me being AI, hey. Here is what I Co-founder, and here's, like, a lot of details. And what do you wanna do? And then I can just say, in this case, do all 4 of them. And then it's gonna propose actual implementation orders. And here, I'm gonna go through the Missing list and take 1 that's a little bit bigger. No. This 1. Like, for example, this is 1 that I recently spun up to, like, optimize some of, like, our skills. You see there's, like, a lot of research that Art. And now there's, like, a bunch of for each of our different plugins, there's, like, Art AI all the skills in a plugin. And so now because all of that planning work is done, when I have time to actually open PRs, I can just press play AI I can just say APIs. And it's spawning Fin new Claude Code instance that had all the context. And the only time it checks in is when it has a plan implementation. And the second time is when the PR is open. SWE, basically, because I Event some time upfront to discuss what I want, 5 days later, I can then just press play and get PRs out. And the idea of all of this is because I stay at that very high level of abstraction, it's very easy for me to AI. Because I don't I don't have to worry about agents going rogue or, like, breaking my workflow. I can just press play, and that agent is gonna do a bunch of stuff and end up in a PR. And that allows me to then have so many of those agents that literally, if you see at the top, I monitor my system RAM to present myself from breaking my laptop because that is currently literally the limit of how many things I can ship in parallel. That and how much information I can process. But, basically, all of this said, 1 APIs whole system, it has tons of Community. And I could probably talk for 30 more minutes about everything in here. Like, I have, like, this lieutenant's feature, and I have, like, quality automatic code cleanup, lots of different cool things. But the general concept that I want to leave all of you with, and I'm gonna go back to the slides, is multi Agent orchestration is like a systems problem. It's not just that you prompt your agents well. It's that you orchestrate Fin system that makes it easy and AI default to just follow. Like, the agents shouldn't have to break the system, basically. And to protect your complex, both your human brain context and attention span and also each individual agent's context. The idea here is the more each individual Agent, each individual task is focused on 1 thing, the more you can the more quality rises, the less problems or confusion you have. And the more they are separated from 1 another, the more you can parallelize without worrying that things overload. And I think, in my opinion, safety can't be retrofitted. I started with safety from the start, and it's now as fast as all the ones that skip permissions. And yeah. Thank you all so much. Talk to me later if you want to see more of the system. And thank you all for coming.