DGI — Dialog Generative Interface

TL;DR

• DGI is the reasoning front door. You give it a goal in plain language. It interprets the intent, selects capabilities by reading their schemas, assembles a DAG, and hands it to the engine.
• AI designs, the engine executes. DGI never runs anything itself, and never invents workflow names. It selects only from the declared catalog.
• DGI and MCP share one catalog. An assistant over MCP picks one type and starts it. DGI assembles many types into a plan. Same registry, same schemas, same engine.
• Good plans freeze into compositions. A plan that works becomes a virtual workflow that runs with no model call.
• Status: alpha. Structured answers (chat, the dgi.chat API, Living Surfaces), reasoning, plan compilation and promote-to-composition ship today. Automatic end-to-end dispatch of multi-step plans is on the roadmap.

DGI stands for Dialog Generative Interface: the natural-language, dialog-driven surface in front of the engine. Older material sometimes reads it as Dynamic Goal Interpreter. Same component; that reading describes what it does: it interprets a goal through a dialog.

Where DGI sits

Everything on Orkestia resolves to one primitive: a workflow. DGI does not invent a parallel execution path. It produces the same workflows that the MCP server exposes to assistants, that Staff actors run, and that you can compose by hand.

Two internal components split the work:

• The reasoning core runs the configured LLM (through your org's AI provider connection), turns a goal into reasoning steps, and proposes candidate skills that map onto workflow types.
• The plan compiler (the virtual engine) discovers installed workflows, assembles a layered DAG, validates it (structure, references, compatibility), and compiles it to engine config.

DGI draws its catalog from the same registry that backs the workflow types registry and MCP discovery. Its own operations are registered as dgi.* workflow types, so the reasoning loop runs through the engine, not beside it.

The DGI loop

1. Interpret the goal

DGI starts from language, not a form. The message plus dialog state is parsed into a structured intent: what the user wants, the entities involved (a repo, a domain, an environment), and the constraints. If a domain is named but no DNS provider is connected, or "the repo" is ambiguous, DGI surfaces the gap rather than guessing. That is the same discipline the MCP server enforces with rule://prerequisites-first.

2. Select capabilities through schemas

This stage keeps DGI grounded. Every workflow type publishes a typed input schema and declares its prerequisites. DGI selects capabilities by reading those schemas, the same way an assistant does over MCP:

A step can only be wired into the DAG if its inputs can be satisfied: by the goal, by a connection, or by an earlier step's output.

3. Assemble the plan

With candidates and schemas known, DGI assembles a DAG. Each node is a workflow; each edge is a data dependency.

{
  "goal": "Stand up a static site for acme/marketing-site and point acme.com at it",
  "plan": {
    "nodes": [
      { "id": "build",  "workflow": "<build-static-site>", "inputs": { "repo": "acme/marketing-site" } },
      { "id": "deploy", "workflow": "<deploy-to-cdn>",     "inputs": { "artifact": "${build.output.artifact}" } },
      { "id": "dns",    "workflow": "<point-domain>",      "inputs": { "domain": "acme.com", "target": "${deploy.output.endpoint}" } }
    ],
    "edges": [
      { "from": "build",  "to": "deploy" },
      { "from": "deploy", "to": "dns" }
    ]
  }
}

The DAG is validated as a whole before anything runs: no cycles, every required input bound, every binding type-compatible with the producing step's output.

4. Execute as a workflow

Once assembled, the plan is just a run on the deterministic engine: event-sourced state, per-run locks, async transitions, Lumen traces, and step-level retry. Execution is deterministic. The AI reasoned about which steps and how they connect; running them does not call the model again.

DGI, assistants, and MCP

DGI and the MCP server are two ways into the same catalog:

An assistant can use DGI as a planning tool ("interpret this goal into a plan") and then watch the resulting run over MCP. Staff runs DGI-produced plans as managed, budgeted, audited work. Because every selection is schema-grounded and every step is a registered workflow, the same governance, identity, and observability apply no matter who pressed the button.

From designed plan to composition

The first time DGI interprets a goal, it pays the full cost: interpretation, catalog search, schema inspection, assembly. Re-reasoning a recurring goal every time is wasteful and non-deterministic. The hybrid model closes this gap: a plan that proves good is compiled into a composition, a single reusable, named, deterministic workflow type with its own schema.

A finished composition runs as virtual.<uuid>@<version>, has a typed input schema, and runs with zero model inference. Design once with reasoning; run forever without it.

Current capabilities

Ask your AI assistant

Plan, without executing, how to deploy a static site from GitHub and point a domain at it. Use only workflow types that exist in my catalog and show each step's inputs.

List the dgi.* workflow types in my org and describe what each one does.

Turn this plan into a composition definition with explicit input mappings, validate it, and show me the errors.

For AI agents

Where to go next