The function the model called with the wrong arguments

A backend engineer on an agent that scheduled appointments told me about a booking that landed in the wrong year. The model had done almost everything right. It understood the user, picked the correct function to create the appointment, and called it. The problem was in one argument. It passed a date in a format the tool half-accepted, and the tool, given something it could parse loosely, produced a booking nobody wanted. The function was right. The input to it was not.

The model’s output is input to your code, and input can be bad

It is easy to think of a tool call as the model doing the work. It is not. The model decides which function to call and what arguments to pass, and then your code runs the function on those arguments. That handoff is the moment to be careful, because the arguments are model output, and model output is not guaranteed to be well-formed. It can be the wrong type. It can be a string where you expected a number. It can be a date in a shape your parser accepts but the user never meant.

The engineer’s tool had trusted its input. It took the argument the model handed it and ran, the same way it would if a tested piece of code had called it. But a tested caller and a language model are not the same kind of caller. One produces arguments you validated at compile time. The other produces arguments at runtime from a probabilistic process, and sometimes they are subtly wrong in ways that still parse.

A malformed argument that still runs is the dangerous kind

The failure that hurt was not the model passing obvious garbage. Obvious garbage tends to throw an error, and an error is loud. The failure was an argument that was wrong but plausible. A date the parser accepted. A quantity that was a valid number but the wrong one. These pass silently into the tool and produce a real action on bad input, and the first sign of trouble is a customer noticing an appointment in the wrong year.

This is why “the model called the right function” is a false comfort. Calling the right function with the wrong arguments can be worse than calling the wrong function, because it looks correct at every layer until the side effect lands. The logs show a successful call. The tool reports success. Only the outcome is wrong.

Treat tool arguments as untrusted and check them at the door

The fix is to stop trusting the model’s arguments and validate them before the tool acts, exactly as you would validate input from any outside source.

Enforce a schema on every argument. Types, formats, ranges, required fields. If the model passes a date, it has to be a real date in the shape you expect, or the call does not proceed.
Reject rather than guess. When an argument fails validation, do not let a loose parser fill in the intent. Stop, and hand the model back a clear error it can correct.
Set sane defaults and bounds. Where a default is safe, use it. Where a value is out of range, refuse it. A quantity of ten thousand should never pass just because it is a valid integer.
Confirm high-impact actions. For a call that books, charges, or sends, a validation pass and sometimes a confirmation step is cheap next to the cost of acting on a bad argument.

The principle is the one you already apply to form input and API payloads. The model is just another untrusted source, and its arguments earn the same suspicion.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement priced at $2,500, we look at every tool the model can call and ask what happens when it calls that tool with the wrong arguments, because sooner or later it will. We put schema validation between the model and the tool, so a malformed date or an out-of-range value is caught at the door instead of turning into a real action. It is far cheaper to reject a bad argument than to unwind the booking it created.

The model choosing the right function is only half the call. Validate the arguments before you run it.