Recommended flows
When to use typed reads, read-only consultation, and write-capable operator conversations.
Use typed read tools for deterministic retrieval, consult_operator for read-only model reasoning, and ask_operator with a unique idempotencyKey for work that can change state. Pass chatId to continue a conversation and activeModuleId when a request targets a specific module.
Create a module
One explicit creation prompt creates the module end to end. The operator plans internally and starts the builder without presenting a separate outline or waiting for a later confirmation turn. Asking for a "course" produces the same thing — the operator works one module at a time, and the module lands in your library for you to add to a course.
"Create a module about our refund policy for new support agents."
Ask for a plan without creating
Ask for a plan, outline, or structure without asking the operator to create or build. It presents the result in chat and stops; no module or build is created. If you later want the module, continue the same conversation with an explicit creation request.
"Draft an outline for GDPR training — show it to me before building."
Ground a module in documents
Upload or connect sources in the Vidext app first, then reference those existing sources in the prompt. The remote MCP server does not accept file bytes; the Operator can search knowledge already available to the organization and ground the build on it.
"Build an onboarding module from the three support-policy sources already in our workspace."
Work with existing content
Refer to existing work by name — the operator resolves it (pass activeModuleId if you already have the id).
"In the GDPR module, make question 2 about data retention and tighten chapter one's narration."
How results arrive
A turn that starts async planning/build work returns a run envelope whose nextAction names get_operation, supplies {moduleId, operationId}, and specifies pollAfterMs. Wait, call it, and follow each returned nextAction until none remains. terminal describes the current planning or build operation; a terminal planner can still return the builder as its next action. A plan-only chat response has no module build to poll.
Correlation IDs — keep them
Every operator turn returns a run envelope. It carries chatId, requestId/traceId/agentRequestId, mutationLevel, modelId, and the normalized ids it lifted from the turn. Store them:
| ID | Use it to |
|---|---|
chatId | Continue the conversation — pass it back to ask_operator to keep building/editing in the same thread |
moduleId / createdModuleId | Focus the next turn on a specific module (pass as activeModuleId); identify it for support |
courseId | Identify the course container for support |
plannerRunId | Identify a planning run for support |
builderRunId | Identify a build run for support |
Follow-up work is typed: use get_operation exactly as directed by nextAction. The run/trace ids exist for correlation: Vidext's own observability is keyed on them, so a support request that names builderRunId X gets answered fast.
Last updated on