Hi all,
Federico Mariani identified that our AI components duplicate the same tool registration pattern and proposed camel-ai-tool, a shared, framework-agnostic abstraction[0]. I took his proposal, did a deeper technical analysis of how it maps to the existing code, and wrote a design doc detailing the implementation [1]. The problem: today, camel-langchain4j-tools and camel-spring-ai-tools each implement the same pattern independently. Same registry, same consumer logic, same tag-based discovery. Duplicated code, and a tool defined for one framework is invisible to the other. camel-openai has no support yet for Camel route tools at all. The proposal: a new camel-ai-tool module that provides a single, framework-agnostic way to define tools. One consumer endpoint (ai-tool:toolName), one shared registry per CamelContext, one executor. Each AI component (LangChain4j, Spring AI, OpenAI) adds a thin adapter to convert from the shared AiToolSpec to its native format. Define once, use everywhere. This also lays the groundwork for any use cases that expose Camel Routes as AI Tools. Considering the impact across multiple components, I split the work into incremental steps to keep reviews focused: 1. Core module (camel-ai-tool) with registry, executor, consumer, tests. PR [2] 2. Wire langchain4j-agent producer to the shared registry 3. Wire spring-ai-chat producer 4. Wire langchain4j-tools producer 5. Deprecate/delete old consumer endpoints 6. Add Camel route tool support to camel-openai (separate JIRA) Step 1 changes nothing in existing modules. Old consumers keep working. [0]: JIRA: https://issues.apache.org/jira/browse/CAMEL-23382 [1]: https://github.com/apache/camel/blob/main/design/aiTool.adoc [2]: https://github.com/apache/camel/pull/24473 Thanks, -- Zineb Bendhiba
