Let the tool decide if the chain should be called again with the return value

[OskarStark]

In my case I craft a dedicated response like:

{
  "foo": "bar",
}

and I don't want to feed it back to the LLM for another roundtrip.

That happens here (in Line 55):

llm-chain/src/Chain/ToolBox/ChainProcessor.php

Lines 46 to 55 in 8365e13

	while ($output->response instanceof ToolCallResponse) {
	$toolCalls = $output->response->getContent();
	$messages[] = Message::ofAssistant(toolCalls: $toolCalls);
	foreach ($toolCalls as $toolCall) {
	$result = $this->toolBox->execute($toolCall);
	$messages[] = Message::ofToolCall($toolCall, $result);
	}
	$output->response = $this->chain->call($messages, $output->options);

I think we should not make it configurable like "Tool A will always feed back to the API", because it can depend on runtime. Maybe a ToolResponse class as an additional allowed return type?

Dummy-code

new class ToolResponse {
    value: string, float etc.
    callLlm: yes/no
}

[OskarStark]

A ToolResponse would couple the tool to the LlmChain bundle/lib. So what about adding more info to the #[AsTool] like for example:

- #[AsTool(name: 'foo', description: 'returns foo')]
+ #[AsTool(name: 'foo', description: 'returns foo', directReturn: true)] 

naming to be discussed

[chr-hertel]

This also conflicts with the possibility of having multiple tool calls. so we would need to require the combination of this setting active with the option parallel_tool_calls: false.
see https://platform.openai.com/docs/guides/function-calling#parallel-function-calling-and-structured-outputs

on the other hand i'd be more in favor of thinking of a generalized extension point here for intercepting the chain with custom logic. event dispatcher comes to my mind immediatley.

[OskarStark]

As discussed we can go with this option and implement something with event dispatcher as a follow up

[chr-hertel]

okay, not as easy as i thought :D