>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3556140. --> Reported by: [marcus_johansson](https://www.drupal.org/user/385947) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Currently we have a module in Tool API that does create deriatives of the tools into function calling standards. Since we want to move Tool API to be the first and foremost way of how you do function calling in AI Core, we want to prepare for this.</p> <p>For the sake of the conversation its important for people to know that there are currently four ways of abstracting the function calls:</p> <ul> <li><strong>ToolsInterface</strong> - in AI Core. This is pure abstraction, for different providers to have a common language on how to declare input and output for function calling and tools. This is not being discussed as part of this issue and will not be touched until we move to Symfony AI.</li> <li><strong>FunctionCallInterface</strong> - in AI Core. This is a way to setup a function call that any provider can pick, the transforms into ToolInterface. This is however not executable. This is rarely used, since structured ouput is a better way and anyway you could use the executable versions and just not execute them. This should get the same treatment as we decide for ExecutableFunctionCallInterface.</li> <li><strong>ExecutableFunctionCallInterface</strong> - in AI Core. This is the main usage of agents currently. It takes structured inputs, executes with access check inside execution and provides a string output.</li> <li><strong>ToolInterface</strong> - in Tool API. This is similar to ExecutableFunctionCallInterface, but has structured output, an access method by itself and in general tools are more generic vs. function calls that are hyperspecific. It can be used in the future for VBO, ECA etc.</li> </ul> <p>Some other background information for the decision:</p> <ul> <li>ToolInterface structure is very similar to ExecutableFunctionCallInterface, so we will most likely be able to create a Drush command that transfers your ExecutableFunctionCallInterface into a ToolInterface, where it just sets the output to string for the time being.</li> <li>There is a possibility that we switch over the Automators to use Tools in 2.x or 3.x, meaning that dependency would need to exist. The other possibility is to use structured output, or use it as is (jsonformer). The main reason for keeping it as jsonformer, is that its just much faster inference time compared to function calling and when you are automating 1000s of items it matters.</li> </ul> <h4>Discussion</h4> <p>There are five different solutions that we can pick as far as I can tell, but please come with more if you have ideas:</p> <p><strong>(1) Only use Tool API</strong><br> This means hard ripping the band aid off and switch over the agent to just look for Tools. </p> <ul> <li>It would mean a hard dependency on Tool API for any agent or anything running (none-abstract) function calling.</li> <li>It would be the easiest to maintain, since you do not have to maintain two similar, but not exact same interfaces and integrations.</li> <li>Any upgrade path for any agent would require to update the function calls to a tool, meaning that for existing agents, there is no upgrade path until someone touches code.</li> <li>Agents as function calls, needs to be switched to agents as tools.</li> </ul> <p><strong>(2) Tool API is the primary</strong><br> This means that the agents is setup similar to above, but we add a deriative from function calling to Tool API.</p> <ul> <li>It would mean a hard dependency on Tool API for any agent or anything running (none-abstract) function calling.</li> <li>It would be fairly easy to maintain, and also to write a deprecation timeline for function calling for 2.1.x or 3.x.</li> <li>Upgrade paths would work, if we keep the ids intact.</li> <li>We do not need to do any actual changes too function calling.</li> <li>Agents as function calls, needs to be switched to agents as tools.</li> </ul> <p><strong>(3) Function Calling follows Tool API</strong><br> This means that the function calling becomes a replica of the tool interface.</p> <ul> <li>It would remove the hard dependency on Tool API.</li> <li>It would be fairly easy to maintain, and also to write a deprecation timeline for function calling for 2.1.x or 3.x.</li> <li>There will be breaking changes, but we can probably find a way in the base class to handle that you can use your current function calls.</li> </ul> <p><strong>(4) We handle both at the same time</strong><br> This means that the agent can connect both function calls and tools, and they have different executors.</p> <ul> <li>It would remove the hard dependency on Tool API.</li> <li>It would be heavy to maintain, since you need to have different UI experiences setting them up and different executors.</li> <li>Deprection won't happen until 3.x for sure.</li> <li>Upgrade paths just works.</li> </ul> <p><strong>(5) Status quo</strong><br> We just keep it as is, where Tool API create function call deriatives.</p> <ul> <li>It needs no extra work.</li> <li>Upgrade paths just works.</li> <li>Deprection won't happen until 3.x for sure.</li> <li>Being able to rewrite output improvement will not be possible.</li> <li>Any UI features from Tool API will not be possible to use.</li> </ul> <p>I have numbered them for discussions sake, if some arguments or a version is forgotten, please comment and I will edit the issue.</p>