You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Otavio Rodolfo Piske (Jira)" <ji...@apache.org> on 2026/05/26 09:26:00 UTC
[jira] [Updated] (CAMEL-23613) Explore a shared contract for Camel runtime to enable AI agent and human collaboration
[ https://issues.apache.org/jira/browse/CAMEL-23613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Otavio Rodolfo Piske updated CAMEL-23613:
-----------------------------------------
Description:
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 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.
was:
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 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.
> 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 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)