What is DGI
Orkestia is Orkestia.dev. DGI (Dialog Generative Interface) is the part of Orkestia that listens to a person and decides which of your workflows answers them. It reads what the person asked, picks from the workflows your organization allows, and replies with something you can act on: a table you can sort, a chart, a form with exactly the fields a workflow needs, or a confirm card for a change. DGI is Alpha.
TL;DR
- Your workflows are its vocabulary. DGI can only run workflows that are registered in your organization, allowed by you, and permitted for the person asking. It never invents a capability.
- It answers with cards, not just text. Reads come back as tables, charts, KPI tiles, logs, grids, diagrams or timelines. The numbers come from the workflow's output, never from a model.
- Changes wait for a person. A write is always proposed on a confirm card first. It runs only when the person it was issued to presses Confirm, once, before it expires. A typed "yes" never counts.
- Typed decisions first, the LLM only if you opt in. Most requests are decided by Jev, a typed decision engine, in one call. The LLM is off by default, and when you turn it on it runs on your organization's own AI provider.
- It runs as the person, not as a robot. Every read and every write runs with the permissions of whoever asked. A member sees what they may see; an end user of your app sees only what your app exposes to end users.
- Use it where your people already are: a chat, your own app over an API, a live page of cards, or an AI assistant over MCP.
What DGI does
| A person says | DGI does | They see |
|---|---|---|
| "Which tickets are open for Acme?" | Picks the read workflow, runs it as the person | A table with row actions such as Details or Assign |
| "Failures by type this week" | Runs the read, counts by a column | A bar chart, drawn from the returned rows |
| "Create an order for Ana, 2 units" | Finds the create workflow and the inputs it still needs | A form with only the missing fields, then a confirm card |
| "Keep an eye on the checkout outage" | Grows a page of live cards for that intent | A Living Surface that updates itself |
| Something your workflows cannot do | Says so, offers what it can do instead | Suggestion chips. You can capture the request for your team |
Where you can use it
| Interface | Best for | Start here |
|---|---|---|
| Chat | People who already talk in your Orkestia chat space: hosted page, embedded React component, or your own client | Structured chat with DGI |
| Any app or API | A support widget, a mobile screen, a backend: send a message, draw the card you get back | Quickstart · Option D |
| Living Surfaces | A page of live cards, outside any conversation, that keeps itself current | Living Surfaces |
| One card, no conversation | Show a single read as a card in your own screen, with no model involved | Interfaces |
| AI assistants over MCP | Claude, ChatGPT or an agent driving the same catalog | Connect an AI assistant |
All of them share one backend: the same cards, the same decision engine and the same safety checks. See Interfaces for how to choose.
What DGI never does
- Run a workflow you did not allow. Chat actors, chat profiles and Living Surfaces each require an explicit allow-list (
allowed_workflow_types), intersected with what the caller may run. An empty list is refused. A single card (dgi.view.render) runs only the read-only workflow you name, as the caller. - Change something without a confirm. Writes are proposals until a person confirms the exact proposal the server stored.
- Show one person's data to another. Cards are read as the viewer. A shared page or card carries its recipe, not its data.
- Make up numbers. Charts, tiles and tables are built in code from workflow output.
- Hold your cloud credentials. DGI works through your connections; secrets never travel in a prompt, a card or a plan.
When a capability is missing
If nobody has built the workflow a person needs, DGI does not improvise one. It says what it can do instead, and your app can record the gap with dgi.workflow-request.create (a description of the capability, optionally the conversation it came from), so your team can build it.
Status
| Capability | Status |
|---|---|
| Structured chat: cards, forms, confirms, chips | Alpha, available |
dgi.chat.* API for any app | Alpha, available |
Living Surfaces (dgi.surface.*) | Alpha, available |
Single read as a card (dgi.view.render) | Alpha, available |
| Jev typed decisions, LLM fallback by opt-in | Alpha, available |
Promote a designed plan to a reusable composition (dgi.workflow.promote) | Alpha, available to members |
| Automatic end-to-end dispatch of multi-step plans | Roadmap |
Where to go next
Living Surfaces
A page of live cards that DGI grows, keeps current and retires by itself. Create, tick, signal, read, list, archive and crystallize a surface with dgi.surface.*, set its policy, run its heartbeat, and follow its patch stream over a WebSocket
How DGI works
The life of one DGI request. Who it runs as, which workflows it may reach, how Jev and the optional LLM decide, how reads become cards and writes become confirms, and how the person's answer comes back