Scheduled agent runs make file ownership a reliability decision
A recurring agent job that reuses its sandbox is not starting from a blank directory. Google’s managed-agent documentation says a scheduled trigger binds an agent, environment, prompt, and cron schedule to a persistent resource; each run reuses the same sandbox, so files persist across executions. It also describes an Environments API for listing, inspecting, and deleting sandbox sessions instead of simply waiting for a seven-day TTL.
That behavior suggests a useful runbook, but not a universal platform contract. Before putting a scheduled worker in production, classify every path it can touch:
- Run-scoped inputs: materialize from a manifest, validate at start, and remove temporary copies at the end.
- Reusable artifacts: keep only outputs with an owner, schema/version, and retention rule. Make the next run read an explicit manifest rather than “whatever is in the directory.”
- Execution state: persist checkpoints separately from generated files, with a clear rule for resuming or abandoning an interrupted run.
- Cleanup: delete expired sessions and transient data deliberately; retain logs and artifacts only for the period needed to debug or audit them.
The key boundary is ownership. A managed sandbox may provide persistence and lifecycle operations; an application that calls a model through an API gateway still owns its scheduler, queue, storage, retries, and cleanup unless its chosen product documentation says otherwise. Model access alone does not prove that managed triggers or an Environments API are available.
A practical acceptance test is to run two identical jobs against a fresh and a reused environment. Record which files are present before startup, which outputs are committed, and what cleanup removes. Fail the deployment if a run can consume an unmanifested predecessor artifact or if deleting an environment leaves production state ambiguous. This keeps reuse useful without turning accidental leftovers into hidden input.