And going farther on your exploration, you might look at rules-based DCFT approaches:
http://web.stanford.edu/~ouster/cgi-bin/papers/rules-atc15
Here the effects would actually be produced based on the state of the model with facts (and presumably intents) in your factoring just changing the model state.
I haven’t tried converting Elm code to this structure but the paper reports strong success and I have built systems in the past that more or less followed this pattern and it definitely helped with reasoning because deciding what to do next — in Elm which commands/effects to issue — was separated from other state evolution.
In your example, I would imagine that this would lead to a field in the state containing something like:
type KingRequestState = NotAsking | Requested | Asking
The intent to get the King in the North would move this field from NotAsking to Requested but make no other changes. The rules for producing effects would generate the effect to get the king when the field value was Requested. And the effects to command conversion code would set the field to Asking when it produced the actual command. Both successful and unsuccessful GotAnswer responses would set the field back to NotAsking.
With everything broken down into intents, facts, and effects, and changes broken across interpretation of intents, application of facts, application of rules to produce effects, and conversion of effects into commands, it could easily become a bit much and might well be worthy of recombination into fewer parts, but from the standpoint of figuring out those parts, it seems like an interesting experiment.
Mark