We would like to identify a bot by its algorithm -- or, slightly more practically, by the code that implements it.
Unfortunately, there is no way to reliably authenticate what algorithm a network entity is running. We can only authenticate JIDs. Therefore, while a bot can advertise its algorithm in the form of a URI, it is (like a player) identified by a JID.
An algorithm URI is chosen by whoever writes the bot code. Like a ruleset URI, it should be a URL pointing at a web page for the program.
(It is still possible for multiple bots with the same algorithm to share a game history. To do this, they would have to connect with the same JID, albeit with different resource strings. This still requires that they all be operated by the same entity -- a common JID means a common Jabber password.)
The bot factory is a new class of Volity entity. It sits on the Net, waiting for a request; when it gets one, it creates a bot, has it join the requested table, and plays a game. (It's analogous to a parlor, but instead of generating referees on demand, it generates bots.) A factory handles exactly one game (one ruleset), but it could support one or several bots (AI algorithms).
A parlor can be configured to run one or several bots itself. (This is how the first generation of bots worked, before bot factories were conceived.)
A parlor can also (independently) be configured to offer access to some number of bot factories. Players on that parlor are, however, not limited to the listed factories. (A game client might be written to query the bookkeeper itself and look for bot factories registered with the given ruleset.) The parlor's list exists for the benefit of people who want to run parlors with associated bot factories.
We refer to these as "retainer.html" class=wikipagelink>retainer bots, in the older classification. (A true ronin bot does not operate by these rules at all -- the Volity network treats it as an independent player.)