Hi Jai! There’s no right or wrong answer here, but probably the easiest way to think about things is having one agent per execution environment. The agent is then the intermediary to that environment and the work that is shipped to it.
One agent can service multiple work queues, so your work queues can be as granular as you like - I recommend grouping deployments into a small number of work queues so that if you ever need to pause work delivery, or limit how many things are running you can do that at the work queue level.
work queues should represent multiple deployments that do similar things and can be paused / limited together, and agents represent the places those things run.