I think tool calling is your answer—you’re just missing a separation of concern(s).
For example to handle personality configuration, don’t use a tool to get personality configuration , use a tool to handle responding to the customer. When your agent has gathered the information to respond to the customer it will call the tool sendMessage with the response. Your tool call implementation is a role play prompt that rephrases the message with the provided tone/personality configuration (this is where the customer config is injected as context). The output is then passed through a guardrails completion for potential censoring before finally being displayed to the customer.
This means your main agent model simply becomes a routing agent (a tool calling optimized model) that directs to sub agents that handles various tasks (like figuring out shipping capabilities, or flavoring responses with personality affects, or adhering to guardrails) keeping the customer centric configuration’s blast radius (impact on the effectiveness of your prompts) narrowed to purely aesthetic completion and out of any functional completion.
FWIW, I think this article could just as accurately be titled "Diagrams Developers can, and cannot, generate".
I'm mainly speaking to the ability to read IaC code ([probably of any library but at LEAST in my case] cdk, pulumi, terraform, cloudformation, serverless) and be able to infer architectural flow from it. It's really not conducive to that use case.
I could also, kidding/not kidding, be speaking to the range of abilities for "mid" and "senior" developers to know and convey such flows in diagrams.
But really my point is this feels like more validation that AI doesn't provide increased ability, it provides existing (and demonstrated) ability faster with less formalized context. The "less formalized context" is what distinguishes it from programs/code.