Possible to deploy ADK workflow agent on a schedual/job? e..g run twise a day

[Allena101]

I am trying to figure out if it is possible to deploy and agent workflow (e.g. sequential workflow) that runs at specific times.

The use case would be a workflow that processes some data and emails.

I do understand that in most use cases with ADK you are not interested in this since the Agent is interacting with the user through prompt requests.

In all the tutorial i have found the Agent is deployed and running in "stand by" , i think as a rest API but i might be using the terminology wrong.

So does anyone know if its possible to run an ADK agent as a scheduled/job? Also can it be done using Vertex AI (which i am trying to learn right now together with ADK)

If there exists a text or video tutorial then that would be terrific! Since ADK is so new, there are not that many tutorials out there yet.

[dexhunter]

In all the tutorial i have found the Agent is deployed and running in "stand by"

You can run it as a job instead. The Python entry point creates a session, gives Runner a fixed start message, reads the events until the workflow is finished, and exits. It doesn't need an interactive user or a web server.

For your Google Cloud setup, put that script and the agent in a Cloud Run Job. Have Cloud Scheduler start it twice a day. The job can still call Gemini through Vertex AI; give its service account access to the required model and data services.

Google's scheduling guide covers setting up the trigger. Since the workflow sends emails, check your sent-email record before resending on a retry.

[jayblast-spec]

Yes. Running it as a Cloud Run Job on a Cloud Scheduler trigger is the right shape. @dexhunter 's answer gets you most of the way there, but "check your sent-email record before resending" needs one correction: check-then-send has a race condition unless the check and the claim happen atomically.

Two failure modes will bite you in production.

Cloud Scheduler retries a job trigger on certain non-2xx responses or timeouts. If your job already started sending emails when the triggering request times out, Scheduler fires a second execution for the same tick. A "query sent-log, skip if found" check at the top of the script doesn't stop two executions from racing through that check at nearly the same moment. Both pass the check before either writes a "sent" record.

Cloud Run Jobs has no overlap guard either. If a run takes longer than the interval between ticks (a slow API call, a big batch, a cold start), the next scheduled execution starts while the previous one is still running. Now two executions are processing overlapping data at the same time.

Fix it with an atomic claim write before you send anything. Use an insert with a unique constraint, a Firestore transaction, or a conditional put, keyed on something stable like schedule_tick_timestamp:recipient_id. Attempt the write first. Send the email only if the write succeeds. If the write fails because the key exists, another execution already claimed it, so skip. If the write itself is ambiguous, a timeout or unknown result, don't send. Fail closed and force a manual check instead of risking a duplicate.

Scheduler doesn't give you exactly-once delivery. An atomic claim write does.