You can have a great AGENTS.md or copilot-instructions.md, but sometimes the model just doesn't care. It can happen because it loses attention, as context grows, or just because it thinks it's better than you. At the same time, agentic coding let's us multitask much more easily. Fire up 5 sessions and fix 5 bugs at once, much wow! The combination of the two changes a lot in a development cycle, and you might have a hard time keeping up with all of the output at times. You have to make sure all that new code follows basic rules like type checking, linting, and testing so you can focus on the bigger picture.
To complicate things, the Copilot CLI (like Claude Code) manages it's own sessions, separately from ones started in VS Code, even if you select Copilot CLI from the drop down. And some hooks for VS Code work for the CLI (managed by VS Code or otherwise), some don't. Some have different inputs and outputs, and they may share a name or a variation of it. Claude hooks can work in VS Code as well, so be careful to not set them up where both run in VS Code. It's all... chaotic.
But down to the tips. First, you can tell the agent automatically to do things in a few ways, but for me, I'm trialing an MCP server that needs to be used all the time, so I chose hooks. Before each session, I simply tell the agent to respect the rules and it has helped a ton with getting it to use my MCP server more consistently. Pretty simple, after you figure out SessionStart is one of the hooks that can work with both the CLI and in VS Code.
Even then, it doesn't always write or fix tests on it's own, so I wanted to create a loop. After the agent is done, I want to type check, lint, and test, and ensure there is 100% test coverage. My vitetest.config.ts already every coverage gate set to 100% except for lines, so it will return with an exit code of 1 or 2, when I run vitest, so I know when there's a problem. Fix problems, verify with hooks there are no more, repeat as needed. There are a few more intricacies worth noting that I've added comments for in the gist, but you could tweak it any way you want. Maybe you want to use a cheaper model for those fixes. You can create a new agent that defines which model and even hooks to use. That means you could chain each step (type check, lint, test, etc) and each one could have specialized instructions!
But there is one more intricacy worth mentioning with this approach. By default, VS Code runs everything in the workspace, as in against your local branch. So if you run multiple agents at once that are working on related code that is incomplete or wrong, it will pick up on those errors and try to fix them, even if they are already being worked on in the session that caused them. That's not ideal and where worktrees come in. Choosing the CLI gives you the option to use git worktrees behind the scenes, which allows you to checkout multiple branches at once. If you do choose to do something like test your entire project after an agent is done, it won't pick up on the problems from other agents.