Observability & audit
Autonomous agents doing real work need to be observable: how fast they run, what they cost, which tools they call, and — when something looks wrong — exactly what happened, step by step. EnClaw gives you three layers: live monitoring at /monitoring, telemetry export to your observability stack at /observability, and the forensic layer — the audit log at /audit and the session transcript viewer at /sessions.
Monitoring UI
/monitoring is the real-time dashboard for agent execution across the tenant. Per agent and in aggregate, it tracks:
- Latency — how long executions take end-to-end, with histograms rather than just averages, so a p95 blowout doesn't hide behind a healthy mean.
- Token usage — consumption per agent and per session. This is your early-warning signal for cost: a runaway agent shows up here long before the provider invoice does. Pair it with per-agent token budgets.
- Tool calls — which tools agents actually invoke, how often, and how often they fail.
- Throughput and error rates — execution volume over time and the proportion ending in errors.
Practical habits: after rolling out a new agent, watch its first week here — steady latency and a sensible tool-call mix are the signs of a well-scoped identity; high error rates on one tool usually mean a misconfigured integration or a permission rule the agent keeps colliding with (see Permissions & approvals).
The runtime status view at /agent-runtime complements this with the current state of the execution engine — active sessions and queued work — useful when you're wondering whether the platform is busy or stuck.
Exporting telemetry — OpenTelemetry and friends
Most organisations already have an observability stack, and EnClaw is built to feed it rather than replace it. Configure exporters at /observability:
| Exporter | What it sends |
|---|---|
| OpenTelemetry (OTLP) | Generic OTel export — metrics and traces to any OTLP-compatible collector. Use this if your stack isn't one of the named ones below. |
| Grafana Cloud | Metrics and traces direct to Grafana Cloud. |
| Datadog | APM integration — agent executions appear alongside your other services. |
| Splunk | Log forwarding into your existing Splunk indexes. |
Because export is standard OpenTelemetry underneath, agent activity can sit in the same dashboards and alerting rules as the rest of your estate — an alert on agent error rate can page the same on-call rotation as everything else.
The audit log
/audit is the tenant-wide, append-only record of who did what. It captures:
- Administrative changes — create/update/delete across agents, users, teams, integrations, permission rules, approval workflows, retention policies and the rest of the admin surface.
- Execution events — agent runs and the tool executions within them.
- Approval decisions — who was asked, who approved or denied, when, and any comment (see Permissions & approvals).
- Secret access — reads and changes in the secrets vault.
- File access — uploads, downloads, deletions and share-link use in File space.
Each entry records the actor, the action, the affected resource and a timestamp. The viewer supports filtering, so "every permission-rule change this quarter" or "everything agent X executed last Tuesday" is a query, not an archaeology project. The security_admin and compliance_officer roles both exist largely to give the right people read access to this surface without broader admin rights.
Session transcripts
/sessions is the transcript viewer: every agent session is recorded in full — the conversation, the agent's tool calls with their inputs and results, and the final outcome. When a user reports "the agent did something odd on Friday", the transcript is where you find out precisely what it saw, what it called, and why the result came back the way it did.
What admins see vs user session isolation
Two rules coexist here, and it's worth being clear with your organisation about both:
- Users are isolated from each other. A regular user sees only their own sessions. One user can never browse a colleague's conversation history, and agents keep per-user context separated — user A's chats don't surface in user B's.
- Admins can review transcripts for governance. Users with the appropriate admin roles can open session transcripts across the tenant through /sessions — that's the point of a governed platform: conversations with org agents are auditable working records, not private correspondence. Admin access to transcripts is itself an audited action.
The isolation rule protects users from each other; the admin rule supports oversight, incident review and compliance. Tell your users plainly that agent sessions on org agents are visible to administrators — it sets expectations and keeps genuinely personal matters out of work agents.
Next
- Permissions & approvals — the decisions the audit log records.
- Troubleshooting — when the metrics tell you something's wrong.