How DGI works

TL;DR

• One turn = one workflow run tree. Sending a message starts a run. Everything DGI does for that turn (classify, reason, call tools, answer) is nested runs under it, visible in Lumen.
• Two paths. An intent gate sends small talk down a fast path (one model call, no tools) and anything that touches your resources down a deep path (a bounded tool loop).
• DGI acts only through the catalog. The deep path has a fixed set of tools: discover types, read schemas and prerequisites, start workflows, ask you for inputs, render results, and build a composition. It cannot call anything that is not a registered workflow.
• Two per-turn modes you can toggle: Deep reasoning and Proactive.
• DGI has no "coding mode". Coding sessions are Staff coding agents, which DGI can help you plan and watch but does not run. They have two modes: laptop and hosted. See Coding sessions.

This page extends DGI — Dialog Generative Interface, which covers what DGI is and how plans become compositions.

Anatomy of a turn

1. Save the message. The message is stored on the conversation before any reasoning starts, so a refresh or a dropped connection never loses it.
2. Intent gate. One short model call classifies the message: does it need live platform data or an action, or can it be answered from general knowledge?
3. Fast or deep path (below).
4. Finalize. The reply, its reasoning trace, suggestions, and the current composition (if any) are persisted together.
5. Stream. The UI receives the turn as it happens (see Streaming).

The turn is dispatched asynchronously: the request returns a run id immediately and the work continues in the engine. That is why a long turn survives a closed tab, and why you can reattach to it later.

The intent gate

The gate fails open. If the classifier errors or returns something unparseable, DGI treats the message as needing tools, so a real task is never starved of its tools.

Fast path

A single completion with no tools and a small output budget. Cheaper and quicker, and it cannot touch your resources.

Deep path: the tool loop

The model runs in a loop. Each round it either calls tools or produces the final answer. The loop is bounded three ways: a turn budget, a per-round output budget, and a wall-clock deadline for the whole turn. If any limit is hit, DGI stops calling tools and closes with an honest "budget exhausted" answer that says what it did and did not finish, instead of hanging.

The tool surface is fixed:

Three rules shape how these tools behave:

• Schema first. Before start_workflow, DGI reads the schema and the prerequisites. A missing connection or input becomes a question to you (request_inputs) or a setup link, never a guess.
• Same gates as everyone else. Every start_workflow runs under your identity and org. Staff approvals and budgets apply. An action that needs approval pauses as a pending action for you to approve.
• Tool results are clipped. Large results are truncated before they go back to the model, with an explicit truncation note, so one big list cannot crowd out the rest of the context.

Conversation context

Chat text alone is a weak place to keep "which connection did we pick?". DGI keeps a working set for the session: the focus of the conversation (for example, deploying an image to a cluster), the entities you selected, and candidate lists from earlier tool results.

• Identifiers never go through the model as free text. The model sees short references and masked labels for resources; the real ids are substituted server-side when a workflow starts. This prevents a model from reconstructing or mangling an id it only saw in prose.
• The working set persists per session, so a follow-up like "now the same for staging" resolves against what you already selected.
• History is queryable. Older turns and the runs they started can be recalled on demand (the Context tools above) rather than replayed in full on every turn.

Per-turn modes

The composer shows two toggles. They apply to the next message you send and can be changed at any time without restarting the session.

Neither mode bypasses a gate: they change how much DGI reasons and suggests, not what it is allowed to do.

Streaming

The whole turn tree streams to the browser over a single live connection. You see:

• the phase ("Understanding…", "Reasoning…", "Applying skills…", "Composing the answer…");
• the activity tree of nested runs and their states;
• reasoning entries: the model's thoughts and each tool call as it happens;
• the composition being built, updated as steps are added.

The browser does not poll. If you close the tab mid-turn, the turn keeps running, and reopening the session restores the view and resubscribes to the live run.

Token-by-token output is not available yet: replies arrive whole when the model finishes a round.

Surfaces

The same loop backs several interaction surfaces in the DGI app:

Coding sessions

DGI plans and observes; it does not edit code. Code changes are done by Staff coding agents, which have two operating modes. Both are provider-blind: the agent never holds git credentials, and only a trusted broker talks to your git remote.

Both follow the same lifecycle: claim a ticket, investigate in a leased worktree, write a plan, wait for human acknowledgement, implement against the acknowledged head, and publish exact git objects through the broker. See Coding agents, Wire a repository, and Run a ticket end to end.

How DGI helps around a coding session:

Limits and guarantees

Ask your AI assistant

Explain the difference between DGI's fast path and deep path using one example of each from my own questions.

List the dgi.* workflow types in my org and tell me which ones are used by the chat path.

Which repositories in my org are registered for coding agents, and which runner groups can serve them?