Viewport daemon, relay, and hosted runtime are available in alpha. Surfaces may change.
VIEWPORT
Concepts

Concepts

The durable concepts behind Viewport: automations, runners, context, approvals, actions, and receipts.

Viewport is built around one customer object: the automation.

Everything else exists to make that automation safe to run, easy to review, and possible to audit.

Core Concepts

ConceptOne line
Automations, routes, and policiesThe customer-facing unit: trigger/route, repo/context/gate policy, worker, and run proof.
InboxWhere humans approve plans, implementation gates, provider actions, and context updates.
Team ContextContext Sources and Update Targets agents may read or propose changes to.
Trust and privacyWhat stays at the customer edge, what Viewport stores, and how credentials are separated.
Organizations and teamsTenant boundary, team ownership, role/tag routing, and access scope.
Machines and pairingHow runners/daemons pair, advertise capability, and claim work.

Legacy concepts still exist in the engine and references:

  • Sessions are live agent runtime streams owned by the daemon.
  • Plans are reviewable artifacts produced by workflow nodes.
  • Workflow YAML is the portable/advanced compiled representation.

The product surface should start from Automations, not raw routes, recipes, or YAML. Routes and Policies are tabs inside Automations.

How They Fit Together

Automation
  route
    trigger
    owner team
  policy
    repos
    context sources + update targets
    approvals
    actions
    runner
      |
      v
Run preparation
  prepared repos
  prepared context refs
  prepared update targets
  credential bindings
      |
      v
Runner execution
  node context
  artifacts
  approvals
  provider actions
      |
      v
Receipts + audit packet

Automation policy says what is allowed. Run preparation makes only those allowed things available. Node policy decides what each step can see or do. Receipts prove what actually happened.

On this page