Concepts at a Glance

TL;DR

Orkestia is one idea repeated everywhere: every capability is a workflow. The rest of the vocabulary describes who designs workflows (DGI, assistants over MCP), who runs them (the engine, on runners in your cloud), who governs the AI that runs them (Staff), how organizations hire each other's actors (Agent Exchange), and what is stored (state, Lumen telemetry, App Data rows, Engram memories).

This page gives you one paragraph per concept and a prompt to try with an assistant connected to the Orkestia MCP server. The deep pages are one click away.

The model in one breath

A workflow type is a capability with a typed input and output contract. Starting one creates a run with its own workflow_id that you watch, inspect, and retry. The engine underneath is an event-sourced state machine: deterministic, concurrency-safe, replayable. AI assistants discover and run capabilities over MCP. DGI lets AI reason about what you want and design a workflow; that design compiles into a deterministic composition. Staff governs the fleets of AI agents; each agent is an agent config (model, skills, tools, budget) launched as sessions on your runners. Agent Exchange is the labor market for those actors across organizations. Lumen observes everything, Engram is what agents remember, App Data holds declared app rows, App Host is opt-in hosting, and identity scopes it all to organizations and end-users.

The concepts

One paragraph each

Workflows and runs

A workflow type is a registered capability with a typed schema and a dotted name such as connection.setup or aws.s3.create_bucket. Starting one produces a run with a unique workflow_id. Atomic types follow PENDING → COMPLETED | FAILED; DAG types chain many steps in layers. Transitions are durable and replayable, and concurrency is guarded so the same run never executes twice. The loop is always the same: discover, fetch the schema (and prerequisites), start, watch.

List the workflow types under the "connection." namespace and tell me which ones are read-only.

Read more: Workflows

MCP: the assistant door

The Orkestia MCP server at https://mcp.orkestia.dev/mcp is how any assistant or agent drives the platform. It exposes tools (whoami, discovery, schema, prerequisites, start, watch, history, stuck runs, retry, resolve, open_app), resources that carry the rules (rule://getting-started, rule://prerequisites-first, rule://grounding, and more), and prompt templates (how_to_use_workflow_mcp, diagnose_workflow_run). Your token scopes everything to your org. Lumen has its own MCP at https://mcp-lumen.orkestia.dev/mcp.

Invoke the how_to_use_workflow_mcp prompt and follow it to show me what my organization can do.

Read more: Connect an AI assistant · MCP integration

Compositions (virtual workflows)

A composition chains existing workflows into your own logic with no new execution code. You declare layers of steps; each step input says where its value comes from: the composition input, a prior step's output, or a static literal. Before anything runs, the design is validated in three phases (structure, references, compatibility) against the live catalog, then compiled to a plain DAG the engine runs like any other workflow. Saved compositions become runnable virtual.<uuid>@<version> types, per organization.

Read concept://dag, then design a two-step composition that creates an S3 bucket and tags it. Validate it against the catalog but do not save it.

Read more: Virtual workflows

DGI

The Dialog Generative Interface is the AI reasoning surface. You describe what you want; DGI interprets the intent, selects capabilities by reading their schemas, assembles a DAG, and hands it to the engine. It never invents workflow names: it selects only from the declared catalog. DGI registers its own dgi.* workflow types, so the reasoning loop runs through the engine, not beside it.

Plan, without executing, the steps needed to deploy a static site from a GitHub repo and point a domain at it. Use only workflow types that exist in my catalog.

Read more: DGI

Staff

Staff is governance for fleets of AI agents. It treats them like an organization: units, actors, role bindings, approval gates, and an audit trail. RBAC is enforced inside the workflow engine through capability metadata on each workflow, so every privileged action is checked at the same layer that runs it, no matter which door it came through. The operator console is at staff.orkestia.dev.

List the Staff actors in my organization and the capabilities each one is allowed to use.

Read more: Staff governance · Operator path: Staff & Agents

Agents

Under every Staff actor sits the agents substrate. An agent config declares the model, standing guidance, workflow-backed skills, per-agent MCP servers, and a budget. Launching the actor starts a session on runner capacity in your cloud. Skills are the guardrail: tool calls are policy-gated against the workflows the skills grant. An actor with no skills can reason but not act.

Show me the agent configs in my org and, for each, which skills and MCP servers are attached.

Read more: Agents

Agent Exchange

Agent Exchange is the labor market for Staff actors. A listing is a versioned offer; a deal is the contract; a lease is the hired position. Buyers send payloads; sellers keep prompts and connections. Orkestia records the ledger and never holds the funds. Same-org hires use the Internal rail and never pay. Operate it at exchange.orkestia.dev.

List workflow types under "data.exchange." and explain which ones read listings without passing another organization's UUID.

Read more: Agent Exchange · Operator path: Agent Exchange

Runners

Runners are where execution physically happens: in your own cloud accounts, never on Orkestia. Runner groups provision self-hosted runners on AWS, Azure, Kubernetes (production), GCP, DigitalOcean, and Magalu Cloud (beta). A reconcile loop converges each group to its min and max, health checks reap dead runners, and drift is repaired. Runner groups also host agent sessions for Staff.

List my runner groups with their provider, state, and scaling policy.

Read more: Runners

Lumen

Lumen is a separate telemetry API (https://lumen-api.orkestia.dev). The engine stores run state; Lumen stores what you send (logs, metrics, Pulse) plus derived error groups and traces. It is off until an org admin provisions it (403 LUMEN_NOT_PROVISIONED). Keys are lumk_ (ingest, read) and lump_ (Pulse). Triage from an assistant goes through the Lumen MCP at https://mcp-lumen.orkestia.dev/mcp.

Using the Lumen MCP, list the open error groups from the last 24 hours and rank them by occurrence count.

Read more: Lumen

Identity and multi-tenancy

Everything is org-scoped. Members (your team) operate the platform. End-users (your app's users) sign in with "Sign in with Orkestia" through @orkestia/auth and can only run the workflows you expose, scoped to their own data. Your organization is resolved server-side from your token; you never pass it by hand.

Call whoami and explain what kind of principal I am and which organization my runs will be scoped to.

Read more: Identity & multi-tenancy

Billing and seats

Orkestia bills the organization: a platform subscription, seats for both humans and AI actors, end-user seat packs for apps you build, and optional add-ons. Above the volume the platform fee includes, usage is metered on workflow executions and requests, and orkestia.dev/pricing is the single pricing source. Per-actor budgets bound what an agent may spend.

Read more: Billing, Pricing & Seats

App Data

App Data is declared application state: virtual tables, serving instances, no DSN in the frontend. End-users never send SQL (workflows, Data API, PostgREST, exposed virtuals). Operators use Query for admitted SELECT. Ownership (owner, app, organization workspace) is enforced on every record op.

Describe the App Data structures declared for my organization.

Read more: App Data

App Host

App Host is opt-in hosting on Orkestia's shared pool: claim https://<slug>.app.orkestia.dev for a live Identity app, attach App Data, publish a zip or launch a process, and optionally apply Buzz (a Nostr relay on buzz-<slug>.orkestia.dev). Cloud Deploy into your AWS is a different product.

List apphost.site.* workflow types and tell me which ones require a live Identity app.

Read more: App Host

Chat

A chat space gives an identity app a team chat on its App Host site. End-users sign in with their app identity and get channels, threads, DMs, search and attachments. Staff actors bound to a seat in the app answer mentions, DMs or whole channels, and can hand a conversation to a person as a ticket. Every control-plane step is a buzz.* workflow; messages go straight to the relay.

List my chat spaces with data.buzz.space.list and run buzz.space.status on each one.

Read more: Chat

Engram

Engram is agent memory: what a session remembers and what the next one loads. Same fingerprint reinforces instead of duplicating. Recall defaults to newest-first (last_k); pack is cue-ranked. Writing is a separate flag. Inspect the live field at engram.orkestia.dev.

Read more: Engram

DevKit

DevKit is the local CLI: webhook redirect to localhost, a provider-blind coding runner, ticket sync, and vw for compositions. It authenticates with an API token from Settings.

Read more: DevKit

SDKs

@ltinteg/workflows-sdk (Node) and ltinteg-workflows-sdk (Python) are generated from the live catalog, one typed start helper per workflow. @orkestia/auth is the browser PKCE SDK for your app's users.

Read more: SDKs

How the concepts fit together

The throughline: AI designs, the engine runs deterministically, governance keeps it accountable, your cloud does the work, and Orkestia keeps only the state and the story.

Where this leads