A workflow display can show which path an agent chose and still leave an investigator unable to answer who approved the change or whether the target record actually changed. The display is useful, but its usefulness should be assessed against the business question the audit must answer.
This article proposes an evidence-gap checklist for one Make-based record-update workflow. It uses the announcement's stated visual trace as a starting point, not proof that every required audit record exists in a selected account. The fictional example does not establish compliance with any regulatory or professional standard.
Understand the announced trace without overstating it
Make's 11 February 2026 announcement describes AI Agents inside the scenario builder and a Reasoning Panel showing tool calls and the paths taken. It also discusses control over which tool inputs are set by the user or determined by AI. These are vendor feature descriptions, not a guarantee that the display is a complete or independently verified record of business authority. Source: Make AI Agents announcement
Inspect the actual environment and version available to the team. Record what the trace exposes, how it can be preserved and which related records remain elsewhere. Do not infer export, retention or reviewer-identity features that the announcement does not establish.
Treat an explanatory trace as evidence of the displayed execution path within its documented scope. It should not be described as complete access to an agent's internal reasoning or proof that every explanation accurately captures the cause of a decision.
Start from the investigator's required questions
For a customer-record update, the reviewer may need the initiating actor, source version, proposed field and value, approval, tool request, operation result and final verification. The information owner also decides how much source content is necessary and who may inspect it.
Separate the questions. What did the agent propose differs from what the application allowed, what a tool reported and what the authoritative system confirmed. A screenshot saying success may be insufficient for the selected process's outcome requirement.
OpenAI's function-calling guide distinguishes model requests, application execution and returned output. This is supporting architecture guidance, not a claim about Make's internal implementation. It helps define the separate evidence stages to examine in the selected workflow. Source: OpenAI function calling
Audit-evidence gap checklist
Use this complete proposed checklist for fictional action TEST-UPDATE-A. Status values are present and verified, gap, or not yet established. A capability not checked in the actual account should not be declared absent.
| Required question | Evidence to inspect | What the visible trace may contribute | Separate verification or gap owner |
|---|---|---|---|
| Who initiated the action? | Authenticated actor reference from trusted application records | Displayed request context, if available | Identity owner confirms the effective actor; prompt text is not authentication |
| What source supported it? | Source reference, version and exact supporting facts | Retrieved material or source labels shown by the path | Source owner verifies coverage and access |
| What was proposed? | Target, field, value and proposal version | Tool input shown in the execution trace | Application owner confirms exact payload and approved field |
| Who approved that proposal? | Authenticated decision bound to target and payload | Review step indication, if actually present | Review-system owner supplies authoritative approval record |
| What executed? | Operation reference and known request outcome | Tool call and returned result | Integration owner distinguishes requested, denied, failed and executed stages |
| What actually changed? | Authoritative readback or required final-result evidence | Reported success can guide investigation | Business-system owner verifies saved outcome |
| Who can inspect the records? | Access tests for trace, source and exported evidence | Visible sharing options, where available | Information owner approves audience and restrictions |
| How long does evidence remain useful? | Owner-approved handling rules and actual retention/export behaviour | Available history may provide part of the record | Respective storage owners verify preservation and deletion paths |
Fictional gap example: the fixture trace shows a requested delivery-address update and a tool result labelled success. The separate approval record cannot be resolved, and the fixture has no authoritative readback yet. The checklist marks approval evidence and outcome verification as gaps. It does not conclude that Make lacks those capabilities; it records what this fixture has not established.
For each requirement, record workflow version, evidence reference, observed status, verification method, reviewer, limitation, repair owner and closure condition. Keep necessary source content in its restricted store rather than copying full customer messages into a general evidence export.
Acceptance fixtures: a normal approved and verified action; missing approval; altered payload after approval; denied tool request; uncertain write response; duplicate action attempt; and an expired or inaccessible source link. A completed evidence pack must reconstruct each observed outcome without inventing authority or hiding uncertainty.
The checklist is accepted when the required evidence is verified or its unresolved gap is explicitly owned. A visually complete path does not close a missing decision record or unverified business outcome.
Verify exact decisions rather than general oversight
An approval should bind to the specific target and payload presented for review. A manager's general instruction to handle the queue does not necessarily authorise every possible record change. The organisation defines that authority, and the trusted application or review system records the applicable decision.
If a value changes after approval, flag the mismatch before execution. The trace can help locate the change, but the implementation must enforce the actual approval rule. A reviewer should not have to infer that the latest visible input is the one previously accepted.
Also distinguish a denied action from a completed one. A path reaching a tool node can still be blocked or fail. The evidence pack should preserve the actual result and the relevant operation reference rather than compress all paths into an action happened summary.
Review access and provider handling separately
Where the workflow uses OpenAI, its data-controls guide distinguishes abuse-monitoring logs and application state with endpoint-specific conditions. Those records are separate from Make's trace and your own evidence store. The guide does not determine Make retention or certify the complete workflow's handling. Source: OpenAI data controls
Map each provider, source store, execution record, export and backup that the proposed evidence process uses. The information owner decides necessary content and handling requirements. Verify current settings in the actual systems rather than assuming that a provider control deletes every local trace copy.
An audit export can expose more than the normal dashboard. Check source text, identifiers, error details and attachment labels in the exact exported format. Preserve useful references while controlling access to any underlying private material.
Work through normal, missing and duplicate actions
In a hypothetical normal case, the trace identifies the tool request, the trusted review system supplies the exact approval and readback confirms the resulting field. The reviewer can follow the linked records and explain the observed outcome without relying solely on the panel's narrative.
In a missing-evidence case, the approval reference is unavailable. The pack keeps that gap open and names the repair owner. It does not ask the model to reconstruct an approval from conversation or label the update authorised because a senior person's name appeared.
In a duplicate case, two requests refer to one verified proposal. The application reconciles the existing operation and the evidence pack records the repeated request without implying two executed changes. If the first outcome is uncertain, verification comes before any repeat action.
FAQ about Make traces and audit needs
Is the Reasoning Panel enough for every audit?
Compare it with the actual evidence requirements and verified account behaviour. This checklist addresses one business workflow, not a universal regulatory acceptance standard.
Does a tool result saying success prove the record changed correctly?
It is one piece of evidence. Use the authoritative verification required by the business process and compare the saved result with the approved payload.
Should a missing feature be marked as an audit gap immediately?
Distinguish an unverified capability from a demonstrated missing record. Inspect the actual environment, then record the evidence status and closure requirement accurately.
If your business needs help defining this process, explore Workflow automation, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.