In the original article the provider of the "LLM that does translation" obviously does not want the magic that comes from being able to embed complex requests i

In the original article the provider of the "LLM that does translation" obviously does not want the magic that comes from being able to embed complex requests in the user prompt and wants just a ML translation tool. And this could be solved by actually making a ML translation tool, i.e. instead of using a generic LLM, make a specialized translation model. However, we do want "the actual magic" as described in the other example of the article about a virtual agent that can handle novel tasks and also process input data from e.g. emails, and there we do want the functionality, as you say, so that "The user can ask questions how ever they want, provide data in any format, request some extra transformation to be applied etc." BUT there is still a difference. We want "User A" to be able to ask questions however they want and request extra transformations, but we don't want "User B" to be able to do the same when some data is coming from them. We want to ensure that when the "User A" "provides data in any format" - which often will include third party data - that this data is never ever interpreted as valid instructions, that any requests in the data are treated as simply data.