Read-Only Agents

Read-only mode constrains an agent to inspection commands only — it can describe state, read logs, query APIs, but it cannot change anything. Useful when you want a recommendation, not a remediation.

​

Two ways to enable it

Use the specialty ceiling for large fleets of investigative agents — for example, 1000 Oracle DB agents that should default to read-only. You can selectively flip individual specialties to remediation later.

​

How it works

The agent knows it’s in read-only mode and tries to comply. But it can still emit a command that would alter state. That’s where the secondary engine — the LLM-as-judge — steps in: it reviews every command before execution. If the command would alter the system in read-only mode, the secondary engine blocks it. Two independent layers of read-only protection:

1. The main engine is told it’s in read-only mode (prompt-level).
2. The secondary engine enforces read-only at every command (runtime check).

​

Partial resolution

When a ticket asks for remediation but a specialty ceiling forced read-only, the job ends as partial rather than failed. The ticket gets a public comment explaining what the agent found and why it didn’t act, so a human can pick up cleanly. See the escalation policy for how partials route in your ITSM.

​

Patterns

​

Plan-then-apply

Tag the first task @2501:investigate and ask for a plan. Read the plan, tweak the rules or prompt if needed, then re-run as a remediation task.

​

Critical fleet, safe by default

Pin all critical-system specialties to investigate-only. Operators can read every diagnostic the agent produces. When you want a specific repair, drop the investigate ceiling for one specialty or one ticket.

​

Audit-mode rollout

When introducing a new specialty or operational rule for the first time, always start in investigate-only. Watch the agent’s plans for a week. Lift the ceiling only after the plans look right consistently.