I guess you could boot up a pool of guilds in your process or better yet get generated on demand as requests are coming in, to process the request, and kill the guild off when the process is done since the request object shouldn't be shared.
It all really depends on how much overhead there is to create and destroy guilds. If it's easy then ideally you could start 100s of guilds or 1000s should your hardware allow it.
I see guilds as a subprocess with its own isolated resources.
Ideally guilds could be equivalent to lightweight processes at application level (not OS), much like in Erlang. Then they could be scheduled to run concurrently using OS threads (multiple guilds per thread) and take advantage of multiple cores. That's part of BEAM, the Erlang VM. I think it's going to take a while.
It all really depends on how much overhead there is to create and destroy guilds. If it's easy then ideally you could start 100s of guilds or 1000s should your hardware allow it.
I see guilds as a subprocess with its own isolated resources.