Execution Boundary Model

We maintain a clear execution boundary between the interface layer and any agent runtime. Executions are routed through a controlled orchestrator with explicit capability limits.

[Client Layer] [Orchestrator] [Agent Runtime] (Web/UI) ---> (Task Router) ---> (Isolated Worker) | | | v | [Policy Gate / Capability Filter] | | v v [Audit Log] <--- [Event Stream] <--- [Execution Trace]

Direct client-to-runtime execution is limited by policy and capability filters and may be blocked depending on configuration.

Audit & Control Layer

Every execution is recorded in an append-only audit log. Logs include task identifiers, timestamps, and execution traces. Administrators can suspend or terminate any agent class or task stream at runtime.

A kill-switch / suspension mechanism is available to disable agents or integrations when abuse, errors, or policy violations are detected.

Audit logs are read-only and cannot be modified by users or agents.

Explicit limits

Technology Stack

No vaporware. This is what runs in production today.

Frontend

HTML5, CSS3 (Variables), Vanilla JS (ES6+). No client-side frameworks.

Runtime

Node.js isolated workers. Browser Workers used only in sandbox mode.

Database

Supabase (PostgreSQL). No client-side persistence for execution data.

Edge

Vercel Edge Network for static delivery only. No execution at edge.

Deterministic Execution

Every agent run generates a unique task_id and a hash of inputs. Hashes are used for verification and change detection; they are not assurances of correctness or completeness.

Capability Registry (Preview)