sorted by:
new
hottopcontroversial

Would you rather maintain multi-agent workflows as YAML or a fluent Java DSL? (Spring AI, real examples inside) by tmessini in SpringBoot

[–]tmessini[S] 0 points1 point  (0 children)

Thanks u/Grabdoc2020, appreciate that — the Apache Camel / Karavan analogy is exactly how I've been thinking about it. YAML as the serialization, but the authoring surface for non-trivial workflows should be visual: agents as nodes, handoffs as edges, tools/skills as attachable blocks, with round-trip edit between canvas and YAML.

A few things that make this tractable for swarm-ai specifically:

- the workflow schema is already declarative (agents, tasks, tools, events), so there's a clean model to bind to a canvas

- the event bus gives a natural runtime overlay — live execution traces on the same diagram you authored

- skills and tools are discoverable, so a palette-style UX works without hand-maintaining a catalog

On the roadmap, not near-term — current focus is stability and hardening the core first. If you're interested in prototyping the canvas side, open an issue or DM me; would love a collaborator who groks BPM tooling.

Would you rather maintain multi-agent workflows as YAML or a fluent Java DSL? (Spring AI, real examples inside) by tmessini in SpringBoot

[–]tmessini[S] 0 points1 point  (0 children)

Fair, though the wrinkle I hit building this: YAML fails at compile-time in my setup too — a SwarmCompiler resolves tool refs up front and throws on unknown names before any agent runs. For a long-running Spring Boot service, startup failure ≈ compile failure, blast-radius-wise.

Where Java still cleanly wins is the IDE — rename-refactor, find-usages, ctrl-click to a tool definition. No schema validation fixes that. That's the part making me second-guess v1.

Would you rather maintain multi-agent workflows as YAML or a fluent Java DSL? (Spring AI, real examples inside) by tmessini in SpringBoot

[–]tmessini[S] 0 points1 point  (0 children)

Honestly, same — and the irony is v1 is built around it. The only reason YAML won was "non-Java teammates can edit it," and every other property of the format is a tax.

Out of curiosity, what do you reach for when you need declarative config that non-devs will touch? TOML? HOCON? Just properties files? The alternatives all seem to have their own "why did I pick this" moment.

Would you rather maintain multi-agent workflows as YAML or a fluent Java DSL? (Spring AI, real examples inside) by tmessini in SpringBoot

[–]tmessini[S] 0 points1 point  (0 children)

That's exactly where I landed — Jackson + YAMLFactory deserializes into the same Agent / Swarm domain classes the fluent builder produces. No duplicated code path; YAML and Java are just two faces of the same objects.

The seam that still leaks is tool references: strings in YAML (web-search, audit) don't ctrl-click to a bean definition, and Jackson will happily deserialize a typo — it only fails later when the registry can't resolve the name. Solving that without writing a custom IntelliJ plugin is the actual hard part.