It depends on what you want from your bot, of course.
The original JinxBot was intended to be a hardcore moderation bot for Battle.net. It was an event-driven system running on three primary threads. The GUI thread (the main thread) was "below normal" priority, as was the connection listener thread (it was also marked as a background thread). The event dispatcher was "above normal" priority. Because of the thread disparity, that ensured that the event dispatcher ran as long as there were events enqueued. The event queue was also prioritized, so things like returned WC3 profiles were lower-priority than, say, channel joins, channel joins were always dispatched first. (This wasn't preemptive; if a WC3 profile was being processed, then the event dispatcher waited for that to complete first).
The way that it worked was that there were obviously things the event dispatcher wanted written to the GUI. But GUIfied things were always low-priority. High-priority event listeners implemented in plugins, such as a moderation plugin, got all event notices before the GUI did. And because Windows doesn't support modifying the GUI in any thread but the GUI thread, I had to marshal that data back to the main thread. .NET has methods called Invoke() to do this and block or BeginInvoke() to do this asynchronously, and that's what I chose to do (the latter).
As long as you have good design it's entirely possible for a moderation bot to have a GUI. There's also the possibility of decoupling the GUI from the bot completely; you can implement a protocol like
RSP (which is incomplete btw) to have a GUI communicate with your bot.
