Well, this is something one might naively hope for, unfortunately it only works to a certain extent.
I think you're still confusing model and "LLM app" there.
I'm not that versed myself in these things, but you can, for example, look at the conversation templates, stop markers etc. in open weight models on HuggingFace, or play around with these things by yourself and modify them using llama.cpp or ollama (the things I mention in this paragraph are, AFAIK, not part of the model). These, and parameters like temperature, sampling etc. are just the things that can be controlled without touching the model.
Of course, frontier models and their uses have supposably a lot more machinery built around them to orchestrate their usage, apart from even chatbots defaulting to "agentic" behavior for many use cases.
And models still are specialized, and fine-tuned for instruction usage, so things like the conversation template, system prompts won't be enough to bend the characteristics of such a model in all desired directions. But "general-purpose model" has become a very fuzzy term by now.
If you want to use a custom chat scheme, use it as an overlay, don't break the default chat/tool use/reasoning template.
Matches my superficial experiments with trying to tweak Ollama's "modelfile" using some LLaMa- or gpt-oss-based instruction-tuned model as "base".
I need to experiment more with base models. The time from the end of 2019 onwards, when I first came across talktotransformer, it felt so magical.
Getting meaningful things out of these things can feel so... restraining.
And on the other hand: I'm tbh freshly stuck in the stage of being amazed at what current frontier coding models and apps can do.
1. The user should be able to prompt the AI to act differently from its default behavior. A human assistant is capable of role playing without always sounding like an assistant.
2. If the user asks the AI to follow the script and not allow unrealistic things to happen it should push back. The user is not always absolutely correct.
Even if it's not supported somewhere (e.g. z.ai API which isn't mature enough and has neither assistant prefills nor actual structured outputs), it's still better and more seamless than using the default user/assistant scaffolding for role alternation.
1. You're sending your in-character inputs to an instruction-tuned model under the user role, in a multiturn chat. It's biased to treat these inputs as instructions and this behavior will show itself no matter what. Besides, the rigid structure of the assistant persona reply (usually tl;dr - explanation - "would you like to know more") is going to leak into such roleplay no matter what. To solve this problem on a generalist model you need to make your harness lump up all character turns into a seamless stream with formalized inline markers (e.g. screenplay-like paragraph prefixes or XML), use one of them as a custom stop string, send all this under one role (e.g. assistant), and prefill the assistant reply with a few messages from the past roleplay. This will break the rigid instruction-tuning structure (and also the cache, since caching breakpoints are based on chat turn boundaries in most APIs).
2. The models are simply not trained to "take incorrect actions back" in a story, this wouldn't make any sense. What happened is considered happened. This is a job for your harness, unless you want to make a specific finetune with a rigid format. You have to design and prompt it around the possibility of out-of-character user inputs, and think about how much freedom you want to give the user and how exactly you want to correct their actions. Validation with a second agent suggested in sibling comments is pretty good for this.