Harness Engineering Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor

Author: Google Cloud Tech · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Harness Engineering Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor · Channel: Google Cloud Tech · 30:37 · Watch on YouTube

Topics: AI agents, Software engineering with AI, AI infrastructure and hardware

Summary

The video explains an agent harness as the tools, context, and orchestration around a language model that let it act beyond generating text. Ryan Lopopolo describes harness engineering as a way to ground agents in an environment, improve their work through documentation and verification, and gradually expand their autonomy. A practical walkthrough compares linear and closed-loop harnesses, including options with additional safety guardrails. The final section presents a three-layer agent stack—model, harness, and knowledge—and highlights examples for each layer.

Key points

An AI agent combines a language model with a harness that connects the model to tools and information from its environment.
Context and environment can help an agent infer what is needed without requiring every detail to be spelled out in the prompt.
Harness engineering can use documentation, coding conventions, static verifiers, and tests to steer agent behavior.
Shifting interventions earlier in the workflow can give agents ways to discover relevant context for themselves.
Small, reviewable changes and iterative verification can build confidence and support longer tasks with less human intervention.
Agents can classify tasks and dynamically retrieve the expertise and context relevant to the work.
Harness design involves choices about loops, tools, and memory; different workflows call for different patterns.
A linear harness provides a consistent, single-pass workflow, while a closed-loop harness can make changes, run tests, and use failures to continue iterating.
The video presents a three-layer stack: a model, a harness, and domain knowledge loaded as needed.
The closing examples feature Gemini Flash, Antigravity’s boost command, and Google Skills as tools for the model, harness, and knowledge layers.

Chapters

Start	Chapter	Summary
00:00	What an agent harness is	The hosts define an agent as a language model plus a harness, using a weather question to illustrate how the harness supplies information the model lacks.
02:04	Harness engineering and context	Ryan Lopopolo discusses the term’s origins and explains how curated context can help agents understand expectations without elaborate prompts.
04:40	Engineering practices and shifting left	The conversation covers documentation, tests, static verification, observability, and making useful context easier for agents to find.
09:26	Growing autonomy over time	Ryan describes aligning agent output with organizational standards through iterative, reviewable changes and gradually larger tasks.
14:12	Advice for using agents	Ryan recommends ambitious experimentation, learning from failures, and investing in reusable tools and context rather than over-scaffolding agents.
19:02	Building and comparing harness patterns	A hands-on segment explains how a harness connects model intent to action and compares linear, closed-loop, and guarded workflows.
24:50	The model, harness, and knowledge stack	The final segment presents a three-layer agent stack and discusses a fast model, Antigravity’s boost command, and Google Skills.

Quotes

So the harness is everything in that AI agent that isn’t the LLM. — 00:30

I aspire to be an incredibly lazy prompter — 04:07

all of harness engineering is an increasingly sophisticated set of tricks to bring the agent back to baseline — 10:32

The goal of that connection is to optimize a model to do what we want. — 20:38

Your coding agent doesn’t need a smarter model. It needs a better stack. — 25:21

Concepts and entities

agent harness, Harness Engineering, Gemini Flash, Gemini 3.8 Flash, Antigravity, Agent Development Kit (ADK), Google Skills, Ryan Lopopolo, Google Cloud, Codex, Claude Code, Cursor

Full transcript (original language)

00:00 How far into the future can you peel back the ambiguity to empower your agents to have autonomy over that task. So they’re taking more cues from the context and environment that you’re operating in, rather than what you’re just saying explicitly in the prompt. That’s right. I aspire to be an incredibly lazy prompter. If I have done the job to give the model the tools and context it needs to ground itself, then I don’t need to front load that into the prompt. It’s very important to continually be updating what you think is possible with these lovely tools that we have.

00:30 In this episode, we are going to dive deep into the concept of agent harnesses. Agent harness is the newest buzzword in AI. So what exactly is it. Yeah, well, in short, an AI agent is a large language model plus an agent harness. So the harness is everything in that AI agent that isn’t the LLM. So for instance, how Gemini Flash is the model and Google anti-gravity is the harness. Exactly like that. So if you ask questions like, why is the sky blue.

01:03 Or tell me a joke. The model can give you words back without doing any additional research. It already has those answers. But if you ask a more complex question like should I wear a raincoat. Well, the LLM doesn’t have the answer to that. It needs more information. So something the harness needs to figure out what the weather is. So almost anytime we’re interacting with AI, we are actually interacting with an agent. So we ask the agent, should I wear a raincoat. The agent gives those words to the LLM,

01:33 and the LLM sees those words, but it doesn’t have the answer. And so it gives words out that amount to go find out what the weather is. What is the weather. Find that information for me. So then the agent harness gets that weather information like it’s sunny out. And then the harness takes our original question should I wear a raincoat plus the new information about the weather from the harness that it’s sunny out and gives all of that back to the LLM and then the model can respond. No, it’s 98 and sunny. You don’t need a raincoat.

02:04 So an agent harness is everything that is wrapped around the LLM to give the agent powers beyond just. Here’s some text in give me text out to dive deeper into this concept tilde sat down with Ryan, a Googler, and also the person who coined the term agent harness. Hello I am tilde, and I’m here with Ryan lopopolo. Hi and we’re going to talk about harnesses. How did harness become a term. And is it true that you’re the person that coined it.

02:35 Yeah, we did a ton of work on trying how to get these coding agents to be fully autonomous. And there were a ton of neat things we did around the coding agent to make that possible. We published some great work on it in February of this year, and it kind of has taken the industry by storm. So excited to go into it with you all in detail today. Yeah, absolutely. I read your essay on leveraging Codex in an agent first world, and I think it’s fascinating. And anybody who cares about the future of software engineering must read it. You make a really compelling case

03:05 for not writing any code manually. Yeah, I’ve been trying my best not to do so, and I don’t think I’ve actually opened an editor at all since around May of last year. Holding strong here at Google. Wow, it’s been eight weeks here for me. Amazing I have to admit that not reading code that I’m going to put into production scares me a little bit, but you make a very compelling case for it. So that engineers are just going to be writing specs in natural language, and that’s all

03:35 we’ll be doing. So what was the most surprising thing you learned putting this into practice. It is very much the case, I think, that you have to take models getting better and better over time as a given. But even as the models get better and better, I think I have come to understand that they won’t necessarily become better at better at knowing what I want by default. So the whole idea with harness engineering is to do that context and environment curation around the model so that it more naturally every time it boots up, comes to understand

04:07 what it is exactly that I want. And as the models get better and better and smarter and smarter and follow instructions more and more, it allows them to do more and more complex things. The more I ground them in what good looks like for me. So they’re taking more cues from the context and environment that you’re operating in, rather than what you’re just saying explicitly in the prompt. That’s right. I aspire to be an incredibly lazy prompter, because if I have done the job to give the model the tools and context it needs to ground itself, then I don’t need to front load that into the prompt.

04:40 One thing that struck me about your essay was that you advocate for putting the kinds of engineering best practices that you might use when scaling up, in terms of number of engineers working on a project like linters, like well-defined coding conventions. Which of those best practices do you feel have worked best for an agent first workflow. To be honest, all of them. I really want to try to push the bounds on autonomy as much as possible. And I think there’s this spectrum of interventions

05:11 that we can put in place with the models. The most simplest, smooth brained, stupidest one I can think of is literally just try my prompt again without changing anything else to see if I get better results. But, that does not scale to my teammates. It doesn’t scale across my time. So I can think about putting these interventions further and further to the left. In the software engineering process. I can add docs, I can add some agents that points at those docs, or I can add a static verifier and a test.

05:42 Maybe those static verifiers themselves will introduce prompts to the agent and onward and onward and onward. Eventually, if we are lucky or not so lucky into evals that we can upstream to our good folks in DeepMind in order to help make Gemini app the best. Amazing And by shifting, can you define a little bit what you mean by shifting left. Yeah so I want the interventions that we give to the model and its environment and its tools to be as cheap as possible to implement. And for these agents who crave text, who operate on text,

06:16 providing them more text in increasingly more sophisticated and automated ways is what I mean by shifting it to the left. So appending some text to my prompt, this is as basically far to the right as we can go, and giving the model tools and the ability to reason through its own documentation corpus that we give, it would be increasingly further to the left to give the model the means to go discover that context for itself. What are some emerging new best practices for example,

06:49 self-healing, observability, agentic loops that might not have been possible before the technology got as good as it is now. Yeah it is. It’s very cool that simple tools that already lean into the best practices that you and I already use for software engineering are able to be leveraged by these agents in increasingly creative ways. And one reason that is the way it is because best practice tools are very well represented in the training data. If I can collapse an observability problem

07:21 into something that I have used my entire career with something shaped like PromQL and online observability techniques, well, that’s something the model is going to know how to do well. It composes super nicely. We move the collection and aggregation of observability data into a best in class tool for it. We give the model something that composes really nicely with a CLI that is able to move reasoning into determinism and give it essentially a very easy access to context

07:52 in a dense format that is going to know what to do with. And we can use that pattern all over the place to take your high scale best desires for software engineering and just go do them, because code is very cheap to produce right now. I can see the agent fail in a particular way. One thing I added the other day is I like the idea of structuring my markdown with the links embedded, not as part of the inline flow of the prose, but as an anchor kept close to it.

08:24 And I do that to make it really efficient for the agent to read the actual prose text in the documentation. But the link itself, I write some test for that. It’s close to that text. So my named anchor is in the end of the paragraph or the list that it’s associated to. And this is some gross code that I have vibed up that sort of keeps context efficient. It keeps the text human readable for me. So it’s easy for us to review. And I have solved this problem for forever. That’s maybe slightly idiosyncratic to my preferences,

08:56 but also good for my agents and my team. So you’re solving for the loss in the middle problem and also human readability at the same time. That’s right. That’s right. Because I’m not writing any of the code. I do require it to be pretty readable. So I can peek under the covers of the agent’s execution, because looking at the end produce artifact is how I want to treat agents, whether they’re producing code or Google Docs or Google Sheets. I want to look at the end artifact, say, is this reasonable.

09:26 And if it’s not reasonable, I do need to have some way of backing out to why write what nonsense went into the production of this unreasonable Google Sheet that I need to whack the agent on the head to make sure it does not make that same mistake again. Whack the agents on the head, I love it. So you wrote this essay in February of 2026, and it is now September 2026. And one thing that you said you didn’t know at the time is, how is this system going to evolve in the long term. Yeah, if I were to say like what challenge

10:00 I have been trying to solve with harness engineering this whole time. It has been. Do agents Cohere over long time horizons. I am a big believer that all the work that we do in human organizations is very much an iterative sort of process. We have not one shotted the Google Business. It has taken very many years to build it to where it is and the contributions of many over a very iterative process, and to have agents be full blown participants in that production

10:32 of work essentially means we need to keep realigning the things they produce to the Golden thread of what the organization considers to be good. And basically, all of harness engineering is an increasingly sophisticated set of tricks to bring the agent back to baseline, whether that’s small PRS that are easy to review. And if the small PEs are easy to review, well, then it should be easy to operationalize agents to do some of that reviewing, which means we can narrow the state space of those small PRRs which lets us go longer horizon with less human intervention.

11:05 And this is what is meant by increasing the size of the loop that you are using agents for. How much confidence do you have that in a small change you can get something reasonable. Can you stack those small changes end to end in order to get something reasonable over a longer arc. And then what would it mean for me, as the supervisor of this system, to try something more ambitious to do a bigger loop. Oh, wow. So starting with something small and working iteratively from there to give your agents more and more autonomy, making bigger and bigger changes as you scale up.

11:37 That’s right. And eventually you can get to the point where things like wholesale language migrations are tractable because you have put enough guardrails in place to know that a bunch of changes stacked end to end are good. You can trust the code that’s being produced, which means you can apply that trust and autonomy in a novel direction. As I was sort of working on these various autonomous software engineers and engineering managers,

12:07 it was very cool to see different individuals contribute to these agents, because you could watch building out the stats of RPG character. I get a new person on the team who is a React architect and boom, like the attention that they pay is able to bump out the stats in front end architecture and performance. And this is something that I don’t normally bring to the table here. So curating a diverse team like this and having them all contribute to a central leverage

12:37 producer of work, actually means you can get quite well-rounded agent that has the best of everyone as a result. Wow that’s amazing. You’re hiring for a team, but you could just specify exactly what skills you need, and then the agent just brings those to the table. That’s right. And moving it back to harness engineering being a set of tricks to refine that golden thread of execution. I need the agent to both be a backend architect and a front end performance expert, because I don’t know what task I’m going to do.

13:08 And you would think around sitting in sprint planning in the beginning of the week, divvying up work based on who has the expertise. But if you only have agents doing the work, they need to figure out which expertise they need to activate. And this is why having the agent classify what work it’s going to do, and use that to dynamically discover what context it needs to pull in, is part of what it means to have high autonomy. Because if you’re not paying attention to the code that is produced in great detail, that also means you probably don’t want to be super in the weeds on prompting and identifying

13:41 tasks and pointing the agent in the right direction in the first place, which is again, another thing that’s going to let us expand that loop. Yeah, it sounds like you’re also like expanding the autonomy you’re giving them as far as business logic, like giving them more and more ambiguous problems to solve, the same way you would with growing an engineer from a junior engineer to a senior engineer across the span of their career. That’s right, that’s right touching on this is I think it’s very interesting to think about the sorts of skills that are now applicable with using agents as the execution force between producing code.

14:12 And I do think about it in terms of that loop size. How far into the future can you peel back the ambiguity to empower your agents to have autonomy over that task. And in the same way, I want staff engineers solving problems for the organization six months out. I want from junior to senior to staff engineers with agents. Think about how far into advance they can unblock their agentic team. Now bringing it back to the bigger picture, I was wondering if you have advice for your average engineer and how much they need to know about harness engineering,

14:43 or whether it might make sense for them to build their own harness. I have never built a harness. I think this is a big misnomer with what I term harness engineering. I have always kept the anti-gravity like thing in your agentic system as fixed. Take the best model you can as soon as it comes out. Try to have high ambition with it. Be actively discarding all your priors on what is possible because the world moves very quickly these days.

15:16 Try and have high ambition. Observe when the agent fails to do a good job, interrogate it and yourself on why, and then try to use the fact that code is very cheap to produce. Prose is very cheap to produce, to refine the environment around the agent to just try your best to disallow these divergences from good behavior. And the more and more you do this, the more tools you give to the agent. The more rich documentation, the more you help the agent navigate that documentation and just in time,

15:47 find the right things. The more and more complex tasks it should be able to accomplish the less you have to keep your hand on the wheel. And tools in context is a thing that is very, very core to the agent. All harnesses expose essentially a file, read a grep and an arbitrary command execution tool, which means if you focus all of your efforts on improving quality on tools and context, you can freely adopt the newest models as they come out,

16:17 and you’ll be constantly accruing leverage into a bit of the system that will never become obsolete, which is a big challenge. With these agents, you can very much over scaffold around them, which constrains them unnecessarily as they get better and gets you into sunk cost fallacy around not wanting to throw this stuff away. Yeah, I can certainly relate to that. Oh, this is amazing. I’m so glad you joined us at Google. Do you want to tell us a little bit about why and what have you been working on. Yeah, so I am working on Google Cloud.

16:51 I am trying to build the best agents to help you operate your Cloud. And the reason I find this to be so exciting is my entire motivation. Working in AI has been to chase after deployment. It’s my belief that today we have what’s called capability overhang, where the models are so good beyond what we are able to extract from them in terms of useful work today. So the goal for me as an applied engineer is to chase after gobbling up as much of that capability overhang

17:22 as I which means trying to increase the ambition and spaces in which we deploy this thing and put it into places where it just doesn’t exist so far. And Google Cloud, I think, is this very wide and deep hole of very complex systems. It is essentially a very large computer. And part of having an agent be successful is to give it a computer. And I want to make Google Cloud the best computer for agents such that they can operate it exceedingly well. And to help customers do that on their own in the process.

17:55 There is no Cloud. It’s just someone else’s computer. That’s right. That’s right. That’s right. And we want to give we want to give the agents a big somebody else’s computer. Do you have any last words of advice or any hot takes you want to share with our audience. It’s very important to continually be updating what you think is possible with these lovely tools that we have. The pace of AI progress is so fast, and you want to make sure that your experience with them

18:28 and the expertise that you are building with yourself and your teams, is one that will continue to make sense as the agents and their harnesses continue to improve, which means focusing on these two extensible interfaces around tools and context is the way to do that. Agents will always need context in order to do that last mile adaptation into what you think good is. And as you can continue to shift that knowledge right, left shifted to the left in terms

19:02 of increasingly capable tools, which act as a form of memory and enforcement of what you think good looks like. You’ll continually be amazed as the models are able to do more and more interesting things for you over time. Thank you so much and thank you for tuning in. Thank you. So now that Tilda and Ryan have talked about the concepts behind an agent harness, we know that a lot of you are developers who want to see the code and get hands on. Dive a little deeper. So let’s look at how Billy customizes his own agent harness

19:34 for specific tasks by weighing design decisions like looping and memory. And we’ll also look at the differences between linear and closed loop patterns. An engineering mentor of mine always said, you can just use the framework, but a great engineer will really understand the framework. Building a harness yourself is how you understand what’s happening under the hood when things break. Agent harnesses are the ways that we’re able to push on our models and get the most out of them. If we look at a model on its own and unharnessed model,

20:07 it can know about tools, but it has no way to execute anything. And we know that many models have been fine tuned for tool use so they can take actions like interacting with files, making API calls, managing their context and memory. But on their own, the model doesn’t have a way to interact with the environment. Let’s take a look at some code I’ve got here. If I run this code, the model can only output the text saying that it should inspect the file. The harness needs to do the work of connecting

20:38 that intent to the action. So the goal of that connection is to optimize a model to do what we want. And maybe we want it to be coding or writing or researching. And agent harnesses are the way to do that. Now there isn’t one best harness to rule them all. There isn’t one best solution here, and that’s kind of what we’re exploring right now in this problem space of ancient harnesses. What’s important in one problem might not matter in others.

21:09 So with each harness, there are a few things you can make decisions about. Looping how many times will it loop. Tools what tools should it use. When should it use them. How should it use them. And memory. How important is memory for the workflow and when do you want to retrieve it. So we’re going to take a look at three different harnesses here. And the first pattern I want to show is a linear harness with no looping. So this is going to be able to inspect a file, output

21:43 a recommendation and exit or just output the answer if it didn’t need to look at that file just returning there. And it’s always going to go through this same exact flow. This is great. If you need some level of determinism. You want it to be able to do the same thing each time. So let’s just run this one as well. Let’s actually run it. And we’ll give this a second to output the result. So we went through this file.

22:15 We outputted the result synthesizing the information from the file and the analysis that we wanted it to do. But this is always going to go through that same exact flow each time. Read the tool once, output the response, and then ends. Now another pattern which is super common in code editing and more is this kind of closed loop. So just continuously running over and over until there’s an exit state.

22:45 So if I want to do something that’s working on code, making edits to that code, I want to use this kind of closed loop harness. I want it to run until the problem is resolved. So here we’re going to basically apply a code edit change, and then after that change we’re going to run the tests. So until the tests pass we will not be returning. Or I think here we’ll return after maybe five iterations. But this is going to let us change the code, then run the test suite, capture that failure output, not just

23:15 see did it pass or not. We’re going to see why it failed and feed that error back into memory and loop through it until we can get those tests to pass. And then a final one I want to look at today is just something with more safety guardrails. If we want to build something from scratch but don’t want to implement all of this functionality one at a time, you might reach for a tool like hk, the Agent Development Kit by Google, and this allows us to build something more advanced with more guardrails, with memory compaction built in.

23:48 And you don’t have to code all those features yourselves, but you still have a lot more customization than using something out of the box. So even here, I’ve got this block destructive commands function, and I’m making sure I don’t do any dangerous commands like removing files, dropping my database, pushing to GitHub before taking an action, like running some kind of code. So here, we’re able to work with an agent to give it a lot of customization

24:19 without having to use something purely out of the box. So right now, the most popular agent harnesses are tools like Google antigravity Cloud Code cursor. And everyone’s going to say, this is the best thing right now. And all of these tools are fantastic. But what are they the best for. What are they fantastic for. And a lot of them are great for using a computer in a specific way, using memory in a specific way, solving problems in specific ways. But you might need something opinionated for the problems

24:50 you’re trying to solve. And what makes these tools work so well and feel really smooth when working on your computer or writing code isn’t the model themselves. Those models are really smart. It’s the harness engineering around the models. They are smartly designed with engineering principles and all the right tools to write software effectively right now. All right, back to Smitha and Luke. That was an excellent deep dive into agent harnesses, but there’s a lot of cool things happening in the AI space right now.

25:21 And I Smitha, you’ve got a lot of other things that you’d like to share, so let’s talk about those. Your coding agent doesn’t need a smarter model. It needs a better stack. Whenever developers feel like their coding agents are hitting a wall, the first reflex is to just jump to a heavier foundational model. But once you work with AI workflows day in and day out realize that the model is only one piece of the puzzle. A truly high performing agent devstack comes down to three connected layers. Number one is the model.

25:51 Number 2 is the harness, and number 3 is the knowledge. When all three click into place, everything changes. Today, I’m walking you through the three tools that I’ve been loving this week one for each layer of that stack. So layer number one is the model layer. And my daily driver this week has been Gemini 3.8 Flash. Now your initial reaction might be why Flash. Why wouldn’t you want something with the heaviest reasoning tier. And here’s the secret to agentic workflows.

26:22 Agents don’t work like traditional single turn prompt boxes. They run in continuous loops, so an agent might inspect a directory, update a function, execute unit tests, and then repeat that sequence 20, 40, or even 60 times just to finish one task. So when you have something that uses that many sequential hops, speed and cost compound dramatically. So a fast, cost effective model isn’t a downgrade. It is the exact thing that makes real time agentic

26:55 loops practical and responsive. Because Flash is so lightweight, it churns through dozens of iterations effortlessly. It keeps me in the complete loop without running up a massive bill. And once you have a fast model, you need a dynamic structure orchestrating it. That brings us to layer number 2, which is the harness. The tool I’m using here is anti-gravity, specifically their boost command. In one sentence, boost is a command that transforms a single model into a coordinated team.

27:28 So instead of relying on one agent to do everything sequentially, boost actually spins up an orchestrator. It delegates specialized subagents in parallel, and also it finishes with an independent verification pass that thoroughly audits the work before anything touches your code base. Here’s how to get the most out of it. First off, you don’t need to use it for everyday tasks. So, for example, if you’re just working on standard features or you’re adding a UI component or navigating a code base, the default agent is snappy and efficient,

28:00 but you want to save boost for deeply intricate engineering challenges. So for example, this table right here shows you a really good use case on when boost is super useful. So the following table actually compares three execution modes in anti-gravity. And it shows you how boost can actually change things around. So you want to save boost for the deeply intricate engineering challenges that are described in this table right here, which tells you exactly when you want to use boost.

28:31 That leads us to our third and final piece, which is layer number 3, the knowledge layer with layer number 1 and 2, you’ve got a fast model and you’ve got a coordinated harness. But now what happens when you want your agent to try and configure, for example, your Cloud infrastructure. How does it know how to do that. That’s exactly where Google skills comes in. So this repository actually recently crossed 19,000 stars on GitHub. It’s still early and actively evolving, which means the contribution window is wide open right now

29:03 if you want to get involved. To put it simply, a skill is a curated domain knowledge that your coding agent loads on demand. So it’s not just an MVP server. It is not a heavy plugin. It’s clean, precise context that is given to your agent that stops your agents from guessing and actually informs them on how to do things. So this repository contains over 100 different skills across Google Cloud, Firebase, Flutter, Maps, and many more.

29:33 And also installation is super simple. All you have to do is run this single command to install all of these skills. And best of all, because it’s completely harness agnostic. Whether you’re running Cloud Code, Codex or Google anti-gravity, they can all pull from this exact repository as you look at your own workflow this week. Think beyond just changing models. Use things like Gemini 3.8 Flash to power rapid high frequency loops. You can make use of anti-gravity boost

30:04 to do complex tasks with anti-gravity, and then also to give your agents specialized knowledge to do things on Google, as well as Flutter Maps and many more. You can make use of Google skills. Smither that was really terrific. I’m going to be jumping back into anti-gravity this afternoon to work on a project, so I will definitely be installing those Google Cloud Skills. So thank you for sharing those tips. You’re welcome and thanks to everyone, for watching the Asian factory. Leave a comment on what you’d like to see us talk about next.

30:37 All of the resources talked about in this episode will be LinkedIn the description box below. If you want to learn more about using anti-gravity to automate building software, check out this next video.