YT YouTube2Text

YouTube2Text → Transcripts → Tất cả những gì bạn cần biết về Harness Engineering

Tất cả những gì bạn cần biết về Harness Engineering — Transcript

by Việt Nguyễn AI · 7,395 words · 1,141 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Hello everyone. Recently, if you have
0:03been following AI news, you must have
0:05heard phrases like Agent Harnesses or
0:07Harness Engineering quite a lot. OpenAI
0:10talks about it, Anthropic talks about
0:12it, Google talks about it, and all the
0:14big players are talking about it.
0:16However, this is also one of the most
0:18confusing terms today. Even among those
0:21directly building AI agents, not
0:23everyone can clearly and distinctly
0:25explain what Harness Engineering is.
0:28The most common explanation you will
0:30often hear is that Harness is the
0:31environment for agents. However, with
0:35this explanation, many people still
0:37don't really understand what Harness
0:39Engineering actually is and how it
0:41differs from terms like Prompt
0:43Engineering or Context Engineering. So
0:46today, in this video, I will explain it
0:48to you in a simple and
0:49easy-to-understand way so you can truly
0:51grasp what Harness Engineering is.
0:53First, you can remember a simple
0:55formula: an agent equals a model plus a
0:58harness. This means that large language
1:01models, such as versions of GPT, Gemini
1:04, Haiku, Opus, Sonnet, or Claude, are
1:07just the brain. And the harness is
1:10everything surrounding that brain to
1:12make it actually work. The content of
1:14this video includes three main parts.
1:17In the first part, I will recount the
1:19development journey of agents from
1:21Prompt Engineering to Context
1:23Engineering, and now to Harness
1:24Engineering, as well as why the AI
1:26industry has followed this path. In the
1:30second part, I will dissect each
1:32component within the harness so you can
1:34see how each one operates. In the third
1:37part, the final section, I will add
1:39some important things you need to know
1:40if you want to use AI agents or even
1:42build them effectively yourself. To
1:44make it easier to visualize, throughout
1:47this video, I will use a consistent
1:48example: opening a pho restaurant. You
1:51have just hired a very talented chef.
1:53He has read every cookbook in the world
1:55and knows how to cook almost every dish
1:56. This chef is the model, or rather
1:59large language models such as versions
2:02of GPT, Claude, Opus, Gemini, or Haiku.
2:05However, this chef has two significant
2:07weaknesses. First, he only knows how to
2:09do exactly what is written on the order
2:11slip placed in front of him. That order
2:13slip is the prompt. Second, he has no
2:16memory. He only knows what is currently
2:18sitting on his kitchen counter.
2:20Anything cleared off the table, he
2:22forgets completely. That kitchen
2:24counter is the context window of the
2:26model. The larger the table, the more
2:29you can display, but every table has
2:31its own limits. So, the question here
2:33is: how can this genius yet forgetful
2:35chef run an entire pho restaurant
2:37serving hundreds of customers daily
2:39without any mistakes? The AI industry
2:42answered this question through three
2:44stages of development, going back to
2:462022 when ChatGPT first launched. At
2:48that time, the model's context window
2:50was only around 4,000 tokens,
2:52equivalent to a few hundred words. In
2:55our example, the chef's kitchen counter
2:57at this point is tiny. It only has
2:59enough room for a few order slips and a
3:01few other small items. With such a
3:03small table, the only thing we can do
3:05is write the order slip very skillfully
3:07, which is Prompt Engineering. For
3:09example, if you just write "a bowl of
3:11pho," the chef will cook a generic bowl
3:13, which might not be what the customer
3:15wants. But if you write "beef pho,
3:17extra green onions, less noodles, clear
3:19broth, no spicy," the bowl of pho will
3:21be much closer to what is requested. In
3:24the AI world, it's the same; this is
3:26the time when people learned how to
3:28assign roles to models, provide
3:29examples, and make clear requests. The
3:32central question for users and
3:33developers in this phase was: how
3:35should I write the prompt? However,
3:37prompt engineering has a major
3:39limitation: the model only answers once
3:41and that's it. People call this "
3:43one-shot." It's just like the chef
3:45reading the slip, cooking it once,
3:47serving it, and being done. He doesn't
3:49know how to fetch more ingredients,
3:51taste the food, or make corrections.
3:53With this tiny capacity and one-off
3:55workflow, people realized that writing
3:57good prompts alone isn't enough for big
3:59, complex tasks. The question began to
4:01emerge: how can we use this tiny
4:03context window more intelligently to do
4:06more work while using less space? And
4:08so, people started shifting gradually
4:11from Prompt Engineering to Context
4:13Engineering. If Prompt Engineering asks
4:16how to write the order slip, Context
4:18Engineering asks what should be laid
4:19out on the kitchen counter. Since the
4:22counter space is limited, everything
4:24placed on it must be truly valuable. We
4:26cannot bring the entire warehouse to
4:28the table; delivering the right thing
4:30at the right time is what matters most.
4:32To achieve this, people use three main
4:34techniques. The first is Tool Calling,
4:37the second is MCP, and the third is RAG
4:40. Let's talk about Tool Calling first.
4:42Tool Calling can be roughly translated
4:44into Vietnamese as "gọi công cụ."
4:46Instead of bringing the whole pantry to
4:48the table, the chef is allowed to go
4:50into the storage, grabbing just the
4:52beef and onions needed for the dish.
4:54It's the same for AI; the model
4:56searches the project itself, reading
4:58only the files relevant to the task it
5:00is working on. Tool Calling also allows
5:02the model to perform actions rather
5:04than just reasoning or talking
5:06theoretically. The second technique is
5:08MCP, which stands for Model Context
5:10Protocol. Imagine MCP as a standard
5:13power outlet in a kitchen. Companies
5:16that make kitchen appliances, like meat
5:18grinders or slow cookers, just need to
5:20follow the plug standard to plug them
5:22in and use them immediately. MCP helps
5:25companies add features and connect
5:27their services to large language models
5:29. The third technique is RAG, which
5:31helps retrieve external documents when
5:33needed. It's like having a cookbook in
5:36a restaurant that summarizes all the
5:38recipes. When a customer orders an
5:41unfamiliar dish, the chef simply flips
5:43to the right page instead of memorizing
5:45the whole book. RAG connects the model
5:48to a private database so that data is
5:50always ready whenever needed. Thanks to
5:53these techniques, a new generation of
5:55agents has emerged, especially coding
5:57agents like Cursor, Windsurf, Roo Code,
5:59while at the same time, the models
6:01themselves are getting better. Context
6:04windows have also grown from a few
6:06thousand to hundreds of thousands, and
6:09now even millions of tokens. This means
6:11the chef's kitchen counter has now
6:13become much larger. Users are starting
6:16to assign larger tasks to agents, such
6:18as building an entire feature or fixing
6:20a series of bugs. And context
6:21engineering helps the agent load the
6:23right context and act independently,
6:25allowing it to handle increasingly
6:26complex tasks. But eventually, this
6:28progress hits a ceiling; it has its
6:30limits. Imagine you give a chef a
6:33massive order to cook for a wedding of
6:35500 guests. In the world of programming
6:38, this is like telling an agent to
6:40clone an entire website. If you only
6:42use prompt engineering, you will get a
6:44very rudimentary website because the
6:46model only provides one response. If
6:48you use context engineering, the
6:50results will be better, but still not
6:52quite right. The website will be
6:54unfinished, with broken buttons and
6:56untested features, much like a wedding
6:58banquet missing dishes or serving food
7:00that no one has tasted yet. The problem
7:02here isn't that context engineering is
7:04bad, but that the task is too large and
7:07too complex. There is a major issue
7:09here called context summarization.
7:11Suppose cooking for the wedding takes
7:1212 hours; no matter how big the kitchen
7:14counter is, it will eventually fill up.
7:16When the kitchen counter is full, the
7:18chef will have to clear the table. He
7:19will write a summary of what he has
7:21done on a small piece of paper. Then he
7:23will clear everything else away and
7:24continue working. Remember that this
7:26chef has no memory, so after clearing
7:28the table, he will only know what is
7:30written on that piece of paper. In
7:32other words, the agent is limited by
7:34its own ability to summarize its work.
7:36If the summary is wrong, the
7:38consequences can be unpredictable.
7:39Sometimes the agent finishes
7:41summarizing and thinks the job is
7:42already done. Sometimes it
7:44oversimplifies things, assuming certain
7:46features are finished and tested. When
7:48in reality, they are not. That is why
7:50when you use AI, you often find tasks
7:52left unfinished, or even completely
7:54untouched, yet the agent still claims
7:56everything is done. This way of
7:58expanding the kitchen counter makes the
8:00agent look like it can handle longer
8:02tasks, but it is actually not very
8:04efficient. This is when people started
8:05trying many ways to overcome this
8:07barrier. One way is to use sub-agents.
8:10It is like the head chef now hiring
8:12many sous-chefs. Each sous-chef has
8:14their own workstation, with context
8:16managed in a hierarchical structure.
8:18The second way is to use an entire
8:20swarm of agents. With this approach,
8:23multiple agents are used at the same
8:24time. Each agent has its own individual
8:27context window. It is similar to having
8:29multiple head chefs in the same kitchen
8:30. However, the difference between this
8:33second method and the first is that
8:34here, the roles of these chefs are
8:36equal. And these very experiments led
8:39the entire AI industry to the third
8:41stage. These are the courses that I am
8:43currently teaching. If you are
8:45interested in these courses or want
8:47more information, you can contact me
8:49via the Zalo number shown on the screen
8:51. Actually, Agent Engineering existed
8:53long before the term "Agent" was even
8:56used. When experimenting with
8:58sub-agents and swarms, people gradually
9:00realized that we need to master three
9:02things at once. First is a better
9:04coordination layer. Who does what, and
9:06in what order. It is just like in a
9:08noodle shop; it is the operational
9:10process and the kitchen manager. Second
9:12is a better working environment. It is
9:15like a kitchen that needs to be fully
9:16equipped, with tools arranged in a
9:18logical way. Third is better context
9:21management. It is similar to deciding
9:23what to set on the table and what to
9:25clear away. Combine all three of these
9:28and we have Harness. "Harness" in
9:29English originally refers to the gear
9:31put on a horse so its power can be
9:33directed to the right task. For example
9:35, the task of pulling a carriage. This
9:37term has been widely used since the
9:39beginning of 2026. Many people say it
9:41is just a buzzword. But in reality, it
9:43generalizes a huge shift that is
9:44currently taking place in the AI
9:46industry. One of the most important
9:48changes in Harness Engineering is the
9:49idea of a loop. Instead of having a
9:51chef work for 12 hours straight with an
9:53increasingly messy table, we divide the
9:55work into shifts. At the start of each
9:57shift, the kitchen counter is
9:58completely cleared. This means the
10:00agent gets a brand-new context. However
10:02, every shift must strictly follow the
10:04rules for how to start and how to
10:06finish. Specifically, the process
10:08usually looks like this. First, people
10:10write a comprehensive requirement
10:12document called a Product Requirements
10:14Document, or PRD for short. It is
10:16similar to a detailed menu for an
10:18entire wedding. From there, they break
10:20it down into a specific task list in a
10:22JSON file, like a checklist taped to
10:24the kitchen wall. Something like: dish
10:26one is banana blossom salad, dish two
10:28is boiled chicken, dish three is sticky
10:30rice. Then from here, the loop begins.
10:33Each work shift, the chef starts with a
10:35clean table. He reads the checklist,
10:38picks exactly one unmade dish, cooks it
10:40, and tastes it. It is like running a
10:42test, then logging what was done and
10:44marking that dish as complete. That is
10:46the end of a shift, and the next shift
10:48repeats the exact same process. Until
10:50every item on the checklist has been
10:52marked off. Because each shift involves
10:54only one dish and a clean table, the
10:56chef will never be overwhelmed by
10:58having too much work. And because
11:00everything is carefully recorded on the
11:02checklist and logbook, there is no risk
11:04of the agent mistakenly thinking a task
11:06is done due to faulty context
11:08summarization. The most famous example
11:10of this approach is ReAct, a technique
11:11that once caused a stir in the AI
11:13community for its high efficiency. But
11:15what is even more remarkable is that
11:16its underlying structure is extremely
11:18simple. It starts by converting to a
11:20JSON file and then iterating through
11:21each feature until completion. Its
11:23source code repository is very small.
11:25Anthropic’s Ness demo is the same—
11:27very lightweight and simple. One thing
11:30to clarify here is that Ness
11:31engineering does not kill context
11:33engineering, and certainly not prompt
11:35engineering. If you open the source
11:37code of an AI coding agent, like Client
11:39for example, you will see its system
11:41prompt is still a very elaborately
11:43written prompt. Prompt engineering is
11:45still used; it has just become a small
11:47branch within the whole system. Imagine
11:50three nested circles. The innermost
11:52circle is the prompt, reminding the
11:54agent who it is. For example, that you
11:56are the head chef of a pho restaurant.
11:58The middle circle is context; it
11:59decides what we should lay out on the
12:01kitchen table. The outermost circle is
12:04Ness; it controls the entire operation
12:06of the restaurant, guiding the chef
12:08through each step of the workflow. This
12:11means the prompt asks how to write the
12:13order ticket, context asks what to put
12:15on the table, and Ness asks how the
12:17entire restaurant should operate.
12:20Nowadays, most AI coding agents have a
12:23Ness layer integrated inside. However,
12:25each provider designs it in a different
12:27way. That is why every company is
12:29talking about Ness today. Now, we will
12:33analyze what is inside a Ness. Put
12:36simply, Ness is an architecture that
12:39helps turn a model into an agent. A
12:42model, or large language model, is
12:44essentially just a text generation
12:46machine. You ask, it answers, and then
12:48it stops. It’s like a great chef who
12:50just stands in one place and recites
12:52recipes orally. Ness is what gives him
12:54the ability to act, see the results of
12:56his work, and continue until the dish
12:58is truly finished. The clearest
13:00examples of Ness are AI programming
13:02tools, such as Claude Code, Codex,
13:05Cursor, or Windsurf. Each tool starts
13:07from the same problem. How can the
13:09model write and fix code on a real
13:11project? And interestingly, despite
13:13being made by different companies, they
13:15have gradually converged on very
13:16similar architectures. Before going
13:18into detail, we need to distinguish
13:20Harnesses from another thing that is
13:22often confused with them: frameworks.
13:23If you are interested in AI, you have
13:26surely heard at least once of names
13:28like LangChain, LangGraph, CrewAI, or
13:31AutoGen. They are all frameworks, not
13:34Harnesses. A framework is like a kit
13:37for us to assemble our own kitchen. It
13:39gives us each individual piece
13:41separately. Here is the stove, there is
13:43the fridge, and this is the recipe
13:45shelf. You, the architect, have to
13:47assemble them yourself. Frameworks are
13:50made for humans to assemble an AI agent
13:52themselves. As for Harnesses, they go
13:54in the opposite direction; there is no
13:56assembly step here at all. A Harness is
13:58essentially like a restaurant where the
14:00keys are handed over to us. Things like
14:03the stove, tools, processes, or rules
14:05are all pre-configured. Technically,
14:09it's like a loop combined with a
14:11catalog of tools and a permission layer
14:13. Everything is pre-connected. A
14:16Harness is made for the Agent itself to
14:18work. You just need to provide the goal
14:20, and the Harness will take care of the
14:21rest. In short, a framework is like you
14:23having to build your own kitchen. While
14:25a Harness is like a kitchen that has
14:27already been built. You just have to go
14:29in and operate it. So, what exactly is
14:31inside a Harness? There are nine main
14:33components that you need to know. As I
14:35mentioned in the previous part, each
14:37company or each party will have a
14:38different way of designing Harnesses.
14:40For the rest of this video, I will use
14:42the Harness from Anthropic, the company
14:44behind Claude, as an example because it
14:46is one of the best AI coding agents and
14:48their Harness is also considered one of
14:50the best in the world today. These nine
14:53main components include the main loop,
14:55context management, tools and skills,
14:58sub-agents, pre-built skills, session
15:00memory, system prompt assembly, and
15:03extension hooks. Permissions and safety
15:05. Now, let's walk through each
15:07component one by one. The first
15:09component, and the foundation for every
15:11agent, is the loop. It sounds
15:13sophisticated, but at its core, it's
15:15just a while loop in the code. Let's
15:17look at how a chef makes a bowl of pho
15:18in our restaurant. He reads the order
15:21ticket and the kitchen rules. He
15:22decides what needs to be done. For
15:24example, slicing the meat thinly. He
15:26starts slicing, then checks the result
15:28to see if the meat is thin enough. That
15:31result is placed back onto the table.
15:34Then he goes back to the first step and
15:36checks what needs to be done next. For
15:37example, blanching the rice noodles. He
15:40performs this step and then looks at
15:42the result again. Then he checks again.
15:44The next step is pouring the broth,
15:45tasting it, and checking if anything is
15:47missing. For instance, if it lacks salt
15:50, he adds more. With an AI agent, it
15:52works exactly the same way. The model
15:54reads the system prompt and decides
15:56which tool to call. It runs the tool,
15:58takes the result, feeds it back into
16:00the context, and repeats. Thus, the
16:02loop will stop in one of the following
16:04two cases. First, when the model
16:06returns a text response without calling
16:09any more tools. Meaning the chef
16:11announces that the dish is finished.
16:13Second, when it hits the loop limit,
16:15like the shop rule: if you redo it over
16:1720 times and it's still not right, stop
16:20. Report to the manager. This limit
16:22ensures that the agent will never run
16:24forever without ending. Think of this
16:26loop as the main engine that helps
16:28operate the entire restaurant. The
16:30other eight components all revolve
16:31around and serve it. That was an
16:33example with a text-based model, but
16:35for multimodal models that read text
16:37and images, the loop is exactly the
16:39same. Now, let's move on to the second
16:41component. In each loop, the kitchen
16:43table gets increasingly crowded. We add
16:46new order tickets, tool results, and
16:48notes. Sooner or later, this table will
16:51be full. Meaning it reaches the model's
16:53context limit. At this point, Hes will
16:55have to decide on three things. First,
16:57what needs to be kept as is. Second,
17:00what can be summarized, and third, what
17:02can be discarded. Let's take Claude's
17:05code as an example. In the past,
17:07Claude's kitchen table was about
17:08200,000 tokens wide, and then we got
17:11the Opus model, which increased this
17:13number to 1 million tokens. When the
17:16table reaches a certain threshold, for
17:18example 80%or 90%, Hes will trigger a
17:21step called compaction, or context
17:23compression. The most important or most
17:26recent messages will be kept as is. As
17:28for the rest, they will be compressed.
17:30In a pho restaurant, this is like
17:31cleaning the table during peak hours.
17:34The three newest order tickets are kept
17:35on the table. The 10 old completed
17:38tickets are consolidated into a note
17:40saying 10 bowls served, table five
17:42requested no onions. As for onion peels
17:44and scratch paper, we throw them
17:45straight into the trash. This step is
17:47extremely important and can cause
17:49terrible consequences if done poorly.
17:52For example, in the step where we
17:54consolidate the 10 old tickets, if we
17:56accidentally forget the note that table
17:585 requested no onions, the customer
18:00will receive a bowl full of onions.
18:02Therefore, context management must be
18:04designed very carefully. Next is the
18:06third component. This component
18:08consists of two layers: tools and
18:10skills. Tools are the most basic
18:12operations like reading a file, writing
18:15a file, running a command, or searching
18:17code; in the kitchen, these are the
18:19knife, the cutting board, and the pot.
18:22Every pho restaurant must have these
18:24tools. Rice shops or noodle shops are
18:26the same. Tools are universal in nature
18:28. Skills are a layer that sits on top
18:31of tools. This is where an
18:33organization's proprietary knowledge is
18:35packaged, usually in the form of
18:37markdown files. In a pho restaurant,
18:38skills are the drawer of heirloom
18:40recipes, how to simmer broth for 12
18:42hours, the restaurant's unique ratio of
18:44star anise and cinnamon, and the
18:45standard way to plate a bowl of pho.
18:47Using the same knife and the same pot,
18:49every shop has a different secret
18:51recipe. You can simply remember that
18:54tools are the same in every restaurant.
18:57But as for skills, every restaurant is
18:59different. And to manage everything, we
19:02need a directory called a registry.
19:06Just imagine it as a board hanging on
19:07the kitchen wall, clearly listing the
19:09tools available and the permissions
19:11required to use them. For example, this
19:14specific knife can only be used by the
19:16head chef, while other knives can be
19:18used by anyone. And if you want to use
19:20these tools, where should you get them
19:22from? Technically, each tool only needs
19:24to be described by four things: name,
19:26required permissions, processing
19:28function, and a description. A
19:31summarized list including name,
19:32permissions, and description will be
19:34sent to the model so it knows what is
19:36in the kitchen. An interesting point is
19:39that the way skills are registered is
19:41quite similar to tools. A skill is
19:44essentially just a tool that, when
19:46called, opens a file to read. It is
19:50just like a chef who only opens the
19:52recipe book when needed, rather than
19:53laying out every single recipe from the
19:55start. This way, the kitchen counter
19:58does not get excessively cluttered. The
20:01fourth component is sub-agents. At some
20:05point, when the restaurant has to
20:07prepare overly complex dishes or cook
20:09multiple dishes in parallel, one chef
20:11with one counter is not enough. That is
20:15when the agent will create sub-agents
20:17to handle separate tasks. Just like a
20:20head chef calling in extra kitchen
20:22assistants. Each assistant will have
20:23three things of their own. First is a
20:26separate work session, meaning a
20:27separate counter that is not shared
20:29with the head chef. Second is a limited
20:32set of tools; for instance, an
20:33assistant just checking inventory won't
20:36be allowed to touch the knives. Third
20:38is a focused instruction, like "you
20:40only need to do exactly this specific
20:42job." Usually, a Hayes will have three
20:45types of kitchen assistants. The first
20:47type is the exploration assistant. This
20:49assistant is responsible for checking
20:51the pantry, assessing the situation,
20:53and this assistant is only allowed to
20:55look, not to touch anything in the
20:56pantry. The second is the general
20:58assistant. This assistant will do the
21:01common tasks, and finally, there is the
21:03inspection assistant. This assistant
21:05will taste the dishes to see if they
21:07meet the requirements. Each type of
21:09assistant will have its own permissions
21:11, list of tools, and specific
21:13instructions. The process by which the
21:15main agent delegates work to sub-agents
21:17includes three main steps. First is
21:19assigning tasks, second is setting
21:21limits, and third is collecting results
21:24. The head chef assigns tasks, limits
21:26the scope of the assistant, and then
21:28only receives the final result.
21:29Assistants can make a mess on their own
21:31table as much as they want. It doesn't
21:33affect the head chef's table at all.
21:35Thanks to that, the head chef can do
21:37many tasks at once while still keeping
21:39their table tidy. When talking about
21:41the third component, we are talking
21:43about skills. And there are many skills
21:45that users will add themselves during
21:47the usage process. They usually look
21:50for skills online from reputable
21:52sources, for example, from major
21:54companies like OpenAI or Anthropic,
21:56such as front-end design, back-end
21:59design, or model building. After that,
22:02they will add these skills to the AI
22:04Coding Agent so that from now on, the
22:06AI Coding Agent can also use these
22:08skills. However, besides the skills
22:12that users add and supplement to the
22:14model, every Hayes has a set of
22:16built-in skills. Meaning, from the very
22:18beginning, it already has these skills
22:19available. Users do not need to install
22:21anything extra at all. For example,
22:23with Claude Code, it will certainly
22:25have some very basic skills. For
22:27example, such as reading files, writing
22:29files, editing files, searching,
22:31running commands on the machine, or
22:33navigating through code. For a Hayes,
22:35these skills are mandatory; you cannot
22:37function without them. Because an agent
22:40that cannot read or edit files can in
22:42no way be called a coding agent. It is
22:45just like how someone who cannot
22:46perform basic tasks like holding a
22:48knife or turning on the stove cannot be
22:50called a chef. Of course, these default
22:53skills are quite basic, and in reality,
22:55they are not much different from
22:57regular tools. Besides the basic skills
23:00, modern agents today also have a set
23:02of higher-level skills available. For
23:06example, skills for creating git
23:08commits, opening pull requests, or
23:10running tests and reading the results.
23:14These are skills similar to knowing how
23:16to plate food beautifully, how to
23:18package food for takeout, or how to
23:20hand over shifts properly. Some of
23:22these skills will vary depending on
23:24which company is building the agent.
23:26The sixth component is memory or
23:28storage for the work session. A
23:30long-running agent session always has
23:32states like what has been done, what is
23:34being done, or what is left to do. If
23:37the program crashes halfway and our
23:39agent has no mechanism to write to the
23:41disk, everything will be lost. It is
23:44like a busy restaurant suddenly losing
23:46power. The chef already has a poor
23:48memory. So after the power goes out, he
23:50will completely forget which tables
23:51have been served and which are still
23:53waiting. Modern agents today solve this
23:55very simply. Usually, they use a file
23:58that is append-only, never to be
23:59deleted or edited. Often it is a JSON
24:02file or a Markdown file. Every message,
24:04every tool usage result, and every
24:06context compression is recorded as a
24:08line in this file. In the noodle shop,
24:10that is the kitchen logbook. After
24:12finishing a task, the chef will
24:13immediately record a line. For example:
24:1510:05 AM, table 3 served two bowls of
24:18rare beef pho. The rule is to only
24:19write and never erase. Once recorded,
24:21it is immediately saved to the disk. If
24:23the power goes out right after, the
24:25line just written remains safe. Thanks
24:27to this logbook, even if an incident
24:29occurs. For example, if the head chef
24:31has a family emergency and has to go
24:33back home for a few days. During these
24:35days, someone else will step in to
24:37replace him. The new person just needs
24:39to read the logbook from start to
24:41finish—essentially a replay—to know
24:43exactly how things are progressing and
24:45what needs to be done to continue the
24:47unfinished work. And because this
24:49logbook only allows adding new entries,
24:51not deleting old ones, two shifts can
24:53write in the same book without worrying
24:55about stepping on each other's toes. In
24:57short, the program or a session might
24:59encounter glitches or incidents, but
25:01the logbook never will. The seventh
25:03component in HNES relates to how we
25:05connect and assemble system prompts
25:07together. Essentially, system prompts
25:11in today's complex AI agents aren't
25:13just a static block of text written
25:15once; they are a combination from an
25:17assembly line consisting of many
25:19components. When an AI agent starts,
25:23HNES traverses up the project's parent
25:25directories to find instruction files
25:28with specific names, such as agent.md
25:30or rules.md, and then inserts their
25:32content into the system prompt. It can
25:36also load other memory files we've
25:38saved simply by reading the directories
25:40and files on the drive. Imagine our pho
25:42restaurant has now become a chain with
25:44many branches. At the start of each
25:46shift, the chef receives an instruction
25:47sheet consisting of two parts. The
25:49first part contains the general rules
25:51for the entire chain. Use the correct
25:52broth recipe, the correct portion of
25:54meat, and ensure hygiene. Every branch
25:56must follow these. But the latter part
25:58differs because each branch operates in
26:00its own way. For example, branch A
26:02mainly serves dine-in customers. A
26:03specific note here is that every order
26:05slip must include a table number. Bowls
26:07for the same table need to be prepared
26:09so they can be served together. Once
26:10finished, place them on the service
26:11counter for staff to take to the
26:13correct table. As for branch B, it
26:14specializes in takeout. Note that each
26:16order slip must have an order ID, and
26:18noodles, broth, and herbs must be
26:20packed separately. Before delivery,
26:21verify the number of servings and
26:23attach the order ID to the bag. Now,
26:25suppose both receive a request for two
26:26beef noodle soups. But at branch A, the
26:28chef will prepare two bowls for table
26:30service. While at branch B, he will
26:32prepare two takeout sets and attach the
26:34correct order ID. The skill and general
26:36recipe remain the same, but the
26:38workflow must follow each location's
26:40guidelines. It is similar for AI agents
26:42; each project may have its own
26:44specific file.md or agent.md. Does this
26:47project specify which command to use
26:48for running tests? Does the other
26:50project specify which directory to
26:51place the source code in? Agents will
26:53follow appropriate instructions so the
26:55same model knows how to work across
26:56different projects. It is like a chef
26:58arriving at a specific branch and being
26:59given the correct instruction manual
27:01for that branch. However, there is a
27:03point here that we need to pay
27:04attention to. Most agents today use an
27:06optimization technique called prompt
27:08caching. Specifically, prefix caching.
27:11This means if the beginning of the
27:12prompt is identical to the previous
27:14time, the model won't need to reprocess
27:15that part. Therefore, the processing
27:17will be much faster and much cheaper.
27:19In the kitchen, it is like this. The
27:21general rules at the beginning are
27:23already memorized by the chef, who can
27:24just glance over them. The chef only
27:26needs to carefully read the notes at
27:28the end of the rule sheet. But if
27:31someone inserts a new line at the top
27:33of this sheet, everything behind it
27:35shifts, and the chef has to read from
27:36start to finish. Of course, this will
27:39take more time. Therefore, the order in
27:41this instruction sheet is very
27:43important. The static part should be
27:45placed first. The dynamic part should
27:47be placed later. If we reverse it, we
27:49will ruin the prefix caching. This is
27:51one of the reasons why agents can run
27:53hundreds of loops while keeping costs
27:55at an acceptable level. The eighth
27:57component is hooks. We can translate
27:58this into Vietnamese as "điểm móc."
28:01This is how we can extend agents. Hooks
28:04allow us to insert our own custom logic
28:06before or after a tool runs without
28:08needing to touch the HNES core. There
28:10are two types of hooks. The first type
28:12is a pre-tool hook, which runs before
28:14the tool executes. It receives the tool
28:17name and input arguments, then can
28:19allow, reject, or modify that call. In
28:21a pho shop, this is like an inspector
28:23standing right next to the kitchen.
28:25Before adding beef to the pot, this
28:26inspector checks whether the beef is
28:28still within its expiration date. If it
28:30is still fresh, they allow it; if it is
28:32expired, they block it. If a customer
28:34asks for less salt, they adjust the
28:35seasoning accordingly. The second type
28:37is a post-tool hook. It runs after the
28:39tool has finished executing and sees
28:41the result. It cannot block anything
28:42anymore because the task has already
28:44been completed. Its job is auditing,
28:46logging, tracking, and observing, much
28:48like a kitchen camera recording every
28:50dish served so the owner can review it
28:52at the end of the day. Technically
28:54speaking, communicating with hooks is
28:57very simple. HNES sends data in JSON
28:59format, and the hook returns an exit
29:02code to tell HNES whether to allow or
29:04reject the action. Hooks can also help
29:07different components communicate with
29:09each other. Hooks are how businesses
29:11actually put HNES into practice,
29:13helping them attach their own security,
29:15auditing, and compliance rules to the
29:17right hook points. And the final
29:19component, the ninth one, is
29:21authorization and security. This is the
29:23component that decides whether an agent
29:25is a useful tool or a potential danger.
29:28HNES defines a hierarchical
29:29authorization system. Level one is
29:32read-only, level two allows writing
29:33within one's own workspace. Level three
29:36is full access. Each tool declares the
29:38minimum permissions it needs, and it is
29:40HNES's duty to verify that at the time
29:42of distribution, before the tool can
29:44even run. In the pho shop, imagine we
29:46have three types of access badges. The
29:48green badge allows entry only to
29:49inspect the inventory, without touching
29:51anything. The yellow badge allows
29:52cooking in the designated kitchen area,
29:54while the red badge grants full access,
29:56from turning off the main gas valve to
29:58dumping the entire pot of broth. There
29:59is a point we need to note here: the
30:01same tool can be either safe or
30:03dangerous depending on how it is used.
30:05Take a water tap; if we use it to wash
30:07vegetables, it is harmless, but if we
30:09spray it into an electrical outlet, it
30:11is very dangerous. It is the same with
30:13computers; there are safe commands,
30:14such as listing files, viewing content,
30:16or searching, which only require read
30:18access. As for dangerous commands, such
30:20as deleting files, running with
30:22administrative privileges, or shutting
30:23down, they require higher permissions.
30:25For example, full access. As for the
30:28remaining commands, they usually fall
30:29somewhere in between. Therefore, Hanes
30:31needs to examine the specific action to
30:33see what the agent intends to do, how
30:35far its impact goes, and if it falls
30:37within the permitted scope. For tasks
30:38that have been permitted, the agent can
30:40proceed. For tasks that exceed that
30:42scope, the system can block them or ask
30:44for your confirmation before execution.
30:46It is just like our chef being allowed
30:48to get ingredients and cook dishes
30:49according to orders on their own. But
30:51if he wants to throw away a whole pot
30:53of broth simmered for 12 hours, he
30:55would need to notify the owner, explain
30:57why, and wait for approval. The purpose
30:58of the permission layer is to clearly
31:00define which tasks the agent can do
31:01independently and which ones require
31:03human decision-making. When that
31:04boundary is clear, you will feel more
31:06secure when delegating tasks to the
31:07Agent and will also know which steps
31:09require your involvement. We have just
31:10reviewed the individual components of
31:12Hanes one by one. Now, let's try to put
31:15them all together to see how a user's
31:17request will be processed. Suppose you
31:19ask an AI coding agent, such as Claude
31:22Code, a request like "Please help me
31:24fix the issue where the login button is
31:26unresponsive." In the noodle shop
31:28example, imagine this as the moment a
31:30customer orders a bowl of rare beef pho
31:32without green onions. First, Hanes will
31:34gather the necessary instructions for
31:36the agent, including general rules,
31:38project-specific guidelines, and
31:39information about the working
31:41environment. It is just like a chef
31:42receiving their shift instructions and
31:44then reading the customer's order slip.
31:45Next, the development phase begins. The
31:48agent uses tools to locate the code
31:49related to the login button, reads the
31:51necessary files, and identifies the
31:53cause of the error. If needed, it can
31:55delegate a sub-agent to investigate a
31:57part of the project and return the
31:58results. Before any tool is run, it
32:01checks whether that action is permitted
32:03. Configured hooks can also participate
32:06in the verification at this stage. Just
32:09like a chef knowing which tools to use
32:11and which area to work in, they must
32:13follow kitchen regulations. Once the
32:15cause is identified, the agent modifies
32:17the code and runs a test. If the test
32:19reports an error, the results are fed
32:21back to the agent for further fixes. In
32:23a pho shop, this is the moment the chef
32:25tastes the broth. If it doesn't taste
32:27right, they adjust it and taste it
32:28again. Throughout the process, Hannes
32:30records the progress of the work. If
32:32the context becomes too long, it
32:33retains only the necessary information
32:35for the agent to continue. It's like
32:37keeping a kitchen log while clearing
32:38the table to make space for more work.
32:40Finally, once the fix and tests are
32:41complete, the agent reports the result
32:43back to you. The bowl of pho is served
32:45exactly as ordered, with no extra
32:47ingredients. Thus, you only made one
32:49request, but behind it lies an entire
32:51process. Reading instructions, finding
32:53information, using tools, and verifying
32:55permissions. Testing and recording the
32:57results. Hannes organizes that process
32:59so the model can complete the work step
33:01by step. Through this example, we have
33:03seen how the components in Hannes
33:05coordinate with each other. However, to
33:07be able to use or even build such
33:09systems yourself, there are a few
33:11points to keep in mind. First, with the
33:13same model, different organizational
33:15methods will yield different results.
33:17Place the same chef in two different
33:19kitchens. In the first kitchen, tools
33:21are lacking and disorganized.
33:23Ingredients are a mess, and the order
33:25slips are unclear. In the second
33:27kitchen, everything is well-organized,
33:29customer requests are clear, and there
33:31is a final check before serving. The
33:33chef's skill level in these two
33:35kitchens remains the same, but the
33:36ability to produce dishes that meet
33:38requirements will differ. It is the
33:40same with AI; the same model, when
33:41provided with the right tools, clear
33:43instructions, and a way to verify
33:45results, can work much more effectively
33:47. Therefore, when an agent isn't
33:49performing well, don't just think about
33:51switching to a more powerful model.
33:53Check to see if it has enough
33:55information, the necessary tools, and a
33:57way to recognize errors to self-correct
33:59. Second, you can improve HNES without
34:01having to build everything from scratch
34:03. An easy way to visualize this is that
34:06Hannes consists of the parts the
34:07manufacturer has already made and the
34:09parts you can add for your own work.
34:11With tools like Cursor or Codex, the
34:14core is already built, including how to
34:16call the model, run tools, manage
34:18context, and organize the workflow loop
34:20. It is similar to taking over a
34:23kitchen that already has a stove, a
34:25refrigerator, and utility systems; you
34:27don't need to rebuild everything
34:28yourself. However, you still need to
34:30add your own restaurant's specifics,
34:33such as recipes, ingredient
34:34organization, shift handover guides,
34:36and food inspection processes. In
34:39working with AI, that could be an
34:41agent.md or clues.md file containing
34:43project instructions, scripts, routine
34:46tasks, automated testing snippets, or
34:48connections to necessary tools. In
34:51other words, you don't need to write an
34:53AI coding agent yourself before you can
34:55start doing Hness Engineering.
34:57Adjusting an existing tool to make it
34:59follow your specific process is also
35:01part of this job. Third, there are
35:04errors that must be prevented by
35:05mechanisms rather than just empty words
35:07. Suppose the chef frequently forgets
35:09to turn off the stove. You could stick
35:11a note on it saying "remember to turn
35:13off the stove." If he still forgets,
35:14you might stick up another note. But at
35:16some point, you will realize that you
35:18need a more reliable mechanism. Such as
35:20an automatic shut-off timer, for
35:22example. It is the same with Agents. If
35:24it keeps making the same mistake,
35:26writing more prompts might help, but it
35:28may not be enough. Similarly, if the
35:31agent frequently breaks existing
35:33functionality when editing code, you
35:35can add tests to catch those errors. Or
35:37, if there is a directory that
35:39shouldn't be modified, you can restrict
35:41write access to that folder. The thing
35:43to remember is that instructions tell
35:45the agent what to do, while checks and
35:47permissions help it detect or prevent
35:49unauthorized actions. A good agent
35:51setup needs to combine both of these.
35:53Fourth, if you want the agent to be
35:55able to self-correct, you need to let
35:57it know whether the result is right or
35:59wrong. In previous parts, I mentioned
36:00the importance of testing many times. I
36:03need to emphasize it once again here.
36:04This is a very important point. If we
36:06want our agent to be capable of working
36:08through multiple steps on its own. A
36:10chef who cannot taste the food will
36:11find it very difficult to know if the
36:12dish is seasoned correctly. The agent
36:14also needs a similar way to evaluate
36:16what it has just done. For code, this
36:18could be test results or error messages
36:20. For interfaces, this could be
36:22screenshots to compare against the
36:24requirements. For calculations, this
36:26could be a verification step using a
36:28tool. If you just assign a task and let
36:30the agent guess if it did it correctly,
36:32it will be very hard to trust the
36:34output. But with clear feedback, the
36:36agent can rely on it to proceed. It can
36:38fix errors where they appear, re-check,
36:40and then move on to the next step.
36:42Therefore, when designing a task for an
36:44agent, always consider what it will
36:46rely on to know if it has done the job
36:48correctly. Finally, if you want the
36:50agent to be more autonomous, prepare a
36:52work environment for it with clear
36:54boundaries. In the permissions section,
36:56we talked about requiring the agent to
36:58ask for permission before performing
36:59certain operations. But if you now want
37:01it to work through multiple steps
37:02without constantly stopping to wait for
37:04confirmation, what should you do? One
37:06way is to prepare a dedicated work
37:07environment for it, often called a
37:09sandbox. Depending on the needs, it
37:11could be a container or a virtual
37:13machine configured with appropriate
37:14limits. Using the pho restaurant
37:16example, imagine you set aside a
37:18separate kitchen to test new dishes.
37:20The chef can test recipes, try
37:21different preparation methods, mess up,
37:23and start over while the main kitchen
37:25still serves customers. Of course, that
37:27experimental kitchen needs to be
37:28properly isolated. Which ingredients to
37:30use, which equipment to touch, and
37:32whether items can be taken from the
37:34storage. It is the same with agents;
37:36what matters is not just having a
37:38separate workspace, but clearly
37:39limiting the data and resources it can
37:41access. If the scope of influence is
37:43better controlled, you will have the
37:45basis to allow the agent to be more
37:46proactive within that scope. So, we
37:48have gone through the entire pho
37:49restaurant, from the ordering process
37:51to how the whole kitchen is organized.
37:53If you only need to remember three
37:55things from this video, remember that
37:57prompt engineering is about writing
37:58requests clearly. Context engineering
38:00is about providing the right
38:02information at the right time. And HES
38:04Engineering is about organizing the
38:05entire process so the model can use
38:07information, take action, check results
38:10, and continue working. HES consists of
38:12nine core components, but you don't
38:14need to build all nine from the start
38:16by yourself. If you are using an AI
38:18coding agent, start with the tasks
38:20closest to your needs. For example,
38:22write clear project instructions, add
38:24procedures for repetitive tasks, and
38:26prepare a way to verify the results.
38:29Then, we can continue to observe where
38:31the agent is getting stuck to keep
38:32improving it there. A great chef needs
38:34a well-organized kitchen to truly
38:36showcase their skills. With AI agents,
38:39the model is very important, but how
38:41you organize the work around it is
38:43equally important. That is the meaning
38:45of the formula I introduced to you at
38:46the beginning of this video. An agent
38:48equals the model plus HES. I hope the
38:50things I shared in this video are
38:52useful to you. Thank you so much for
38:54your time. I will see you in the next
38:56videos. Yeah.

About this transcript

This page contains the full transcript of Tất cả những gì bạn cần biết về Harness Engineering by Việt Nguyễn AI, generated from the public captions YouTube serves with the video. The transcript has 7,395 words across 1,141 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.