Logging n8n AI Agent decisions for audit: tool calls, reasoning and traceability

n8n's AI Agent node decides on its own which tools to call, in what order, and with what arguments. That's exactly what makes it powerful — and exactly what becomes a problem the moment a decision needs to be explained after the fact. "Why did the agent refund this customer?", "On what basis did it classify this email as non-urgent?" — without a structured trace, the only answer is to replay the execution in the n8n interface, if it hasn't already expired. This guide shows how to turn an agent's reasoning — its tool calls, its observations, its final decision — into a queryable audit trail, building on the AI Agent node and on the logging pattern already detailed in our GDPR audit trail guide with n8n and Supabase.

The problem: execution data isn't an audit trail

n8n keeps execution data for every run, viewable in the interface — but this trace has three limits for audit purposes. It's subject to a retention policy (often a few days or weeks self-hosted, less on cloud depending on the plan): past that window, it's gone. It's not queryable by a third party or a reporting tool: there's no way to ask "show me every refund decided by the agent last month" without opening each execution one by one. And it mixes the technical trace (nodes, timings, network errors) with the business decision an auditor actually cares about. What you need is a dedicated table, populated on every run, that isolates decisions and their justification — exactly the role already played by the "Audit logging in Supabase" workflow from the Compliance & Audit Pack, adapted here to an agent's decisions rather than a questionnaire's answers.

What Return Intermediate Steps actually exposes

The AI Agent node alternates reasoning and action following the ReAct pattern — we cover this mechanism in our agentic RAG guide. In the node's options, Return Intermediate Steps exposes this path instead of just the final answer: an intermediateSteps array, where each item contains the action the agent decided on (tool name, arguments passed) and the observation returned by that tool. This is the raw material of the audit trail: without it, you only ever know the agent's answer, never the path that led to it.

Step 1 — Enable the trace on the AI Agent node

In the AI Agent node's settings, under Options, check Return Intermediate Steps. The node's output shape changes: instead of a plain output field, you get output (the final answer) and intermediateSteps (the array of reasoning-action cycles). If the agent uses custom tools or Vector Store Tools, each call shows up as a distinct entry in the array, with the tool name and the exact arguments sent.

Step 2 — Shape the steps before inserting them

A Code node right after the agent flattens the array into rows ready to insert:

const steps = $input.first().json.intermediateSteps ?? [];
const rows = steps.map((step, i) => ({
  json: {
    agent_run_id: $execution.id,
    step_order: i,
    tool_name: step.action?.tool ?? null,
    tool_input: JSON.stringify(step.action?.toolInput ?? {}),
    observation: typeof step.observation === "string"
      ? step.observation.slice(0, 4000)
      : JSON.stringify(step.observation).slice(0, 4000),
  },
}));
rows.push({
  json: {
    agent_run_id: $execution.id,
    step_order: steps.length,
    tool_name: "__final_answer__",
    tool_input: null,
    observation: $input.first().json.output,
  },
});
return rows;

Truncating at 4000 characters keeps a bulky observation (an entire document fetched by a search tool) from blowing up the table — in the vast majority of audit cases, the first characters of an observation are enough to understand the decision; keep the full content elsewhere (vector store, file) if a need for full re-reading exists.

Step 3 — A dedicated sub-workflow for agent decisions

As with the GDPR audit trail, isolate the insert in a sub-workflow called via Execute Sub-workflow rather than duplicating a Supabase node in every workflow that contains an agent. The Supabase schema, separate from the generic audit_log table:

create table if not exists agent_decision_log (
  id bigserial primary key,
  agent_run_id text not null,
  workflow_name text not null,
  step_order int not null,
  tool_name text,
  tool_input jsonb,
  observation text,
  recorded_at timestamptz not null default now()
);
create index if not exists idx_agent_decision_run
  on agent_decision_log (agent_run_id, step_order);

The sub-workflow's Supabase node receives each row produced in step 2 and inserts it with Insert. Reconstructing a decision becomes a plain query: select * from agent_decision_log where agent_run_id = '...' order by step_order — the equivalent of a debugger for an execution long gone from n8n's history.

Two concrete use cases

On the email triage agent from the Inbox AI Pack, the audit trail shows why a message was classified "urgent" rather than "administrative": the scoring tool called, the keywords detected in the input, the score returned. On the RAG documentation assistant from the RAG Assistant Pack, it shows which knowledge base was queried, with what rephrased query, and which passages actually grounded the answer — proof, if the answer is ever disputed, that "it's not in our documents" wasn't the model inventing an excuse but the outcome of a genuinely unsuccessful search.

What the EU AI Act actually requires — and what it doesn't

Nicholas Diakopoulos, in a landmark 2016 article in Communications of the ACM ("Accountability in Algorithmic Decision Making"), already laid out the principle this article builds on: an automated system is only accountable for its decisions if there's a trace of its internal workings, not just its output. The EU AI Act turns this into a legal obligation for systems classified as "high-risk" under Annex III (recruitment, credit scoring, medical devices…): Article 12 mandates automatic logging throughout the system's lifecycle. A 2026 study by Buscemi and co-authors proposes a method for translating these legal requirements into concrete technical checks ("Assessing High-Risk AI Systems under the EU AI Act"). That said, the timeline for these Annex III obligations was pushed back to December 2027 by the "AI Omnibus" simplification adopted in 2025-2026 — an internal assistant or a support bot generally doesn't fall into this high-risk scope, but the same logging remains the best available practice for demonstrating the accountability required under GDPR Article 5(2) whenever an agent processes personal data.

Going further: from raw logs to a readable report

An agent_decision_log table that keeps growing every day is only useful if someone can turn it into a summary without reading thousands of JSON rows. The principle is the same one detailed in our article on AI-generated audit summary reports: a Basic LLM Chain with a Structured Output Parser, fed the rows for a given agent_run_id, producing a structured summary of the reasoning rather than a technical dump. And to keep an eye on what this logging actually costs in extra calls, our guide on tracking AI call costs in n8n applies directly: every logged step corresponds to a call the agent was already billed for — the logging itself only adds a near-free Postgres write.

An audit trail of agent decisions isn't a regulatory checkbox in most use cases — it's mainly what turns an AI agent from a black box into a system whose past decisions can be explained, one by one.