E.D.D.I — Multi-Agent Orchestration Middleware for Conversational AI

E.D.D.I (Enhanced Dialog Driven Interface) is a production-grade, config-driven multi-agent orchestration middleware for conversational AI. It coordinates users, AI agents, and business systems through intelligent routing, persistent memory, and API orchestration — without writing code.

Built with Java 25 and Quarkus. Ships as a Red Hat-certified Docker image with the Manager dashboard and Chat UI built in. Selected as a UNIDO Trusted Partner for Industrial AI. Native support for MCP (Model Context Protocol), A2A (Agent-to-Agent), the OpenAI Chat Completions API, Slack, OpenAPI, and OAuth 2.0.

Website · Documentation · License: Apache 2.0

📑 Table of Contents

• 🏁 Quick Start
• 💡 Why EDDI?
• 📸 See It In Action
• ✨ Features
• 📖 Documentation
• 📋 Compliance & Privacy
• 🏗️ Development
  • Prerequisites
  • Quarkus Dev Mode
  • Maven Command Reference
  • Build & Docker
  • Kubernetes
• 🤝 Contributing
• 🔒 Security
• 📜 Code of Conduct

🏁 Quick Start

The fastest way to get EDDI running is the one-command installer. It sets up EDDI + your choice of database via Docker Compose and points you at the dashboard, where the Platform Operator (or the form-based agent wizard) creates your first AI agent for you.

Linux / macOS / WSL2:

curl -fsSL https://raw.githubusercontent.com/labsai/EDDI/main/install.sh | bash

Windows (PowerShell):

Invoke-WebRequest -UseBasicParsing -Uri "https://raw.githubusercontent.com/labsai/EDDI/main/install.ps1" -OutFile "install.ps1"
Unblock-File .\install.ps1
.\install.ps1

Requires Docker. The wizard auto-generates a unique vault encryption key for secret management.

Everything is served from one port: http://localhost:7070 opens a chooser between the Manager (/manage, the admin dashboard) and the Workforce workspace (/workforce, group conversations), and the standalone chat UI is at /chat. See Getting Started.

bash install.sh --defaults                 # All defaults, no prompts
bash install.sh --db=postgres --with-auth  # PostgreSQL + Keycloak
bash install.sh --full                     # Everything enabled (PostgreSQL + auth + monitoring)
bash install.sh --local                    # Build Docker image from local source
bash install.sh --eddi-version=6.5.0       # Pin a release (image and compose files from its tag)
bash install.sh --dry-run                  # Show the image tag and the git ref the files come from

With the default latest image, the compose files are downloaded from the newest release's tag (looked up through the GitHub API), not from main.

The --local flag is for contributors testing pre-release builds:

./mvnw package -DskipTests    # Build the Java app
bash install.sh --local        # Build Docker image + start containers

🔄 Updating

The installer creates an eddi CLI wrapper that makes updating easy:

eddi update

This pulls the latest Docker image from the registry and restarts the containers. It works even when the same tag (e.g. latest) was re-published — Docker always checks the remote digest for changes.

Upgrading across releases? Read the upgrade guide first: Upgrading from 6.4 lists what an existing deployment must change, because several defaults now fail closed (a Keycloak realm imported from 6.1–6.4 needs a repair that re-running the installer applies and eddi update does not). A database that comes from EDDI 5 starts with Upgrading from 5.x.

eddi command not found? The CLI lives at ~/.eddi/eddi (Linux/macOS) or ~/.eddi/eddi.cmd (Windows). Either restart your terminal so the PATH takes effect, or use the full path:

# Linux / macOS
~/.eddi/eddi update

# Windows (PowerShell)
& "$HOME\.eddi\eddi.cmd" update

If the eddi CLI isn't available, run the equivalent docker commands from your install directory (~/.eddi by default):

cd ~/.eddi
docker compose --env-file .env -f docker-compose.yml pull
docker compose --env-file .env -f docker-compose.yml up -d

Adjust the -f flags to match your setup (e.g. add -f docker-compose.auth.yml if using Keycloak).

🐳 Docker Compose (Manual)

If you prefer manual control over Docker Compose:

# Default (EDDI + MongoDB)
docker compose up

# PostgreSQL instead of MongoDB — a complete stack, so it is NOT layered on
# docker-compose.yml (an overlay cannot un-declare the base's mongodb service)
docker compose -f docker-compose.postgres-only.yml up

# With Keycloak authentication. No realm account ships a password (see the
# header of docker-compose.auth.yml, or let install.sh --with-auth set one)
docker compose -f docker-compose.yml -f docker-compose.auth.yml up

# With Prometheus + Grafana monitoring
docker compose -f docker-compose.yml -f docker-compose.monitoring.yml up

# With a local LLM — Ollama on the same Docker network, reachable as
# http://ollama:11434 (no host.docker.internal needed)
docker compose -f docker-compose.yml -f docker-compose.ollama.yml up -d

# The same local LLM, on the host's NVIDIA GPUs — layered on the Ollama overlay
# above, never instead of it (all it adds is `gpus: all`)
docker compose -f docker-compose.yml -f docker-compose.ollama.yml \
  -f docker-compose.ollama-nvidia.yml up -d

# Auth + monitoring + NATS together (overlays stack in any combination)
docker compose -f docker-compose.yml -f docker-compose.auth.yml \
  -f docker-compose.monitoring.yml -f docker-compose.nats.yml up

Available compose overlays: docker-compose.auth.yml (Keycloak), docker-compose.monitoring.yml (Prometheus+Grafana), docker-compose.nats.yml (NATS JetStream), docker-compose.ollama.yml (local LLM; add docker-compose.ollama-nvidia.yml on top for NVIDIA GPU access), docker-compose.chroma.yml (vector store), docker-compose.mcp-sidecar.yml (reach a stdio-only MCP server through a bridge sidecar — read the MCP Client guide first), docker-compose.local.yml (build from source). docker-compose.postgres-only.yml is a complete standalone stack rather than an overlay — use it on its own, not with -f docker-compose.yml; so is docker-compose.openwebui.yml, a runnable Open WebUI demo of the OpenAI-compatible API.

The compose files publish EDDI (and Keycloak) on 127.0.0.1 only. To reach them from another host, set EDDI_BIND=0.0.0.0 (and KEYCLOAK_BIND for Keycloak) in .env — with authentication on.

The Ollama overlay pulls llama3.2:3b on first start and keeps models in a named volume; override with OLLAMA_PULL_MODEL=qwen3:4b, or set it empty to skip the pull. It also sets EDDI_OLLAMA_DEFAULT_BASE_URL, so the agent wizard and the setup API pre-fill a base URL that resolves from inside the container — the one thing that trips up every first local-LLM agent, because localhost there is the container, not the host.

docker-compose.ollama-nvidia.yml adds GPU access to that Ollama and needs two things of the host, neither of which it degrades gracefully without: Docker Compose 2.30.0 or newer, which is where the gpus service attribute was introduced — older versions fail on it, so check docker compose version — and the NVIDIA Container Toolkit configured as a Docker runtime. gpus: all is a device request: with no GPU driver registered, the daemon cannot satisfy it and the container fails to start (could not select device driver "" with capabilities: [[gpu]]) rather than quietly falling back to the CPU. If you want Ollama on the CPU, leave this overlay off.

docker pull labsai/eddi    # Pull latest from Docker Hub

→ hub.docker.com/r/labsai/eddi

💡 Why EDDI?

Most multi-agent frameworks (Lan