Cloud agents

The audit trail behind every agent session

If you cannot reconstruct what happened three weeks later, you do not have an audit trail. You have a feeling.

The short answer

An AI agent audit trail records who asked for the work, what the agent did, what it produced and who accepted it. Polaris writes six separate records: an append-only activity feed, a per-step session event stream, the comment thread, file version history, document snapshots, and the effort counters stored beside each job's human-hour estimate. Members can read these; only triggers and server-side code can write them.

Records kept: 6
Session event kinds: 8
Client write access: None

The six records

Each answers a different question, which is why one of them is not enough.

Activity feed
An append-only table written by database triggers, covering created, assigned, unassigned, moved, started, completed, reopened, urgent on and off, due changed, commented, attached and deleted. It answers who did what to this task.
Session event stream
Per job, an ordered sequence numbered from one, with kinds session, thought, search, tool, progress, delivered, error and done. Each search event carries the query text. It answers what the machine actually did.
The comment thread
Progress notes and the final delivery are comments authored by the agent's member row, sitting in the same thread as human replies. It answers what was said and by whom.
File version history
Each revision of an attachment preserves the previous path, size, version number and author before the new one is written. It answers what this file looked like before.
Document snapshots
Updating a document in place first stores a full snapshot of the title and every block. It answers what this page said last week.
Effort counters and the estimate
A finished job stores its human-minute figure alongside the raw counters it was computed from. It answers why this line on the bill says what it says.

Reconstructing a session after the fact

The order to read them in when something looks wrong.

1
Start at the activity feed
Find the assigned event. It names the actor, the worker and the moment, which fixes who set this in motion.
2
Open the job row
It carries the status, the attempts counter, the claim time, the finish time and, on failure, the error message that ended it.
3
Replay the event stream
Read the events in sequence number order. Search events show the exact queries, tool events show each call, and thought events show the model's own text between calls.
4
Read the thread
The early progress comment states the plan the worker announced. The delivery comment is the claimed result, with source URLs where it researched.
5
Diff the artifacts
Compare the current attachment against its stored versions, or the current document blocks against the snapshot taken before the last update.
6
Check the arithmetic
The effort counters on the job row multiply out through a published formula. If the search count does not match the search events, that is a discrepancy you can point at.

Who can write what

Job rows carry a read policy for org members and no client write path beyond creating a review job on something you can already see. Activity events and session events are readable by members and written by triggers and the runtime's service credential, never by a browser.

The connection and API-key tables go further. They have no select policy at all, so a credential cannot be read back through the client API by anyone, including the admin who set it. What members can query is a function that lists which connections hold a working credential, without ever returning one.

Agents deliver, humans close

One rule holds the whole product together, and it is a rule about who is allowed to say finished.

When the deliverable is a file

A chat reply is not a deliverable if the thing you needed was a document somebody can open.

Work log

The record that makes an unwatched run reviewable afterwards.

Human-equivalent hours

A billing unit denominated in the work replaced, not the compute consumed.

What an AI worker costs, and how the hours are counted

The whole formula is on this page, including the parts that make it an estimate rather than a measurement.

Questions people ask

+Can an agent delete its own history?

No. The activity and session event tables are written through triggers and the runtime's server-side credential, and neither exposes a delete path to a member client. Deleting the task removes its rows by cascade, which is a human action recorded as a delete event on the feed.

+How long is the session stream kept?

Events live as ordinary rows tied to their job, so they persist as long as the job does, and job rows persist until the task is deleted. Individual event bodies are truncated at fifteen hundred characters, so a very long block of model text is stored clipped rather than in full.

+Does the audit trail record what the model was thinking?

It records the text the model produced between tool calls, stored as thought events, plus every search query and every tool call with a short summary. It is a record of observable actions and outputs, not of internal state.

+Is any of this exportable?

Everything described here is ordinary Postgres in your own project's database, queryable with SQL. Polaris does not ship a one-click audit export in the product today.

+Who can see an agent's work in a private bucket?

Job rows and their event streams are readable only when the underlying task is visible to you, and private buckets narrow that check. Work done inside a private bucket does not surface in the org-wide activity view for members without access.

Cloud agents that keep working after you close the laptop

For the person whose agent is brilliant, local, single-player, and dead the moment the lid goes down.

Agents deliver, humans close

One rule holds the whole product together, and it is a rule about who is allowed to say finished.

When the deliverable is a file

A chat reply is not a deliverable if the thing you needed was a document somebody can open.

How an AI worker gets tool access

The interesting part of tool access is not the list. It is where the credential lives and who can read it.

Work log

The record that makes an unwatched run reviewable afterwards.

Human-equivalent hours

A billing unit denominated in the work replaced, not the compute consumed.

Human-in-the-loop

The system cannot complete the loop without a person, by design.