How To See What Your AI Agent Is Doing Without Reading A Log File

Logs and traces tell you why something broke. Run history and digests tell you that it broke. Approval queues stop it breaking. Most owners are sold the first and need the last three. That ordering is the whole page. The first group is diagnostic and arrives after the damage, which is fine, because diagnosis is genuinely a technical job and you should not be doing it. The second group is detection, and detection is the part that has to reach you rather than sit in a tool waiting to be opened. The third group is prevention, and it is the only one that changes the outcome rather than describing it. Owners are sold diagnostics because diagnostics are what the tooling market builds. Tracing products are impressive in a demo and they are the artefact a builder is proud of. Nobody demos an email that says "nothing needs you today", even though that email is worth more to the person paying for the agent than any trace view will ever be. The practical test: if the agent quietly stopped working this morning, which of the six artefacts would tell you before a customer did? If the honest answer is none of them, you have observability for the builder and none for the business.

All three major automation platforms ship run history as standard, and it is more capable than most owners realise. Everything in this section comes from the vendors' own documentation as published in July 2026. Zapier documents 11 distinct run statuses: successful, errored, filtered, handled error, on hold, needs review, running, safely halted, delayed, scheduled and skipped. The interesting one is "needs review", which Zapier's documentation attributes to Zapier Agents and Human in the Loop. That matters beyond Zapier, because it proves an approval queue is a first-class platform concept rather than something a builder invented for your job. Per run, Zapier's history shows which step broke, the input and output data that flowed through, the final status, and the settings used. Make's scenario history holds run records with nine fields, including date and time, status, duration, operations consumed, size of data transferred and a replay option. Alongside the runs, Make keeps a change log of user actions: scheduling changes, edits and activation. That change log is a partial audit trail of what humans did to the automation, and Zapier's documented status list has no equivalent. Make also documents CSV export of history, and full-text search restricted to Pro plans and above. n8n's executions view lists workflow name, status, start time and duration, with six documented statuses: new, running, waiting, succeeded, cancelled and failed. Two details from Zapier's documentation are worth pinning up. A run can be caused by more than one status but only one is displayed. And Zapier automatically pauses a Zap that errors every single time it runs, which means a broken automation can go quiet in a way that looks exactly like nothing is wrong.

n8n's documented default execution retention is 336 hours, which is 14 days. That is the single most important number on this page, because most Australian business records must be kept for five years. Three defaults in n8n's own configuration reference control this, and all three are worth knowing precisely. `EXECUTIONS_DATA_MAX_AGE` defaults to 336, described by n8n as the execution age in hours before it is deleted. `EXECUTIONS_DATA_PRUNE_MAX_COUNT` defaults to 10000, described as the maximum number of executions to keep in the database, with the oldest deleted first and 0 meaning no limit. `EXECUTIONS_DATA_HARD_DELETE_BUFFER` defaults to 1, being how old in hours the finished execution data has to be before it is hard-deleted. Executions in the new, running or waiting states are never pruned. Annotated executions, meaning ones that have been tagged or rated, are also never pruned, and that is the documented escape hatch if you need specific runs kept. Now the argument. The Australian Taxation Office requires most business records to be kept for five years, running from when the record was prepared or obtained or the transaction completed, whichever is later. If an agent's runs form part of a business record, because the agent sent the quote, issued the invoice or recorded the customer's instruction, then a 14-day default retention is between one and two orders of magnitude short of the legal requirement. Two things to be clear about. Those figures are n8n's published defaults, not a description of your setup, and any competent deployment may well have changed them, so check your own instance's configuration before drawing conclusions about your own exposure. And on the ATO side, the ATO's own record-keeping page blocks automated access, so the five year rule here comes from consistent secondary Australian sources and should be confirmed with the ATO or your accountant. Penalty unit values change, so we are not publishing a dollar figure for the penalty. The conclusion holds either way: if the record matters, design the record. Do not rely on a platform's history tab that was built for debugging, not for retention.

Three of the most obvious questions an owner would ask have no documented answer we could verify, so ask them directly rather than assume. This is stated plainly because a page that pretends to know is worse than useless. We could not confirm whether Zapier, Make or n8n send error notification emails by default. Not one of the three. This is the first thing a non-technical owner assumes is happening, and it is precisely the thing that may not be. If nobody has explicitly configured an alert, the safe assumption is that a failure will sit in a history tab nobody opens. We could not confirm Zapier's history retention period. It is not stated on the documentation pages we reached. We could not confirm Make's per-plan retention in days either. Make's documentation says the number of days depends on your pricing plan and points to the pricing page. A commonly repeated figure of 30 days circulates but we could not verify it against Make's own pricing page, so treat it as unconfirmed. Four questions to put to whoever built or sold you the agent, in writing: 1. When a run fails, who is told, through what channel, and how quickly? 2. How long is run history kept on this plan, in days? 3. If a client disputes something in nine months, can we still show what was sent? 4. What happens if the alerting itself stops working? A builder who cannot answer those four has not finished the job. If you would rather have someone else ask them, a workflow audit is the short version of exactly that conversation.

The agent framework tooling has genuinely good observability, and almost none of it is built for the person paying for the agent. That gap is the real problem, not a shortage of features. Tools such as LangSmith and Langfuse offer tracing, latency percentiles, token cost breakdowns and human-in-the-loop approvals. Technically that is strong work. LangSmith documents dashboards covering token usage, P50 and P99 latency, error rates and cost, plus alerting and approval workflows. Langfuse, which is open source, offers typed observations, agent graph visualisation in beta and tool-call analytics. We could not confirm pricing, retention periods or which features are gated by tier for either product, so we are not stating any. Here is the honest reading. A trace view showing P50 and P99 latency next to a token cost breakdown is precisely the thing a business owner will never open. Not because they could not understand it, but because it does not answer any question they have. Their question is "did the quotes go out, and is anything sitting there waiting for me". So the gap in the market is not observability. It is owner-facing observability. Everything an engineer needs to debug an agent exists and is well built. The thin translation layer between that machinery and a person running a business is the part that almost always has to be built deliberately, per business, by somebody who has thought about who reads it and when.

Five patterns cover almost every practical option, and each has a failure mode that shows up within weeks. The patterns below are a synthesis of what the platforms already implement plus general operational practice. We searched for practitioner research on agent-visibility design for non-technical business owners and found no survey or study, so nothing here is presented as "what practitioners recommend". | Pattern | Good for | How it fails | |---|---|---| | Daily or weekly digest email | Reaching someone who will never open a tool | Becomes wallpaper, or arrives unread and manufactures false confidence | | Chat channel the agent narrates into | Ambient team awareness, searchable, cheap to build | Muted within a week if it posts every success, which hides the exceptions too | | Approval queue | Stopping consequential mistakes before they happen | Rubber-stamping, or a bottleneck until someone turns the gate off | | Simple dashboard | Answering "is it running" on demand, drill-down detail | Pull rather than push, so nobody opens it | | Exception-only alerting | Best signal to noise, scales as agents multiply | Silence is ambiguous: all fine, or everything including the alerting is dead | Notice that four of the five fail through human behaviour rather than technical fault. The system keeps working exactly as built while the oversight quietly evaporates. That is why the pattern you choose matters less than whether you have designed for the moment attention runs out.

The most dangerous outcome of any visibility pattern is not that it breaks. It is that it keeps arriving, nobody reads it, and everyone now believes there is oversight when there is none. A digest becomes wallpaper within a fortnight if it is always the same and always fine. Worse, the digest itself can break silently, and once it does, silence reads as all clear. Two mitigations do most of the work. Put a number in it the owner actually cares about commercially, such as enquiries handled, quotes sent or dollars, rather than a technical status. And include an explicit "nothing needs you" line, so a missing email is conspicuous rather than indistinguishable from a quiet week. A chat channel that posts every successful run gets muted within a week, and once it is muted the exceptions are invisible too. The fix is two channels: one for exceptions that pings, one for the firehose that does not. An approval queue where approvals are frequent and almost always fine turns the human into a clicking machine, and the check becomes theatre. It can also become a bottleneck until somebody sensibly turns the gate off to get work done. Gate on consequence, not on everything. Money going out, messages to clients, anything irreversible. Not internal note-taking. A dashboard nobody opens has exactly the observability value of no dashboard. Treat it as the drill-down destination from a link in the digest, not as the primary channel. Exception-only alerting has the best signal to noise of the five and one severe flaw. Silence is ambiguous. It needs a heartbeat, a scheduled message that proves the alerting path itself is alive, before you can trust quiet as good news.

Alert fatigue is not a soft concern, it is one of the better-measured phenomena in operational safety, and clinical medicine is where the numbers live. The figures below come from the US Agency for Healthcare Research and Quality's Making Healthcare Safer III alarm fatigue chapter, which cites the underlying studies. Studies show the proportion of clinical alarms that are false ranges from 72 per cent to 99 per cent. One academic medical centre recorded more than 59,000 alarms in 12 days. A single medical unit recorded 16,953 alarms over 18 days. Between 2005 and 2008, 566 patient deaths related to monitoring device alarms were reported to the US Food and Drug Administration's MAUDE system. The Joint Commission required hospitals to make alarms a priority in 2014 and to have alarm management policies and staff education in place by 2016. ECRI ranked alarm hazards the top health technology hazard in 2012. The most encouraging figure in that chapter is the one showing the rate is a design outcome rather than a fact of nature. An intervention by Dandoy and colleagues reduced false alarms from 95 per cent to 50 per cent, and cut median cardiac alarms per monitored patient day from 180 to 40. The transferable mechanism has two halves, and the second is the one that happens in a business. Alert fatigue leads to desensitisation, so people stop reacting. It also leads to people actively reconfiguring the system to shut it up. That is exactly what an owner does when they mute the chat channel or filter the digest into a folder they never open. A second, independent context confirms the pattern outside healthcare. IDC, working with FireEye in 2021, surveyed 350 respondents comprising 300 US-based security operations centres and 50 managed security service providers. More than a third of IT security managers and analysts said they ignore threat alerts when the queue is full. False positive rates were 45 per cent at the security operations centres and 53 per cent at the managed providers. If trained professionals ignore alerts at that rate, a business owner with a phone full of notifications will too.

There is no credible measurement of how long a broken automation keeps running before anyone notices. We searched specifically for it and found only vendor assertion with no data behind it. As far as we can tell, this genuinely does not exist as measured research. That absence is worth sitting with, because the claim is repeated constantly. Automation vendors assert that silent failures are common and expensive, and they are almost certainly right, but nobody appears to have put a number on time-to-detection for a broken workflow. There is no equivalent of the alarm fatigue literature. If someone quotes you a figure for how long automations run broken, ask where it came from. The closest defensible proxy comes from a different field, and it is an analogy rather than a claim about automation. IBM's Cost of a Data Breach Report 2025 puts the global mean time to identify and contain a breach at 241 days, being 158 days to identify and 83 days to contain, which IBM describes as the lowest in nine years. Note what the identify half of that means. Organisations with security teams, monitoring tools and regulatory pressure take an average of 158 days to notice that someone is in their systems. An agent that quietly stopped sending quotes three weeks ago is not going to announce itself either. The mechanism is the same: nothing is on fire, no error is thrown, and the absence of activity looks identical to a quiet period. This is the argument for a heartbeat and for a digest with a commercial number in it. Both convert "nothing happened" from invisible into obvious.

A log is for diagnosis. An audit trail is for accountability. They look similar and they serve completely different purposes, which is why treating a platform's history tab as an audit trail goes wrong slowly and then all at once. Three separate reasons an audit trail earns its keep, and they are worth separating because they have different retention needs. Dispute resolution. A client says you never sent that quote, or that you quoted a different price. Without a run record you have your word against theirs. With one you have a timestamped record of exactly what was sent, to whom, and when. This is the reason owners find most immediately persuasive, and it is the one that most often surfaces months later, well outside a 14-day retention window. Accountability when the agent is wrong. An agent will eventually send something incorrect. The question that follows is whether a person approved it. An approval record is the difference between a mistake and a governance failure. That is not a technical distinction, it is the difference between explaining an error and explaining why nobody was watching. Regulatory record keeping. Covered above: most business records need to be kept for five years under ATO rules, per consistent secondary Australian sources that should be confirmed with the ATO or an accountant, and platform defaults are nowhere near that. One thing we deliberately are not claiming. We did not verify how Australian Privacy Principle 1 and Australian Privacy Principle 11 obligations bear on audit trails specifically, and we did not verify the Notifiable Data Breaches assessment window. Both come up constantly in content on this topic. Neither is stated here as an obligation, because we have not checked it against the regulator's own guidance.

I am not technical. Which one artefact should I insist on? Run history plus a weekly digest that draws from it. Run history is the only one of the six artefacts a non-technical person can genuinely read, and every major platform provides it. The digest is what gets it in front of you without opening a tool. Add an approval queue for anything that spends money or contacts a client. Will the platform email me when the agent breaks? Do not assume so. We could not confirm that Zapier, Make or n8n send error notification emails by default. Ask your builder to show you the alert firing, not just describe it. Then ask what happens if the alerting path itself fails, because silence from a dead alerting system looks identical to silence from a healthy one. How long does my automation platform keep run history? n8n's documented default is 336 hours, which is 14 days, with a default prune threshold of 10,000 executions. Make says it depends on your plan. Zapier's retention period is not documented on the pages we reached. Check your own configuration rather than trusting a figure from an article, including this one. Is a run history enough to satisfy record keeping obligations? Unlikely on default settings. Most Australian business records must be kept for five years, and default platform retention is measured in days or weeks. If the agent's output forms part of a business record, write those records somewhere you control, such as your CRM, accounting system or a document store, rather than relying on the platform's history. Are approval queues worth the friction? On consequential actions, yes. On everything, no. If approvals are frequent and almost always fine, the person approving becomes a clicking machine and the check stops meaning anything. Gate money going out, messages to clients and anything irreversible. Leave internal note-taking ungated. What about tools like LangSmith and Langfuse? They are good, and they are built for engineers. Tracing, latency percentiles and token cost breakdowns are the right tools for debugging an agent and the wrong tools for reassuring an owner. If your builder uses one, that is a good sign about their process. It is not a substitute for something that answers your questions in your language.