Well, it could be a function that allows CS to issue multiple calls to different CS server bots, N is number, at the same time, and wait for the results of N bots or timeout after y milliseconds and continue.
But this creates a lot of complexity for the benefit of a faster response. I am not sure it is really worth it.
And I imagine that this would be difficult to change within CS.
However, this would enable a developer to change the way that CS can be implemented.
This is how I see it.
Essentially, you would create a very slim, main bot, that does preprocessing, minimal main processing and post-processing.
In the main processing, it looks for a responder and then the current, then pending topic. And any special processing, like gambits in special situations. If a response is found, it would send the response. Essentially the same as the current simple control script. I don’t recall if this is exactly what I am doing, but it would probably be the same up until this point.
The changes would be in the second layer.
After the most common processing, if there is not a good response, it would issue parallel requests to the subtopic bots with matching topic concepts, testing for responses, and the main bot would wait for responses from all subtopics or timeout after y milliseconds and continue.
The main bot would receive the results, and decide on the best response, and then make the needed updates to mark the rejoinder, update the current and pending topics, and any other housekeeping.
If there is not a good response, go through the topics in parallel looking for a good response. The main bot would pick one from the many and do the housekeeping.
And then the rest including gambits and other last-ditch efforts.
The benefit would be a much faster response, because each bot is working in parallel. And you can create really big memory specialized bots. Maybe put them on different servers and auto-scale them when they are at cpu capacity.
This could be the end state, I would have to make some changes to make this, but I am sure I would make it work.
Not clear on the user files, and if that could be shared from the database.
Another benefit would be that you could probably switch out subtopic bots on the fly, without having to restart the main bot. Each subtopic bot could undergo A:B testing without code changes in the main bot. But I think there is special logic to see if a topic changed, and this changes the processing. I am not sure how this would be reconciled.
It is adding a lot of complexity, and I am not sure the response improvement outweighs this increase in complexity.