Sometimes the underlying LLM tries todo multiple tool calls in parallel instead of just one. Sometimes this breaks the underlying assumptions in the adapter code.
We likely need to do two things to close this ticket:
make sure the existing methods that expect one tool call at a time are robust to the case where the LLM tries to call multiple in parallel
add new method(s) as needed (with a different type signature) which explicitly expects one or more invocations of the tool (and gracefully falls back to the case of a single tool call by presenting an array of length one in that case)
Alternatively we could try to make the parallel case work with the existing type signatures by adding an optional field in the final event which will hold every additional tool call after the first one. This is a bit weirder of a type signature, but it has some advantages:
it extends the methods we already have, without adding new methods with potentially weirder names
it guarantees at the type level that the number of calls is "at least one" (by having one mandatory call and an optional array of additional calls), which means that callers don't need to have special case code that handles the "impossible" case of an empty array
Sometimes the underlying LLM tries todo multiple tool calls in parallel instead of just one. Sometimes this breaks the underlying assumptions in the adapter code.
We likely need to do two things to close this ticket:
Alternatively we could try to make the parallel case work with the existing type signatures by adding an optional field in the final event which will hold every additional tool call after the first one. This is a bit weirder of a type signature, but it has some advantages: