The background agent is absolutely fantastic and has revolutionised my development workflow but it also has its limitations in its current state.
Thanks to the fantastic Background Agent API that is available we can create our own abstractions while we are waiting for Cursor to create official solutions.
For instance, one of my customers have a huge job of porting a 20 year old codebase from legacy Dotnet Framework to a more modern .NET core codebase.
They have already laid the foundation, ported a few of the features so there are good examples and this is enables us to work with background agents in a clever way where it is literally just “Look at old code, look at new conventions and pattern => refactor!”
The codebase is HUGE and it would be tedious to spawn background agents for each feature, also some features rely on each other etc.
The solution that we came up with is an orchestrator that initiates with a plan mode, where we very in depth explain what we want to do, this spawns a background agent that is ONLY responsible for digging deep into the codebases, gather as much context as possible and come back with either
- Follow up questions
- A plan
The planning agent comes back with clear instructions for one or many subagents.
Some tasks rely on each other, so we kind of copied github actions concept of “needs”.
So for instance, it can come back with a plan where first subagent is responsible for creating “common functionality” that all other subagents will need. And then that subagent will execute first and when it reports back with a “success” all other subagents that rely on the intial subagent can start working in parallell.
Our solution is far from perfect (you see a bug in the ui where two tasks are duplicated haha), but it doesnt NEED to be perfect as it does the job for us. I expect Cursor to release similar (more polished) features like this in short 
But until then, explore the background agent api and tailor the solutions that YOU need!