[
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)
