Choose an approach
Agent integration should be gradual. Installing a client adapter should not silently move a project from “the agent can read docs” to “the agent can provision infrastructure.”
The four levels
| Level | Agent can do | Human control | Security meaning |
|---|---|---|---|
| Human-only | Nothing through vops; the human uses CLI and dashboard. | Every operation is human-driven. | Baseline. |
| Knowledge-assisted | Read vops concepts, workflows, schemas and public capabilities. | Human still runs every infrastructure command. | No infrastructure session. |
| Governed advisory | Use scoped semantic tools through a short-lived session; propose plans and request approval. | Targets, limits and approvals are enforced inside vops. | Guarded vops path, but an unrestricted OS shell may bypass it. |
| Protected | Same governed path from an isolated agent process with no credential, SSH or administrative-CLI access. | vops is the only infrastructure path. | Enforced isolation, when the launcher exists. |
Protected mode is not currently shipped. It is a design target, not a checkbox in client setup.
Recommended progression
1. Start knowledge-assisted
Install the project-scoped skill and bootstrap, but do not create an infrastructure session. Let the agent:
- identify the correct vops workflow;
- inspect the repository;
- generate or validate
flui.yaml; - explain which human commands would come next.
The human runs and approves the operational commands.
2. Add read-only governed access
Create a short session for one repository and known targets. Use it for private inventory, status and diagnostics before enabling mutations.
This proves client configuration, MCP transport, session expiry and audit without spending money or changing a server.
3. Add planned mutations
Allow semantic mutations that support an immutable plan. Keep:
- a short expiry;
- one environment;
- explicit targets;
- a low operation count;
- zero provider spend unless provisioning is the actual objective.
The agent may propose. The human approves.
4. Expand only from evidence
Increase limits for a repeated workflow after inspecting its plans, failures and audit history. Do not grant a broad standing session because one deployment worked.
Choose by task, not client
| Task | Sensible starting level |
|---|---|
| Explain vops or prepare a manifest | Knowledge-assisted |
| Diagnose a known staging host | Governed advisory, read-focused |
| Deploy to staging | Governed advisory with plan approval |
| Provision a billable server | Governed advisory with target and spend limit |
| Make production changes unattended | Not recommended in advisory mode |
| Operate from a cloud-hosted agent | Outside the local-only MVP unless the user supplies a deliberate bridge |
Codex, Claude Code, OpenCode and Antigravity all use adapters over the same control model. Changing client does not upgrade advisory isolation into protected isolation.
A session is task authority
Create a new session for a new objective. Reusing a broad session across unrelated repositories or environments defeats the value of its audit and policy scope.
When the task ends, revoke it even if its expiry is near.