Best use
Full product orientationRead this once before your first real mission and revisit it when a later feature feels disconnected.
Start Here
How opheli.ai works
This is the core product manual page. Read it when you want the full operational picture of how opheli.ai turns an objective into reviewed work and a durable artifact.
Guide summary
Use this page to understand the surface before you act inside it.
A complete workflow guide from Mission Control and Provider access through Runs, Artifacts, Replay, Orb, Copilot, and support.
Guide type
Start HereThis guide reflects the current product workflow and surface ownership.
Sections
13Summary first, then steps, mistakes, and recovery notes.
Related guides
6Written against the current product structure and core execution workflow.
Workflow spine
Provider -> Operators -> Context -> Mission -> Task -> Run -> ArtifactEverything else in the product supports this execution chain.
Related action
Launch MissionOnce this flow makes sense, Launch Mission is the fastest way to start.
Guide section
A. Start with Launch Sequence and Mission Control
New users usually arrive through Launch Sequence and then settle into Mission Control. Launch Sequence is the guided first-run path; Mission Control is the always-on command surface after setup.
Mission Control should become your reference point for active work, recent execution, next actions, approvals, and artifacts that just landed.
What it is
Launch Sequence teaches the product through a real first execution path. Mission Control becomes the operating dashboard afterwards.
When to use it
Use Launch Sequence during first-run setup. Use Mission Control every day to monitor and steer work.
Where to find it
Launch Sequence appears after sign-in for new users. Mission Control is the dashboard route and the anchor behind Mission Orb.
What happens next
You choose provider posture, create a starter team, and move into launch-ready work.
Common mistake
Skipping the guided setup, then trying to infer the product model only from navigation labels.
Related action
Open Launch Mission when Mission Control tells you the setup is ready.
Guide section
B. Configure provider access
Provider Vault controls whether execution runs through a real provider or stays in Mock Mode. BYOK means you connect your own provider credentials and the provider bills model usage separately from your opheli.ai subscription.
If no real provider is connected, Mock Mode remains the safe low-friction way to understand product flow without external API cost.
What it is
The provider access and default-model layer.
When to use it
Before any real execution and anytime provider credentials or model posture change.
Where to find it
Provider Vault from the authenticated product.
What happens next
Connected providers become available to operators and runs.
Common mistake
Assuming opheli.ai pays your model bill or that your API key will be visible again after save.
Related action
Open Provider Vault and confirm your default model before launching real work.
Warning
Credential safety
Provider keys are encrypted and not shown again after save. Store the original credential securely before you submit it.
Guide section
C. Configure operators
Operators are specialist roles such as coordinator, researcher, analyst, reviewer, writer, or coder. They are not just custom chatbots. They define how work is split and how the runtime approaches different phases.
A good starter team is usually coordinator, researcher, reviewer, and writer. Add more only when the work genuinely benefits from a distinct lane.
What it is
The role and instruction layer for execution.
When to use it
Before launching a mission and whenever your workflow needs different specialties.
Where to find it
Operators in the authenticated product.
What happens next
Tasks and runs can use those operators for planning, execution, review, and final packaging.
Common mistake
Adding too many operators too early or skipping the reviewer role.
Related action
Create a starter team, then review system prompts and provider/model alignment.
Guide section
D. Add context
Context Vault stores notes and approved source material. Attach context to a mission or task when the work should be grounded in real references rather than generic model reasoning.
Context is selected into runs deliberately and within bounded limits. More context is not automatically better. Relevant context wins over volume.
What it is
The source-material layer.
When to use it
When the run needs customer notes, competitor references, technical constraints, briefs, or uploaded documents.
Where to find it
Context Vault plus mission/task context attachments.
What happens next
Attached context becomes available to the runtime when the run is built.
Common mistake
Uploading too much unrelated material or assuming visible context is automatically attached.
Related action
Add the most relevant context, then verify the mission or task actually references it.
Guide section
E. Launch a mission
Launch Mission and Mission Builder help you frame the objective, output type, operators, context posture, and execution plan before the system creates a mission or starts a run.
This is the moment to turn a rough idea into something explicit enough for real execution.
What it is
The guided mission creation surface.
When to use it
When you are ready to move from setup into real work.
Where to find it
Launch Mission from Mission Control or navigation.
What happens next
Mission Builder can create the mission, prepare tasks, and launch execution.
Common mistake
Launching with a vague objective or the wrong output shape.
Related action
Open Launch Mission and review the plan before you confirm.
Guide section
F. Understand tasks
A mission is the objective. A task is the executable work unit inside that objective. Not every mission needs many tasks, but multi-lane work usually benefits from splitting research, analysis, review, and packaging.
What it is
The execution-ready unit of work.
When to use it
When a mission needs multiple lanes, assignments, or phases of delivery.
Where to find it
Tasks under their own index and linked from missions.
What happens next
Tasks become the source of runs and can hold operator assignment and priority.
Common mistake
Creating one giant task for work that should be separated into reviewable lanes.
Related action
Review your task list before launching runs at scale.
Guide section
G. Run execution
A run is the actual execution record. It moves through planning, specialist execution, review, and final artifact packaging. Steps are persisted so the runtime can resume or retry rather than losing the whole effort.
Runs may be queued or continue in the background depending on the runtime and provider posture.
What it is
The durable execution record.
When to use it
Every time work should move through the runtime and become an artifact.
Where to find it
Runs and the run detail page.
What happens next
The run either completes, waits for approval, or needs continue/retry intervention.
Common mistake
Reading status alone and ignoring Replay, review messages, or failed-step detail.
Related action
Open the run detail page and use Continue Run or Retry Failed Step when the UI makes that option available.
- Planning turns the objective into an execution frame.
- Specialist execution advances the main claims, research, or draft work.
- Review challenges weak evidence, risk, readiness, or unsupported claims.
- Final artifact packages the usable deliverable.
Guide section
H. Review the artifact
Artifacts are the final deliverables. They are not the same thing as operator messages. Messages show the execution conversation; the artifact is the finished output intended for use or handoff.
Use the artifact page to review the final result, its summary, linked execution context, and any improvement flow exposed by the UI.
What it is
The final output layer.
When to use it
When the run has completed or when you need the deliverable instead of the execution conversation.
Where to find it
Artifacts and linked run surfaces.
What happens next
You can copy, review, improve, or route the deliverable into its real workflow outside the product.
Common mistake
Treating run messages as the final deliverable.
Related action
Open the Artifact page after the run finishes and review the formation summary as well as the output itself.
Guide section
I. Review Mission Replay
Mission Replay is the proof-of-work layer. It tells you what happened during execution, which events mattered, where risks or challenges appeared, and how the final output formed.
What it is
The execution narrative and evidence trail.
When to use it
When you need to trust, investigate, explain, or improve the result.
Where to find it
From the run detail page.
What happens next
Replay informs whether to continue, retry, revise, approve, or extract reusable patterns.
Common mistake
Using only the final artifact when the decision really needs proof of how the result formed.
Related action
Open Mission Replay before shipping important output or after any failed run.
Guide section
J. Use Mission Orb
Mission Orb is the persistent action layer. Navigation tells you where you are; Mission Orb tells you what matters now, what needs action, and which shortcut will move you forward fastest.
What it is
The always-available attention and action layer.
When to use it
Whenever it surfaces a next-best action, warning, approval need, or quick path.
Where to find it
Across authenticated product surfaces.
What happens next
You can jump directly into approvals, support, guidance, or the next operational move.
Common mistake
Ignoring warnings and navigating manually when Mission Orb is already pointing at the blocker.
Related action
Use Mission Orb when it has an attention or approval state before opening unrelated screens.
Guide section
K. Use Mission Copilot
Mission Copilot is the command layer for asking questions, promoting ideas into missions, explaining runs, and improving artifacts. It can propose actions, but risky actions still require confirmation.
What it is
The conversational command surface.
When to use it
When you need explanation, setup help, or guided action suggestions.
Where to find it
Mission Copilot from the authenticated product and contextual surfaces.
What happens next
Copilot can generate action cards, explain current posture, or help create the next work item.
Common mistake
Treating Copilot as final expert advice instead of a product guide and action assistant.
Related action
Ask Copilot to explain a run before escalating to support when the issue may just be workflow confusion.
Guide section
L. Reuse with Blueprints and Mission DNA
Official Blueprints provide curated starting patterns. Mission DNA turns successful private work into reusable user-owned patterns. Blueprint Packs bundle compatible official patterns for faster onboarding into repeated work types.
What it is
The reuse and scaling layer.
When to use it
When you do similar work repeatedly or want a guided pattern instead of a blank start.
Where to find it
Blueprint Library, Launch Mission, and Mission DNA surfaces.
What happens next
Mission Builder can start from the Blueprint with context requirements, operator roles, and quality rules prefilled.
Common mistake
Assuming private Mission DNA becomes public or that uploaded source material is copied into reusable patterns by default.
Related action
Open Blueprints after your first successful mission to see whether a reusable pattern would save setup time.
Guide section
M. Get help
Use Help Center when you need product guidance. Use Contact Support when something seems broken, blocked, or unsafe and the workflow guide, Replay, or Copilot are no longer enough.
What it is
The recovery and escalation layer.
When to use it
When provider access fails, runs get stuck, artifacts do not appear, or the workflow remains unclear.
Where to find it
Help Center, Contact Support, Mission Orb, and contextual “Report this Run” paths.
What happens next
Support receives safe page and related-object context without provider keys or hidden prompts.
Common mistake
Pasting secrets or expecting support to infer the relevant run without a linked object.
Related action
Open Contact Support from the run, mission, task, or artifact that is actually affected.
Tip
Escalate with context
A support request linked to the right run or artifact is faster to investigate than a generic “something broke” message.