In practice, the Perl library code has worked out quite well. Using the libraries, building XProcs which respond to their environment is a simple task, allowing the programmer to concentrate on the code specific to their own application. The table mechanism is a particular help, removing the tedium of testing input against multiple regexps. Various incarnations of the libraries have been used by other XProc programmers with good effect. At least one major project, Adam Messinger's digital money XProcs, uses the full UDPBot code successfully.
Ideally, agents like Floyd that perform all their functions entirely inside of ccr should be implemented directly in ccrl. Writing in ccrl allows the programmer to take advantage of ccrl's benefits: if nothing else, it eliminates the need to parse ccrl itself. In addition, ccrl directly supports several features useful to building agents such as persistent data storage and multithreading.
On the other hand, currently implementing an agent on the scale of Floyd in ccrl is somewhat awkward. The biggest difficulty is the lack of ccrl development support: documentation is sparse, and it is difficult to input and debug code into a running ccr. The semantics of ccrl are just unusual enough that it takes some time to understand how to do some common operations such as storing arbitrary data and calling methods and operating on their return values. Implementing an agent like Floyd in ccrl is conceivable today; the process of doing so would be a valuable education in practical ccrl hacking.
Floyd's use of UDP protocols, while essentially functional, has a couple of shortcomings. The most serious is a lack of a reliable communication layer. While Floyd does not fail entirely in the face of communication failures, dropped packets result in incomplete information. Implementing a reliable transport layer on top of UDP is sufficiently stateful that it should probably be written in native ccrl, not in Perl.
Floyd's current session key approach to identifying responses to particular queries could also use improvement. Session keys are sufficiently random to prevent mistakes from being made --- if a Floyd somehow hears a reply that was not intended for him, he can know to ignore that message. However, the protocols are probably not secure against malicious spoofing attacks: in particular, the session key was not designed to be random and secret enough for true security. One particular problem is that UDPReceive energy propagates, so anyone in Floyd's refspace can hear the replies he is getting.
The timeout mechanism used by Floyd now to collect replies is the beginning of a multithreaded, stateful XProc. Floyd can give the appearance of doing two things at once: listening in to replies to a broadcast query while also answering simple one shot requests from other users. With a bit of expansion, the code could be extended to offer true multithreading by allowing Floyd to have multiple broadcast queries pending at once and separating out replies based on session key.