EDDI is a Java 25 and Quarkus middleware that turns JSON configuration into multi-agent conversational flows, with MCP and A2A protocol support and a Docker-first install path. The interesting part is the config-driven agent model; the open question is how much of the enterprise compliance framing the repository itself documents.

Can I use labsai/EDDI commercially?

Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is labsai/EDDI still maintained?

Yes. The repository received new commits within the last day.

What programming language is labsai/EDDI written in?

Mainly Java, according to GitHub's language statistics.

labsai/EDDI review: config-driven multi-agent orchestration on Quarkus

At a glance

What is it?: EDDI is a Java 25 and Quarkus middleware that turns JSON configuration into multi-agent conversational flows, with MCP and A2A protocol support and a Docker-first install path. The interesting part is the config-driven agent model; the open question is how much of the enterprise compliance framing the repository itself documents.
Who is it for?: Adopt EDDI if your team already runs Java services and wants agent behaviour expressed as versioned JSON rather than as application code, and if a Docker Compose deployment with MongoDB or PostgreSQL is acceptable. Do not adopt it if you need a Python-native stack, or if you intend to run it without reading the compose files, because the PostgreSQL path is a standalone stack that cannot be layered onto the default one.
Can I use it commercially?: Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository received new commits within the last day.
What is it written in?: Mainly Java, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 10, 2026 · labsai/EDDI

The problem EDDI targets: agent logic that lives in code instead of configuration

Most agent frameworks expect you to write the orchestration. You import a library, define tools as functions, and wire the control flow in the host language. EDDI takes the opposite position. The README describes it as a config-driven multi-agent orchestration middleware that coordinates users, agents and business systems through routing, memory and API orchestration, and states the goal as doing this without writing code. The unit of work is a JSON agent definition, not a Python or Java class. That matters for a specific kind of team: one that has an existing Java service estate, a platform group that owns deployments, and product people who want to change how a bot routes a conversation without a code review. The README also points at a form-based agent wizard and a Platform Operator role, which suggests the intended workflow is configuration through a UI rather than hand-edited files. Whether the JSON schema is stable enough to treat as an interface is not something the README settles.

What actually runs: Quarkus, a database, and overlay services

The runtime is a Java 25 application built on Quarkus, shipped as a Docker image. The README states the image is Red Hat certified, which for teams already running Red Hat tooling is a procurement detail rather than a technical one. Around the core sit optional services expressed as Compose overlays: Keycloak for authentication, Prometheus and Grafana for monitoring, NATS JetStream for messaging, Chroma as a vector store, and Ollama for a local model. Persistence is MongoDB by default, with PostgreSQL offered as an alternative. The protocol surface listed in the README is MCP for both client and server roles and A2A for agent-to-agent communication, plus Slack, OpenAPI and OAuth 2.0 integrations. Conversation memory is described as persistent, which in practice means it is stored in whichever database you selected. The topics list also names LangChain4j, so the LLM abstraction layer is not homegrown. What the README does not describe is the internal routing algorithm: how a message is matched to an agent, and what happens when two agents both claim it.

Installation: one script, then a CLI wrapper you will need to find

The documented quick start is a single command. On Linux, macOS or WSL2 it is curl -fsSL https://raw.githubusercontent.com/labsai/EDDI/main/install.sh | bash. On Windows there is a PowerShell equivalent that downloads install.ps1, calls Unblock-File and then runs it. Docker is the only stated prerequisite. The installer takes flags: --defaults for no prompts, --db=postgres --with-auth for PostgreSQL plus Keycloak, --full for database, auth and monitoring, and --local to build the image from source. Contributor builds go through ./mvnw package -DskipTests followed by bash install.sh --local. The script also generates a vault encryption key for secret management and installs an eddi CLI wrapper. The README notes that if the command is not found, the binary lives at ~/.eddi/eddi on Linux and macOS or ~/.eddi/eddi.cmd on Windows, and that a terminal restart or the full path will fix it. That is a small thing, but it is the first thing that will go wrong on a locked-down workstation.

Compose overlays, and the PostgreSQL trap

The README is unusually explicit about how the Compose files combine, and one detail is worth reading twice. The default is docker compose up, which starts EDDI with MongoDB. PostgreSQL is not an overlay. The README states that docker-compose.postgres-only.yml is a complete stack rather than an overlay, because an overlay cannot un-declare the base file's mongodb service, and that it must be used on its own rather than with -f docker-compose.yml. Everything else stacks: docker-compose.auth.yml, docker-compose.monitoring.yml, docker-compose.nats.yml, docker-compose.ollama.yml, docker-compose.chroma.yml and docker-compose.local.yml can be combined in any order with repeated -f flags. The Ollama overlay is the one with the most documented sharp edges. It pulls llama3.2:3b on first start, keeps models in a named volume, and can be redirected with OLLAMA_PULL_MODEL=qwen3:4b or skipped by setting the variable empty. It also sets EDDI_OLLAMA_DEFAULT_BASE_URL so the wizard pre-fills a URL that resolves inside the container, which the README calls out as the thing that trips up every first local-LLM agent, since localhost inside a container is the container itself. That is a real piece of operational knowledge, not marketing.

Updating, and what the maintenance surface looks like

Updates go through the CLI: eddi update pulls the latest image and restarts the containers. The README claims this works even when the same tag was republished, because Docker checks the remote digest. Without the CLI, the equivalent is docker compose --env-file .env -f docker-compose.yml pull followed by the same command with up -d, run from the install directory, which defaults to ~/.eddi. If you use Keycloak you add -f docker-compose.auth.yml to both commands. The release cadence visible in the repository is roughly monthly, with 6.1.2 in late June, 6.2.0 in late July and 6.3.0 in late August. That is frequent enough that pinning a specific tag rather than following latest is worth considering, though the README does not describe a version pinning mechanism or a migration process for agent JSON between releases. That gap matters more here than in a library, because the agent definitions are the artefacts your team edits, and nothing in the supplied material says whether an agent written for 6.1.2 loads unchanged in 6.3.0.

Compliance claims and the evidence behind them

The repository description lists EU AI Act, GDPR and HIPAA under enterprise compliance, and the README has a Compliance and Privacy section. What the supplied material does not contain is the content of that section, the audit logging format, the data retention controls, or any mapping between a configuration key and a regulatory requirement. For a team in a regulated environment this is the part that decides adoption, and it is the part the README excerpt does not substantiate. The licence is Apache-2.0, which is permissive and carries no copyleft obligation on your own code, but it also means the project offers no warranty and no compliance guarantee. The OpenSSF Best Practices and Scorecard badges in the README point at external assessments; they are worth opening, but a badge is not a substitute for reading how conversation data is stored and how long it is kept. Anyone evaluating EDDI for a healthcare or public-sector deployment should treat the compliance line as a claim to verify against the docs site, not as a feature list.

Where EDDI is the wrong tool, and what to use instead

EDDI is the wrong choice if you want your agent logic to be ordinary application code that you unit test with the rest of your service. The config-driven model is the whole point, and it is also the constraint: anything the JSON schema cannot express becomes a feature request rather than a pull request in your own repository. It is also a poor fit if your team is Python-native. LangChain or LlamaIndex would let you define the same routing and memory behaviour in the language your engineers already use, at the cost of owning the deployment, the persistence layer and the protocol endpoints yourself. The trade is concrete. EDDI gives you MCP client and server support, A2A, Keycloak integration, Prometheus and Grafana overlays and a database choice out of the box, and asks you to accept a Java 25 runtime and a JSON configuration surface in return. A Python framework gives you direct control over the orchestration loop and asks you to build the operational scaffolding. If you have neither a Java estate nor a platform team, the scaffolding cost is usually the smaller problem.

Editorial conclusion

Adopt EDDI if your team already runs Java services and wants agent behaviour expressed as versioned JSON rather than as application code, and if a Docker Compose deployment with MongoDB or PostgreSQL is acceptable. Do not adopt it if you need a Python-native stack, or if you intend to run it without reading the compose files, because the PostgreSQL path is a standalone stack that cannot be layered onto the default one. Before committing, verify two things on your own machine: whether the installer's generated vault key survives your backup and restore process, and whether the compliance claims in the README are backed by documentation you can hand to a reviewer.

Official sources

Community notes