The agent/threadpoolsize simply defines the number of java threads which will running concurrently.

When an agent tries to process a task it will request a free thread from the agent/threadpoolsize allocation. And when it's action has completed it will release the thread back.

But this doesn't mean one agent will have 1 thread.

Say, for instance, you're not running any agents at all. And then 8 users decide to send a single email each. Then this would create 8 entries in the PR_SYS_QUEUES table.

Now if you start the SendCorr agent it will retrieve these 8 records and attempt to process them concurrently.

If you are running with the default agent/threadpoolsize size (I believe this is 5) then you should see 5 threads are then allocated to send the first 5 emails. And as one thread completes its task, it will be freed up and then the SencCorr agent will take it again to process one of the remaining 3 emails.

But returning to your question about configuring this to a much higher value, and whether this is advisable or not.

I would image if you have reasonably efficient agent activities then most of these allocated threads would be idle all of the time. And in the worst case scenario (where all are active with some task) this will naturally put some overhead on your application server in terms of CPU and memory.

Unfortunately I don't have any kind of ballpark figure to suggest how best to size this.