A resource pool is a collection of resources that can be used by one or more agents. The number of resources available is defined by the pool and not the number of agents using the pool.

e.g. I have a resource pool called "Coverity Licenses" it has 5 units. I have 20 build agents 15 of which can use the "Coverity Licenses" resource pool. When a build step requires the "Coverity License" the build agent will draw from the pool, leaving only 4 licenses available.

This concept can be simulated at the moment by defining a machine that contains 5 units of the "Coverity License" resource and creating a parent step that encapsulates any build step that requires Coverity. However this is not ideal.

1- It assumes I know the difference between a node based and grde wide resource, e.g. If I change my license from 5 floating license to 10 licenses on specific machines I will need to rewrite all my configurations.
2- It messes up the process of transferring files to and from build agents, I now have to transfer files from the machine that did the checkout, to the machine that owns the "Coverity License" resource then to the machine that will perform the build.
3- Sometimes I may want to define a resource on a build agent. In this setup, I write a custom Node Selection script that checks for a list of resources plus the names of any resources that are defined as User Attributes on the node itself, e.g. I define a list of resources for a step "GCC" I also define a list of resources on a build agent "Win32 licenses" I join the two lists to form a set of resources that must be acquired to run a specifc step on a particular node. This may sound like a side case but it is actually a very powerful feature, see here for a full discussion:
http://forum.pmease.com/viewtopic.php?f=1&t=2843&p=10691#p10691