What AgentSight JSON snapshots contain—and what they omit

Short answer: a versioned view snapshot, not a lossless trace

In AgentSight v1.0.35, report export loads an AgentSight materialized view and serializes export_snapshot to JSON. The documented shape is schema_version: 1. It is also the response shape of GET /api/v1/snapshot, though the live API uses its own source selection and, when Direct Node authorization is enabled, requires an evidence.read capability. An integration must not assume that a local export file and a live API response describe the same time window.

The contract permits additive version-1 fields: ignore unknown fields, but reject a schema version you do not support. The documented writer emits nullable values as null and missing collections as empty arrays. Treat source-specific null as unknown rather than imputing zero or inferring success. These statements are pinned to product commit c1574366122a90c451bca6a84713e28813ab95e2; they are source inspection, not a new live benchmark.

Which rows are exported, and which evidence is only summarized?

The snapshot includes summary, model-grouped token_summary, network_targets, process_nodes, audit_events, resource_samples, sessions and tool_calls. The summary also records covered timestamps, view source, event/call counts, token totals and the requested audit limit.

Importantly, there is no top-level full llm_calls array and no full token-usage row set in schema 1. A positive summary.llm_calls count means the view counted calls; it does not make a per-call request, response or latency record available in this export. For downstream profiling, the model-grouped token summary is a rollup, not a substitute for the underlying per-call evidence.

Network entries can contain a raw request path. Process entries may carry argv, command lines and working directories. Audit rows may include arbitrary details, while tool calls may include their inputs and outputs. Therefore an apparently technical snapshot may disclose repository names, secrets in arguments, prompts or tool results. Access control and field-level minimization must happen before distributing a derived artifact.

The audit-limit edge case that can break a compliance report

In MaterializedView::export_snapshot, the summary and the emitted audit array are built separately. summary.audit_events is a count reported by the view before export limiting. The array is sorted by timestamp (with event ID breaking ties) and only the most recent requested rows are retained. The implementation additionally caps the output at 100,000 rows, even if a caller requests more.

By default, the CLI --audit-limit is 10,000; the snapshot API also defaults to 10,000. Passing zero produces no audit rows while the summary may still report events. A caller asking for 250,000 rows does not override the implementation cap. And because summary.audit_limit echoes the requested option, consumers must not mistake that field for proof that exactly that many rows were made available.

A safe completeness annotation stores all three values: summary.audit_events, summary.audit_limit and audit_events.length. If the visible count is smaller than the reported total, investigate the effective limit and data lineage; do not report omitted rows as non-events. Even matching counts do not establish complete capture at the kernel or application boundary—event loss and source-specific reconstruction remain separate questions.

Nine integration decisions grounded in the current source

Consumer observation	Supported interpretation	Unsafe inference
schema_version is 1; unknown extra key appears	Version 1 is the documented contract. Added fields within that version should be ignored by tolerant readers.	A new field is not a promise that existing readers must start using it. Reject unsupported schema versions.
summary.audit_events is 2,200; audit_events has 1,000 rows	The summary is a pre-export-limit count; the array may contain only a bounded subset.	Those 1,000 entries cannot be treated as the complete process/file/API event history.
audit_limit=0 in a snapshot request	The export path can produce an empty audit_events array even if the summary reports observed audits.	An empty audit array is not proof that no audited event occurred.
audit_limit requested above 100,000	The materialized view clamps the emitted audit array to at most 100,000 rows.	summary.audit_limit records the requested value, not necessarily the effective cap.
summary.llm_calls is positive; no llm_calls array exists	The snapshot publishes aggregate LLM counts and model-grouped token_summary, not the full LLM-call row set.	Do not use it as a lossless prompt/response archive or assume per-call trace completeness.
process_nodes[].exit_code is null	The model has no value for that optional field in this row.	Null is not 0, a successful exit, or a signal classification.
audit_events[].view_source differs across related events	Lineage is per row: direct view, SQLite reconstruction, agent-native, or legacy unknown.	Do not treat differing row sources as independent proof of two separate logical operations.
resource_samples is empty	This view produced no resource-sample rows for export.	It does not prove zero CPU or memory use, or that the agent was idle.
tool_calls[].input and output are present	The snapshot may include captured tool arguments and results rather than only categorical metadata.	Never treat a complete snapshot as sanitized or public-safe just because it is JSON.

Reproduce the contract check without publishing raw evidence

The following is a local example for an already-recorded, authorized capture. It writes a sensitive JSON file and prints only coarse metadata. The commands are documented source-based procedures, not an executed test from this article. Use the canonical CLI documentation for installation and capture setup.

agentsight report export --db ./agentsight-run.db --audit-limit 1000 -o snapshot.json
jq -e '.schema_version == 1 and (.audit_events | type == "array") and (.summary.audit_events | type == "number") and (.summary.audit_limit == 1000)' snapshot.json
jq '{schema_version, source: .summary.source, audit_total: .summary.audit_events, audit_included: (.audit_events | length), audit_requested: .summary.audit_limit, llm_calls: .summary.llm_calls}' snapshot.json

To verify the 100,000-row cap and summary behavior directly from the pinned implementation without collecting private agent data, inspect these functions:

git checkout v1.0.35
rg -n "export_snapshot|snapshot_summary|fn audit_events" ext/analysis/src/view/mod.rs
rg -n "audit_limit|run_export" collector/src/main.rs collector/src/cli_db.rs collector/src/server/web.rs

This static inspection verifies code branches and schema structure; it does not demonstrate a real workload producing 100,000 rows. An operational integration should add its own fixture tests for unknown extra fields, unsupported schema versions, nullable values, limit zero, and incomplete audit arrays, without placing private snapshot samples in public CI logs.

Design a downstream evidence record that preserves limitations

For a dashboard or automated review, store the export source, timestamp, schema version, original window, requested limit, observed row count and a clear annotation that the snapshot is a selected view. Keep a separate decision for task success: a process exit row or agent completion state alone does not validate the generated patch, test run or external action. The process EXIT evidence note explains that boundary.

If your question is whether reconstructed or directly captured audit rows agree, use the audit provenance reference. If the source stream lost observations, read the capture-loss analysis. A JSON snapshot has different semantics from OpenTelemetry GenAI span export; neither format automatically grants the completeness or privacy properties of the other.

Primary sources, scope and open limits

Research scope: AgentSight v1.0.35, product commit c1574366122a90c451bca6a84713e28813ab95e2, reviewed 1 November 2026. We inspected the documented schema, view implementation, CLI flags and API authorization path. No live capture, end-to-end privacy assessment, production API call, count-consistency benchmark or downstream consumer compatibility experiment was performed. Recheck the implementation for any newer release before treating this source-pinned behavior as current.