These docs are an early preview — some sections are still being expanded.
Vidext Docs

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:

IDUse it to
chatIdContinue the conversation — pass it back to ask_operator to keep building/editing in the same thread
moduleId / createdModuleIdFocus the next turn on a specific module (pass as activeModuleId); identify it for support
courseIdIdentify the course container for support
plannerRunIdIdentify a planning run for support
builderRunIdIdentify 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

On this page