From prototype to production: running AI agents on Cloud Run

Getting an AI agent to work once on your laptop takes an afternoon. Getting it to run every day, unattended, without surprise bills or silent failures, is a different job. This is how we approached that move for Agent Studio, and why we chose Google Cloud Run.

Why serverless containers suit agents

Most agents are bursty. They wake up on a schedule or an event, do a few minutes of work (mostly waiting on model APIs), then sit idle for hours. Paying for an always-on server for that pattern is wasteful.

Cloud Run fits this shape well:

• Scale to zero. When no agent is working, nothing is running and nothing is billed.
• Containers, not lock-in. Each agent is a standard container image. It runs the same locally, in CI and in production, and could move to Kubernetes or another platform later.
• Independent scaling. The planning agent and the distribution agents scale separately, so a busy publishing day for one channel doesn’t slow the others.

One service per agent

We deploy each agent as its own service. That keeps deployments small, lets us roll back one agent without touching the rest, and gives each one its own logs, permissions and limits. It also mirrors the team design: one agent, one job, one service.

Triggers: schedules and events

Agents start in two ways:

• On a schedule, for recurring work such as the weekly planning run or daily source checks, using a scheduler that calls the service.
• On an event, for reactive work such as “a new article was published”, which is what wakes the distribution agents.

Separating the two keeps the system predictable: scheduled jobs set the rhythm, events handle everything that follows from them.

Secrets and permissions

Agents touch real accounts: a CMS, an email platform, social networks, a video channel. Our rules:

• No keys in code or images. API keys and tokens live in a managed secret store and are injected at runtime.
• Least privilege. Each service gets its own identity with access only to what that agent needs.
• Drafts by default. Where a platform supports it, agents create drafts rather than publishing, so a person approves the final step.

Controlling cost

Model calls, not compute, are usually the biggest line on the bill. What helps:

• set hard limits on instances and request timeouts per service, so a bug can’t fan out;
• cap tokens per task and log usage per agent, so you know which one is expensive;
• cache research results that several agents reuse instead of fetching them again;
• use smaller, cheaper models for formatting and classification, and save larger models for writing and reasoning.

Making failures visible

An unattended agent that fails silently is worse than no agent. Every run should log what it was asked to do, what it produced and how long it took. Failed runs should retry a limited number of times, then alert a person rather than retrying forever.

The checklist we use before calling an agent “production”

• It runs from a container image built in CI, not from a laptop.
• It has its own service identity and only the secrets it needs.
• It has instance, timeout and token limits.
• It logs every run and alerts on repeated failure.
• Anything public-facing goes through a human approval step.

Build on it

If you’re a SaaS founder moving AI features from prototype to production, this is the kind of groundwork iMelonArt Ventures helps portfolio companies put in place. Pitch us what you’re building.