[
https://issues.apache.org/jira/browse/CAMEL-23613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18084101#comment-18084101
]
Milos commented on CAMEL-23613:
-------------------------------
Interesting discussion. I also think this becomes increasingly important as
Camel moves toward more AI-assisted workflows.
During my graduation internship I worked on the iPaaS Fluxygen, which uses the
same Assimbly runtime Raymond mentioned above. One of the things I worked on
was an AI step that could be used directly inside an integration flow. The idea
was that the step could inspect incoming information and, based on a prompt and
runtime context, generate outputs such as summaries, classifications,
transformations, etc.
One thing I noticed during development is that the current developer experience
around AI integration can still feel quite heavy. In many cases,
components/frameworks need to be wired manually through Java configuration and
the registry before they become usable inside routes.
>From an AI-agent perspective, this kind of setup can also add difficulty: if
>an agent needs to understand, generate, or modify integrations, requiring
>multiple Java-level steps and registry wiring makes the interaction surface
>more complex than necessary.
I therefore think there is a lot of value in having a more standardized and
discoverable runtime contract/interface for AI-enabled Camel instances. In that
context, simplifying the interaction model (for example via consistent URIs,
declarative options, and predictable configuration patterns) would likely make
it significantly easier for both humans and AI agents to reason about and
interact with Camel runtimes.
This also connects to a few guiding principles that seem relevant for this
direction:
* simplicity
* consistency
* no-code (or low-code where possible)
* standardisation
Another aspect that may become increasingly important is AI
security/governance. Once AI agents can inspect runtime state, payloads,
metrics, routes or logs, the runtime probably needs mechanisms such as:
* payload/context sanitization and secret masking
* least-privilege access for AI agents
* retracing of AI actions and modifications
* separation of trusted instructions vs untrusted runtime/payload data (prompt
injection prevention)
Especially in enterprise integration environments, Camel often processes highly
sensitive data, so these concerns will likely become part of the overall design
as AI capabilities evolve.
Really interesting initiative overall.
> 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)
