AI Agent Production Readiness Checklist (Google Cloud)

An AI agent is ready for real users when it keeps working through restarts, slow dependencies and traffic spikes, when you can reconstruct what it did after the fact, and when its cost, access and data location were decided on purpose rather than by default. This checklist has thirty checks in six groups. Each one says why it matters and how to verify it, so a team can run through it against its own agent in an afternoon.

It is written for agents built with Google ADK or a Gemini function-calling loop and deployed on Cloud Run, but most checks apply to any agent that calls tools. The code behind several of them is in the article on deploying multi-agent systems with Google ADK. A check you cannot verify is a check you have not passed: treat "we think so" as a fail.

Does the agent keep its state across restarts?

Cloud Run instances are replaced on every deployment and during scaling, so anything held in process memory is eventually lost. These checks make sure a restart is invisible to the user and a duplicate request is harmless.

Check	Why it matters	How to verify
Session state lives outside process memory	An in-memory session store loses every active conversation on restart	Restart the service in the middle of a conversation; the next turn continues with full context
The session store has backups and a retention period	Sessions are user data, not scratch space	Restore a backup into a test instance; the retention period is written down
Tools with side effects are idempotent	Retries and duplicate requests must not charge, book or email twice	Send the same write request twice; exactly one effect results
Shared resources are protected against concurrent claims	Two users can request the same slot at the same moment, and check-then-insert is a race condition	Fire two parallel requests for the same resource; one succeeds. The booking article uses a PostgreSQL advisory lock for this
Conversation history is bounded	Unbounded history raises cost on every turn and eventually exceeds the context window	Run a 50-turn session; the behaviour at the limit is defined and tested

Do tool calls fail safely?

Most production incidents with agents start in a tool, not in the model. A tool that hangs, errors quietly or returns stale data lets the agent report success on something that did not happen.

Check	Why it matters	How to verify
Every external call has a timeout	A hanging dependency stalls the whole conversation	Block a dependency in a test; the agent answers within the timeout and says what failed
Retries use backoff and only wrap safe operations	Retrying a non-idempotent write can repeat its effect	Review each tool and mark it read or write; only reads retry by default
A circuit breaker protects flaky dependencies	One slow API should not stall every conversation at once	Force repeated failures; calls fail fast, then recover when the dependency does
Tool errors reach the agent as structured errors	A swallowed exception turns into a confident wrong answer	Make a tool return an error; the agent tells the user it could not complete the task
There is a hard cap on tool iterations per request	A runaway loop burns tokens and time	Set the cap (the booking agent stops after five iterations) and test what the user sees when it is hit

Can you reconstruct what the agent did?

The question that decides whether you can operate an agent is "why did it do that on Tuesday at 14:32?" If the answer needs a guess, the agent is not observable.

Check	Why it matters	How to verify
Every model call and tool call is logged with session, agent, inputs and outputs	Without it a wrong answer cannot be traced to a step	Pick a past conversation and rebuild its steps from the logs alone
Requests are traced across the agent and its tools	You need to see which sub-agent produced a wrong result	Open the trace of one request in Cloud Trace and follow it end to end
Log retention and access are decided	Logs hold user data and must not be kept or read by default	A written retention period and a named list of readers
A set of real conversations is replayed before each release	Behaviour regressions are invisible until a user hits them	Run the set on a release candidate and compare answers with the last release
Alerts exist for error rate, latency and spend	You should hear about a failure from monitoring, not from a user	Trigger each alert on purpose once

Is the cost of running the agent predictable?

Agent cost is mostly tokens, and tokens grow with conversation length and with the size of the tool results you put back into the context. Cost that nobody measures is cost that surprises.

Check	Why it matters	How to verify
Token usage is measured per session and per tool	You cannot control what you do not measure	A dashboard shows input and output tokens per session
History is windowed or summarised	Each turn re-sends the history, so cost per turn grows with session length	Compare input tokens at turn 1 and turn 20 of the same session
Repeated tool results and large static prompts are cached	Paying twice for identical work	The cache hit rate is visible and non-zero
Cloud Run concurrency and maximum instances are set	They cap spend and downstream load during a spike	Load test up to the cap and watch what happens beyond it
Budget alerts exist on the project and the model API	A runaway loop or a leaked key shows up in hours, not at month end	The alert threshold is set and the recipient is a real person

Are access and secrets handled properly?

An agent turns model output into actions, so treat the model like any other untrusted caller: it should only be able to do what the user is allowed to do, and the check belongs in the tool, not in the prompt.

Check	Why it matters	How to verify
Each service runs under its own least-privilege service account	It limits what a compromised component can reach	List the roles of every service account; none is broader than the service needs
Secrets live in Secret Manager, not in code or repository files	Keys committed to a repository are leaked keys	A repository scan is clean, and a key can be rotated without a code change
Internal agent endpoints require IAM authentication	An open endpoint is an open agent	An unauthenticated call is rejected
Tool arguments are validated and model output is treated as untrusted	The model can produce wrong or malicious parameters, including through prompt injection	Send malformed and hostile arguments to each tool; read tools cannot write
Tools enforce which data the current user may see	A prompt instruction is not an access control	Ask for another user's data; the tool refuses, not the prompt

Is EU data handling decided on purpose?

These checks support GDPR and EU AI Act obligations; they do not replace legal advice. The article on EU AI Act and GDPR controls for RAG systems goes through the architecture in more detail.

Check	Why it matters	How to verify
Resource locations are restricted to EU regions by organisation policy	Residency by accident is residency you cannot prove	Try to create a resource outside the allowed regions; the policy refuses
Every store of personal data is inventoried: prompts, logs, vector index, caches	Erasure has to reach every copy	A written list of stores, each with an owner and a retention period
The erasure path is tested, including the vector index	GDPR Article 17 applies to data embedded in an index too	Erase a test user and confirm nothing remains in the index, caches or logs
Users are told they are talking to an AI system	The AI Act requires this for systems that interact directly with people (Article 50)	The interface shows the disclosure before the first answer
The legal basis and the AI Act classification of the use case are confirmed with counsel	Architecture cannot decide either	A dated written note from your legal or data protection team

How should you use the checklist?

Score each check as pass, fail or unknown, and treat unknown as fail. Fix the failures that can lose data, money or customers first: state, side effects and access. Then close the observability and cost gaps, because they decide how quickly you can find and contain the next problem. Re-run the list whenever the agent gains a new tool or a new data source.

If you would rather have someone else run these checks against your agent and give you a ranked plan with estimates, that is what an agent production review is.

AI Agent Production Readiness Checklist for Google Cloud