쉐도잉 연습: Most devs don't understand what agents are - YouTube로 영어 말하기 배우기

OpenAI just introduced AgentKit, a complete set of tools for developers and enterprises to build, deploy and optimize agents.

⏸ 일시 정지

재생 속도:

106 문장

문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.

OpenAI just introduced AgentKit, a complete set of tools for developers and enterprises to build, deploy and optimize agents.

This is cool, fairly exciting announcement, developers can now design workflows visually, embed agentic UIs faster.

Now I don't really care about this product, I'm not sure I'll end up using it really.

But what I am kind of interested in is how they're talking about agents.

Because if we look at this, this is not an agent to me.

We have here a set of deterministic steps.

We start, then we enter a jailbreak guardrail, which by the way just filters for malicious inputs I assume.

Then we have another LLM call here which just routes the input to one of three separate agents.

This to me is not an agent builder, this is a workflow.

I thought we as a kind of AI engineering typescripty community had landed on some definitions for what agents were

and what workflows were.

But it turns out no we didn't because OpenAI seems to have a different definition from the one that we've been using.

I want to talk through this debate so that you understand what agents are, what workflows are and why the distinction even matters.

And the best place to start is with Anthropic's famous article building effective agents.

This came out in December last year and it basically codified what an agent was and what a workflow was.

This is how Anthropic defines an agent, it's essentially a loop.

We'll talk more about what this loop is in a minute and what makes this agentic. But

if we zoom up to a workflow example here we can see a very similar example to what OpenAI just put out.

Instead of a loop here we have a directional flow, we have predetermined code paths.

And this is what Anthropic calls a workflow.

And it's kind of funny too that this famous article really talking about, you know, titled building effective agents actually talks through like six different kinds of workflows.

Let's go to TLDraw where we've got a bit of dark mode where we can actually dive into some of these concepts.

An agent is a loop where the LLM decides when to stop.

That loop is essentially multiple LLM calls one after the other.

Now if you call an LLM multiple times with the same information it's not going to do anything useful.

And so to make this an agent you kind of need to give it new information each time.

The way that works is the LLM calls tools.

It basically says execute this piece of code for me and then tell me what happened when that piece of code ran.

Just to dive into this for a minute it kind of looks like this.

Let's imagine our system has access to a tool called write file where it can write files to the file system.

The user can say to the agent, write a new file called gitignore.

Then the assistant comes back with a message here saying, okay, call this tool with this content and this path.

On our local machine then we execute the tool and we send the result back to the LLM.

And so this flow becomes a loop where the LLM is gaining more information each time.

This beautiful loop is what drives things like clawed code, coding agents, all the stuff that you're kind of used to using.

The key thing then is that the agent then decides when it's had enough.

So the agent can either continue to call tools or it can say stop.

At which point it will emit a special token

that just says stop and we can catch that in the frontend and no longer call the LLM again and again.

Workflows are of course much easier to define.

There's no loop here, it's just predetermined steps one after another.

You take one LLM call, you pass its result to another LLM call and you pass that result to another LLM call.

You might have some deterministic logic in these steps, like If the LLM call returns one thing, do one thing.

If it returns another, do another.

But all of those code paths are known ahead of time and written in code.

Workflows are neat, by the way, because you get opportunities to optimise the system.

For instance, you can have parallel workflows where you have multiple LLM calls at the same time.

We might take in or produce a chunk of text, split it into two parts, get the LLM to summarise each part of it, and then pass the results of those to another LLM call where we summarise the summaries.

Because the path to the solution is known up front, we can optimise it in all sorts of ways, which make workflows really, really powerful.

And by the way, if I had to pick between agents and workflows, like one that I could take to a desert island, I would probably pick workflows.

But that's just me because I'm a natural contrarian.

So let's sum up then.

Agent and workflow.

What are the differences?

What are they good at?

Well, the first thing to say that to qualify in this category, you need multiple LLM calls.

Like a single LLM call all by itself doesn't really qualify as either an agent or a workflow.

It's just a frickin' API call.

We don't need an extra definition for that.

To me, the key difference is who decides when to stop the program.

With an agent, as we saw, it is the LLM really.

The LLM can say, OK, I've done the work, let's now stop.

Whereas in a workflow it is predetermined steps that are known up front.

Now the reason that this entire distinction matters is that agents and workflows are good for different things.

An agent is really good when the path to the solution is unclear

or when you need to be able to generalise it to lots and lots of different tasks.

Coding Coding assistants are a really, really, really good example of this.

Because the coding assistant in Clawcode or Cursor doesn't know what kind of codebase it's going to go into, it doesn't know what kind of bug you're going to throw at it, and so it needs to be able to adapt on the fly.

In other words, agents are really, really good at improvising.

But workflows are much better when the path to the solution is known up front.

When you need to do the same thing a thousand times, you always want a workflow.

Because as we saw with the parallelizable steps you can basically optimise it in all sorts of different ways.

Whereas an agent you really leave the optimisation up to the agent itself.

Agent is like jazz, you know, it's all improvisation, all feel.

And workflows are like classical music where you can spend ages optimising the upfront set up

so that the final output is as good as it can be.

The next thing to say though is that agents and workflows are a spectrum, not a hard definition.

Most systems out there you will see will be somewhere on this gradient between agent and workflow.

For instance, a pure agent where the LLM is solely in charge of deciding when to stop, well, I don't want to deploy that because that thing is going to eventually run forever.

And so most agents have a max steps counter, in other words a deterministic stop in the code to prevent the agent running infinitely.

This is so common that tools like the AISDK actually have a max steps parameter to their agents.

Going further down we have agents that contain workflows.

Many agents are able to call workflows from within tools.

Which by the way allows you to build really really smart systems

because you get the generalizability of the agent and then you're able to optimise the tools that that agent has.

Finally, of course, you can have workflows that contain loops.

This might be that you produce some text and you evaluate it multiple times to refine the output continuously.

The difference here, of course, is does the LLM itself have the ability to break the loop early?

For me that's a sign that it's an agent rather than a workflow.

But these terms are on a spectrum

and most systems out there will use some combination of each or have agents within workflows or workflows within agents.

And so the definitions are useful because they allow you to think about problems in terms of patterns.

And so it kind of hurts me a little bit when I see as agent workflows grow more complex.

Ah, what did we do to deserve this?

This is just so confusing.

Now of course I'm annoyed I suppose because I'm interested in agents versus workflows as like a pedagogical tool, as a teaching tool.

Because I do find the definitions useful for communicating what you're trying to build and the trade-offs between them.

But also there's a sense that everyone's using the word without there necessarily being a good definition behind it.

I only hope that this definition will spread

100

that the anthropic definition of just two calls in a loop will be what people land on.

101

Now if you're digging what I'm putting out then you will love AIHero.dev.

102

I'm going to be releasing something soon which is going to mash together AI

103

and TypeScript and give you the ability to ship really powerful AI applications with the language

104

that you know and you know that I love.

105

Thanks so much for joining along folks.

106

I will see you very soon.

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

☕ 커피 한 잔 사주기

ShadowingEnglish는 여러분의 지원 덕분에 100% 무료로 운영됩니다. 서버 및 AI 유지 비용이 많이 듭니다. 여러분의 커피 한 잔이 큰 힘이 됩니다! ��

PayPal로 기부하기

ShadowingEnglish.com – 영어 쉐도잉 연습

쉐도잉(Shadowing)으로 원어민처럼 영어를 말하세요. YouTube 영상을 한 문장씩 듣고 따라 말하며, 진짜 발음과 유창성을 키우세요. IELTS 학습자들이 선택한 방법.

쉐도잉 연습: Most devs don't understand what agents are - YouTube로 영어 말하기 배우기

상황 및 배경

일상 대화를 위한 5가지 주요 문구

단계별 쉐도잉 가이드

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉 연습: Most devs don't understand what agents are - YouTube로 영어 말하기 배우기

앱 다운로드

상황 및 배경

일상 대화를 위한 5가지 주요 문구

단계별 쉐도잉 가이드

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법