JiriOndrusek opened a new issue, #8993: URL: https://github.com/apache/camel-quarkus/issues/8993
### Description When `camel-quarkus-langchain4j-agent` is used inside an application that also has Quarkus LangChain4j on the classpath, the `CamelAiToolProvider` (auto-discovered as a CDI `ToolProvider` and applied by Quarkus LangChain4j to every `AiServices` instance, including the one the Camel agent component builds internally) serves **all** `AiToolRegistry` tools to **every** Camel agent request. Camel agents already have a deliberate mechanism for selecting registry tools — the endpoint's `tags` parameter. Serving them through the auto-discovered provider as well causes three problems: 1. **Agents on models without tool support break**: registering a single `ai-tool:` route anywhere in the application attaches a `tools` array to every agent request; a backing model without tool support (e.g. `orca-mini` on Ollama) then rejects every request with `does not support tools`. 2. **Duplicate tool specifications**: an agent endpoint with `tags=...` receives the matching tool twice — once from the endpoint's own provider, once from the auto-discovered one (Quarkus LangChain4j appends provider specifications without name dedup) — wasting tokens on every request and risking rejection on providers that are strict about duplicate function names. 3. **Tool leakage into unrelated conversations**: tools become callable from agents that never asked for them. Observed concretely in `langchain4j-agent-ql4j`: a chat-memory conversation answered a "what is my name?" question by calling the leaked `userDb` tool instead of using its memory. ### Reproduction `integration-tests/langchain4j-agent-ql4j` after the ai-tool migration (#8914/#8985): every agent request carries the `userDb` tool, the tagged agent carries it twice, and a real-Ollama run fails 13 of 16 tests. Related test-failure report: #8992. ### Expected behavior Camel `langchain4j-agent` endpoints receive registry tools only via their `tags` parameter. `@RegisterAiService` interfaces and user-built `AiServices` keep receiving all registered tools by default (restrictable with `@CamelAiTools`). ### Note The tool-specification duplication is also observable independently in Quarkus LangChain4j (`AiServiceMethodImplementationSupport` appends provider specs to a plain list while dedup-ing executors by name) — worth a separate upstream report. --- _This issue was drafted by Claude Code on behalf of Jiri Ondrusek._ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
