A command that evaluates “the last run” sounds like a small convenience. In CrewAI’s tracing change merged September 21, making that convenience reliable required separate answers to three questions: did the whole trace arrive, which run finished later, and can another writer change the answer before it is saved?
The work replaces an exposed execution identifier with a project-local .crewai/last_run.json record. The companion CLI change reads that record for crewai eval. A wrong pointer can therefore send the evaluator to a different run from the one the developer meant to inspect.
One file, three promises
First, eligibility. The trace exporter records a run only after export has succeeded, and refuses to record a partially failed export. The related ephemeral-buffer path also excludes truncated traces. A successful upload of whatever remained is insufficient if the grader cannot see the whole run.
Second, ordering. Imagine run A finishes at 10:01 and run B at 10:02. B’s writer reaches the file first; A’s arrives later. Blindly replacing the file would label A the latest. The new writer compares completion times and preserves an existing record when it proves that a different run finished later.
Third, publication of that decision. Each writer gets its own temporary file. Where file locking works, a lock covers the read, comparison and replacement together. Atomic replacement prevents a half-written JSON file; the larger locked region prevents a complete but stale decision from overwriting a newer one. Those are different guarantees.
The review changed what “last” could promise
The public PR identifies Claude Code use, and the commit history contains agent co-authorship. That establishes reported agent assistance, not autonomous authorship or a measured productivity gain. The interesting receipt is the revision trail: an initial atomic write gained ordering logic, an overstrict timestamp rule caused timing-dependent test failures, and the read–compare–replace sequence then gained a lock.
The final rule is deliberately modest. The same run may refresh its record. Missing completion times and millisecond ties allow the incoming write. On platforms without flock, or filesystems that refuse a lock, the writer proceeds without serialization. A convenience record is not allowed to fail the agent run; it is also not a universal concurrency guarantee.
The tests expose another useful correction. A test for projects using platform credentials originally replaced the very recording guard it was supposed to exercise. The revised case uses the real guard. Otherwise a green test could have concealed a rule that wrongly disabled local recording for those projects.
A transferable skill: test the meaning before the write
When building a “latest” pointer, write the ordering rule before choosing the storage primitive. Test an older completion arriving after a newer one, ties, missing timestamps, simultaneous writers and a refused lock. Separately test whether the underlying artifact is complete enough to publish. A perfectly atomic pointer to an incomplete trace is still the wrong answer.
We loaded the inspected writer in isolation and confirmed three cases: an older late writer preserved the newer run; equal completion times allowed replacement; disabling file locking still allowed a write. This was a local source probe, not CrewAI’s full test suite or a live AMP evaluation. We inspected exporter eligibility and upstream concurrency tests without independently exercising that whole path.
The result is a small, explicit contract other builders can reuse. Keep the useful shortcut, state where its ordering guarantee ends, and make the failure cheap. The next test is whether evaluation reaches the intended complete run under real overlapping workloads—not merely whether the record remains valid JSON.