Skip to main content
Version: v5.7.0

12.3 Evidence: activity, trust review, transcripts

packs:agentspacks:agent-governance

After this you can: read Felix's activity timeline, run a trust review, follow its working day of recommendations and gated change, and open a transcript.

Before you start — tick each one:

  • Lesson 12.2 — Enrol, own, assign, grant, ceiling (opschain learn 12.2)

In the GUI: Governance → Agents carries each agent's activity and trust review read-only; the project's Agents tab opens Felix's chat and its logs panel; Inbox → Approvals opens the approval context of a change it raised.

Felix is hired and trusted under supervision in prod. This lesson is what the platform records while it works — all of it emitted server-side at the enforcement seam, so no agent code path can omit its own trail — and the two views that turn the record into a decision. The activity and trust-review reads need packs:agent-governance; the events themselves are base.

1. The activity timeline​

Every call Felix makes through its request lane is dispatched in-process under its service account and audited by the server, never by the agent: info:agent:request with the method, path, status and applied tier, or warn:agent:request_refused. The per-agent timeline reads them back, lifecycle verbs included:

opschain admin agent activity felix

Always a machine document: agent_id and an events array, each row with its type, payload and created_at — for example "type": "info:agent:request", "payload": {"applied_tier": "supervised", …}. The same rows are in the estate-wide feed, opschain events --type-search agent, and in Audit history. A departed agent's timeline still answers by member id with "departed": true (lesson 12.5).

2. The working day​

What Felix produces depends on its tier at the target:

  • At advise (its assignment floor, or an advise grant) it files a recommendation: proposed action, arguments, rationale, evidence. The asset's owner accepts it — the change is then created under the human's authority with the agent attributed — or dismisses it. Events: info:recommendation:filed, then accepted, dismissed, expired or superseded.
  • At supervised (the grant from lesson 12.2) Felix's own change request is created gated: it enters the same pending-approval funnel as human-governed change, with one more checklist line naming the tier. The payload cannot name a tier or waive a gate; the server resolves and stamps everything.
  • At autonomous the change runs ungated within scope.

Read the cards and the queue:

opschain recommendations list limebank --status open
opschain recommendations show limebank <recommendation-id>
opschain approvals list

The recommendations table carries ID, STATUS, AGENT, LANE, NODE, TITLE, CORRELATION and DUPLICATES; the approvals inbox carries a WHY column.

That WHY is the point: every agent-originated change MUST state its rationale — the create request's rationale attribute, refused by name when missing — and the whole unit of work shares ONE correlation chain. Invoking one of Felix's capabilities stamps a correlation id on the exchange (info:agent:invoked is the root hop), the SDK carries it on every call the agent makes, and the recommendation, the transcript and the change join it. The approver reads it back as the approval context — "requested by felix (agent, SUPERVISED, owner release_managers)", the rationale verbatim, the recommendation it implements, the chain hop by hop (lesson 10.3):

opschain approvals show <run-id>
opschain chains show <correlation-id>

3. The trust review​

The trust review is the promotion case — what a quarterly review cites when it raises (or cuts) Felix's autonomy:

opschain admin agent trust-review felix

A machine document with requests_by_tier, requests_refused (caps included), recommendations by outcome, the active grants applying to Felix, its assignments and the assignment_floor, plus — where declared — owned_by, type with its tier_ceiling, the release and release_stage the instance runs, the disclosures, and for a brokered AI Agent tokens_by_provider and cost_centre (lesson 12.6). Read it beside the activity timeline: the timeline is what happened, the review is what was allowed and how much of it was used.

4. Transcripts​

Chat with Felix is captured server-side — mandatory, no off switch — one sealed segment per exchange, and read back through the API: GET /api/projects/limebank/agents/felix/chat_transcripts/{exchange}; without an exchange id the same path lists your own sealed exchanges with the agent, newest first, with a redacted first-line preview. The event is info:agent:chat.

An AI Agent additionally captures adapter-transit transcripts — every model interaction crossing the adapter — redacted twice under the standing rule (all resolved secrets and PII masked before persistence, never at render) and read back at …/agents/felix/adapter_transcripts/{exchange}; sealing lands info:agent:adapter_transcript. Both kinds ride the retention.chat_transcripts_days horizon (365 days when omitted, 0 means never), with archive-before-purge, and an exchange cited as evidence on a legal-held ledger entry is exempt until the hold lifts (opschain docs retention).

Check yourself​

  • Which command summarises what Felix did against what it was allowed, and where does a transcript live?
  • Which event is the root hop of one unit of Felix's work, and which command renders the whole chain from invocation to the approver's decision?

What you learned​

  • The activity timeline is the raw, server-emitted record of every request, refusal and lifecycle verb; the trust review is the decision view over it.
  • At advise Felix files recommendations a human accepts; at supervised its own changes wait in the approvals inbox with a mandatory rationale.
  • One unit of agent work is one correlation chain — invocation, reads, recommendation, transcript, change — and the inbox reads it back as the approval context.
  • Chat transcripts are always captured; AI Agents add adapter-transit transcripts, redacted before persistence, both under one retention horizon.

Next: lesson 12.4 — Releases, stages and the rollover — hire to retire (opschain learn 12.4), or back to your track (opschain learn).