I like to think in parallel Claude instances the same as software threads. Sometimes adding more threads will make the program faster, but sometimes the overhead of managing them will not be worth it.
I tend to go for parallel agents when the task I have can easily be split into non overlapping chunks, preferably if one chunk doesn't depend on another. Let's say I'm working on a new feature which will require changes to both frontend and backend. I can first define a shared contract between them (how the API endpoint will look, what inputs it will receive, what it will output) and then spin up one agent to work on each separate part.
Or maybe you're refactoring a part of the system that has hard coupling with other components (think maybe a notification system). You could spin multiple agents for each to handle a different coupling point.
In general I think that the same good software engineering practices that help with teams can help with parallel agents. It's important to remember though, with each agent you have more code to review (using shared interfaces could help your review process) and if you don't do a good enough division you'll get a fair share of merge conflicts to fix later. Also it's important to have each agent on it's own git work tree to avoid concurrent edits to the same file
One last workflow I have for parallel agents is getting up to speed on a codebase. I can divide the codebase into discrete groups and ask each agent to read it and report the findings. This one is an easier workflow since it doesn't really matter if the agents overlap on a few files since they aren't editing it.
For me it's been mostly trial and error trying to get to a good balance between multiple agents and the overhead it brings