Which Model Ran Last Night's Job? Scheduled AI Agents and the Missing Run Receipt
Which Model Ran Last Night's Job? Scheduled AI Agents and the Missing Run Receipt Your scheduled agent ran at 3 a.m. The output arrived on time, but it reads a little different from yesterday: a sentence is shorter, a summary skips a detail it usually catches, a customer reply sounds a touch more formal. Nothing failed, and the run log says success. So which model wrote it? That question sounds simple. For a scheduled agent, it often has no answer: the run happened while everyone was asleep,
Which Model Ran Last Night's Job? Scheduled AI Agents and the Missing Run Receipt
Your scheduled agent ran at 3 a.m. The output arrived on time, but it reads a little different from yesterday: a sentence is shorter, a summary skips a detail it usually catches, a customer reply sounds a touch more formal. Nothing failed, and the run log says success.
So which model wrote it?
That question sounds simple. For a scheduled agent, it often has no answer: the run happened while everyone was asleep, the model is not written down anywhere, and by the time someone asks, the next run has overwritten whatever trace there was. The job ran. The receipt is missing.
Why the model matters more than the run log admits
A scheduled agent is not one fixed program. It is a workflow that calls a model, and the model can change without the workflow changing. A platform update swaps a default. A provider retires a version and routes the old name to a new one. A teammate tests a different model and forgets to switch it back. A fallback kicks in because the first choice was busy, and the run completes on a cheaper model nobody selected.
Each change is invisible in the output. The message still goes out, the report still gets written. What changes is quality, tone, cost, and sometimes accuracy, and the drift shows up as a vague feeling that the agent got worse this week. Without a record of which model ran each job, there is no way to connect the output to the cause. The team rewrites the prompt while the real change was a model swap nobody logged.
Cost is the second reason. Two models can differ by ten times on price for the same job, and a month of quiet overruns adds up before anyone opens the billing page. The invoice shows tokens and totals, not which run burned them. The third reason is accountability: when an agent sends a customer a wrong number or a wrong promise, the first question after the fix is what produced it, and a run without a model record cannot answer.
Why scheduled runs hide the model
The model setting for a scheduled agent lives in more places than most teams expect, and that is where the trace gets lost.
First, the agent's own setting, which the scheduled task inherits. Change the agent's model and every future run changes with it, silently.
Second, step-level overrides. A workflow can call one model for drafting and another for checking, while the run log records only that the steps finished.
Third, the platform default. When no model is pinned, the platform picks one, and platforms change their defaults. A default that pointed at one model in January can point at another by March, and every scheduled run quietly moves with it. The workflow file never changed. The model did.
Fourth, fallback and routing. When the chosen model is unavailable or rate-limited, many platforms fall back to another model so the run completes instead of failing. The run succeeds, the output ships, and the record says nothing about the swap. Some setups also route each request to whichever model fits a budget or latency rule that night, so the model is decided at runtime and exists only in the run itself, if the run wrote it down.
Most run logs record whether the job ran, not how it ran: a timestamp, a status, a duration. The model, the version, the provider, and the cost per run are treated as details the operator does not need, until something looks off.
What a run receipt should contain
A run receipt is a short record attached to every scheduled run, written the moment the run finishes, in the same place every time. It needs five fields.
The model id, exactly as the provider names it, including the version. Not "the default" and not a bare brand name. Two versions with similar names can behave differently.
The provider and the route: which service served the call, and whether it went through the platform's relay, a direct key, or a fallback path.
Whether a fallback or substitution happened, and what the original choice was. This one line turns a mystery into a fact: the run wanted model A, got model B, and here is why.
The token counts and the cost: input tokens, output tokens, and the price for that run. Cost per run is the number that makes model drift visible before the monthly invoice does.
The configuration snapshot: the prompt version, the reasoning setting, and the tool list the run had. A model change and a prompt change at the same time are impossible to separate later unless both are recorded.
With those five fields, the question "which model ran last night's job" becomes a lookup, not a search through dashboards.
How to get a receipt today
Start by making the run say its own model. Add a step at the end of the workflow that writes the model id, the version, and the token counts into the run log or a shared note the team reads. Some platforms already expose the model in run metadata; the step just copies it somewhere durable.
Next, pin the model where it matters. A scheduled job that handles customers, money, or anything public should name its model explicitly instead of floating on a platform default. Pinning turns a silent drift into a visible error or a deliberate decision. Low-stakes runs can keep the default.
Finally, keep the receipts where the agent can read them. A receipt locked in a platform log that the agent never sees is only useful to a human doing forensics. A receipt the agent can read on its next run becomes memory: last night's job ran on this model, cost this much, and produced this outcome. The next run starts from that fact instead of from zero.
The memory layer behind the receipt
A run receipt is only useful if it survives until it is needed, and if the next run can find it without someone digging. That is where a shared memory layer earns its place. Vilix AI is a cloud-hosted memory layer that gives every agent the same memory, everywhere, over MCP. The model that ran last night's job, the cost, the fallback, the outcome: all of it can live in one memory every agent and every tool reads. Because Vilix AI stores full conversation history, not just facts, the receipt keeps its context: what the run was asked to do, what it produced, and what happened next.
Getting started takes no infrastructure. Vilix AI is cloud-hosted, so there is nothing to install and nothing to maintain. The free plan is free forever, and a 7-day Pro trial needs no credit card. Everything stored can be exported or deleted at any time.
Give each run a receipt, keep the receipts where every run can read them, and the next time the output looks different, the answer will be one lookup away.
Free forever, no credit card.