“Everything is logged” is the easiest sentence to write on a governance page and the hardest to mean. Most AI agent logs record what the agent produced. Very few record what the agent saw, and that is the field you will need on the day something goes wrong.
The test for an audit trail is not whether it exists. It is whether a competent person, six months later, can answer a specific question about a specific run without re-running anything.
The question an audit trail has to survive
Here is the concrete case. In March, an agent emails a customer stating their outstanding balance is £14,200. In September the customer disputes it, and the real figure at the time was £4,200.
There are three possible explanations, and they have completely different consequences. The agent read the correct record and generated a wrong number. The agent read a record that was itself wrong at that moment and has since been corrected. Or the agent read a different record altogether and attributed it to the wrong contact.
An output-only log distinguishes none of these. It shows the email. You can see what was sent, and you can see the current state of the invoice, which has changed. The middle explanation and the first are indistinguishable, which means you cannot tell whether you have a model problem or a data problem, and those demand opposite responses.
Recording the observation returned by each tool call collapses the ambiguity immediately. If the trail shows the balance-reading tool returned £4,200 and the drafting step produced £14,200, you have a model problem and the agent should lose its send tool today. If the tool returned £14,200, your reconciliation was wrong in March and the agent behaved correctly on bad input.
The fields, and what breaks without each one
| Field | Level | What it answers | What breaks without it |
|---|---|---|---|
| Reasoning text | Per step | Why this step at all | Post-hoc review becomes guesswork about intent |
| Tool selected | Per step | Which capability was used | You cannot tell a read from a write |
| Parameters proposed | Per step | Exactly what was requested | A suggestion-only run leaves no evidence of intent |
| Observation returned | Per step | What the agent actually saw | Model error and data error are indistinguishable |
| Started by | Per run | Who is accountable | Accountability lands on “the AI” |
| Exit reason | Per run | How and why it ended | Every failure looks the same |
| Duration, tokens, cost | Per run | What it consumed | Spend cannot be reconciled to work |
| Configuration in force | Per run | What it was permitted to do | You cannot reproduce the conditions |
The parameters row deserves a note. It is what makes a non-acting agent accountable. An agent running in suggestion mode changes nothing, so an output-only log has nothing to record, and “what would it have done?” becomes a question you can only answer by running it again under different conditions. Storing the proposed payload makes the counterfactual a record.
Write the record before the work, not after
The natural implementation is to run the agent and then write down what happened. That works until the process ends mid-run, which it does on every deploy and every crash.
When it does, two things happen at once, and both are invisible. The run leaves no row, so the history looks clean. But the credits it consumed were charged call by call as it went, so the usage line shows spend with no corresponding work. From the history side it looks like nothing happened; from the billing side it looks like a mistake. Neither view contains the information that would reconcile them.
Writing the run row before the first billed step fixes this with no clever machinery. The row exists, marked running, carrying the agent, the workspace and the task. It is then updated in place on the way out, through success and through failure, on the same code path rather than a happy path with a catch bolted beside it. A row still sitting at running is then not a mystery; it is the visible signature of an interruption, and it is supposed to be there.
Actors, principals, and the thing a log cannot tell you
When the actor is software, “who did this” splits into three questions, and a trail that answers only one of them will mislead you.
Which billing and isolation identity was this charged and scoped to? That is the principal, and it should be on every record.
Which human started the run? Separate field, separate meaning. An agent that only runs when a person starts it has a clean answer here; one that fires on a schedule needs the schedule recorded as the initiator and the person who created the schedule recorded somewhere else entirely.
Who set the permissions it operated under? This is the accountability question, and it is answered by the agent’s configuration history, not by the run. If autonomy can be passed in at run time, the answer is whoever pressed the button, which makes the setting a property of the moment rather than of the job. Storing autonomy on the agent instead means the answer is whoever last edited it, deliberately.
A principal is not a person. A signed-in staff member, a verified customer and a scheduled job can all resolve to the same workspace and they are not equally identified. Any log that flattens them into one actor field is losing the distinction you will most want. This is the same argument as the AI agent system of record, applied to the record of the agent rather than the records it touches.
Be specific about what is not recorded
Here is the position worth taking: an audit trail’s credibility comes from its stated gaps, not from its coverage claims.
The most common gap is refusals. A prompt stopped by a guardrail or a call stopped at a spend ceiling is usually refused before any execution record is created, so it reaches error handling and never reaches the history. The consequence is precise and worth writing on a wall: an empty AI history does not mean nothing was attempted. If you are evaluating a platform, ask specifically whether a blocked call leaves a row. “Everything is logged” is not an answer to that question.
The second common gap is derived fields presented as observed. A confidence score is the usual offender. If a score can be defaulted, inferred from settings, or generated for a run that made no model call, then the field is decorative and sorting a review queue by it is sorting by nothing. A score should either come from a real scoring pass or be null and render as a dash.
What Oneop records, in three groups
Oneop writes evidence at three different times, and the third group is the honest one.
Before the model runs, the credit reservation is written inside the same transaction that charges it, carrying the workspace, the kind of work and its weight. The spend record cannot exist without the workspace on it. The agent run row is likewise inserted before the first billed step.
After the call returns, an execution record is written on the success path and the failure path alike, carrying which model actually served the call after any fallback, tokens used, latency, and the error text when there was one. Every agent step keeps its reasoning, chosen tool, proposed parameters and the observation returned, and the run keeps how it ended out of nine distinct exit reasons: goal reached, out of steps, out of tokens, out of time, no progress, blocked by a guardrail, tool error, escalated, or out of credits.
Not at all, for a refusal. That gap is stated plainly on the AI governance page rather than smoothed over. Two further boundaries worth knowing: rejecting a queued agent action records the decision, the reviewer and the time, while a rejected automation approval currently records nothing, and the agent run reports the model it was configured to use rather than the fallback model that may have served the call. The per-call execution record has the model that actually served it.
Simulated runs are kept distinguishable on purpose. A simulated Oneop run makes no model call, creates no credit row, stores no confidence score rather than a flattering one, and is badged in the run list. A demo that looks exactly like production is a feature in a sales call and a defect in an audit.
Design your trail so that the uncomfortable question is answerable, then read what an approval queue must show a reviewer and which guardrails run before the action, since both write into the same record. The full field list for a run is on the AI agents page.