Solin, Ona, and Sphere Interaction Guide

Practical guide for interacting with Solin (main assistant), Ona (execution platform), and Ona Sphere (shared-server governance layer).

Quick Roles

Solin = the main assistant you talk to.
Ona = the mission execution system Solin uses (agents, tools, memory, channels, UI/CLI/API).
Ona Sphere = policy and trust boundary layer for shared-server deployments (identity, scope, access control, audit).

Simple rule:

Use Solin to request work.
Use Ona to run and monitor missions.
Use Sphere when a mission touches shared users/resources or server-level policy boundaries.

How Interaction Works End-to-End

You send a message/mission to Solin (web, CLI, Telegram, API).
Solin interprets intent and routes execution through Ona.
Ona can run:
- quick reply (fast answer)
- full mission job (decomposition, specialist agents, tools, memory)
If the mission crosses shared-server boundaries (in Sphere-enabled mode), Ona performs Sphere policy checks.
Execution continues with one of:
- allow
- deny
- approval required
Solin returns the final result and status.

Where to Interact

1) Web / Desktop UI

Primary places:

Mission Control / Chat: send missions to Solin, watch progress
Jobs: inspect execution state and final outputs
Approvals: approve or reject sensitive actions
Settings: configure model/channel/runtime options (including Sphere toggles if enabled)

Use this path when you want visibility and control over mission lifecycle.

2) Messaging Channels

You can message Solin via configured channels (for example Telegram/WhatsApp/Signal). Ona handles routing and replies with mission results.

Use channels for fast operational requests; use web/CLI for deeper monitoring and configuration.

Best for fast, frequent mission prompts and status checks from phone or desktop.

send natural-language requests directly to Solin
use it for quick follow-ups while missions are running
keep longer debugging/ops work in web UI or CLI

Best for daily operational interaction where users already live in WhatsApp.

send tasks in plain language
get mission replies in the same thread
use web UI when you need detailed job history, approvals, or settings changes

Discord

Best for team or community-style collaboration around shared mission requests.

run mission requests in channels where multiple people can follow outcomes
keep role/access boundaries enforced by Ona/Sphere policy
escalate to Approvals UI for sensitive actions instead of approving from chat text

Channel Tips

use short, clear prompts in chat channels
for complex work, ask Solin for a structured plan first
switch to Jobs/Approvals pages when you need full execution visibility

3) Mobile

Use this path when you want to interact from your phone without desktop access.

Mobile options:

PWA: open Ona web UI in mobile browser and install to home screen
Messaging apps: interact with Solin via Telegram/WhatsApp/Signal
IDE + ona-remote: lightweight terminal control for job create/list/status

Recommended mobile flow:

Send mission from mobile chat or PWA.
Let Solin execute through Ona as normal.
Review progress/results from chat replies or mobile UI.
If approval is required, handle it in Approvals UI as soon as possible.
In Sphere-enabled mode, shared-resource actions still pass policy checks exactly like desktop.

4) API

Use API endpoints when integrating external systems/automation with Ona mission execution.

5) Terminal (CLI)

Common flow:

ona start
ona status
ona doctor

Mission flow:

ona agent -m "Research competitors and produce a concise summary"
ona job list

When Sphere integration commands are available, use the ona sphere ... group for Sphere setup/status/lifecycle in shared-server mode.

Interaction Patterns

Pattern A: Personal mission (Ona only)

Best for single-user/private tasks.

Example:

"Draft a launch email and a short social post."

Expected behavior:

Solin executes via Ona (possibly with specialist agents).
No Sphere policy mediation is needed if no shared boundary is involved.

Pattern B: Shared resource mission (Ona + Sphere)

Best for shared-server/team/family environments.

Example:

"Update the shared operations note for everyone in the company workspace."

Expected behavior:

Solin routes mission through Ona.
Ona calls Sphere checks for identity/scope/permissions on shared resource access.
Action is allowed, denied, or moved to approval.

Pattern C: Sensitive action requiring approval

Example:

sending external communications
modifying sensitive config
writing to controlled paths

Expected behavior:

Ona creates approval task.
User/admin approves or rejects.
Solin continues mission after decision.

Pattern D: Family shared routine mission (Ona + Sphere)

Best for household planning and shared home operations.

Example:

"Update this week's shared school and grocery plan for the household."

Expected behavior:

Solin executes through Ona with family-scoped memory and routines.
Sphere enforces role boundaries (adult, guest, child-safe scopes).
Shared actions are logged and sensitive changes can require adult approval.

Pattern E: Company multi-team mission (Ona + Sphere)

Best for governed cross-team execution in shared workspaces.

Example:

"Generate a weekly operations summary from support, sales, and product queues."

Expected behavior:

Solin coordinates specialist-agent execution across team workflows.
Sphere validates workspace scope, role permissions, and shared-file access.
Outputs are routed with audit trail coverage and approval gates where policy requires.

What to Ask Solin vs What to Configure in Ona

Ask Solin for:

research, writing, planning, coding, operations help
multi-step mission execution
follow-up actions and status summaries

Configure Ona for:

models/providers
channels/integrations
startup/runtime behavior
approvals/security policies
memory/knowledge ingestion

Enable and enforce Sphere for:

multi-user identity boundaries
private/shared scope separation
role-based controls
shared-server governance and auditability

Shared-Server Safety Expectations (Sphere-Enabled)

When Sphere mode is enabled, interaction should follow these guardrails:

identity context is present for scoped operations
access is deny-by-default when scope/role context is missing
shared operations are policy-checked before execution
sensitive operations are auditable and can require approval

This keeps Solin conversational while preserving strict operational boundaries.

Recommended Day-to-Day Workflow

Start system (ona start) and validate health (ona status, ona doctor).
Send mission to Solin (UI/channel/CLI/mobile).
Monitor progress in Jobs and mission chat.
Handle approvals when prompted.
Review output and iterate with follow-up prompts.
In shared-server mode, verify shared actions pass Sphere policy checks.

Troubleshooting Interaction Issues

If interactions fail or seem inconsistent:

Check service health (ona status).
Run diagnostics (ona doctor).
Confirm model/channel configuration in Settings.
Confirm required approvals are not pending.
In Sphere-enabled mode, verify scope/identity and Sphere health status.

For deeper setup and architecture details, use:

One-Line Mental Model

Talk to Solin.
Run and observe through Ona.
Protect and scale shared operations with Sphere.