EDDI: Multi-agent AI orchestration middleware, built on Quarkus 3.34

[ginccc]

Hey everyone 👋

I'm Gregor, and I've been building EDDI, a config-driven multi-agent orchestration middleware for conversational AI. It's built entirely on Quarkus 3.34 and Java 25, and I wanted to share it here since Quarkus has been absolutely central to the project.

The problem

Most multi-agent frameworks today are Python or Node libraries. Great for prototyping, but hard to govern when you need auditability, multi-tenancy, and compliance in production. EDDI takes the opposite approach: a deterministic Java engine that safely governs non-deterministic AI. Agent behavior lives in versioned JSON configs, so you can change how agents behave without redeployment.

How deep does Quarkus go?

EDDI isn't just "built on Quarkus". It relies on the ecosystem heavily:

What	Quarkus Extension
REST API + SSE streaming	quarkus-rest, quarkus-rest-jackson
Multi-tenant auth & RBAC	quarkus-oidc, quarkus-keycloak-authorization
DB-agnostic storage	quarkus-mongodb-client + quarkus-jdbc-postgresql (switch with one env var)
Cron, heartbeats, dream cycles	quarkus-scheduler
50+ custom metrics	quarkus-micrometer-registry-prometheus
Distributed traces	quarkus-opentelemetry
Health probes	quarkus-smallrye-health
MCP Server (42 tools)	quarkus-mcp-server-http (Quarkiverse)
Template engine	quarkus-qute

Dev mode with live reload has been invaluable. Iterating on agent behavior configs with instant feedback is a huge productivity win.

Highlights

• 12 LLM providers: OpenAI, Anthropic, Gemini, Mistral, Azure OpenAI, Bedrock, Ollama, and more (via langchain4j)
• Multi-agent debates: 5 discussion styles with nested group composition
• MCP + A2A: Control EDDI from Claude Desktop/Cursor; agents discover and talk to each other via Google's A2A protocol
• Smart model cascading: Try cheap models first, escalate when confidence is low
• Persistent memory: Cross-conversation fact retention with dream consolidation
• Enterprise-ready: Envelope-encrypted secrets vault (AES-256), SSRF protection, EU AI Act audit ledger, GDPR cascading erasure
• One-command install: curl ... | bash sets up everything via Docker

5,100+ tests with Testcontainers, >80% coverage, OpenSSF Best Practices badge. Ships as a Red Hat-certified container image.

Quarkiverse extension

We're also building a quarkus-eddi Quarkiverse extension: Dev Services, fluent client API, SSE streaming, and an MCP bridge. Not yet on Maven Central, but the repo is public if you want to follow along.

Links

🔗 GitHub · Website · Docker Hub · Apache 2.0

---

I'd be curious to hear: is anyone else in the Quarkus community working on LLM/agent orchestration? And if anyone has experience publishing Quarkiverse extensions, I'd appreciate any tips on the release process. 🙂

[maxandersen]

Definitely interested in this space of showing agents harnesses is just middleware and not tied to a specific language. And your EDDI definitely makes use of a big list of middleware :)

[maxandersen]

What are the questions you have about the release process ?

[ginccc]

Thanks Max! Yeah, the goal is that EDDI handles the hard parts (orchestration, memory, compliance, tool sandboxing) as middleware, and then protocols like MCP and A2A open it up to any language or tool. A Python service can talk to EDDI agents via A2A (or REST), Claude Desktop can manage them via MCP. The Quarkus extension adds the native Java on-ramp: @Inject EddiClient with Dev Services that auto-start EDDI during quarkus:dev, so there's zero setup for Quarkus developers to get a full agent orchestration layer running.

On the release process, here's where I'm unsure:

1. Versioning: quarkus-eddi wraps EDDI's REST API. We haven't done our first release yet (still at 6.0.0-SNAPSHOT), so now's the time to decide: should the extension version match EDDI (currently 6.0.2), or have its own independent semver? Lockstep is simpler for users ("same version = compatible"), but it means publishing releases even when nothing changed on the extension side.

2. Testing expectations: We have unit tests and @QuarkusTest integration tests that spin up EDDI via Testcontainers. Two questions here:

   • Is there a recommended pattern for testing Dev Services specifically?
   • Does the Quarkiverse ecosystem CI handle daily builds against the latest Quarkus core, or does that need additional setup?

3. Listing on quarkus.io: Is there a specific docs structure needed to get the extension listed on the extensions page?

4. Minimum Quarkus version: The extension is currently built against Quarkus 3.17, but EDDI itself runs on 3.34. Should the extension target the latest LTS, or track the current Quarkus release? We want broad compatibility, but we also don't want to maintain workarounds for older versions.

If there's another Quarkiverse extension that follows a similar pattern (client SDK wrapping a standalone server), I'd love to look at how they handle these things.