- 00
Complete topology. The local runtime: owner controls, agent connections, the shared record and managed execution. The two main databases hold knowledge and operations respectively; journals are not a separate shutdown-seal service. Internal helpers are grouped here. A published successor-storage configuration can additionally attach a separate kernel store and truth journal; those conditional stores are not shown as the default topology.
- 01
Connect an agent. Connect an agent: with a workspace and profile configured, run sophia agent connect. The CLI asks the owner API for a scoped, expiring bearer. If workspace approval is missing, it raises a durable request and asks you to approve, then rerun connect. On success it writes an owner-only MCP config in the checkout. A new harness session reads that config and connects over HTTP. No lease, seat, private launch overlay or managed process is created. The connection survives daemon restarts until it expires or is revoked.
- 02
Managed launch. Managed launch: the Panel invokes the CLI and owner API. The workspace must have agent access approved; the daemon records managed launch state, prepares a private overlay with the provider login, and creates the launch credential relay. A systemd transient unit runs the managed host and harness. The harness’s Sophia wrapper obtains its credential from the relay and proxies HTTP MCP calls. Credential publication starts managed session capture. This is a separate path from connecting an existing harness.
- 03
Agent does work. Agent does work: HTTP MCP authenticates the bearer and exposes the tools permitted by its profile, surface, allowlist and runtime settings. New unspecified profiles default to the 33-tool standard surface; existing or explicit broader profiles can differ. Managed bearers also validate current lease and workspace policy. Tools use their owning stores. Call auditing and eligible work receipts record available identity and result digests, but deferred or failed receipt persistence must not be mistaken for a durable receipt on every response.
- 04
Workspace approval. Workspace approval: the Panel polls pending grant requests through the CLI. You approve or deny workspace agent access; the CLI sends that decision to the owner API and it is recorded in the operations database. The request survives a tray or daemon restart. With no tray, the CLI can answer the same queue. There is no signed provider proof or new approval ceremony for every launch. Tool-specific write approval remains a separate profile setting.
- 05
Your terminal. Your terminal: for a managed launch, the harness writes to its PTY and the relay carries bytes over a Unix socket. Your emulator runs the attach client with an expiring one-shot attachment token. Closing the terminal need not stop the harness; a new token can reattach to the live session. There is one active attachment and a bounded backlog that may truncate. Managed units are bound to the daemon service, so daemon shutdown is different from closing the terminal.
- 06
Boot & backups. Boot and backups: systemd runs the daemon. Existing data requires the existing encryption key. After an unclean shutdown, the knowledge database’s SQLite quick_check runs during boot; a valid clean-shutdown marker moves that check after readiness. Journal-chain verification is scheduled after readiness when needed. Interrupted managed captures are reconciled, and scheduled backups use the daemon’s own database handles to copy the data and encrypt the accompanying archives. Restoring a backup is an explicit offline CLI operation, not automatic rollback on a key error. The old shutdown seals and recovery coordinator are gone.
- 07
Agent to agent. Agent to agent: coordination tools write posts, waits and shared work records to the knowledge database. Agents poll or reread their inbox. Supporting MCP clients can subscribe to resource-update hints, then fetch the content through their own visibility rules. Those hints are best-effort pointers, not message payloads or a guarantee that an idle harness will wake up.
- 08
Evidence → action. Evidence to action: the implemented evidence-envelope path prepares and submits a supported coordination set_activity action. Preparation binds evidence, authority and delivered context; submission records admission or refusal. Admitted work passes through an outbox and terminal-result verification. These tools require a surface that exposes them, not the default standard surface. This is a specific implemented action path, not a universal gate around everything an agent does.
- 09
Who did what. Who did what: the web console reads connection, managed-session and audit records from operations, and claims, evidence and mutation history from knowledge. These records preserve the identity and provenance available to each path. Ordinary connected agents do not acquire managed leases, and an audit view is not proof that every external action or every deferred receipt was captured.
- 10
The record disagrees. The record disagrees: agents and mining add structured claims and evidence. Conflicting claims about the same subject and predicate can be surfaced for review. Explicit corrections link a replacement to the prior claim; archiving is a separate operation. This is structured conflict detection and correction lineage, not a promise to detect every semantic disagreement or prohibit all deletion.
- 11
Update Sophia. Update Sophia: the Panel runs the same sophia update command you can use in a terminal. The CLI verifies the signed package, stops the daemon through systemd, calls the existing privileged helper once through pkexec to verify, cache and install with dpkg, then refreshes and starts the user service and checks readiness. Five steps are recorded in a CLI state file; failures can use a cached previous package for rollback. There is no daemon upgrade-admission protocol or independent lifecycle coordinator.