The Approval and the Action Are Not One Record

An agent does not only answer. It calls tools. It reads files. It writes records. Months later someone will ask three questions at once: what did it do, who allowed it, and are those two facts the same act.

Identity writing now treats an agent audit trail as a chronological record of inputs, reasoning steps, tool calls, outputs, and the human who delegated authority. Reconstructing a chain of micro-decisions a year later takes more than a chat log. 1 Data-governance writing draws the same line from the other side. A model trail captures a decision. An agent trail has to capture the decision, the action, and the steps between them. Log an agent the way you log a model and you miss the part that matters. 2

A 2026 runtime paper puts both pages into a test: what evidence binds the approval to the execution, and can an independent verifier reproduce the same action identity later? 3

This Brief does not prove a named HR or LMS write failed that test in an audit. It proves the test exists, and that the stack most teams already have , ticket, IAM role, SIEM line, change record , answers a different question. Those artifacts can show that work was allowed in a class of cases and that a call occurred. They do not produce one record in which this write is that approval. If the join is missing, you do not have a record of the act. You have two files that happened to exist in the same week.

1. 1. An agent trail is a record of action, not only of text. The trail that matters names the agent, the human who delegated authority, the prompt, the intermediate steps, each tool call with what went in and what came back, the output, the override if there was one, and the policy in force that day. Chat history is not that trail. Neither is an access log that only shows a call landed. 1
2. 2. Logging a model is not logging an agent. A model trail is mostly inputs, outputs, and versions. An agent trail has to include the systems it touched, whether those calls were permitted, and the policy checks that fired or did not. The sentence the model emitted is not the act. The tool call is. 2
3. 3. The hard join is approval to execution. Different runtimes need an object that binds those two so a later reader can reproduce the same action identity. A standing grant plus a call log is not that object. That is a replay test, not a storage setting. 3

The old log assumed a person typed a command. One input, one output, one pair of hands. If you kept the command and the result, you had the act.

An agent breaks that assumption. It can make a dozen small moves inside one run, each with a tool it already holds permission to use. It can write a completion at 2:14 a.m. under a role issued in March. It can halt, get overridden, and continue under a different person than the one who opened the ticket. Replay, in this Brief, is not a movie of the model’s private thoughts. It is the later ability to put that sequence back together so a second reader sees this approved work, not merely that work occurred.

One identity-product page defines the trail as a chronological, tamper-evident record of every agent input, reasoning step, tool call, and output. Every entry starts with two identities: the agent, and the verified human who delegated authority to it. If the agent calls an API, the log records the call, the input submitted to the tool, and the result that came back. If a person stops the run or changes course, that override stays in the record. Policy versions sit next to the timestamps. The page’s own test is time. Auditors may ask for justification up to a year later. Stepping backward through the chain then takes more than basic logging. 1

Read that as a parts list, not as a claim that most enterprises keep it.

Prompt. Agent identity. Human who handed over authority. Each tool invocation. What the tool received. What the tool returned. The intermediate steps a reviewer would need in order to walk backward. The override, if there was one. The policy that was in force that hour.

Drop any one of those and “we logged it” starts to mean “we have a file.” A chat export keeps the sentences. An access log keeps the fact that a call occurred. Neither keeps the act.

A data-governance page says the common mistake is using the model template on the agent. A model trail captures a decision: inputs, outputs, versions. An agent trail has to capture a decision and an action and the steps between them. Log a model like an agent and you over-collect. Log an agent like a model and you miss the action. 2

The agent version adds every tool and system call, the decision trace, every dataset and system touched, and whether the call was permitted. Runtime policy checks belong in that trail. The point of recording the check is not decoration. It is so a later reader can see not only what happened but whether it was allowed when it happened. 2

That split is the load-bearing distinction. The sentence the model emitted is not the act. The tool call is.

A completion written into an LMS is a tool call. An assignment pushed from an HR event is a tool call. A skills flag flipped in a talent file is a tool call. If the log only kept the sentence the agent said about those writes, the writes are invisible. If the log kept the writes and not the permission check, the later reader can see that something landed and cannot see whether it was allowed to land. Both failures produce the same public object: a tile someone else will trust.

The runtime paper is the test those two pages imply. It converts messy activity from different agent runtimes into canonical action objects and asks two questions. What evidence binds the approval to the execution? Can an independent verifier reproduce the same action identity later? 3

Those are not logging-volume questions. They are identity questions.

Picture two folders. In one, a manager approved an agent to update learning records when roles change. The ticket is complete. The owner is named. The role was issued. In the other folder, an API wrote a completion and an assignment at 2:14 a.m. The SIEM line is complete. The LMS row is complete. Both folders are good on their own terms. Neither folder knows the other exists. A later reader can say that approval happened and that writes happened. They cannot say that this write is that approval. The act has no single identity. 3

Replay is the opposite picture. One object carries the delegated human, the policy version, the tool, the payload, the result, and the time. A second person, months later, can step through it and get the same action identity. The chat window can be gone. The original operator can be gone. The join still works.

That is also why the ordinary stack feels like an answer and is not one. The March ticket is the first folder. The 2:14 a.m. SIEM line is the second. Competent teams produce both and stop. The paper’s test keeps going. Are they one act?

The sources are not LMS manuals. Learning still inherits the failure, because learning is where an unbound write becomes a transcript another human will treat as proof.

021 asked who occupied the seats on a learning control path: who assigns, who finishes, who writes the record. This Brief is the next question. Once those seats have been used, do they leave one act or two files? A green completion tile with no join between the authorization and the write is not a learning record. It is an orphan action. Payroll, compliance, and the next manager will still treat the tile as proof. They will be reading a model log wearing an agent label.

020 asked whether the next action could be held before it became effective. This Brief is later. The action already ran. Holding it is no longer available. Replay is what remains.

A skills update prescribed by a gap-closing agent is the same shape. The prescription is an approval story. The enrollment write is an execution. If those two cannot be joined, L&D has a path and no act. The company will still report the path as closed.

None of that requires a fourth source. It requires taking the test in 3 seriously in the one place Autonoma readers already use records as proof.

No source here names a production learning system that failed replay in an audit. The identity page is selling a product. Read the parts list, not the demo. The data-governance page is selling a command center. Read the model-versus-agent split. The runtime paper is a design for a verification layer, not a field study of installed agents. The two-folder scene and the learning-tile application are this Brief’s joins. They illustrate the test. They are not additional evidence that a named suite failed it.

Autonoma forecast: Over the next 12 months, buyers will keep treating access logs and chat exports as agent audit, and will keep pointing at the provisioning ticket when asked who authorized a write. Score the trail on whether an outsider can join the approval to the tool call a year later. The timing is editorial.

Observed in the sources:

• An agent audit trail is defined as inputs, reasoning steps, tool calls with input and result, outputs, delegated human authority, overrides, and policy versions, built to survive a later request. 1
• A model trail and an agent trail are treated as different objects. The agent trail includes permission and runtime policy checks. 2
• Replay is framed as binding approval to execution so a later verifier can reproduce the action identity. 3

Not documented as a production incident. Watch these:

• A tool call exists in one log and the approval exists in another, with no shared action identity.
• An audit sample can show that work ran and cannot show who authorized that run.
• The answer to “who approved this write” is the onboarding ticket from another quarter.
• A learning completion or assignment write has no join to the authorization that was supposed to precede it.
• Chat export or access-log retention is presented as the agent trail.
• An override or policy change left no mark on the record of the write.
• Payroll or a manager treats the tile as proof while the trail sits in two folders.

For CLOs and L&D: Treat assignment, completion, and skills writes as tool calls. If you cannot join the authorization to the write, do not treat the tile as evidence. Ask for the join on any agent that can enroll, complete, or flag a skill. If you will not keep the join, say out loud that the tile is a dashboard event, not a training record.

For HRIT and security: Stop scoring agent control on whether a log file exists. Score it on whether a later reader can reproduce the act. Retention days answer a storage question. A live IAM role answers a class-permission question. Replay answers an identity question. Do not let the first two stand in for the third.

For audit and compliance: Ask for the bind, not the dump. Agent identity, delegated human, tool, payload, result, policy version, override if any. If any one of those is missing, the trail is a model log wearing an agent label. If the team produces the ticket and the SIEM line and calls the matter closed, record that as two files, not one act.

For suite buyers: Put replay in the RFP. Can an independent reader join approval to execution twelve months later? If the vendor answers with retention days, prompt logs, or “the agent runs under a named role,” they heard a different question.

For counsel: A working bind is discoverable. That is not a reason to pretend the chat export is the bind. It is a reason to decide, in advance, which writes you will be able to stand behind.

Weight: Open. The objection that should win, if any of them wins, is not that traces are expensive. It is that the enterprise already reconstructed the act and this Brief is asking it to reconstruct it again under a new name.

Walk the existing stack. A human opened a ticket and named an owner. IAM issued a role. The agent ran under that role for weeks. SIEM logged the API call. The LMS wrote a completion. Change control can show who was allowed to touch the system that day. A competent security team, asked whether this agent did this write, will produce those artifacts and call the question closed. On that view the Brief is late. The bind is the grant. The call log is the execution. Stitching them into a third object called an action identity is ceremony sold by identity vendors and a runtime paper. It also creates a file opposing counsel can notice and demand. You may not want a year-later movie of every tool payload a learning agent sent.

That case deserves a full answer, because parts of it are true.

It is true that provisioning, IAM, SIEM, and change control are not nothing. It is true that logging every reasoning step for every harmless run is a new collection program. It is true that two of the three sources here are selling software. It is true that none of them is an LMS manual, so the learning-tile scene is this Brief’s join, not a quotation. It is true that “replay” can be misread as a demand to store the model’s private chain of thought, which most teams should not keep.

What the case does not do is answer the question the sources pose.

A standing grant is permission for a class of work. It is not identity for this write. The ticket that onboarded the agent in March does not say the 2:14 a.m. completion in September is that ticket. IAM can show a role was live. It cannot show the payload that landed, the policy version in force that hour, or whether a person halted the run and someone else continued it. SIEM can show that a call occurred. It cannot bind that call to the human who delegated authority for that act, which is the first field on the identity-page parts list. 1 Change control can show who was allowed to write. It cannot show that this write is the write that was allowed. 23

Two complete files in the same week are still two files. That is the whole Brief. The existing stack is good at proving that work was possible and that work occurred. It is weak at proving they are the same act. The runtime paper’s test is not whether logs exist. It is whether an independent reader can reproduce one action identity later. 3 If the answer is the ticket plus the SIEM line, the answer is no.

The sampling variant is the same objection with a budget. Keep the rich trail for money movement and privileged access. Treat a learning write as noise. Sample the rest. That rule is rational until someone else treats the tile as proof. Payroll already does. Compliance already does. The next manager already does. The tile is how the company claims a person was trained. Once that is true, the write is high-consequence whether L&D put it in the high-consequence bucket. Sampling can still be the operations choice. It cannot be the claim that the tile is evidence.

A last objection is liability in the other direction. A bind that actually works is discoverable. Teams will under-log on purpose. Fair. Under-logging is a decision to have no record of the act. Say that. Do not call the chat export the record.

Vendor pages remain vendor pages. Read the parts list and the model-versus-agent split. Do not read a SKU. The paper remains a design, not a field study. Learning remains the place the orphan action gets trusted, not a fourth source.

Decide what the completion tile is.

If it is evidence that a person was trained, or that a role-change path ran under authority, then the write is an act. An act needs one record: the human who delegated, the policy in force, the tool, the payload, the result, and the time, bound so a later reader can see that this write is that approval. A standing grant is not that bind. A chat export is not that bind. Retention days are not that bind. SIEM plus the onboarding ticket is not that bind. Those artifacts prove a class of permission and a call. They do not produce one action identity. 123

If you will not keep that record, stop treating the tile as evidence. Treat it as a dashboard event. Tell payroll and the next manager the same thing. Do not keep two stories , one for audit (“we log everything”) and one for the business (“the tile means they finished”).

High-consequence is not only money. High-consequence is any write another human will trust later. Assignment, completion, and a skills flag are already in that set. Bind those writes or retire their meaning. There is no third option that leaves the tile in place and the trail in two folders.