TL;DR
- Choose Cloud Run Jobs, Amazon ECS scheduled tasks or Azure Container Apps Jobs when your team can package and operate the agent as a cloud workload.
- Choose Modal when a Python-oriented managed execution model and simple scheduling fit the build.
- Choose Grok Bot when a persistent managed agent environment and application use are the requirement rather than hosting your own container.
- Scheduling is one part of production. State, secrets, logs, idempotency and recovery determine whether the agent is dependable.
Contents
- Quick comparison
- What always-on should mean
- Cloud Run Jobs: best for containerised tasks on Google Cloud
- Amazon ECS scheduled tasks: best for an AWS environment
- Azure Container Apps Jobs: best for Azure-centred finite work
- Modal: best for Python-oriented managed execution
- Grok Bot: best for a persistent managed agent environment
- State, secrets, logs and recovery
- FAQ: running AI agents in the cloud
Quick comparison
| Option | Best fit | Execution model |
|---|---|---|
| Google Cloud Run Jobs | Container jobs on Google Cloud | One-off, scheduled or workflow-triggered tasks that exit |
| Amazon ECS with EventBridge Scheduler | Container tasks in an AWS operating environment | Scheduled ECS tasks with AWS permissions and monitoring |
| Azure Container Apps Jobs | Azure teams needing manual, scheduled or event-driven jobs | Finite container executions |
| Modal | Python teams wanting managed functions and cron scheduling | Deployed functions with platform scheduling |
| Grok Bot | Users wanting a persistent managed agent and computer | Named Bots, routines, connectors and a shared account computer |
The first four primarily run code you own. Grok Bot is a managed agent product with a different control and persistence model. Compare the operating job, not just the word “agent.”
What always-on should mean
Most GTM agents do not need to consume compute continuously. They need to be available when a schedule or event starts work, preserve necessary state outside the process, and report whether the job completed.
A daily account-research job can start, process its queue, store outputs and exit. A reply handler may need an event-driven service. A persistent application session may favour a managed agent environment. Choose the runtime from the workload rather than leaving a process alive merely to call it always-on.
Define the completion boundary. If a job enriches a record and drafts a message, state whether success requires both results, and what should happen when the second step fails.
Cloud Run Jobs: best for containerised tasks on Google Cloud
Cloud Run Jobs executes container tasks to completion rather than serving requests continuously. Google documents one-off, scheduled and workflow execution, logs, configurable retries and task timeouts.
It is a strong fit when the agent can be packaged as a container and its state lives in an external store. Cloud Scheduler can initiate recurring execution, while service accounts control access to other Google Cloud resources.
Cost: model the CPU, memory and execution duration, plus scheduler, storage, networking, model and external-tool charges. Check current regional rates for the planned resource size.
Tradeoff: the platform runs the container; your team owns application-level recovery. A retry must not duplicate a CRM update, message or purchase.
Amazon ECS scheduled tasks: best for an AWS environment
Amazon ECS tasks can run on a schedule through EventBridge Scheduler. This suits teams already operating containers, identity and observability in AWS.
Define the task role narrowly and store secrets in the appropriate managed service. EventBridge starts the work, but the application still needs to write a durable status and surface partial failure.
Cost: include the selected ECS capacity such as Fargate, logging, data transfer, storage, model calls and external APIs. A schedule itself is rarely the dominant cost of an AI workload.
Tradeoff: AWS offers many composable services, which can produce a robust system or unnecessary complexity. Use only the queueing, orchestration and storage components the recovery design requires.
Azure Container Apps Jobs: best for Azure-centred finite work
Azure Container Apps Jobs supports manual, scheduled and event-driven execution of finite container workloads. It is relevant when the team already uses Azure identity, networking and monitoring.
Scheduled jobs use cron-style expressions; event-driven jobs can respond to supported scaling events. Keep the business queue outside the container so an interrupted instance does not erase its remaining work.
Cost: calculate consumed compute and the accompanying logs, storage, models and external services under the intended region and workload.
Tradeoff: an event trigger indicates that work is available, not that the business action succeeded. Store per-item outcomes and make retries safe.
Modal: best for Python-oriented managed execution
Modal lets Python teams deploy functions and schedule them, including cron-based execution. It can reduce infrastructure work for agents whose code and dependencies fit its model.
Keep business state in a durable store and declare the resources the function actually needs. A scheduled function should emit a run identifier and a concise completion record that an operator can inspect.
Cost: use the current platform rates for compute and other consumed resources, then add model and data-provider usage. Serverless execution can lower idle cost without making a long model-driven task cheap.
Tradeoff: platform convenience comes with its own deployment and debugging model. Ensure the team can reproduce a failed input and retrieve enough logs to resolve it.
Grok Bot: best for a persistent managed agent environment
Grok Bot provides named Bots with memory and a persistent cloud computer. It can use connectors and computer use, run routines and continue while the user's device is closed.
This is different from deploying your own agent container. The product manages the environment and interaction model, while the user supplies access and instructions. Bots under the same account share the computer, files, browser sessions and application logins.
Cost: access follows eligible plans and weekly usage; confirm the current plan matrix and capacity for the workload.
Tradeoff: the shared computer requires deliberate account and client boundaries. It also offers less infrastructure-level control than a cloud workload you build and operate yourself.
State, secrets, logs and recovery
Store business state outside the running process. Each item should have an identifier, status and enough information to resume. Do not treat a long model conversation as the only record of which accounts were already processed.
Keep secrets in the platform's secret-management route and grant only the permissions the job needs. Separate environments and customers where access or data boundaries require it.
Log decisions at the right level: source record, tools called, resulting business action and error. Avoid storing unnecessary sensitive prompt content merely because verbose logs are available.
Make writes idempotent. A retry should update or recognise the same intended record rather than creating a second task or sending another message. Send failures to an owned recovery queue instead of retrying forever.
FAQ: running AI agents in the cloud
Does a scheduled agent need a permanent server?
No. Many jobs can start on a schedule, complete and exit. Persistent services are useful for workloads that genuinely wait for requests or maintain live connections.
Which platform is cheapest?
It depends on resources, duration, model calls, data services and operational needs. Compare the same representative job.
Where should agent memory live?
Durable business state should live in an appropriate external store. Runtime memory or a conversation alone is not a sufficient recovery record.
Are retries always safe?
No. Design external writes to recognise repeated execution and avoid duplicated actions.
When is a managed agent environment preferable?
When the team values an integrated persistent agent and application environment more than direct control of its own runtime and deployment.
The agent still needs an execution workflow. Our comparison of n8n vs zapier vs make covers the adjacent options.
Sources and comparison method
The recommendations are editorial assessments of workflow fit, not results from a comparative product test. Supporting product references are linked below; prices and plan entitlements should be confirmed for the configuration being purchased.
- Google Cloud Run Jobs
- Schedule Cloud Run Jobs
- Amazon ECS scheduled tasks
- Azure Container Apps Jobs
- Modal cron scheduling
- Grok Bot overview
Work with Forma Nôrden
Forma Nôrden designs cloud-run revenue workflows with explicit state, permissions and recovery. We help teams choose the smallest dependable execution model for the business process. Explore how we work.
For enquiries about this article: partnerships@formanorden.com
