We have different patterns really for running these agents at scale. So, one of them really is sort of the swarm pattern which for my definition is starting off with an individual intent firing that out to a number of different agents and then funneling that back in let's say to an individual PR or task. Fleets is where you're fanning out agents across let's say number of different repositories inside of an organization which is a capability we've had in Owner for quite some time now. And then the bottom you've kind of got events. If you think about how do we take the human out of the loop and build this sort of software factory, you need to know how and when are you going to trigger those agents, when do they come online? A lot of this already exists with existing sort of web hook infrastructure. Stripe has one. There's what they call minions which is built on top of their existing infrastructure where they've then plugged in these coding agents. Another very noteworthy one and Ramp has been so loud on social media these last couple of weeks. But, they also built one that they internally call inspect which again is their sort of infrastructure for for running these background agents.

We at least believe that for running sort of proper development tasks, it has to be inside of a virtual machine. The reason for that is for the isolation from a security standpoint, a container is not bulletproof isolation boundary. They're also bursty. If you run them on Kubernetes or in pods, you have noisy neighbor problems. And only with having sort of the full isolation of a VM will you be able to effectively do this properly.

Over the last couple of days I had a few questions with people talk about harness engineering and what is it? For me, it's really another extension on context engineering whereby everything in your repository from skills to agents.md to unit tests, everything that you could possibly use to give feedback to your agent is for me harness engineering. The conceptual SDLC that we present and talk about with each other is very coarse-grained five steps. Agents don't respect this and they don't understand I mean, these boxes contain a ton of complexity. So, if we take something like plan or plan stage, actually within that our SDLC has a ton of different sort of micro steps almost to it. And if we're wanting them to train agents to then step through the SDLC, we need to find ways to actually break down the SDLC into these some of these micro steps.

But I think we are now at the cusp of now effectively solving this. And I think it might be solved in a few different ways. One is through sort of state machines, you know, by building out workflows and effectively state machines that we've had for a very long time and then building these as our versions of our SDLC. I do believe to a degree some of the ideas from durable executions comes into this as well. You know, lots of companies have pioneered this over time to be able to run a process in a in a durable fashion. But we do need to solve also the gates and compliance section of this. And I do believe actually there is definitely a a gap right now also for packaging this in some form of like CLI construct whereby you can run this locally in a sort of development environment, but also then remotely in, you know, in a CI or some other fashion like this.