쉐도잉 연습: The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory - 영상으로 영어 말하기 배우기
연습 모드 선택
각 모드는 전체 화면 연습실로 열립니다.
222 문장
문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.
1
- Hi everyone, my name is Luke, and my goal is that 20 minutes from now, you'll be able to assemble agent teams
2
that can complete tasks orders of magnitude harder than what you can complete with a single agent today.
3
A little bit about me.
4
So, I come from a background in DevTools.
5
About two and a half years ago, I started a project at Block, which is where I was working at the time.
6
and that project evolved into Goose.
7
Goose is now one of the leading coding agents, is open source.
8
And it's recently was donated to the AI agentic AI foundation and So it's been really cool to see.
9
Nowadays, I work at factory.
10
where I lead our core agent, Harness.
11
And Factory's mission is to bring autonomy to the entire software development lifecycle.
12
So I want to start off with a claim.
13
The bottleneck in software engineering nowadays is not intelligence.
14
It's now limited by human attention.
15
Even the best engineers can only complete a couple of tasks at a time.
16
They may have a backlog of 50 features, but they can only drive a few forward per day, because every task, requires their attention, every commit needs their review.
17
Today's models are smart enough to figure out all 50 of these tasks.
18
but there's not enough bandwidth to supervise their implementation.
19
So, we kept asking ourselves, what if a human decides what to build and then a system figures out how to do so?
20
Right?
21
An agent could just work for hours for days and you come back to finish work.
22
So that's what I'm here to talk about.
23
When you start researching multi -agent frameworks and systems, you quickly realize that the field's a bit of a mess.
24
Everyone has their own framework, their own terminology, their own opinions of what works and doesn't work.
25
And so I want to propose a simple taxonomy.
26
There's five frontier multi -agent frameworks.
27
One is delegation.
28
This is where one agent spawns another agent, and the parent agent may say, "Go figure out the database schema," and then gets a response back.
29
This is the simplest form of multi -agent communication.
30
It's what most people implement first.
31
You have you know, sub -agents and coding tools are the most common example.
32
The other one is creator verifier, right?
33
Where one agent builds something, and then you have another agent that checks that work.
34
And the key here is like a separation of concerns.
35
The agent that implemented the code is has some cost bias, right?
36
Once that code to work, A fresh agent with fresh context is way more likely to find issues
37
and this is why we do code review as humans as well.
38
- Thank you.
39
Another one is direct communication.
40
This is when agents communicate without a central coordinator.
41
It's kind of like DMing each other.
42
It's hard to get right, though, because state fragments across conversations without that coordinator and there's no single source of truth.
43
The next one is negotiation, right?
44
Negotiation is when agents communicate but over a shared resource.
45
So that might be, you know, they want to use the same API, they want to modify the same portion of the code base, But negotiation doesn't need to be adversarial.
46
In fact, the best use case is when there's net positive sum trading, right?
47
Um, when agents have a potential win -win situation while interacting.
48
And then the last one is broadcast, and that is when one agent sends information to many.
49
Think of it like status updates, new context that applies to everyone,
50
new shared constraints, It's a bit less flashy than the other ones, but it's critical for maintaining coherence over long running tasks.
51
And so when you have all these different building blocks, how do you assemble that into a system that can run for many days?
52
So missions is our answer.
53
It's a system that combines four of those: delegation, creator /verifier, broadcast and negotiation.
54
into a single workflow.
55
you describe a goal, You scope that through a conversation.
56
you approve a plan, and then the system handles execution for hours or days and that enables you to focus on something else.
57
Notably, a mission is not a single agent session.
58
It's an ecosystem of agents that communicate through structured handoffs and shared state.
59
It uses a three -role architecture.
60
There's orchestrator, there's workers, and then there's validators.
61
The orchestrator handles planning.
62
When you describe what you want, the orchestrator is kind of like your sounding board.
63
It asks you the right strategic questions.
64
It...
65
you know, checks out if there's any unclear requirements in the problem space, and then it eventually produces a plan that includes features,
66
milestones, and then something that's called a validation contract.
67
And that validation contract defines what done sort of means before any coding is done.
68
And I'll come back to why that matters, because it turns out to be really important to the system.
69
The next role are workers.
70
they handle implementation.
71
When a feature is assigned to a worker, that worker has clean context, no accumulated baggage, no degraded attention.
72
The worker reads its spec, it implements the feature, and then commits via Git, allowing the next worker to inherit a clean slate and a working code base.
73
And then the last row are validators.
74
they handle verification.
75
And so most systems validate by maybe running lint, type check, tests, Maybe they do code review.
76
Missions does all of that, but we also validate behavior.
77
Instead of just asking, you know, does the code look right?
78
we wonder, does this work end to end?
79
That's the difference that lets missions run for many hours, many days in a row without drifting.
80
And making it work had to involve sort of rethinking validation entirely.
81
So, When you've worked with coding agents before, you've probably seen this pattern.
82
where an agent builds a feature, it writes some tests, the tests pass, there's full coverage, but the tests were sort of shaped by the code.
83
not by what the code was attempting to actually do.
84
Tests written after implementation don't catch bugs.
85
They confirm decisions.
86
So if you rely on validation like that, your system will eventually drift.
87
That's why this validation contract exists.
88
It's written during planning, before any code, and it defines correctness independently of implementation.
89
So for a complex project, This can be hundreds of assertions.
90
and each feature is assigned one or more assertions that it must satisfy.
91
the sum of all features, must mean that every assertion is covered.
92
After each milestone of features, we have two types of validators that run.
93
So you have the scrutiny validator, and the user testing validator.
94
The first one, is more traditional.
95
It runs the test suite, type checking lint, and critically it spawns dedicated code review agents for each completed feature within the milestone.
96
And then the second one, which is the user testing validator, is more interesting.
97
It kind of acts like a QA engineer.
98
It spawns the application.
99
it interacts with it through computer use or something similar to that.
100
It fills out forms, checks that pages render correctly, clicks buttons and ensures that functional flows work holistically.
101
So this step takes significantly longer than the previous one of the scrutiny validator
102
because the system is interacting with a live application.
103
And what we've noticed is that most of the mission's wall clock time is actually spent here, waiting for this real -world execution to occur, instead of generating tokens.
104
Critically, neither validator has seen the code before.
105
They're not invested in the implementation, and so validation is adversarial by design.
106
Okay, so then validation catches bugs, right?
107
But for a system that runs for many days, you also need to make sure that context isn't lost between the agents.
108
When a worker finishes a feature, it doesn't just say, I'm done.
109
It fills out a structured handoff detailing What was completed?
110
What was left undone?
111
what commands were run throughout that agent loop, and what were the exit codes of those commands.
112
What issues were discovered?
113
And did it abide by the procedures that the orchestrator defined for that worker.
114
Thank you.
115
That's how we catch issues and how the system self -heals.
116
The errors get caught at milestone boundaries, corrective work gets scoped, and the mission sort of like pulls itself back on track.
117
not by hoping that agents remember what happened, but by forcing them to write it down, and then actually address issues,
118
and I'll, present on that in just a sec.
119
Our longest mission ran for 16 days, which is much longer than a full sprint.
120
And we believe that they can run for 30.
121
That's only possible because of this structure.
122
So once we had this architecture, the next question became, how do we actually run it?
123
um, The most obvious choice is like parallelism.
124
If you have 10 agents running at one point in time, then you have 10 times the throughput.
125
But we tried that, and it doesn't really work for tasks in the software dev domain because agents conflict.
126
They step on each other's changes, they duplicate work, they make inconsistent architectural decisions.
127
And so the coordination overhead ends up eating up the speed gains all the while you're burning tokens.
128
The difference with missions is that we run features serially.
129
So there's only one worker or valid error running at any given point in time.
130
Within a feature, we allow for parallelization on read -only operations.
131
So you have something like searching through the code base or researching APIs, all that gets paralyzed.
132
Within validators, we also parallelize read -only operations such as code review.
133
This is serial execution with targeted internal parallelization.
134
It seems slower on paper, the error rate drops dramatically.
135
and when you have tasks that run for many days, the sort of correctness compounds.
136
Thank you.
137
Now, Your standard chat interface doesn't really work for something that lasts many days.
138
At a quick glance you need to be able to see how much of the project have you completed, and what amount of the budget that you originally set off with have you burned through?
139
So using a mission actually, we built Mission Control, which is a dedicated view for this.
140
You can see what is Active Worker doing right now? read -off, hand -off summaries that detail what did the worker,
141
the validator, discover, how it's going to sort of like alter its course moving forward.
142
Or, you could just-- you know, go check out, go hang out with your friends that night.
143
This entire view lets you just run missions asynchronously, and you could be plugged in as a project manager overseeing the implementation or you could just you know,
144
go and hang out with your friends.
145
Okay, so the right model in each role.
146
Everything here sort of assumes one thing, and that is that you're using the right model in each role.
147
Planning benefits from slow, careful reasoning, implementation from fast code fluency and creativity, validation benefits from precise instruction following.
148
Right?
149
And so no single model nor model provider is best at all three of these.
150
Using systems like missions requires the development of a new skill, which internally we've been calling droid whispering,
151
but it's this idea that you need to be able to mentally model how different LLMs interact, where they fail, how those failures compound over a multi -day run,
152
And then you need to make a deliberate choice as to which model sits in which seat.
153
Theo, the engineer who built our missions prototype, came up with our model defaults, but we really encourage people to make these their own and customize them to the needs of their project.
154
So for example, validation might use a different model provider entirely
155
to make sure that it's not biased by the same training data.
156
There's a structural advantage of a model agnostic architecture.
157
You're only as strong as your weakest link and if you're locked into one model provider, then you're constrained by that family's weakest capability.
158
as models continue to specialize, the ability to put the right model in the right seat becomes a compounding advantage.
159
and works in the other direction too.
160
If you're using missions, the structure of that can compensate for models that are not quite at the frontier level performance.
161
So the validation contracts, the milestone checkpoints, they allow you to run missions very, very successfully, even using open -weight models.
162
Thank you.
163
Now, this all sounds quite theoretical, what does it actually look like in production?
164
I got an example of building a clone of Slack right here.
165
This slide has a ton of info, but I'll walk you through Just a few things I want to call out.
166
60 % of our time is spent on implementation.
167
and 60 % of our tokens as well.
168
Notice how validation never succeeds on the first go.
169
That's in the mission-- what's it? the one on the bottom left.
170
We almost always have to create follow -up features.
171
So it really demonstrates the value of a system that does this QA loop.
172
you end up with 50 % of your lines of code at the very end, in the bottom right.
173
being tests and 90 % of your code is covered by those tests.
174
And lastly, we take advantage of prompt caching heavily, to make sure that we're sort of offsetting the price of running such a long task.
175
People are really taken to missions, and it's been awesome to see what folks have been building with them.
176
Some examples I've included in this slide, but ones that I want to call out are specifically in the enterprise setting, which is where factory really shines.
177
They've been used to prototyping new ideas and features overnight.
178
to make sure that people can build internal tools at increasingly rapid rates, to run huge refactors and migrations,
179
for ML research, and to modernize code bases, so that agents are more productive in them.
180
Thank you.
181
One thing that I wanted to talk about was also this concept of, like, the bitter lesson.
182
Because every person building multi -agent systems has this fear of
183
the next model release sort of like making their architecture obsolete overnight.
184
Um, so, When we were building missions, we decided we had to make this system get better with every model improvement.
185
This means that almost all of the orchestration logic is defined in prompts and skills, instead of like a hard -coded state machine.
186
how it decomposes features and handles failures.
187
is all in about 700 lines of text, and four sentences of this can alter the execution strategy pretty dramatically.
188
Worker behavior is driven by skills that the orchestrator defines per mission, so you get very customized behavior.
189
and the only deterministic logic is very thin
190
and it's focused on enabling models to do what they do best
191
while the system handles like the bookkeeping right stuff like running validation
192
and ensuring that progress is blocked when there are some handoff issues that are not addressed.
193
So missions sort of ensure the discipline, and the models provide the intelligence using primitives that they're already familiar with,
194
like AgentsMD, skills, etc. So what does this unlock?
195
Remember the bottleneck that I started off with, human attention.
196
the economics are sort of changing.
197
Before a team of five engineers might be able to work on 10 work streams at any given point in time, Now maybe with missions we can bring that up to 30.
198
The team can focus on interesting problems such as the architecture, product decisions, instead of worrying about the execution per se.
199
and The important thing is the code base ends up cleaner than when you started.
200
the end -to -end tests, the unit tests, the skills, the structure that missions provide means that agents and humans are more productive in that environment moving forward.
201
So now that you understand how missions are structured and how they actually work, you can see that they're really a composition of those original strategies, right?
202
Delegation shows up everywhere, and how the orchestrator spawns workers, and how we spawn research sub -agents.
203
Trader Verifier is fundamental in that validation and implementation are always separate agents with separate context.
204
broadcast runs through the shared mission state that every agent references,
205
and negotiation shows up at milestone boundaries where the orchestrator defines Does this handoff summary sort of look correct?
206
Do we need to create follow -up features, re -scope, et cetera? But strategies aren't enough.
207
You need the connective tissue.
208
You need these structured handoffs so that agents don't lose context.
209
You need the right model in each role.
210
And you need an architecture that will improve with each model improvement.
211
So, What I like to think about is that people in this room, who are thinking in terms of agent ecosystems, who develop an intuition for how different models compose under pressure
212
that those folks are going to be really shipping the next generation of innovation.
213
There's a lot of open questions still, right?
214
How do we further parallelize the workload of missions so that they run faster?
215
How do we start orchestrating missions themselves into even more complex workflows?
216
but the data from production missions is clear.
217
This works on real projects at scale today.
218
So This is what I'll leave you with.
219
Open Droid.
220
try running slash missions, argue with the orchestrator about the scope, approve the plan, and then go do something else.
221
I'm excited to see what you guys build, and I'll be around to answer any questions for the rest of the day.
222
Thanks.
앱 다운로드
유창하게 말하는 데 필요한 모든 것
AI 발음 평가문장마다 점수 확인
IPA 발음 연습모든 소리 마스터
단어 학습나만의 단어장 만들기
단어 게임놀면서 외우기
같은 채널
C11
Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar
Daily ConversationUniversity StudentsWorking Adults
C11
What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI
Daily ConversationUniversity StudentsWorking Adults
C12
Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley
Business EnglishInterview EnglishUniversity Students
C1Why Software Factories Fail
Daily ConversationUniversity StudentsWorking Adults
C12
How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS
Business EnglishUniversity StudentsWorking Adults
C28
Beyond Code Coverage: Functionality Testing with Playwright — Marlene Mhangami, Microsoft
Business EnglishUniversity StudentsWorking Adults
C19
"Software Fundamentals Matter More Than Ever" — Matt Pocock
Business EnglishUniversity StudentsWorking Adults
C1Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic
Business EnglishUniversity StudentsWorking Adults
FOR YOU
추천 영상
C112
25 문장
Introducing the Agents API
Business EnglishUniversity StudentsWorking Adults
C12
210 문장
What Software Architecture Should Look Like • Dave Farley • GOTO 2022
Business EnglishUniversity StudentsWorking Adults
C11
309 문장
Claude Code: The Advanced Guide (99% of Devs Skip These Features)
Business EnglishUniversity StudentsWorking Adults
C11
12 문장
Rapid Engineering With AI
Business EnglishUniversity StudentsWorking Adults
C11
124 문장
Agentic AI Frameworks Explained: Workflows, Multi-Agent, & Production
Daily ConversationUniversity StudentsWorking Adults
C14
164 문장
System Design Mock Interview: Design Facebook Messenger
Business EnglishUniversity StudentsWorking Adults
C12
144 문장
WWDC26: Run local agentic AI on the Mac using MLX | Apple
Business EnglishUniversity StudentsWorking Adults
C13
460 문장
Welcome to Agentic GTM: The AI Revolution in Sales
Business EnglishUniversity StudentsWorking Adults
C11
180 문장
Your API Can’t Handle Real-World Integrations
Business EnglishUniversity StudentsWorking Adults
C18
24 문장
Introducing Automations: always-on coding agents
Business EnglishUniversity StudentsWorking Adults
이 비디오로 말하기 연습을 해야 하는 이유는 무엇인가요?
이 비디오는 소프트웨어 개발에서의 멀티 에이전트 아키텍처에 대한 깊이 있는 통찰을 제공합니다. 이를 통해 여러분은 영어 회화 연습에 좋은 소재를 찾을 수 있습니다. 특히, 기술적이고 전문적인 프레젠테이션을 접함으로써, 실제 상황에서 사용하는 다양한 어휘와 표현을 익힐 수 있습니다. 이 비디오를 통해 전문 용어를 반복함으로써 shadowspeak 연습을 더욱 효과적으로 할 수 있습니다. 말하기 연습은 듣기 능력을 강화하고, 새로운 어휘를 자연스럽게 내장하는 데에 큰 도움이 됩니다.
문맥 속 문법 및 표현
비디오에서 사용된 주요 문법 구조와 표현은 다음과 같습니다:
- What if ~? - 상황에 대한 가정이나 제안을 할 때 사용하는 표현으로, 창의적인 사고를 자극합니다. 예: "What if a human decides what to build?"
- Could just + 동사 원형 - 가능성을 제시하는 구조입니다. 예: "An agent could just work for hours."
- Separation of concerns - 특정 문제를 다루기 위한 구성 요소 간의 책임을 분리하는 개념으로, 전문적인 대화에서 흔히 사용됩니다.
- Negotiation - 협상을 의미하며, 여러 에이전트 간의 자원 공유를 다루고 있습니다. 이는 영어 회화를 연습할 때 유용한 표현입니다.
일반적인 발음 함정
이 비디오에서 주의해야 할 발음 관련 함정은 다음과 같습니다:
- Agent - [에이전트]로 발음되며, 자주 사용되므로 정확한 발음이 중요합니다.
- Negotiate - [네고시에이트]로 발음하며, 'g' 소리와 'sh' 소리가 결합되어 발음됩니다.
- Autonomy - [어토너미]로 발음되며, 중간의 't' 발음이 종종 빠지기 쉽습니다.
이런 발음 연습은 shadow speak와 같은 기법을 통해 더욱 강화될 수 있습니다. 비디오를 시청하며 따라 하는 것은 실제 회화 능력을 현저히 향상시키는 데 도움이 되며, shadowspeaks를 통해 보다 자연스럽고 유창한 영어를 구사할 수 있도록 도와줍니다.
이 영상의 문법
화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.
| 문형 | 영상 속 표현 |
|---|---|
| 수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점 | was donated · is assigned · is covered |
| 현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때 | it's been · you've worked · we've noticed |
| 관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보 | Block, which is · one, which is · days, which is |
쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법
쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.