CAMEL-23928: Add AiServices builder customizer and tool-calling options to AgentConfiguration#24485
CAMEL-23928: Add AiServices builder customizer and tool-calling options to AgentConfiguration#24485davsclaus wants to merge 2 commits into
Conversation
…zer and tool-calling options to AgentConfiguration Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 10 tested, 29 compile-only — current: 10 all testedMaveniverse Scalpel detected 39 affected modules (current approach: 10).
|
davsclaus
left a comment
davsclaus
left a comment
There was a problem hiding this comment.
Clean, well-structured PR that follows existing patterns. The aiServicesCustomizer escape hatch and tool-calling options are a good addition to avoid users having to reimplement configureBuilder() from scratch.
One minor style nit inline.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
|
I'm analysing this, please hold on before merge. |
zbendhiba
left a comment
zbendhiba
left a comment
There was a problem hiding this comment.
Hey @davsclaus , thanks for the PR!
I'm happy you opened this. These are real concerns from users, and I want to address them. I'll definitely work on some of these for the camel-ai-tool (CAMEL-23382).
That said, I looked at how these options work in the context of our current agent component, and I have a few concerns.
Our ToolExecutor already catches errors In LangChain4jAgentProducer, our Camel ToolExecutor catches all exceptions and returns them as strings to the LLM. LangChain4j never sees the exception. So toolExecutionErrorHandler and toolArgumentsErrorHandler would never fire for Camel route tools.
They could work for customTools (raw @tool objects). But we need integration tests to prove it.
Error handling defaults are flipping in langchain4j 2.0
Worth noting: langchain4j is changing the default behavior of both error handlers in 2.0.
- ToolExecutionErrorHandler currently returns the exception message to the LLM. In 2.0, it will throw instead. The current default is actually a security concern because it can leak internal data to the model.
- ToolArgumentsErrorHandler currently throws. In 2.0, it will return a text message to the LLM.
So the defaults are swapping. If we expose these options now without tests, we'll also need to handle the breaking change when we bump to langchain4j 2.0. One more reason to wait and get this right.
compensateOnToolErrors can't work with route tools
This feature relies on @CompensateFor annotations on Java methods. Our tools are Camel routes, not annotated methods. So this option has no effect in the Camel tool model.
Again, it could work with customTools. But we need an integration test.
aiServicesCustomizer vs agent=#myBean
Camel creates the AiServices and manages the builder. If a user wants full control, they can build their own Agent and inject it via agent=#myBean. That already bypasses configureBuilder() entirely.
The customizer runs last and can silently undo what configureBuilder() sets up. I'd rather point users to the existing agent bean injection path. Probably we need to sync on architecture design approval for this.
What I need before we can merge
Integration tests covering both Camel route tools and annotated @tool objects for each option:
- maxToolCallingRoundTrips (this one I'm pretty confident works)
- toolExecutionErrorHandler with Camel route tools. Does it actually fire?
- toolArgumentsErrorHandler. Same question.
- hallucinatedToolNameStrategy with our dynamic ToolProvider
- compensateOnToolErrors without @CompensateFor annotations
- aiServicesCustomizer not breaking the rest of the configuration
If the tests show these options don't work with Camel route tools, I'd rather wait. CAMEL-23382 (camel-ai-tool) is about to land and will
replace the Camel tool executor. Anything touching that area now will be rewritten in a few days. Better to revisit on top of the new tool model.
maxToolCallingRoundTrips is the one option I'm confident about. We could scope this PR to that and move the rest to a follow-up after camel-ai-tool lands.
|
yeah lets park this |
3 participants
Summary
Claude Code on behalf of davsclaus
AiServicesbuilder tool-calling options directly onAgentConfiguration:maxToolCallingRoundTrips,hallucinatedToolNameStrategy,toolExecutionErrorHandler,toolArgumentsErrorHandler,compensateOnToolErrorsaiServicesCustomizer(Consumer<AiServices<?>>) escape hatch for configuring anyAiServicesbuilder option not directly exposedAbstractAgent.configureBuilder(), with the customizer invoked lastThis addresses a gap where users needing tool-calling error handling (e.g. handling hallucinated tool names) had to implement
AgentFactoryand reimplement all ofAbstractAgent.configureBuilder()from scratch.Follow-up CAMEL-23929 will expose the simple scalar options as
@UriParamonLangChain4jAgentConfiguration.Test plan
AgentConfigurationTest)camel-langchain4j-agent-apicamel-langchain4j-agentmodule compiles cleanlyCo-Authored-By: Claude Opus 4.6 noreply@anthropic.com