The loop in one line
1. Author
Describe a process to the AI Composer, or build it on the visual canvas. Both produce the same editable workflow graph.
2. Run
Start a run from chat, the API, or an SDK. ModuleX checks your credit and capacity, then executes the graph step by step.
3. Observe
Watch the run stream its progress event by event, pause it for your input when needed, and inspect the final result.
Step 1 — Author a workflow
A workflow is an editable graph that connects tools, data, and agents into a repeatable process. You build it one of two ways, and both ways edit the same graph.Describe it with the AI Composer
Tell the AI Composer what you want in plain English. It turns your description into a complete, editable workflow graph, then keeps editing the canvas as you chat with it.
Build it on the canvas
Open the workflow builder and place nodes by hand. You connect steps, set their options, and pass data between them with references.
{{node_id.field}}. You do not need the details now; the workflow engine and the node types overview cover them in depth.
Authoring is multi-user. Several people can edit the same canvas at once, with live cursors, presence, and node locks so edits never collide. See the realtime and collaboration model.
Step 2 — Run it
A run is one execution of a workflow. You can start a run from three places, and the result is the same execution either way.From chat
Trigger a workflow inside a chat and watch it run there.
From the API
Run a workflow programmatically over REST and stream the result.
From an SDK
Run from your own code with the official JavaScript or Python client.
What happens when you press run
1
ModuleX checks you can run
Before any work starts, ModuleX runs a quick admission check: do you have the credit and the capacity to run right now? If yes, the run proceeds. If not, the request is declined cleanly with a billing error — nothing partial executes. This check applies to runs, AI Composer turns, Assistant turns, and managed-knowledge calls.
2
The run starts and you get a run id
ModuleX accepts the request and hands back a run id along with a stream you can listen on. The actual execution happens in the background, so the response comes back immediately.
3
Each node executes in turn
The engine walks the graph from its entry point. Every node does its work — calling a model, retrieving from a knowledge base, calling an integration tool, branching, and so on — and writes its result into the run state for the next step to read.
4
The run reaches a final state
The run ends in one of a small set of outcomes — it completes, it fails, or it is cancelled. Some runs pause partway to ask you a question first (see Observe).
The admission check is real and live on the run, AI Composer, Assistant, and managed-knowledge surfaces. When it declines a request you get a
402, 403, or 429 response carrying a structured reason (usage gating & limits). Plain create, read, update, delete, and organization-settings calls are not gated this way — they return a simpler error shape. See Errors & status codes for both.What a run costs
ModuleX meters managed usage in credits. Each run is a flat charge, plus the managed model and managed-retrieval usage it consumes along the way. If you bring your own model keys, that usage is billed by your provider and is not metered as credits. The credits and billing model explains exactly what consumes credits.Step 3 — Observe the run
You do not wait blindly for a result. While a run executes, it streams its progress to you event by event over Server-Sent Events (SSE) — so you can watch each step happen live, in the app or from your own code.Live event stream
The run emits a sequence of events as it goes: a metadata event when it starts, a node-update event each time a step finishes, and a terminal event when it ends. You read them in order.
Pause for a human
A run can stop to ask you a structured question — a choice, a yes or no, free text, or a request to connect a credential. You answer, and the run continues. This is called human-in-the-loop.
What the events look like
What the events look like
Each event arrives as a small JSON object with a
type field that tells you what it is. A run typically streams a metadata event, then a node_update event per step, and finishes with a done event. If a step needs your input, you get an interrupt (workflows) or a user_input_request (the AI Composer and Assistant), the stream stays open, and you respond to continue.A heartbeat event arrives periodically during quiet stretches — for example while a run is paused waiting on you — so the connection stays open. You can ignore heartbeats; they carry no run data. For the full event taxonomy, see the realtime overview.Pause, resume, and cancel
Pause, resume, and cancel
When a run pauses for your input, it does not lose its place — its state is checkpointed. You answer the question and the run resumes from exactly where it stopped. Answering a pause never charges you a second time; a run is charged once.You can also cancel a running or paused run. Cancellation is graceful: the current step finishes, then the run stops. For the precise pause-and-resume contract, see human-in-the-loop resume.
Run progress (SSE) and canvas collaboration (which keeps several editors in sync) are two separate realtime systems that travel over different channels. The realtime and collaboration model keeps them straight — and notes which sync paths are live versus retired.
Run a workflow from code
The same loop works programmatically. You authenticate, start a run, then open the stream and read events until a terminal one. Every request carries two headers: your API key as a bearer token, and the organization the request runs in.Wire fields stay snake_case (
run_id, thread_id). The SDKs accept camelCase in your code and convert it for you on the request. For the full run-from-code walkthrough, see Run a workflow (REST + SDK); for authentication, see Authentication.The shortcut: the Assistant
Not every task is worth building a workflow for. The Assistant is an agentic chat that authors, runs, and observes in a single conversation: you state a goal, it decides which connected tools to call, it calls them step by step, and you watch the same kind of live stream. It pauses for your approval before sensitive actions, just like a run can.AI Composer
Use the AI Composer when you want a reusable workflow you can run again and again. It produces a graph you own and can edit.
Assistant
Use the Assistant for one-off or open-ended tasks. It acts directly with your tools — no workflow to set up first.
Where everything lives
The whole loop happens inside an organization — the shared workspace and billing boundary. Your workflows, credentials, knowledge bases, plan, and credits all belong to one organization, and every run is metered against it. Each member has a role; the live roles are owner and admin, and actions such as using the AI Composer, the Assistant, and schedules require one of them.Organizations, roles & membership
How tenancy works: the organization context, membership, and what owners and admins can do.
Credits & the billing model
How managed usage is metered in credits, and where the admission check applies.
Keep going
Workflows & runs
A closer look at what a workflow is, what a run is, and the run identities you will meet.
Realtime & collaboration model
How runs stream over SSE and how the canvas stays in sync across collaborators.
Quickstart
Create an organization, get an API key, and make your first authenticated call.