Use it for prompts, personas, threads, contexts, and generated artifacts.

Generated output should not become canonical truth.

Keep generation logic away from direct business writes.

Make AI context visible and auditable.

Keep generated artifacts assistive rather than authoritative.

Check the orchestration paths first.

Keep output traceable to its origin.

Protect domain authority from silent writes.

Confirm the output remains typed and reviewable.

Assistant

Assistant is the AI orchestration layer for personas, prompts, threads, and generated output inside Molino.

This feature exists so users can:

• generate or refine structured content
• interact with assistant workflows
• capture guided AI output for follow-up actions

Inside Molino App, this feature exists to:

• keep AI context explicit and auditable
• separate prompt orchestration from domain truth
• support generation flows without turning AI into the source of truth

• routes and APIs: app/api/ai/*, app/api/devprompts/route.ts, app/ideas/api/generate/route.ts
• models: AssistantThread, AssistantMessage, AssistantFile, DevPromptThread, DevPromptMessage, DevPrompt, AIContext, AIPersona, GeneratedFile
• helper surfaces for prompt, persona, and generation flows

• making AI output authoritative over canonical records
• embedding business truth inside prompts

app/ideas/api/generate/route.ts calls generateIdeaAction(), which builds a prompt from optional context, field, and user request. IdeaService.generateIdea() creates an Idea record before the model call, calls OpenAI, then saves the response back to the same Idea record.

This is traceable assistant output. It should remain a suggestion layer and must not silently mutate the referenced entity, entityId, or field.

app/assistant/lib/openai.ts owns the OpenAI client and two execution helpers:

• runLLM() uses the Responses API and returns { output }.
• runStructured() uses structured parsing, then falls back to runLLM() if parsing fails.

MODE_REGISTRY currently combines UI metadata, capability policy, visibility, execution style, and confirmation requirements. It is valuable, but it is doing multiple jobs. Any future catalog split should preserve the current registry behavior before moving lifecycle metadata elsewhere.

planTripWithAssistant() uses structured output and explicitly forbids creating bookings, offers, orders, or documents. This is the correct pattern for assistant-to-domain boundaries: return intent first, then let domain actions decide what can be written.

• getOpenAI() centralizes OpenAI client creation and fails fast when OPENAI_API_KEY is missing.
• runLLM() and runStructured() centralize Responses API and structured-output calls.
• IdeaService.generateIdea() stores the prompt and generated response in Idea records without mutating the referenced domain entity.
• MODE_REGISTRY records capabilities, visibility, execution style, and confirmation requirements per mode.

• Assistant threads can be created and listed through app/api/assistant/threads/route.ts for the logged-in user.
• generateIdeaAction() builds a clean text prompt from context, field, and user request.
• runStructuredMode() enforces structured-mode execution by checking the mode policy.

• Assistant route docs should include app/api/assistant/threads/route.ts as an active thread surface.
• Mode catalog separation is discussed in code comments but not yet implemented as a completed architecture split.
• Idea generation still uses chat completions directly instead of the shared runLLM() wrapper, so OpenAI execution is not fully unified.

Keep Assistant behind commercial work. When touched, unify idea generation through the shared OpenAI wrapper and keep every generated result as an auditable suggestion, not a domain mutation.