The Sentience Agent Execution Record is the local, append-only stream of structured events that Sentience Governor writes for each governed agent session. It uses one schema across every supported integration and stays on the operator’s machine by default.
It is product terminology: the name of the artifact Sentience Governor produces. The concept behind it is governance evidence, and that entry covers what such a record can establish. This entry is about the record itself: what it is made of, what goes into it, what is deliberately left out, and how to read it.
One session, one file, one event per line
A record is a sequence of events for one session, one JSON object per line, appended to as the session runs and never rewritten. “One session, one file” describes the default file sink, not every configuration. The Claude Code integration writes each session to its own file under the operator’s home directory by default; an operator can instead point it at a single file, and then every session’s events are interleaved there, told apart by their session identifier. The other integrations write wherever the integrator directs them. Each integration starts a session when an agent begins governed work: a Claude Code session, a wrapped Model Context Protocol client, a LangChain or LangGraph run, a Pydantic AI run through the separate package.
Where the events go is chosen among three sinks: standard output, a local file, or an HTTP endpoint the operator configures. With standard output or an HTTP endpoint there is no local file at all, and the stream is only as durable as whatever receives it. The Claude Code integration writes to files; events leave the machine only if a sink is pointed somewhere else. Local-first governance covers that stance and its two disclosed exceptions.
The schema is the same whichever integration wrote the record. That is the property the definition stresses, and it is what lets one set of tools read every record: the command line reports, the session report, and the governance tools an agent can call over MCP all read the same shape.
The envelope
Every event, whatever its type, carries the same fourteen envelope fields, and a fifteenth when the session is governed by a profile.
| Field | What it holds |
|---|---|
event_id | A unique identifier for this event |
event_type | One of the six types below |
session_id | The session the event belongs to |
event_sequence_number | The event’s position in the session, counting from 1 |
previous_event_id | The identifier of the event before it, or null for the first |
agent_id | The agent the session belongs to |
deployment_mode | How the agent is deployed, as declared |
timestamp_utc | When the event was written |
primitive | Which of the record’s five governance primitives the event belongs to, or SYSTEM for errors |
payload | The type-specific content, described below |
advisory_flags | The conditions the evaluation noticed on this event |
policy_violations | The identifiers of the rules that matched |
simulated_consequence | An informational statement of what a blocking policy would have done. It is a description, not an action |
pass_through | Whether the action was allowed to proceed. In the current implementation, always true |
profile_fingerprint | A short digest of the governing profile, present on every event of a session governed by one, and omitted otherwise |
The first event of a genuine record, written by the released MCP client wrapper for a stand-in support agent, is reproduced here exactly, including the identifiers and the timestamp of that run. Nothing external was involved; the stand-in tools ran in one process. No governance profile was in force, so the envelope has no fingerprint and the payload has no profile fields.
{
"event_id": "5425dd52-683e-4deb-b938-f82e3e4aabb9",
"event_type": "AGENT_REGISTERED",
"session_id": "47348fc5-fcfc-46fe-91f2-07865f2f6f04",
"event_sequence_number": 1,
"previous_event_id": null,
"agent_id": "support-agent",
"deployment_mode": "vendor_managed",
"timestamp_utc": "2026-09-24T00:37:47.728Z",
"primitive": "REGISTRATION",
"payload": {
"agent_id": "support-agent",
"agent_version": "1.0.0",
"vendor_id": "example-co",
"deployment_mode": "vendor_managed",
"declared_capabilities": [
"crm"
],
"owner_claim": "support-team",
"policy_context": null
},
"advisory_flags": [],
"policy_violations": [],
"simulated_consequence": null,
"pass_through": true
}Two words in that payload matter. owner_claim is a claim: the record notes who the agent says it acts for, and nothing verifies it. declared_capabilities is likewise a declaration. The record is careful to name assertions as assertions.
The six event types
| Event type | Written when | What the payload carries |
|---|---|---|
AGENT_REGISTERED | An agent identifies itself to the session | Agent identifier and version, vendor, deployment mode (vendor_managed or enterprise_managed), declared capabilities, owner claim; when a profile governs the session, whether it loaded and its schema version; and when the profile was resolved through a per-agent binding, the outcome and the binding matched |
INTENT_DECLARED | An objective is declared for subsequent activity, or a session starts without one | The objective text as written, its source (explicit, inferred or none) and confidence, and the declared scope |
SCOPE_ASSERTED | An action is attempted at the execution boundary, before it runs | The tool, the operation type (exactly one of READ, WRITE, DELETE or EXECUTE), the target system, the asserted permission (the same class in lower case, such as write), and for Claude Code shell commands a classification of the command’s effects |
CONTEXT_SNAPSHOT | Data enters the agent’s context, typically when a tool returns | Where the data came from, its size in tokens, its classification if the integration supplies one, and, where the integration reports model usage, the turn’s token counts |
MEMORY_WRITE_ATTEMPT | A write to a persistence target is attempted | The kind of write, how it was detected, the target store, the write’s classification and size, and any retention requested |
GOVERNANCE_ERROR | Capture itself degrades | The kind of failure (a capture failure, an unavailable sink, a schema violation, a timeout), its severity, the stage at which capture degraded, and whether the agent continued |
The first five are the governance primitives: registration, intent, scope, context and memory. The sixth records the record’s own failures.
Each event also carries the evaluation’s findings about it, in the envelope. A declared-scope mismatch, an unexpected operation, an unclassified context entry and the other conditions appear as advisory flags on the event where they were noticed, and a matched rule appears as a policy violation on the same event. The entry on flags and violations explains the two kinds of finding. Neither changes what happens: the action proceeds either way.
What the record does not contain
The record is structured metadata about attempts and findings. It is designed to leave out the substance of a session, with named exceptions, and “metadata” should not be read as “harmless”.
- Not recorded: prompts, completions, tool arguments, tool results, the contents of files read or written, file paths for edits, the full text of shell commands, latency or durations, money, and whether a task succeeded.
- Recorded: for a shell command, the executable name and subcommand of each segment, with the arguments dropped; the objective text as declared, verbatim; sizes in tokens; identifiers and names of tools and target systems.
Two consequences follow. A record usually reveals less than a transcript, but it is not free of sensitive material. The objective text is recorded verbatim and can name customers, projects or systems. Tool names, server names, target systems, executable names and owner claims describe an organization’s systems and who uses them, and the timing and sequence of events describe how work is done. A record should be handled with the same care as any operational log, and the objective text should not contain secrets. And a record cannot answer questions that need the substance: what the agent said, what a tool returned, what exactly a command would have done. Those belong to an observability trace that captures payloads, when one exists.
What the record is evidence of, and what it is not
Every SCOPE_ASSERTED event is written before the action runs, from the pre-execution payload alone. It records an attempt. A following CONTEXT_SNAPSHOT records that something came back. Nothing in the record confirms that the action had its effect on the system it targeted; that evidence lives in that system. In the session excerpted above, the record shows a refund call attempted and no snapshot after it: an attempt without a recorded return. That is all the record shows. The reason is not in it. That the stand-in payment tool raised an error, and that the error reached the caller unchanged, was observed by the program that ran the session, outside the record. An attempt without a return is consistent with a failure, and also with a session that ended, a capture that failed, or an integration that records no return for that call.
The record’s integrity is structural, not cryptographic. Events are numbered contiguously and each names its predecessor, which helps a reader notice an accidental gap or reordering inside the file. It does not establish completeness: events lost after the last one written, a session whose file was never created, or actions that never passed through an instrumented integration leave no gap in the numbering. Nor does it resist tampering, because anyone who rewrites the file can renumber and relink it consistently. There is no hash chain and no signature. The file is appended to by the integration, and anyone who can write to it can alter it. Protecting it, by file permissions or by forwarding events to a store that is append-only in its own right, is the operator’s responsibility.
Capture can fail, and the record is designed to make that visible rather than silent. What happens depends on the failure. A schema violation is reported on the process’s error stream and not written. When the sink itself cannot be written, the governance error is emitted on the process’s standard output, not into the file it could not reach: in a run of the same session against an unwritable path, no file was created and nine governance errors went to standard output, escalating from a warning through a degraded state to a critical error at session close, each stating that the agent continued. A reader of the record alone sees such a session as absent or truncated; the errors are where the process’s output went. The phrase in Sentience’s own documentation, that the gap is recorded rather than silently absent, holds for the process’s output and should not be read as a promise that the file records its own failures.
One schema, several integrations
The shape is fixed; how each integration fills it differs, and the differences are worth knowing when reading a record.
- Claude Code maps each built-in tool to an operation type by a fixed table, classifies
Bashcommands by their effects (semantic action classification), names MCP tools by their server, and, when a session ends, attributes the session’s model usage to turns from Claude Code’s own transcript, in four token classes. - The MCP client wrapper and the LangChain handler infer the operation type from keywords in the tool’s name, and take the target from the tool’s name.
- The Pydantic AI package takes the operation type from tool metadata the developer declares.
Token attribution, where it exists, stops at the turn: the model meters usage per turn, not per tool call, so a record can say how many tokens fell on turns involving a tool and never how many a tool “spent”. Context cost builds on that attribution.
Reading a record
The command line lists captured sessions, opens one event by event or as a summary, produces a session report that summarizes findings and usage, and explains how every number is counted. The same information is available to an agent inside a session through the opt-in MCP server’s governance tools, and a separate reader reviews another system’s existing history against the same questions. In the default configuration all of them read the files described here; Sentience Governor keeps no other store.
An example: a complete short record
The session excerpted above is genuine output of the released MCP client wrapper. A support agent was constructed with the objective “Answer the customer’s question about the status of order 1042” and a declared scope of crm. Three tool calls were made through the wrapper. The tools were stand-ins that really ran; one deliberately raised. Arguments and results do not appear in the record, and findings are described in words.
| Sequence | Event | What it recorded | Findings |
|---|---|---|---|
| 1 | AGENT_REGISTERED | The agent, its version and vendor, an owner claim, a declared capability | None |
| 2 | INTENT_DECLARED | The objective, marked explicit because the developer supplied it, and the scope crm | None |
| 3 | SCOPE_ASSERTED | crm.get_order: READ, target crm | None |
| 4 | CONTEXT_SNAPSHOT | A result entered the context from crm, 9 tokens | Unclassified, with the default classification rule |
| 5 | SCOPE_ASSERTED | vector_store.upsert_note: WRITE, target vector_store | Outside the declared scope, with the default intent rule |
| 6 | CONTEXT_SNAPSHOT | A result entered the context from vector_store | Unclassified, with the default classification rule |
| 7 | MEMORY_WRITE_ATTEMPT | A write to a persistence target, vector_store, 3 tokens, unclassified | Memory-write candidate, unclassified write, with the default memory rule |
| 8 | SCOPE_ASSERTED | payments.create_refund: WRITE, target payments | Outside the declared scope, with the default intent rule |
The record ends at event 8, with no snapshot after the refund attempt. From outside the record, the program that ran the session saw the stand-in refund tool raise and the error reach it unchanged; the record itself holds only the attempt. Eight events, 5,790 bytes, sequence contiguous, chain intact, every event passed through. The write to the vector store was detected as a memory write from the tool’s name, which contains a keyword the wrapper treats as a persistence target; the informational consequence field on that event describes what a blocking policy would have done, and nothing was blocked.
Often confused with
An execution trace. Agent tracing records spans: what ran, with inputs, outputs and timing. The execution record holds what the agent declared and what it attempted, evaluated against that declaration, and omits inputs, outputs and timing. The two answer different questions and can coexist; the record has no OpenTelemetry output.
An audit log. An AI audit trail is a broader idea, and often an append-only, tamper-evident store kept by the system acted on. The execution record is one input to such a trail, kept by the governance layer beside the agent, and it is not tamper-proof.
A chat transcript. Claude Code and other harnesses keep the conversation. The record does not contain it, and reads the transcript only to attribute token usage to turns.
The session report. sentience pulse is a report computed from a record. The record is the source; the report is a reading of it.
Governance evidence. The concept. The Sentience Agent Execution Record is the artifact in which Sentience Governor keeps it.
Where the concept stops
The Sentience Agent Execution Record is a specific artifact with a specific shape: local by default, append-only, structural rather than substantive, one schema. Its value is that a declared reference and every attempted action sit in one place with the evaluation’s findings attached, so that divergence is visible at all. Its limits are just as specific. It records attempts, not effects. It records assertions as assertions. It is only as trustworthy as the file system it sits on. And it holds only what passed through an instrumented integration; an action that reached a system by another route is not in it.