In my initial setup, meaning the one I used for the demo, I did not account for this possibility. So let’s think about this. The whole reason we’re using microservices and relying on context for entity and intent identification is because we have ambiguous responses. If the user wants to respond to the “What is your name” question by giving us his full name, e.g. ’ my name is John Smith’, it should be easier for us to understand his response and we could identify it as ‘inform_name_lastname’ with the name and last_name entities, instead of the generic inform intent. That would be the first way to deal with it that you identified in a).
The other way to do it would be to include this possibility in the microservice itself. I.e. the ‘first_name’ microservice NLU model would be smart enough to also understand 'my name is John Smith" and to extract ‘John’ as first name and ‘Smith’ as last name. That would be similar to your approach b).
The third way would be for the ActionSNLU invoked after the generic ‘inform’ intent to NOT send the user’s message to the appropriate NLU microservice determined by the context. Instead you’d run some logic, either sentence length as you suggested, or maybe presence of multiple entities or something else, to figure out if this is a simple one word answer or something that you could use some other NLU service for. That would be like approach c).
I think depending on your situation anyone of those could be more appropriate. In general though, it seems to me that since the whole reason to use context-based microservices is to help the NLU model disambiguate, where the response is not that ambiguous, your general NLU model should be able to classify the intent properly and extract the correct entities (option A).
I hope that makes sense.