# Earning Autonomy: From Missions to Workstreams — Luke Alvoeiro — session 2026-11-11T20:35:00.000Z → 2026-11-11T20:55:00.000Z _41 transcript lines · 37 slides_ ## Transcript All set. Hi, everyone. I'm Luke. I lead our Core agent team here at Factory. Today, I wanna talk about autonomy and why, the teams that are getting the most out of coding agents are not actually the ones that are handing over, like, the most work on day one. It's instead the folks who are ramping up autonomy gradually, one checkpoint at a time, until what they have starts to resemble a software factory. So for those who don't know us, Factory is a platform, that builds droid and then a whole, like, surface for software engineering and building software on top of that coding agent. Hundreds of thousands of developers use us around the world at companies like NVIDIA, T Mobile, and Adobe. What these companies' engineers are building with us is really like a software factory, a system that runs 20 fourseven and builds software under the company's control. And that's a loop that takes in signals from wherever information is already available, turns them into changes, validates them, and then learns from what production shows. A signal is really like anything that tells you how your software should evolve. So that could be A sensory alert or someone's ID on Slack. Every single one goes to the same stages, so you standardize the process, not the output. So we built that platform on five foundations. It has to be transparent, modular, governable, efficient, and frontier. Most people picture a software factory as this kind of like lights out building where, there's no people inside of it, requirements come in one end, and merge PRs come out the other. And and, really, what we saw firsthand in the field is that that's not the case. The best ones aren't set up like that. They're built around people instead. Humans decide what matters and how much to trust droids over time, and those droids earn their keep as they deliver more work that's higher quality. Every company's software factory looks very different to each other. So what we what we sell is not really this factory. It's the tools and the building blocks to compose them. Now, it's it's worth kind of looking at how we got here in the first place. Back in April, one of our flagship products was Missions, which was one of, like, the first multi agent, products to really take, like, a bite out of the human potential bottleneck that existed in in software engineering. You describe a goal. You'd, like, argue with the orchestrator until you were aligned. You'd approve the plan, and then it would go handle implementation for, like, days or even weeks. When the goal was clear and verifiable, you really could come back to, like, completed work pretty consistently. But as more teams adopted it, we heard Some consistent, like, pieces of feedback. The first was how missions asked you to work. The product assumed that you could plan everything upfront, and then it would just work. And the UX sort of suggested that you shouldn't interrupt them. Missions didn't really, like, ask you any questions or provide, like, an interactive surface for that, communication between you and the agent once it was starting implementation. So this suits, like, migrations and big, big coding, like feature projects, but it didn't really fill... Fit the bill for, like, most kinds of other work. Was cost and time. And that came from, honestly, like, the model's getting really, really good. I'm sure you've all seen now adversarial review is really, really good at finding these issues in your code. And so, at the time, we were adding adversarial review into every milestone's boundary. That just kind of, like, grew the scope of that mission from something like 60 features to over 200. And so you ended up having a token bill and a timeline that matched that. And then the last one was that Were keeping their context to one person. So that was fine for, like, a single project, but it meant that the rest of the team couldn't really build on what that mission had learned. So we went back to the drawing board, and one mental model kept on coming up. When you have, like, an org that is running mental model kept on coming up. When you have, like, an org that is running dozens or hundreds of agents at a given point in in time, you actually have, like, a lot of the the problems that operating systems back in the day solved. How to schedule work, how to run what... Many things at once safely. And how to share state. So every operating system starts with the thing that actually does the work, and we wanted to revisit the agent itself. Long horizon agents run for thousands of turns, and and every inefficiency across of those gets multiplied. So you could have, you know, an extra inference request that's unnecessary or a a tool result that's pretty bloated or a prompt cache miss. All those things compound over time and lead to waste. So we decided to make some pretty significant changes. To the harness itself. The biggest one was programmatic tool calling, also known as code mode. Instead of calling one tool, waiting on the model, and then calling the next, we have the model write a small program that executes all those tools in one go and then prints out only what's relevant. So there's this example here where you have 150 linear tickets that are getting moved from one project to another. Done the normal way, that's, like, 30 inference requests, a million tokens. But as one model generated program, you actually only have, like, 60 ks tokens. It runs much faster, and the model only sees what is actually relevant to the task, the the the fact whether it was successful or not. So this layer of the OS is where being frontier and efficient matters the most. A new model lands every few weeks, and no two fail fail the same way. So we tune our harness in such a way that it evens out this jaggedness across all these different models. The result is that droid is now, you know, higher quality at a lower cost than every other coding agent on the market. Now, you have a faster agent, but that doesn't really give you a step function increase in how much work gets done inside of your system. For that, you need many agents running at once, and they need somewhere to run. Remote missions were held back by this fundamental limitation in the system, where there was one computer that handled all the work. But to run a software factory, you need, compute that scales with the volume of work in the system. Otherwise, every agent is is fighting for the same files or system resources. And so that's why we Built environments, which are reusable definitions of the sandboxes that your droids need, complete with the repos, tools, and dependencies that they that they need to get started with. The system is governable. So there's one control plane, that orchestrates all of these sandboxes together wherever you need them. They can run inside of your own VPC, on on EC two, Kubernetes, whatever compute you already operate. So your code, your data, and your network are in your control. Compute becomes pluggable, just like we made BYOK options and auto model, options that we provide, that provide this model pluggable layer. So now we had agents that were cheap enough to run all the time and the compute to run many at once. And so then the next question was, how do we orchestrate all this work? At first, we tried making this DAG, very complex system of agents composed together by these very strong rules, and it didn't really work. You end up having a lot of the same problems that played In the first place because it was too rigid, and as a result, it was too expensive to run, and it didn't generalize well. So what we landed on instead is something that we call a work stream. It's a standing goal with a team of agents to support it. It has this goal, it has an identity, an environment that it runs on, and memory. A new work stream runs as you and has your access. When it outgrows one person, it can be moved to a service account with its own credentials. So you stay on as A Number, but the work keeps, happening under an identity that the the org actually controls. At the center of every work stream is an orchestrator, and its job looks a lot like a scheduler in an OS. Unlike the graph that we started with, it assembles its agents in whatever way is most natural for the model. So the instructions are pretty short. Right? It's like, delegate first, give each agent an area of ownership, and then for tasks that can fall into an existing area of ownership, delegate to those. You start by talking to it. You just kind of hand things over as you think of them, and then it fans out the work so then, you can get the the control back to you. Agents report back when they finish, when they get blocked, and when there's something that changes the plan overall. But the work stream doesn't just stop there because it takes on more on its own, and it learns from your habits. At some point, the orchestrator may ask you how you decide what to work on, and it learns that maybe bugs are coming from two Slack channels. So here, it can set up an intake and a triage listener. Every thirty minutes, it can go in and pull in those reports from those channels, dedupe them against, you know, existing linear issues or, sentry sentry alerts that already exist, and then weigh each of those against the workstream's goal. So a Slack complaint and a customer error report become one change. The output of triage is a spec that you review and, you're you're capable of, like, weighing in on Or any code gets written. Once you approve a spec, the same worker opens a PR, stewards it until it's merge ready, and then make sure that, you know, review, comments, and CI are passing. So each one of those stages actually maps to an autonomy level in this system. At l one, the work stream pauses for human review at the spec creation, at the PR, and before hitting merge. But, you know, as you level up, that... Those levels of autonomy You can get to l four, where you're auto merging everything by default. The owner gets to set the level, but the confidence to raise it comes from watching the work. So when proposed changes are accurate or PRs consistently merge at the quality that you'd expect, that's actually your cue to move to the next checkpoint. And so that becomes the dial for you. You don't need to decide on day one whether you trust a coding agent to own, you know, your, like, CI health work stream off the bat. You just need to trust it to, to, like, unlock the next So in a factory, an agent that starts from scratch repeats the same mistakes the last one already did. And so we built work streams to have a shared file system. Agents are are encouraged to keep memory and version skills, and so their PRs get better over time. They're also proactive, and they go looking for context that they're missing. So for example, say that your work stream notices that other people are shipping related changes. It sets them an automation that pulls In their PRs, analyzes what they've been working on and what comments they've been receiving in those PRs, and then incorporates them into their memory and skills. So what one agent learns, others can use, and nothing starts cold. That folder is also how agents work together on a project. When the orchestrator spawns an agent, it's capable of telling, you know, each agent where does it... Where where do... Where does its results sort of belong inside of this shared folder. And so So every agent can read and write to the same place. If you ask a a work stream why checkout got slower, for example, you can send dozens of agents out to track out all of those different leads that you have, and then, ultimately, each one can write its findings to the folder, and the orchestrator can merge them. Now, you still need a barrier between implementation and merging, and for us, that barrier is platform level validation. Every PR gets code review, security review, and dedicated queue. Way, and it's a live preview. And so once every review thread is resolved, a risk judge then goes in and decides whether it's safe to prove or not. The judge gets the exact diff and a check out of the branch so it can, like, build and test it, but, ultimately, it reads its policy from our mainline branch so that the change can't rewrite the rules that it's being judged by. Every week, Adroid mines the review comments and goes through and figures out which one authors have actually acted on and then pulls them... And pull... ## Slides ### 00:00:10 # AI Engineer Google ### 00:00:39 # AI Engineer Code Summit Presented by Google DeepMind // AVAILABLE ## LIVE TRANSLATION Scan the QR code to access real-time translation. [https://events.google.com/ai-engineer-code-summit/translation](https://events.google.com/ai-engineer-code-summit/translation) ### 00:01:42 # AI Engineer Europe 2027 Europe's flagship technical AI conference returns to ExCeL London for three days, February 17-19, 2027 ### 00:02:04 # AI Engineer Code Summit Presented by Google DeepMind ## AVAILABLE # LIVE TRANSLATION Scan the QR code to access real-time translation. [QR code linking to https://events.google.com/codesummit/translation] ### 00:03:02 # AI Engineer ## Code Summit ### 00:03:36 # AI Engineer Code Summit ### Presented by Google DeepMind ## // AVAILABLE ## LIVE TRANSLATION Scan the QR code to access real-time translation. [QR code for real-time translation] ### 00:04:08 # AI Engineer Code Summit ## STAY IN THE LOOP SCAN THE QR CODE OR VIEW THE SCHEDULE AT AI.ENGINEER/SCHEDULE [https://ai.engineer/schedule](https://ai.engineer/schedule) [QR code linking to ai.engineer/schedule] ### 00:04:36 [Abstract pattern of grey dots forming a wavy, undulating surface] ### 00:05:09 # AI Engineer Europe 2027 ## ExCeL London ### 02.17 - 02.19 2027 Europe's flagship technical AI conference returns to ExCeL London for three days, February 17-19, 2027 — bringing the world's leading AI labs, platforms, and tools to Europe's builders. [ai.engineer/europe](ai.engineer/europe) [Black and white photo of a grand building in London] [Black and white photo of the London Eye] [Black and white photo of Big Ben and the Houses of Parliament] ### 00:05:36 # AI Engineer Code Summit ## STAY IN THE LOOP SCAN THE QR CODE OR VIEW THE SCHEDULE AT [AI.ENGINEER/SCHEDULE](https://ai.engineer/schedule) [QR code linking to https://ai.engineer/schedule] ### 00:06:43 # AI Engineer Europe 2027 ## ExCeL London ### February 17-19, 2027 Europe's flagship technical AI conference returns ### 00:07:02 # AI Engineer Code Summit ## STAY IN THE LOOP SCAN THE QR CODE OR VIEW THE SCHEDULE AT AI.ENGINEER/SCHEDULE [https://ai.engineer/schedule](https://ai.engineer/schedule) ### 00:07:41 # AI Engineer Code Summit Presented by Google DeepMind ## LIVE TRANSLATION // AVAILABLE Scan the QR code to access real-time translation. [https://codesummit. ### 00:08:14 # AI Engineer ## Code Summit [A large central screen displays the event title surrounded by a grid of sponsor logos. Two smaller screens on either side also display the event title. Large 3D ### 00:08:34 # Earning Autonomy: From Missions to Workstreams Luke Alvoeiro / Member of Technical Staff ❄ FACTORY ### 00:09:10 # A software factory runs 24/7 and builds software under your control ### FACTORY Droids run the loop. Humans govern the outcomes. ### Earning Aut ### 00:09:38 # We built the platform on five foundations - **Transparent** You can see what every agent did and why. - **Modular** It fits how your org ### 00:10:09 # FACTORY We don't sell the factory. We sell the **building blocks** and the **tools** to compose them. ### Earning Autonomy: From Missions to Work ### 00:10:38 ### WHERE WE STARTED # Missions - Describe a goal - Argue about scope - Approve the plan - **Build for days or weeks** > When the goal was clear and verifiable ### 00:11:10 WHERE WE STARTED # Missions - describe a goal - argue about scope - approve the plan - build for days or weeks ## It assumed you could plan everything up front ### 00:11:37 ### WHERE WE STARTED # Missions - describe a goal - argue about scope - approve the plan - build for days or weeks ## Review kept adding scope - **approved plan**: ### 00:12:10 ### A MENTAL MODEL # Many agents run into problems operating systems already solved | OPERATING SYSTEM | SOFTWARE FACTORY | | :--------------- | :--------------- | | thread | agent ### 00:12:41 # Earning Autonomy: From Missions to Workstreams ## Long runs multiply every inefficiency Every operating system starts with the thing that does the work, so we started with the agent. - **PER TURN**: An extra inference request - **PER TURN**: A bloated tool result - **PER TURN**: A cache miss × **1,000s** of turns in a run that lasts days Correctness compounds over a long run, and so does waste. So we made some significant changes to our harness. Luke Alvoeiro / Member of Technical Staff ⚙️ FACTORY [https://docs.google.com/presentation/d/1gQhSHWbAXntO8mMhzhgNW_LjnwfVzKGpB1tPknwdSi/edit?slide=id.h5e8a074ba21af5f1_2_0](https://docs.google.com/presentation/d/1gQhSHWbAXntO8mMhzhgNW_LjnwfVzKGpB1tPknwdSi/edit?slide=id.h5e8a074ba21af5f1_2_0) ### 00:13:07 THE AGENT # The biggest change: programmatic tool calling ## ONE TOOL AT A TIME MODEL -> TOOL -> MODEL -> TOOL -> MODEL -> TOOL -> MODEL -> ... Every call waits ### 00:13:41 # Terminal-Bench 4: same models, higher pass rate, lower cost - **-24%** cost per passed task (OPUS 5.5 vs. OpenCode and ### 00:14:05 # Every agent gets its own computer Every task gets a fresh sandbox, on whatever compute you already run. ## Incoming Tasks - **AUTOMATION RUN** - triage new Sentry errors ### 00:14:39 # Every agent gets its own computer Every task gets a fresh sandbox, on whatever compute you already run. ## Incoming Tasks - **AUTOMATION RUN** - triage new S ### 00:15:10 # First try: agents wired together by rules - **TRIAGE AGENT** - must pull signals - must dedupe by fixed rules - must push to the ### 00:15:39 ## A workstream: a standing goal with its own team of agents agent compute **workstream** orchestrator shared context validation ### The Workstream - **GOAL**: keep ### 00:16:09 # You talk to it, and it fans out the work `agent` `compute` **workstream** **orchestrator** `shared context` `validation` - **YOU ### 00:16:38 # You talk to it, and it fans out the work ## Workstreams - **YOU**: The checkout test is flaky again. - **YOU**: Support flagged a billing bug, can ### 00:17:09 TURNING THE DIAL # It takes on more on its own It learns from your habits and from where you gather information. ## How do you decide what to work on? Most ### 00:17:41 ### TURNING THE DIAL # It takes on more on its own It learns from your habits and from where you gather information. ## How do you decide what to work on? ### 00:18:07 ### TURNING THE DIAL # Remove one checkpoint at a time Raise the level when the specs and PRs keep coming out right. [Flow diagram showing a process with stages: ### 00:18:39 # Earning Autonomy: From Missions to Workstreams ## Every agent it spawns builds on the last **SHARED CONTEXT** Agents read the workstream's memory and versioned skills ### 00:19:11 # Every agent it spawns builds on the last SHARED CONTEXT - agent - compute - workstream - orchestrator - shared context - validation Agents read ### 00:19:39 # Agents work on a project together through one shared folder ## SHARED CONTEXT The orchestrator tells each agent which results belong in the folder. Every agent, on every machine, reads