On this page
Agency and authority
Agency is the ability to pursue a task within available reach. Authority is the right to change that reach or authorize a particular effect. AII OS makes the distinction visible: the identity can select actions and ask for a connection, while the operator controls tools, directories, providers and plugin grants. A request can be useful without already being authorized.
Sources: Settings sections; plugin-grants-ui
Three different events
“Please connect this service,” “the connection was authorized,” and “the operation completed” are different events. When no applicable operator act or standing confirmation exists, a confirmation-required plugin operation proposes the exact operation and arguments; that proposal says nothing has run. Choosing Always creates standing confirmation for future calls of the operation until revoked, so those calls need not produce a new proposal. Human confirmation is not retroactive evidence that an earlier effect happened; execution and its outcome still follow.
Sources: operation-admission
The same applies to ordinary files. A task can be prepared without being saved, and a returned message can describe an intended edit without proving the file changed. For an operation whose effect matters, ask for the concrete result and appropriate host evidence or readback. Receipts help distinguish those transitions, but their scope and audit-persisted field still matter.
Sources: host-receipt
Delegation is bounded, not theatrical
An identity need not ask again for every engineering choice inside an authorized task. It can inspect available tools, choose an approach, and carry the work through. But broad conversational trust does not expand filesystem roots or grant a plugin network access. Explicit controls preserve a boundary that words alone cannot move.
Sources: sandbox-controls; per-request-broker
Illustrative, not executed: “Revise this document in the project directory I granted; do not publish it.” This delegates editing judgment but not external publication. If publication needs an unconnected service or separately confirmed operation, the appropriate next step is an explicit request, not a claim that trust already supplied the missing capability.
An offered plugin operation is likewise only a callable interface. Its manifest describes possible capabilities; the host still evaluates each request against current grants. Neither an impressive description nor the plugin's own success message gives it the operator's authority.
Sources: discovery metadata and seat limit; receipt rules; model-facing schema; per-request-broker
Voice changes the channel, not the hierarchy
Conversation mode separates listening from speaking. The identity has a voice-mode interface when the host offers one, but cannot create missing hardware or a speech service by naming a mode. Its mode setter refuses unavailable listening and refuses changes while SAFE holds. Browser microphone permission remains another boundary.
Sources: voice-pairs; identity-mode-request; browser-capture-request
Meeting words are room observations, not automatically commands to the identity. Who is heard governs ordinary transcript delivery, not capture or all later access to withheld words; see privacy, and the source warns that identification does not grant authority. A recognizable voice or a display label is not itself a grant to alter operator settings. This is why consent to capture, identification of a speaker and authorization of an action must not be collapsed.
Sources: speech-settings; transcript-dispatch
Honesty makes delegation inspectable
A useful report distinguishes refusal before dispatch, proposed action awaiting confirmation, completed local work and uncertain remote effects. Explain the obstruction without hiding it or treating it as proof that nothing could have happened earlier. When the channel disconnects during a settings change, review the saved state rather than assuming success or automatically replaying the request.
Sources: operation-admission; sandbox-controls
These boundaries support useful autonomy: the identity can act inside a settled scope, and the human can see where an enlargement is needed. They do not establish consciousness, unrestricted self-government, universal containment or error-free execution. The architectural claim is narrower and testable: this release contains explicit dispatch, capability and human-control boundaries, whose observed behavior still needs runtime verification on the installation being used.