What to Record in an Agent Approval Log

The short answer names seven fields. Here is what each one is for and how to make it useful rather than ceremonial.

1. Decision ID. A UUID generated by the approval service, not by the agent. It is the join key for everything else. Make it stable before the reviewer clicks anything, so an abandoned request is still a record.

2. Timestamp. Record two: when the request was created and when the decision was made. The gap between them is your time-to-decision metric, which later tells you whether a queue is healthy.

3. Agent run ID and model version. You need to know which run and which model produced the output. Record the run ID from your orchestration layer and the model identifier plus prompt or template version. Without the version, a post-incident review cannot tell whether a behavior change came from a model swap or a human edit to the prompt.

4. Hash or link to the exact output shown. Reviewers need to have seen something specific. Store a content hash plus a pointer to an immutable object store record, so you can prove the reviewer saw the output that was actually executed and not a later revision. If you store only the final output, you lose the ability to detect approval drift.

5. Reviewer identity. A stable identity tied to your directory, not a display name typed into a form. This is what enables separation of duties, the requirement that the person who builds an agent is not the person who approves its production behavior, one of the governance elements described in Dataiku's overview. Where dual approval is required, capture both identities.

6. Decision and rationale. Capture the decision as an enumerated value: approve, reject, edit, or respond. Many frameworks already model this set. For example, LangChain's Deep Agents docs let you configure allowed decisions per tool, with approve, edit, reject and respond available by default and a narrower set for tools like email sending. Pair the decision with a short free-text rationale. A rationale field of 140 characters with a minimum length is usually enough to force a sentence and prevent empty strings.

7. Time taken. Seconds from the request being shown to the decision. This single number powers most of the tuning analysis described later, because it separates reflexive approvals from genuine review.

A minimal record in JSON looks like this:

{
  "decision_id": "9f1c2b7e-4d6a-4c39-9a4e-0f7b2d8c1e55",
  "requested_at": "2026-02-11T14:02:17Z",
  "decided_at": "2026-02-11T14:04:51Z",
  "agent_run_id": "run_01JT4M8QZ2",
  "model_id": "provider-model-x",
  "prompt_version": "refund-policy-v7",
  "output_ref": "s3://agent-outputs/run_01JT4M8QZ2/final.json",
  "output_sha256": "b3f1...9ac2",
  "reviewer_id": "u_88",
  "decision": "edit",
  "rationale": "Refund exceeds policy cap; reduced to 40% and added remediation note.",
  "seconds_taken": 154
}

Two fields are worth adding beyond the seven: the policy ID and version that triggered the gate, and the outcome of the side effect after approval. The authorization envelope described by Permit includes both, and the second one is what lets you prove the approved action actually ran.

Store the log in an append-only table or event stream that the agent cannot write to, with a retention policy tied to your audit requirements. That sentence is short, and every part of it matters.

The write boundary is the critical part. If the agent's own process has update or delete rights on the approval table, then the approval record is no longer independent evidence. Put the approval service behind its own credentials, give it insert-only access, and grant read access to analysts and auditors. If you need corrections, append a correction event rather than editing the original.

The choice between a table and a stream comes down to latency requirements and how you will query the data.

Retention should be set by the obligation, not by disk space. If a regulation or contract requires you to keep records of decisions for a defined period, the approval log inherits that period. Separately, keep a shorter operational copy for tuning. Prompt text may have a different privacy and retention model than the authorization evidence, which the Permit guide makes explicit: store the authorization envelope broadly and keep prompt content under its own rules.

Whichever store you pick, apply the same controls as any other audit control. Aembit's guide to agentic guardrails argues that every API call, database query and system modification should produce records that capture the agent's identity and the access decision, with comprehensive logging forming a backbone of identity guardrails. Salesforce's guardrails overview makes a similar point: operational guardrails define which actions an agent is authorized to take, require human sign-off on high-stakes decisions, and maintain audit logs of every step and the reason for it.

If you are building approvals in Microsoft's stack, the framework's approval flow is a useful reference for the round trip. Microsoft's tool approval docs show an agent run ending with an approval request that carries the function name and arguments, which the caller surfaces to a user before continuing in a new run. That request object is a natural place to snapshot fields 3 and 4.

The first search result will tell you to log approvals. The step further is to read the log on a schedule and make decisions from it. Three questions do most of the work.

Is a gate too frequent? Count approvals per gate per week, divided by the number of agent runs that could have triggered it. A gate that fires on most runs and is approved in nearly all of them is a tax on reviewers and latency. The fix is to move from approval on every action to a risk-based approach. Databricks' HITL explainer notes that mature HITL systems use confidence thresholds and risk scoring to route only a subset of decisions to human review, which is what makes HITL scalable in practice. Zapier's HITL guide makes the same point at the workflow level: add checkpoints where the decision carries risk, nuance or downstream impact, and use what reviewers catch to tighten instructions and thresholds over time.

Is a gate too lenient? Look at the distribution of time taken and the edit rate. A gate where most decisions take under ten seconds and almost none are edits or rejects is either well designed (the agent is consistently right) or being rubber-stamped. The log cannot tell you which by itself, so pair it with sampling. Review a small random sample of approved decisions each week and check whether the approval survived scrutiny. StackAI's approval workflow guide calls for an evidence pack that makes the decision obvious in 10 to 30 seconds, which is a useful benchmark: if median review time is well below that and quality sampling shows few catches, the gate is probably not adding judgment.

Where do reviewers actually intervene? Rationale text is the richest field and the most underused. Edit decisions carry the reason a human disagreed with the model, and that reason is training material. MLflow's review queue writeup describes exactly this pattern: collect traces, mark them pass or fail with human judgment, and the result becomes a dataset that can be used to fine-tune agents or train a judge that grades the first model's work. Approval logs with rationale give you the same asset for free.

Here is a worked example with numbers. Suppose a team runs an agent that drafts customer refund decisions and routes them to a support lead.

• 2,000 agent runs per week reach the refund gate.
• 1,850 are approved, 100 are edited, 50 are rejected.
• Median time taken on approvals is 11 seconds; median time on edits is 2 minutes 40 seconds.
• Edits cluster in one segment: refunds between two thresholds, where reviewers consistently trim the amount.

The frequency is high: 92.5% of gated runs are approved. The leniency signal is the approval median, which sits below the 10 to 30 second window where a reviewer can plausibly read context. But the edit cluster is the actionable finding. Reviewers are reliably overriding the agent in one band, which suggests the prompt or policy constraint for that band is wrong rather than the reviewer being inconsistent. The team's move is to add an explicit written rule for that band to the prompt version, keep the gate, and re-measure edit rate over the next two weeks. If edits drop, the gate can later be tightened to fire only above the higher threshold.

That loop, log, measure, change one thing, re-measure, is what separates an approval log from a compliance artifact. It also settles arguments about whether a gate is worth its latency, because you are comparing reviewer time against error rate and edit volume rather than trading opinions.

A useful test of your schema is to hand it to someone who has never seen the workflow and ask five questions.

1. Who approved this action, and on whose behalf was the agent acting?
2. What exactly did the reviewer see, and can you prove it has not changed since?
3. Which policy required the approval, and which version was in force?
4. Did the approved action actually execute, and what was the outcome?
5. Were any approvals for the same action denied or abandoned?

Replay does not mean re-running the model with a different temperature. Permit's guide defines it as reconstructing the decision from the same principal, agent, tool, resource, policy version, attributes, approval state and outcome, which is only possible with immutable, correlated records. Your approval log supplies the approval state and the identities; the tool trace supplies the execution detail. Join them on the trace ID.

For evidence to be trustworthy, the record has to be protected. Dataiku lists immutable logging of every approval and override as a core element of governed human-AI collaboration, alongside role segregation and escalation paths. Permit notes that auditors will ask how logs are protected and retained and how anomalies are investigated, so plan for access controls and tamper evidence on the log itself, not just on the agent.

The academic literature is clear that the loop is meant to improve the system, not only to document it. A survey of human-in-the-loop machine learning in Artificial Intelligence Review distinguishes active learning, interactive machine learning and machine teaching by who controls the learning process, which is a useful lens: your approval log is closest to interactive machine learning, where human corrections shape behavior continuously.

Start small and expand where the log earns its keep.

Steps 1 to 3 are the setup. Steps 6 to 8 are where the value compounds, because you are now making gate decisions from evidence.

If your agents span several model providers, keeping the approval layer independent of any one vendor simplifies field 3. Quanta Inference gives you text, image, video, audio and embedding models through one API key, with an OpenAI-compatible interface, so a model swap shows up as a clean version change in the log rather than a plumbing project: https://quantaintelligence.ai/inference.