AI Engineer Europe 2026
Cooking with Agents in VS Code
Read the talk
Cooking with Agents in VS Code
Use local, background, and cloud agents to divide a Python application’s work while keeping the right testing and review checkpoints in the developer’s hands.
From a talk by Liam Hampton
Before you start: Familiarity with Git branches, pull requests, basic Python, and VS Code will help you follow the demonstration.
What should an agent actually take off your hands?
Can one prompt create an entire application and solve all its problems? That expectation is the starting problem. Agents now appear in terminals, CLIs, chat windows, and editors, adding choices and cognitive load before they deliver useful work. Liam Hampton connects those expectations to the questions businesses ask next: where are the productivity gains, what is the return on investment, and when does spending on infrastructure and services produce a benefit? Using an agent deliberately starts with understanding the work you are handing over.
Token spending is another concern, distinct from overall productivity. Hampton recounts seeing an unidentified repository on LinkedIn that claimed pirate-style chatbot speech reduced token use. He supplies no measurement; the anecdote captures how actively developers are experimenting with cost. The more practical investigation here is what agents can access in a workspace, how they operate, and how to use them through VS Code and the CLI. Those questions apply beyond GitHub Copilot.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Separate execution environment from developer involvement
A local agent works alongside you in VS Code. Local describes the interaction and workspace, not necessarily where inference happens: the agent can use a remote model or a locally hosted model. The defining feature is close, ongoing developer participation.
A background agent, here provided by GitHub Copilot CLI and accessible within VS Code, works more independently. Its changes live in a Git worktree: a separate working directory attached to the same repository. In this workflow, that directory has its own branch. A worktree need not be a subdirectory, and Git also supports worktrees with a detached HEAD. This separates working files without requiring a separate repository.
A cloud agent moves execution onto remote infrastructure using GitHub services. Hampton uses it for work he wants to supervise less closely, such as documentation. The three environments therefore offer different ways to participate, rather than three levels of model intelligence.
| Environment | Example assignment | Desired involvement |
|---|---|---|
| Local | Write tests | Inspect code and iterate closely |
| Background | Build a front end | Delegate implementation, then inspect |
| Cloud | Prepare documentation | Hand off work for later review |
Tests stay local because Hampton wants to understand what they cover. Front-end implementation gets a background agent because repeated interaction can become arduous; he introduces Autopilot for that assignment. Documentation—README files and open source preparation, potentially using skills—goes to the cloud. His description of background work as fifty-fifty is a qualitative balance of involvement. VS Code supplies one entry point for these environments and third-party agents, reducing the need to manage each through a different interface.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the front-end agent a stopping point
The recorded walkthrough starts with a plain Python product store supporting create, read, update, and delete. Hampton uses a prerecorded build to fit the session. The application works, but its presentation needs attention, so GitHub issue 25 requests a better front end. He selects a CLI background agent and asks: “Summarize and plan a solution to issue 25.” Planning comes before implementation.
The background agent can iterate without Hampton watching every action. He enables Autopilot, described as a preview feature in the recording, to avoid repeated approval questions for tool calls, including MCP calls. He also warns that this can be dangerous. Once the plan is ready, he authorizes implementation with a boundary: stop before creating a pull request and let him test locally. The useful delegation includes both the assignment and the point at which control returns to the developer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Add documentation and tests while the UI builds
With the front-end assignment running, Hampton opens another chat and starts a cloud agent. This repository lacks the supporting files expected of an open source project, so he requests a README, contribution guidelines, and the other necessary documentation. That assignment can proceed while he returns to the code.
The next missing piece is tests. An existing custom agent contains guidance for writing tests for this Python application. Hampton selects a local session, chooses Claude Opus 4.6 with medium reasoning for speed, and asks it to write unit tests. He can inspect the work as it proceeds while the cloud agent prepares documentation and the background agent builds the front end.
The local agent writes and runs tests, and Hampton reports that they pass. Inspection then reveals a different problem: the route errors are unfriendly. He asks the agent to update both the route error handling and its tests. Passing tests do not end the interaction; they create a checkpoint from which the developer can identify behavior that the original request did not address.
For a Python product store, that paired change can be expressed with a small error contract and a test for it. Here is an illustrative missing-product example using Python’s standard library:
python
import unittest
def get_product(products, product_id):
product = products.get(product_id)
if product is None:
return {"error": "Product not found"}, 404
return product, 200
class ProductErrorTests(unittest.TestCase):
def test_missing_product_has_a_clear_error(self):
body, status = get_product({}, "missing")
self.assertEqual(status, 404)
self.assertEqual(body, {"error": "Product not found"})
if __name__ == "__main__":
unittest.main()
The behavior and its expectation change together. In the walkthrough, this close feedback loop remains local while the other assignments continue independently.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Check progress, then run the right working directory
Hampton next checks the running assignments. Updated code and tests appear; the background assignment is reported finished, and the local tests pass. He remarks that some footage was not sped up, but the walkthrough supplies no timed speedup comparison. VS Code keeps the sessions visible together, so he can move between closely supervised work and delegated work without leaving the editor.
The pull request extension shows a documentation pull request from an earlier run. The cloud chat started during this walkthrough is still taking time. That distinction matters: the displayed pull request demonstrates the review path, not completion of the current cloud assignment.
The background agent has respected the requested pause before a pull request, but its initial instructions for testing are wrong. Hampton reminds it that the application is in a Git worktree. The local validation sequence is then:
- Identify the separate worktree containing the generated front end.
- Enter that directory and run the Python application there.
- Resolve the port conflict that interrupts startup.
- Open the resulting Product Store UI and inspect the change.
The distinction between directories is operational: running the original checkout would not show the agent’s isolated changes. Once startup succeeds, the browser preview shows a styled Product Store with name and description fields, an Add product button, and an empty product list.
Hampton also demonstrates new error checking, then recaps the division of labor: local tests for close involvement, a background front end for more independent implementation, and cloud documentation for a longer handoff. The application has been exercised locally; the recording does not show a final merge or production deployment.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What runs behind the cloud session
Cloud agents run in isolated GitHub Actions environments. Hampton raises cost as a common question, but the explanation that follows concerns execution and capabilities, without a price or billing calculation. MCP servers extend the agent’s tools and context: GitHub access supports repository work, and Playwright supports screenshots and automated front-end testing. He also mentions workflow authoring and dynamic workflows.
Hampton describes network allowlists and restrictions on direct pushes to main as safeguards. These constrain an agent’s actions; they do not establish blanket safety. Current documentation, which postdates the demonstration, makes the boundaries more precise: built-in MCP defaults give GitHub repository-scoped read-only tools and Playwright localhost access; the firewall excludes MCP servers and setup-step processes. The branch restrictions govern where the agent can push, not whether it can read the default branch. Human review and testing remain necessary.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make the workflow reusable
The custom test agent is one of several ways to supply repeatable guidance. Hampton introduces four building blocks that also have counterparts in other agent tools:
- Custom instructions define how the agent should operate.
- Custom agents specialize behavior for an assignment, such as writing or fixing tests.
- Prompt files make useful prompts reusable.
- Agent skills package task-specific guidance and resources.
Hampton compares skills to a newer version of AGENTS.md. Treat that as an analogy: Agent Skills use SKILL.md directories, can include scripts and resources, and load on demand. They complement standing instructions rather than simply replacing them.
The interface tour brings those pieces into one place. Hampton opens the GitHub Copilot chat pane and clicks its cog to reach the customization interface. The agent list contains his custom test agent and the built-in Ask, Explore, and Plan entries. Supplied, editable skills include addressing a pull request comment and creating a pull request.
Instructions and prompts have their own entries; creating an agent is one prompt example, and prompts can initiate skills. Hooks and MCP servers are configurable too, although this workspace has no instructions or hooks configured. The same interface also exposes Claude customization, including plugins, hooks, instructions, and skills. It is a place to inspect and configure the agents’ behavior, not just a menu for starting chats.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Connect reusable guidance and external tools
Awesome Copilot provides an open source starting point for customizations. Its material targets Copilot, but Hampton encourages adapting it for other AI tools. He also describes an MCP server for accessing the project from a workflow.
MCP, the Model Context Protocol, connects models and agent workflows to additional tools and services. Hampton uses Azure, GCP, and AWS resources as examples of authenticated access. He contrasts these with tools and documentation servers that can be used without authentication, including Playwright and Microsoft Learn. The authentication requirements depend on the service being exposed.
The closing capability list returns to VS Code as the shared entry point: first-party and third-party plugins, chat customization, what Hampton describes as full MCP specification support, and connections to GitHub Copilot CLI sessions. Together, these let the developer manage different execution environments within the same workflow. Hampton ends by inviting discussion of how others organize their agent work—the central design choice throughout the demonstration is how much involvement each assignment needs.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Community examples of custom agents, instructions, skills, hooks, workflows, and plugins.
Commands for creating and managing separate working directories attached to one Git repository.
How to package reusable agent workflows with SKILL.md, scripts, examples, and other resources.
Further reading
Firewall configuration, default allowlists, and the processes outside its protection.
Agent profile fields, tool permissions, and default GitHub and Playwright MCP access.
Updates since the talk
Current controls for tool approvals and autonomous execution, including Autopilot's security implications.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hello, everybody.
- 0:16
It's great to see so many of you who are still here at the final, on the final day, right at the end. So I hope you've all had a great conference.
- 0:23
Uh, show of hands, who here uses GitHub Copilot?
- 0:28
Awesome. Lovely stuff. Uh, [laughs] who here uses VS Code with GitHub Copilot? Awesome. So I'm gonna be talking about both these things today. I'm gonna be talking about cooking with agents in VS Code.
- 0:40
Now, the gentleman before was speaking about cognitive load of agents, and that is absolutely correct. You see so many different things now with agents, and they're popping up all over the place, from the CLI, in the terminals, in chat windows, in other editors, et cetera, et cetera.
- 0:56
But we still somehow seem to find ourself in this sort of paradigm where everybody thinks agents can solve the world's problems. You still see developers, and I still speak to folks who think we can do one-shot prompts that'll create a wonderful application or solve all of their issues in one go.
- 1:14
Absolutely not the case. And we end up asking these questions from a business perspective of, what's the ROI? What's the productivity boost? Where are we seeing our money? And at the moment we're seeing this whole expenditure on AI and all of this infrastructure, all of these sort of toolings and services, and we're still yet to really reap
- 1:30
the benefits of those services. So when we look at how people are spending and how businesses are looking at AI, we really need to be very careful with how we're utilizing the tools and services.
- 1:43
We need to be careful about token spend. We need to be understanding the tools and the flexibility. I read somewhere yesterday on LinkedIn, uh, somebody has released this repo, it's growing massively in popularity, uh, and it's talking like a pirate for your, your chatbot to talk back to your, your AI services and language models to talk like
- 1:59
that, because it reduces the token spend. Now, people are coming up with these really intuitive and really fun ways to get around token expenditure and really pull in those benefits, uh, very quickly.
- 2:10
So what I'm gonna be talking about is GitHub Copilot agents. Now, this doesn't just apply to GitHub Copilot, this also applies to other AI agents as well. So when we're looking at Copilot agents around context, what they really have access to in your workspaces, how they're being used and utilized from within VS Code and the CLI, we're
- 2:28
going to be looking at all of those things very shortly. So just a plain and simple, what kind of agents do we have at the moment? Now, we're looking at local agents.
- 2:39
We've got local agents which are in VS Code. You may use Claude, you may use all these other AI services, still applicable, still running on your local machine with remote models, anything that you're really using.
- 2:51
Maybe you're using locally hosted ones as well. But this is a way to have local models interacting with you side by side, very hands-on, very much in the context and human-in-the-loop.
- 3:03
Then you've got background agents. Now, we use the GitHub Copilot CLI. We have also got access to that within VS Code. But this is more of an isolated way to be using them.
- 3:14
Now, we are actually using Git worktrees. Show of hands if you know what Git worktree is and who uses them. Awesome. Wonderful. Uh, for those of you who don't know, uh, easy way to explain that is it is a branch that is mapped to an isolated folder within the workspace that you're working in, like a sub-directory, just
- 3:30
a chop of your code with its own little branch associated to it. Very similar to a Git branch in general. Then you've got cloud agents. Now, cloud agents is quite an interesting one, because it allows you to scale outside of your organization very, very quickly and utilize a lot of the power of, I guess, the cloud and
- 3:48
some of the services that we're using in GitHub. Now, we use these when we don't want to be touching it ourself. I use this when it comes to writing documentation or sort of having less of a hands-on approach.
- 4:03
So when would we, when would we use a local agent? Well, I'd use a local agent when it comes to writing tests. I want to be really hands-on with my tests.
- 4:12
I want to understand what's going on in the code base. I really want to be in there in the weeds. When will I use a background agent? Well, a background agent would be great if I want to be sort of a fifty/fifty.
- 4:23
I want to create a UI for a front end o- of an application. I kind of want to know what's going on. I don't really want to hand it off to a cloud agent, 'cause I don't want to be fully out of the loop, but I also, also don't want to really be hands-on to and fro myself.
- 4:36
'Cause that can take time. That can be quite arduous. That can be quite annoying.
- 4:40
So I would use a background agent, and I'm gonna show you how I'm using Autopilot to do exactly that with GitHub Copilot in just a moment. When will I use a cloud agent?
- 4:48
Well, I would use that mostly for documentation. I hate documentation. I don't like writing it. I don't think many people do, unless you're a content developer. Uh, I really just pawn that off to the cloud agents, and that could be making a repository open source friendly.
- 5:02
It could be writing a README, using some skills to do that as well. So what I'm really looking at is VS Code as a single entry point for AI agents.
- 5:13
We have got third-party support, we have got background, we've got local, and we've got remote entry points for all of these agents. So the ultim- ultimately what we're trying to do is understand where you are sitting as a developer and how easy we can make it for you to use these agents to reduce that cognitive load.
- 5:32
Seemed quite complicated, but it's actually really straightforward. So I'm gonna show a video now. I was gonna do this live, but I don't really think I'm gonna have time to do all of this live.
- 5:39
So I'm gonna whiz through this video. So I'm gonna start with a very simple Python application. This is just a CRUD, well, create, read, update, and delete. Just a very simple product store.
- 5:52
Not very pretty, not very good. As you can see, pretty straightforward. What I actually want to do is create a front-end UI for it. So I've got a ticket up in GitHub, and I'm saying, "Hey, this is wonderful.
- 6:05
Going out of front end, we need some more prettiness here. We need it to look good." So I'm gonna say, "Summarize and plan a solution to issue 25." Now, you'll notice I'm actually using a CLI background agent at this point.
- 6:20
Now I'm using that because I want it to be sort of hands-on, hands-off, a little bit of understanding what it's doing. Also don't really care if it messes things up.
- 6:28
It can go and iterate. I'm also gonna be using autopilot. Now, autopilot is currently in preview, and this just means it's not [laughs] gonna ask me a bunch of questions if it wants to do a bunch of tool calls.
- 6:37
Great, wonderful, can be very dangerous. Use that your pro- for ill, right? Don't, don't just abuse that one. Um, but I'm using it here to create a plan. I don't want it to ask me every single time I want it to do an MCP call.
- 6:48
So I'm then saying, "Wonderful. Here's the plan. Now start it, but before you create a pull request," because on autopilot it will do a pull request, "stop and pause and let me test locally."
- 7:00
Whilst that is off doing its lovely stuff, I can then move on to my next stage, where I'm gonna be using another kind of agent. So I'm just gonna go and leave that one behind.
- 7:12
Let's go and spin up a new chat, and let's go and start a cloud agent. I've noticed that, uh, this is not a very open source friendly repository. I want this to be, have a README or ha- have a contribution guidelines, have all this, uh, all these READMEs that I really want as an open source project.
- 7:29
So I'm gonna pull that off, I'm gonna say, "Hey, go and make this open source friendly. Add all the necessary files for it." Don't really care. Now, as a developer, I can go into my code base and start poking around.
- 7:39
I've noticed that I don't have any tests, so I'm gonna go check out, and I've noticed there is a custom agent available for me in VS Code. This custom agent is just essentially explaining and showing how to be using or how to write test cases for this Python application.
- 7:57
So what I could do now is start spinning up a local agent. So just like that, at the very bottom, I can click Local. I'm gonna select Claude Opus four six.
- 8:07
I'm gonna have medium reasoning. I want it to be kind of fast. I don't really care for it too much. It's got a great understanding in this custom agent.
- 8:14
Go and write some unit tests. Now as a developer, I can still skim through. I've got very much a hands-on, to and fro with a local agent. I've got a remote agent doing some work for me, and I've got a background agent creating a new front end.
- 8:28
So here I can see, right, it's, it's written some tests. It's gonna go ahead and try and turn, run them. It's passing the tests. But I've also noticed that there's some other problems in the code.
- 8:37
It's not very friendly. The errors that are coming back are not wonderful. So I'm gonna say, "Go and update the error handling on the routes and update the tests as well."
- 8:47
So you can see I've got a lot of to and fro with this local agent. I've got my remote agent working, and I've got my background agent working all simultaneously.
- 8:55
So whilst that's going off and working, I can go and check out what my other agents are actually up to.
- 9:02
So as it's working through this, you can see Copilot is just gonna be skimming through. I didn't actually speed up some of this video. This is all pretty quick.
- 9:09
I did this pretty, pretty quickly, uh, with these agents. But there you go, you can see some of the code is updated. We've got the new test, we've got the code updated.
- 9:16
Let's go and check out the background agent. That has now finished, which is cool. Let's go and check on the remote agent. How's the remote agent getting on?
- 9:26
Well, actually this is the, this is the test. Run the test. The tests are passed. That is the local agent. That's now finished. Now I can go and check out my remote agent.
- 9:38
So as we're walking through this, we can see as a developer, I've got very much hands-on, hands-off. I'm working with multiple agents simultaneously. We can see where they're running all within this single context of VS Code.
- 9:50
Now, if we go and look on the pull request, uh, extension in VS Code, we can see that I've now got a pull request, and this is one that I previously ran earlier.
- 9:58
The one that's running in the chat is actually taking quite a while. But the principle still stands. It's running all these different agents at the same time.
- 10:08
So all I really want to do now is go and check out my background agent. I want to go see it working. I want to go see this new front end that I've just created.
- 10:16
Now, I asked it to pause before I pushed up a pull request and tell me how to test it. So I'm gonna say, "Well, actually, the way you're telling me how to test that is wrong."
- 10:24
So I've still got hands-on, hands-off. It's more of a fifty-fifty. I'm saying, "This is working in a Git worktree. How do I actually run this?" Now remember, this is what it currently looks like as an application.
- 10:34
So I'm gonna go check out the new directory, which is a Git worktree. I'm then going to run this Python application. You'll see a very drastic change between what is created in my single directory versus what I currently have.
- 10:47
There is a port conflict here. Um, so hurry up and run that.
- 10:55
There we are. So likely that this is the new product demo. Now this is the third agent that I'm running simultaneously, and that is essentially a great way of how you're using different agents within one context to kick it all off using GitHub Copilot.
- 11:10
That's new error checking, and that is how I've been using multiple agents. So one code base, three problems, three separate agents fixed all at the same time. The local agent was writing my test for me because I wanted hands-on.
- 11:25
I really wanted human-in-the-loop. I used my background agent to write the front end because I don't really care. W- what it does is quite an arduous task. It's quite big.
- 11:34
It's quite time-consuming. And then I used my cloud agent to write my documentation for me. So all in all, that's a pretty successful run. So how are cloud agents actually working?
- 11:47
Because I get this question quite a lot. How much is it gonna cost? How is it working? What are they doing, and how do I get them running? Well, they're actually running in GitHub actions.
- 11:56
They're pretty safe and secure because they're running in a isolated environment. They have got extended context through MCP servers. Who here uses MCP servers, just out of curiosity? Awesome.
- 12:06
So cloud agent actually has, uh, access to the GitHub MCP server and the Playwright MCP server, so you can do testing with screenshots, you can do automated front-end testing, and you can obviously write your workflows.
- 12:19
You've got, um- The, the dynamic workflows now, and it has got built-in safeguards. So you've got network firewalls. You don't want this agent talking to a whole bunch of different things.
- 12:29
It is absolutely whitelisted and restricted. It also doesn't have access to your main branch, therefore you're not able to push directly to your main branches. It's very much restricted in that sense, so it is very safe to use.
- 12:41
Now, I mentioned earlier, this is very much GitHub Copilot, but it is not just GitHub Copilot that this applies to. This actually uses all the same concepts across all different AI agents, uh, that you can use.
- 12:53
So custom instructions very much defining how the agent is running. You've got custom agents, which is what I showed you today in that short demo, where you're able to use very specific agents to tackle certain problems, i.e.
- 13:05
fixing test cases or writing test cases. You have prompt files, which will help you with your prompting, and agent skills. Agent skills is more of like the, the newer version of agents.md.
- 13:14
Ev- there's always, like, a new thing that's coming on every single week now. So all of this is actually applicable to GitHub Copilot as well as other AI services too.
- 13:25
Now, inside VS Code, this is a modal which is very recent, and I can jump out of the slides in just a moment to show you exactly, um, how this looks.
- 13:34
So if I was to go over to VS Code, open up my GitHub Copilot chat pane, and if I click the cog up here, you can actually see everything that I have in one user space for you to customize the chat and the agents that you are running.
- 13:47
So whether you've got agents, I've got my custom test agent, I've got my built-in agents, which is ask, explore, and plan. I've got some skills. So this is essentially what some of the VS Code team sort of preempt you to be using here.
- 13:58
So you've got some extensions. You've got address a PR, uh, comment. You've got create pull request. You can jump into these and edit them as you wish, and this is just intuitive skills that we have popped in there for you.
- 14:09
I don't have any instructions, but this is where you'd have your instructions file, your prompts if you've got any built-in prompts like creating an agent. Just different prompts that can then go off and kick off skills.
- 14:18
You've got hooks. I don't have any hooks on this one, but a very good example if you wanted to create or configure some hooks, you can do so with, uh, Copilot inside VS Code, and any MCP servers as well.
- 14:28
So you kind of have this whole control plane and this modal which allows you to control your agents and chat customizations from within one single place. This isn't just confined.
- 14:38
We have third-party support as well, so there is Claude as, uh, down here. So you can have access to all of your Claude things, uh, and all of your plugins, uh, hooks, instructions, and skills for Claude too.
- 14:48
So it's not just restricted to VS Code and GitHub Copilot.
- 14:55
So if you want to get hands-on with some of the, uh, skills or customizations, we have got this awesome open source project which we're running. It's called Awesome Copilot.
- 15:03
It's aka.ms/awesomecopilot. Like I said, this is directed at Copilot, but it's absolutely not just for Copilot. You can use this and massage them and use them for other AI tooling as well, 'cause we do know that people in the community use more than just Microsoft things and GitHub things.
- 15:21
We also have an MCP server, so if anybody's interested in utilizing this from their, uh, from their workflow from an MCP standpoint, we also have encapsulated that into an MCP server.
- 15:31
For those who don't know about MCP, so the Model Context Protocol is a great way for you to get hands-on and extend the, uh, LLMs that you're working with or any of the chat customizations that you have.
- 15:42
For example, if you wanted Azure or talk to your Azure resources or, I don't know, GCP, AWS, et cetera, you can go through an MCP. It'll obviously be locked down by authentication, uh, but there's also free ones as well and open ones which don't require authentication, like Playwright and documentation ones, i.e.
- 15:58
Microsoft Learn, uh, and so on and so forth. So just in time, uh, as a wrap up, Visual Studio Code is a single entry point for AI agents, and we're really building this agentic workflow around multiple different services.
- 16:13
We've got third-party plugins, we've got first-party plugins, and we've got the full spec support for MCP. We've got chat customizations, and you can connect to the GitHub Copilot CLI sessions through VS Code.
- 16:25
So it's all in one single sequential, uh, sequence for you as a developer inside your workflow. I would love to hear more about your workflows and what you're using and the agents and how you're using them after the session, because I believe I've only got just less than a minute left.
- 16:40
So thank you ever so much for listening, and thank you very much for coming today. [audience clapping] [upbeat music]