Skip to content

Docs

Enterprise

Ops notebooks

An ops notebook is a saved, re-runnable sequence of governed operations — a literate runbook. Each cell names a tool (search memory, query a database, read Kubernetes, run a command…) plus its inputs. Running a cell goes through the same allowlist, guardrails, RBAC and recording as the assistant — the notebook itself holds no capability.

Building a notebook

  • New notebook, then Runs as — pick an agent access. Cells inherit that access's scope, target allowlist and guardrails. Read-only tools (search memory, audit) work even with no access bound.
  • Add cell, choose a tool, and fill its fields (e.g. a server_id for host metrics, or target_id + sql for a query).
  • Run a cell to execute just that step; its result is saved on the cell. You can edit a field and re-run — the run uses what's currently in the field.
Notebooks are read-only / investigative by design — the mutating rollout tools are not offered in a cell. A cell can never exceed the scope of the access it's bound to: a tool the access doesn't grant is refused.

Starting from a template

Don't start from a blank page. From template opens a picker with ready-made runbooks you clone into your own editable notebook (then bind an access and fill in the targets):

  • Incident triage — recall prior occurrences, scan recent activity, check cluster events.
  • Database health check, Crashloop sweep, Server audit, Security quick-look.

Saving your own template

Turned a notebook into a repeatable procedure? Save as template (name + description) makes it a reusable starting point for everyone in your workspace — it appears in the picker under Your template, and you can delete it there. Templates store no agent access or results; each use clones a fresh, editable notebook.

Permissions

activity.read

Notebooks need activity.read; the page is hidden until an administrator enables ops notebooks. What a cell can actually do is governed entirely by the agent access it's bound to — see Agent access (MCP).