Architecture & state
Separating plans, actions and evidence.
Chat is not the system’s memory
Canonical state includes the goal, success criteria, step, observation, allowed options, ownership, approval and deployment identity. The SQLite-backed State Store is designed to keep this state typed and persistent. Model calls receive only necessary, bounded context.
One loop, two logical roles
Operator owns the loop. Supervisor produces plans and diagnoses; it does not access tools directly. Initially there is one active task, one active action and one computer-input owner. Model services support these roles; they are not independent desktop users.
An action is a contract
The action envelope carries task, step, state version, runtime, ownership, tool, arguments, expected effect, verification and idempotency identity. Executor rechecks freshness and permission at execution. An action with an unknown result after interruption is reconciled through observation instead of blindly replayed.