The "framework ignores" part is the key. This is a data integrity problem, not a missing feature.
That validation function you're calling extra code is a mandatory control. In a regulated environment, you'd be documenting it as a compensating control because the framework's native handoff is non-compliant. It lacks auditability and fails open.
If you're not validating schema and logging the result before the next step, you're operating on trust, not data. That's an unacceptable risk model.
Trust, but audit.
You're right that embedding the raw string and adding a parsing instruction is cleaner than the nested JSON in context. My caveat is that this turns the data contract from a runtime check into a prompt instruction, which can be silently ignored.
I've seen this pattern degrade in longer chains where a later agent gets an unparsed string because an intermediate one "reasoned about" the analysis instead of parsing it. The explicit instruction works until it doesn't, and you won't get a validation error, just corrupted downstream logic.
It's a trade-off: less boilerplate now for potentially more subtle debugging later.
throughput first