CAMEL-23467: camel-aws-bedrock - add invokeAgent and invokeInlineAgent operations#25086
CAMEL-23467: camel-aws-bedrock - add invokeAgent and invokeInlineAgent operations#25086oscerd wants to merge 2 commits into
Conversation
…t operations The aws-bedrock-agent-runtime component did not expose InvokeAgent (invoking a deployed Bedrock agent) or InvokeInlineAgent (defining the agent at invocation time), the primary entry points for agent-based workflows on Bedrock. Both APIs return event streams, so they are implemented on the async client the same way the existing invokeFlow operation is: a response handler whose visitor collects the emitted events, awaited with join() and unwrapping the CompletionException around AWS service exceptions. - Add invokeAgent and invokeInlineAgent to BedrockAgentRuntimeOperations. - Add agentId, agentAliasId, sessionId, streamOutputMode and the inline foundationModel/instruction options, each overridable by a header. - Provision the async client for the two new operations, as done for invokeFlow. - Collect the ResponseStream events (chunk, trace, returnControl, files) and publish traces, return-control payloads, files and citations as headers. Citations arrive on the chunk attribution rather than as their own event. - Honor streamOutputMode: complete (default) accumulates the chunks into a String body, chunks exposes the List of chunks, matching the runtime component. - The agent APIs are session based, so a session id is generated when none is configured, and the one used is always echoed back on the session id header. invokeAgent and invokeInlineAgent use parallel but distinct SDK event types, so the collected traces/returnControls/files are held as the SDK objects and the header metadata documents both variants. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
davsclaus
left a comment
davsclaus
left a comment
There was a problem hiding this comment.
Nice feature addition — the implementation cleanly follows the established invokeFlow patterns, and the test coverage is solid.
Two minor convention notes inline (non-blocking). This review does not replace specialized review tools such as CodeRabbit, Sourcery, or SonarCloud.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 12 tested, 26 compile-only — current: 9 all testedMaveniverse Scalpel detected 38 affected modules (current approach: 9).
|
…test visibility Per project conventions, converted BedrockAgentRuntimeProducerInvokeAgentTest to AssertJ assertions and dropped the public modifier from the class and its lifecycle/test methods. Adds the test-scoped assertj-core dependency, which was not yet declared in camel-aws-bedrock (other camel-aws modules already declare it the same way; the version is managed in the parent). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
gnodet
left a comment
gnodet
left a comment
There was a problem hiding this comment.
Well-structured feature addition that cleanly follows the established invokeFlow patterns. The AgentInvocationResult inner class and joinAgentInvocation/resolveRequired helpers are good DRY extractions. Test coverage is solid (9 tests) and documentation is thorough.
Two minor consistency items:
1. streamOutputMode field initialization (low) — In BedrockAgentRuntimeConfiguration.java, the streamOutputMode field is declared as private String streamOutputMode; (defaults to null). The existing BedrockConfiguration (runtime component, line 78) initializes the same field: private String streamOutputMode = "complete";. The defaultValue = "complete" in @UriParam is metadata-only. The code works because prepareAgentResponse treats null as the complete case, but for consistency the field should be initialized:
private String streamOutputMode = "complete";2. Async client Javadoc (low) — The setBedrockAgentRuntimeAsyncClient Javadoc still says "required for invokeFlow which streams events back" but the async client is now also required for invokeAgent and invokeInlineAgent (both call requireAsyncClient()). Should mention all three streaming operations.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of Guillaume Nodet
davsclaus
left a comment
davsclaus
left a comment
There was a problem hiding this comment.
Well-structured feature addition — the implementation cleanly follows the established invokeFlow patterns, the AgentInvocationResult inner class and joinAgentInvocation/resolveRequired/resolveSessionId helpers are good DRY extractions, and the test coverage is solid (9 tests).
The two minor items flagged by @gnodet (streamOutputMode field initialization and async client Javadoc) are the only remaining notes — both non-blocking.
This review does not replace specialized review tools such as CodeRabbit, Sourcery, or SonarCloud.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
3 participants
Motivation
CAMEL-23467. The
aws-bedrock-agent-runtimecomponent did not expose InvokeAgent (invoking a deployed Bedrock agent) or InvokeInlineAgent (defining the agent at invocation time) — the primary entry points for agent-based workflows on Bedrock.Approach
Both APIs return event-stream responses, and the component already had a working precedent for that in
invokeFlow: the AWS SDK async client, a response handler whose visitor collects the emitted events, awaited withjoin()and unwrapping theCompletionExceptionthat wraps AWS service exceptions. Both new operations follow that same shape rather than introducing parallel machinery.Changes
invokeAgentandinvokeInlineAgentadded toBedrockAgentRuntimeOperationsand wired into the producer.agentId,agentAliasId,sessionId,streamOutputMode, and for the inline variantfoundationModel/instruction.enableTraceis reused and its label/doc widened to cover agents.invokeFlow(so users don't pay for a Netty client when only doing synchronous operations).ResponseStreamevents (chunk,trace,returnControl,files) are collected. Traces, return-control payloads, files and citations are published as headers. Citations arrive on the chunk attribution rather than as their own event, which is where they're picked up.streamOutputMode: honored with the same semantics as the runtime component —complete(default) accumulates the chunks into aStringbody,chunksexposes theList<String>. Overridable per exchange by header.CamelAwsBedrockAgentRuntimeSessionIdso a route can continue the conversation.pojoRequest=trueaccepts anInvokeAgentRequest/InvokeInlineAgentRequestunchanged — which is also how the richer inline options (action groups, knowledge bases, collaborators, guardrails) are reachable without adding a dozen URI options.aws-bedrock-agent-runtime-component.adocplus the supported-operations list.One thing worth flagging for review:
invokeAgentandinvokeInlineAgentuse parallel but distinct SDK type families (PayloadPart/TracePart/… vsInlineAgentPayloadPart/InlineAgentTracePart/…). The collected traces/return-controls/files are therefore held as the SDK objects and the header metadata documents both variants, rather than pretending a single type applies.Testing
BedrockAgentRuntimeProducerInvokeAgentTest— 9 tests, all passing — mirroring the existinginvokeFlowtest approach (mocked async client capturing the request):agentId/foundationModelproduce a clear validation errorstreamOutputModebranching shapes the body (StringvsList), including the header overrideThe test uses AssertJ assertions and package-private visibility per project conventions. Note this required adding a test-scoped
assertj-coredependency tocamel-aws-bedrock— it was not on the module's test classpath. That mirrors howcamel-aws2-sqs,camel-aws2-athenaandcamel-aws2-stsdeclare it, and the version is managed inparent/pom.xml, so no new version is introduced.Full reactor
mvn clean install -DskipTestsfrom root: success, with catalog/DSL metadata regenerated.Note on the regenerated
aws-bedrock-agentmetadata: that component declaresheadersClass = BedrockAgentRuntimeConstants.class(pre-existing), so adding constants there also regenerates its header metadata. I verified this is index renumbering plus the new entries — all existingFlow*headers remain present (15 → 26 headers, none removed).Main-only (4.22.0), additive — no backport.
Claude Code on behalf of Andrea Cosentino (@oscerd).
🤖 Generated with Claude Code