[
https://issues.apache.org/jira/browse/CAMEL-23613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18084032#comment-18084032
]
Raymond edited comment on CAMEL-23613 at 5/28/26 8:35 AM:
----------------------------------------------------------
Some additional thoughts:
Starting with the notions of independence and embeddability. Currently, there
is the Jbang-MCP module. I imagine it would be possible to simply add a Maven
dependency, for example, "camel-ai-support" or "camel-management-mcp" (or
similar). This would make it runtime independent, and not runtime specific.
Adding this dependency would make Camel AI-enabled/aware. The aim is for Camel
and AI to work seamlessly together.
Of course, the decision of which Java AI framework to use is still to be made
(LangChain4J, Spring-AI — version 2.0 is just around the corner — pure MCP, or
something else). The API/interface should be easy to configure using YAML or
programmatically, and it should be possible for AI agents to call it.
Prototypes exploring this should be assessed against pre-established criteria.
I think the criteria will depend largely on how you expect the Camel/AI tandem
to be used. One of the first things to consider is how various types of users
may use it in the future. What questions, tasks and skills does a
Camel-AI-enabled system need to handle? Does it only need to serve as an MCP
tool and execute requests from the AI agent, or can users add their own skills
to it?
Suppose I have an AI-enabled Camel instance running in an unconfigured
container. Can I ask it to create integrations from scratch? Can I instruct it
to start or stop routes (lifecycle management), monitor system performance and
take actions based on events and errors? Should it be fully independent? Or
should there always be a human in the loop?
Brainstorming use cases can be done with the help of the AI itself by asking
how Camel is used and managed, by looking at questions on Zulip and in the book
Camel in Action, and by looking at the current documentation and, of course,
real Camel implementations.
Starting from 'end users' and practice-driven use cases probably provides the
best approach.
And finally there is also the question of AI-security. Camel mostly processes
highly sensitive (think of financial or HR data) data. It probably need some
guardlines, or hard protection that it cannot alter or use exchange data
directly.
was (Author: skin27):
Some additional thoughts:
Starting with the notions of independence and embeddability. Currently, there
is the Jbang-MCP module. I imagine it would be possible to simply add a Maven
dependency, for example, "camel-ai-support" or "camel-management-mcp" (or
similar). This would make it runtime independent, and not runtime specific.
Adding this dependency would make Camel AI-enabled/aware. The aim is for Camel
and AI to work seamlessly together.
Of course, the decision of which Java AI framework to use is still to be made
(LangChain4J, Spring-AI — version 2.0 is just around the corner — pure MCP, or
something else). The API/interface should be easy to configure using YAML or
programmatically, and it should be possible for AI agents to call it.
Prototypes exploring this should be assessed against pre-established criteria.
I think the criteria will depend largely on how you expect the Camel/AI tandem
to be used. One of the first things to consider is how various types of users
may use it in the future. What questions, tasks and skills does a
Camel-AI-enabled system need to handle? Does it only need to serve as an MCP
tool and execute requests from the AI agent, or can users add their own skills
to it?
Suppose I have an AI-enabled Camel instance running in an unconfigured
container. Can I ask it to create integrations from scratch? Can I instruct it
to start or stop routes (lifecycle management), monitor system performance and
take actions based on events and errors? Should it be fully independent? Or
should there always be a human in the loop?
Brainstorming use cases can be done with the help of the AI itself by asking
how Camel is used and managed, by looking at questions on Zulip and in the book
Camel in Action, and by looking at the current documentation and, of course,
real Camel implementations.
Starting from 'end users' and practice-driven use cases probably provides the
best approach.
> Explore a shared contract for Camel runtime to enable AI agent and human
> collaboration
> --------------------------------------------------------------------------------------
>
> Key: CAMEL-23613
> URL: https://issues.apache.org/jira/browse/CAMEL-23613
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 4.x
> Reporter: Otavio Rodolfo Piske
> Priority: Major
> Fix For: 4.x
>
>
> During our AI working group discussion, we identified a gap in the developer
> experience:
> *Context:*
> * Humans and AI agents currently lack a shared, structured view of a running
> Camel application.
> * Humans rely on visual tools (Karavan, Kaoto, TUI, dev consoles), while
> agents interact through logs, MCP tools, and file system changes — but these
> views are disconnected. As integration development shifts toward AI-assisted
> workflows (prompt-first, with visual tools as a display layer), we need a
> common contract that both humans and agents can consume to understand the
> state of a Camel application at design time and runtime.
> *Proposal:*
> # Design a contract (set of APIs / protocol) that exposes Camel runtime
> state: route topology, endpoint inventory, message flow metrics, error
> states, REST/OpenAPI specs, and dev console information.
> # Evaluate the [Agent-Client
> Protocol|https://agentclientprotocol.com/get-started/introduction] as a
> potential standard for agent-IDE/tool communication, rather than inventing a
> custom protocol.
> # Revisit the existing Camel LSP work to assess whether it can be
> improved/extended (with AI assistance) to provide protocol-level integration
> and editing capabilities.
> # Coordinate with the community to ensure this contract becomes the de-facto
> way of consuming Camel runtime information
> {*}Goals{*}:
> * Enable a faster feedback loop where a developer can prompt an agent, the
> agent modifies a route, a running Camel instance hot-reloads it, and both
> human and agent can verify the result through the same interface.
> * Provide a consistent experience across the SDLC — the same contract serves
> design-time visualization, local development, and production observability.
> * Start with local-first (single laptop, no cloud dependency) to validate
> the approach and build field confidence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
