Local operator platform
Engine and operator console run locally, daemons are started by the customer, and approval gates remain close to the operator.
Architecture
Designed for operator oversight and realistic enterprise boundaries
Agent Control combines a local or customer-managed control plane with SaaS-friendly intake and brokering patterns so governance and deployment can evolve without rewriting the product story.
Connectivity Model
Pull, not inbound dependence
The core design choice is that customer-side execution pulls work instead of requiring the vendor to reach into a customer network. This makes the architecture easier to position with security and infrastructure stakeholders.
- Onboarding publishes work intent, but does not dispatch execution directly.
- The queue stores intents and status events as the shared broker.
- The chosen control plane pulls jobs, dispatches to approved daemons, and returns signed progress updates.
Deployment Models
Choose the operating posture that fits the customer
Customer-managed control plane
Execution remains inside a customer-managed environment while SaaS onboarding and queue services can stay outside.
Vendor-operated onboarding and queue
Business intake, enrollment, and visibility can be offered as vendor-hosted services without claiming the same model for execution.
Governance Controls
Operator protections
- Human approval before sensitive writes, shell actions, and MCP operations.
- Path boundaries enforced per daemon workspace.
- Execution history and approvals visible through operator-facing surfaces.
- Canvas output reviewed before it becomes accepted content.
Architecture Invariants
Design positions that matter in RFP review
- The engine does not spawn daemons.
- Onboarding and queue are separated from execution authority.
- Queue and onboarding do not act as hidden execution layers.
- Security controls are part of the runtime story, not a slide-only promise.
Website Deployment
This landing site is intentionally separate from the control-plane Vercel deploy
The current root Vercel configuration is for the control plane and its Python runtime. This website is static by design so it can be deployed from its own folder as a separate Vercel project with no dependency on the control-plane includeFiles, API entrypoint, or build command.