Quick Start

Get from zero to a ranked offer and a recorded response. Workbench configures campaigns; the Runtime (Client Pulse Responder) scores them in real time. Learning only happens if you close the loop.

Hosted demo: https://medemo.ecosystem.ai . Point the Runtime Dashboard Runtime URL at that host (or at your local Runtime on 8091 / 8099) and Invoke a campaign.

What you are running

Current Workbench train: 2.0.3 (pins Runtime 0.9.7.0, Server 0.7.9.0, Notebooks 0.3). Runtime runs on Java 25 (Amazon Corretto 25). Workbench 2 local backend is Python 3.14.

Piece	Role	Current pin
Runtime	Java 25 scoring engine: plugins, `/invocations`, `/response`, builtin MCP, dashboard, campaign BDD	0.9.7.0
Workbench	Operator UI: projects, deployments, EcoGentic journeys, Claude Operator	2.0.3
Server	Modeling, corpora, push to Runtime	0.7.9.0
Notebooks	Processing / generative workers (not the scorer)	0.3

Product differences live in plugins and properties, not if (product == …) in the Runtime. See architecture.

Closed loop (required)


Your app or dashboard
  → POST /invocations   (params is a JSON string)
  ← ranked final_result (save uuid + offer_name)
  → POST /response      (singular — never /responses)


{
  "campaign": "your_campaign",
  "subcampaign": "your_campaign",
  "customer": "none",
  "channel": "app",
  "numberoffers": "2",
  "userid": "ecosystem",
  "params": "{}"
}

params stays a string ("{}" or encoded {"input":[...],"value":[...]}). Nested JSON in params is rejected.

On accept, send that row’s uuid plus offer_name:


{
  "uuid": "dcb54a23-0737-4768-845d-48162598c0f7",
  "offers_accepted": [{ "offer_name": "OFFER_A" }],
  "channel_name": "app"
}

Full contract: API Access.

Runtime Dashboard — invoke a campaign and accept an offer

First score (after install, or on the demo)

Open the Runtime Dashboard. Default Runtime port is 8091 (local run_local.sh often 8099).
Pick an ACTIVE campaign, set customer / channel / number of offers, Invoke.
Accept a ranked row. That sends POST /response with that row’s uuid and offer_name.
Optional: MCP tab → Ontology Explorer; Testing tab → properties-driven BDD.

Runtime DashboardInvoke, accept, MCP, and config.Ontology for agentsGround MCP tools before invoke / response.Campaign testingCucumber BDD from the campaign properties file.

Runtime Ontology Explorer — search concepts and related MCP tools

Campaign Testing — properties-driven BDD report

Install the stack

Local setupClone the compose repo, Docker Desktop, start.sh.MarketplaceAWS or Azure listings for platform and modules.Docker ComposeService map: Workbench, Server, Runtime, Notebooks.Kubernetes / OpenShiftCluster install and environment maps.

Longer local guide: Local Installation. Compose detail: Docker Compose. OpenShift: OpenShift. After containers are up: Post-install.

Copy ecosystem_env.txt to .env. Set ECOSYSTEM_API_KEY (license). OPENAI_API_KEY is only needed for generative paths. Do not commit .env.

Ports (typical)

Surface	Port	Notes
Workbench (Docker / marketplace)	80 / mapped path	Default login `admin@ecosystem.ai` / `password` — change it
Workbench 2 local SPA	5270	`frontend/run.sh`
Workbench private API	8001	Workbench MCP Streamable HTTP `POST /mcp`
Server	3001	Modeling APIs
Runtime	8091	Scoring; builtin MCP is `POST {RUNTIME}/mcp` on this port. Local debug often 8099
Grafana	3000	Optional infra charts — not the Runtime tester UI

Default Docker Compose maps 8092–8095 to extra Runtime scoring instances (ecosystem-runtime-solo2 …). Builtin MCP is on the same scoring port as /invocations (8091). A separate Python MCP sidecar image exists for MLFlow / custom FastAPI; do not confuse it with Runtime-solo2.

There are three MCP-related surfaces. They share the path /mcp but are not interchangeable. See MCP Support.

Surface	Where	Use
Runtime builtin MCP	`POST {RUNTIME}/mcp` (0.9.7+)	Score, feedback, ontology validate, campaign admin
Workbench MCP	Workbench API 8001 `POST /mcp`	Deployments, enrichment, operator tools
Runtime MCP sidecar	Optional Python image	MLFlow refresh, custom FastAPI

Configure a campaign

In Workbench, create or open a project and deployment.
Choose predictor type: Dynamic Engagement (named approach / sub_approach), static H2O, or Two-Tower (predictor.model.type=similarity — not a bandit approach). Catalog: Algorithms.
Set pre-score / post-score / reward plugins. Single-class custom Java can Compile (JIT /generateClass from Runtime 0.9.6.0). Multi-class plugins still need a build pipeline.
Push the deployment to the Runtime. Confirm /ping and the campaign on the dashboard.

Do not invent algorithm IDs. Python create_online_learning(..., algorithm="ecosystem_rewards") is a document type, not the scoring approach.

Agents

Runtime 0.9.7+ exposes ontology REST (GET /ontology/runtime/...) and MCP tools so agents validate payloads before scoring.

Recommended flow: getClosedLoopRecipe → listCampaigns → validateInvokeRequest → invoke → validateResponseRequest → response.

Walkthrough: Ontology for agents. Prompts such as runtime-closed-loop are listed on MCP Support.

What 0.9.7 / Workbench 2 added

Use these after the stack is up — they are the operator surfaces that used to be missing from this page.

Capability	Where
Runtime Dashboard (invoke / accept)	Dashboard
Ontology Explorer + REST catalog	Ontology for agents
Campaign Cucumber / BDD	Campaign testing (`POST /test/campaign`)
Builtin MCP	MCP Support
JIT plugin compile	Parameters (`/generateClass`)
Virtual variables on all deployment types	Virtual variables
Model convergence (Dynamic Engagement)	Model convergence

Release notes: Runtime 0.9.7.0, Workbench 2.0.3.

User guides — recommenders, plugins, virtual variables
Runtime plugins — pre / post / reward
Model convergence — Dynamic Engagement tuning
Changelog — Runtime 0.9.x and Workbench 2.0.x