[
https://issues.apache.org/jira/browse/CAMEL-23613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083486#comment-18083486
]
ege edited comment on CAMEL-23613 at 5/26/26 12:26 PM:
-------------------------------------------------------
Hi Otavio and the community,
Really exciting topic — glad to see this being discussed officially!
I've been working on something in this exact space: CamelBee
([https://github.com/camelbee/camelbee]), an open-source library that embeds a
live route topology visualizer and real-time exchange tracer directly into a
running Camel application. I also built an initializer at
[https://camelbee.io|https://camelbee.io/] that scaffolds AI-ready Camel
microservices with the UI embedded from the start, and an MCP server for
generating them through prompting workflows.
Not sure how much overlap there is with the direction you have in mind, but
happy to share more details or discuss if any of it is useful to the proposal.
— Ege Karaosmanoglu [https://github.com/camelbee/camelbee] |
[https://camelbee.io|https://camelbee.io/]
was (Author: JIRAUSER313512):
Hi Otavio and the community,
Really exciting topic — I'm glad to see this being discussed officially, as
it's something I've been thinking about a lot as well.
I actually built a tool focused on this exact problem space: CamelBee
([https://github.com/camelbee/camelbee]), an open-source library that can be
added to a Camel application as a Maven dependency. It embeds a React
Flow–based UI directly into the running service, providing:
* Live route topology visualization with animated message traversal
* Real-time exchange tracing with payload inspection
* Timeline-based debugging/scrubbing through exchange history
* JVM and route health metrics (heap, GC, exchange counts, etc.)
It works with both Spring Boot and Quarkus.
On top of that, I also built [https://camelbee.io|https://camelbee.io/], which
scaffolds Camel microservices using CamelBee starters as the parent setup. The
generated projects include the topology UI and tracing capabilities out of the
box, along with AI-oriented project metadata files (CLAUDE.md, AGENTS.md) to
help AI agents understand project structure and workflows more effectively.
There's also an MCP server that exposes the scaffolding capabilities directly
to AI agents, allowing fully structured Camel microservices to be generated
through prompting workflows.
I also recorded a short video demo if it helps illustrate the approach:
[https://www.youtube.com/watch?v=K-Qm1NyGqUk&t=13s]
I'm not sure how much overlap there is with the direction being discussed, but
I'd be very happy if any of these ideas or approaches are useful to the
proposal. And if there's interest in discussing or collaborating further, I'd
absolutely love to be involved.
— Ege Karaosmanoglu [https://github.com/camelbee/camelbee] |
[https://camelbee.io|https://camelbee.io/]
> 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)
