Production agents are not prompts with permissions. They are distributed systems with identities, tools, state, policy, cost and failure modes.
Google Cloud’s July checklist for the “agentic enterprise” is useful less as a product announcement than as evidence of how quickly the engineering question has changed. The conversation is no longer simply Which model should we use? It is Who is allowed to build agents, what may they access, how do they retain context, how are actions evaluated, and who owns the failure when an automated step goes wrong?
Why this matters
A model can produce an impressive answer in a demo. A production agent must survive ambiguity, partial outages, stale data, policy changes, malicious input, cost spikes and a user who changes their mind halfway through a task.
That difference turns an AI feature into an operating system problem. The agent needs an identity. Its tools need scopes. Long-running work needs durable state. Every consequential action needs a policy, an evidence trail and a defined route to human review.
The questions behind the questions
Google’s list spans build, scale, optimization and governance. Four themes deserve particular attention.
1. Build for a specific operating boundary
Start with one agent and a narrow mandate. “Help with procurement” is not a production specification. “Collect the documents required to onboard a supplier, validate mandatory fields, flag sanctions-screening exceptions and prepare the record for approval” is much closer.
A narrow mandate makes the tool set, evaluation suite, permissions and owner legible. Multi-agent architecture should appear because the workflow requires specialization—not because an architecture diagram looks more advanced with six circles.
2. Treat connectivity as governed capability
MCP, APIs and connectors make enterprise systems available to models. Availability is not authorization. A useful design distinguishes between discovery, read, propose and execute permissions. The same agent may be allowed to retrieve an invoice, draft a correction and request approval, while being prohibited from posting the change itself.
Agent identity also matters. Acting as the user, under a delegated identity, or through a service identity creates different audit, revocation and segregation-of-duties implications.
3. Make time and state explicit
Many valuable workflows are not chat turns. A claim may wait two days for a document. A supplier onboarding may pause for legal review. A maintenance workflow may resume after an event from an ERP.
Durable state, idempotent tool calls, checkpoint-and-resume behaviour and explicit timeout rules are therefore core design choices. Memory should not become an undefined bucket of conversational history. It should be separated into task state, approved organisational knowledge, user preferences and records that must never persist.
4. Govern the execution loop, not just the output
Output filters are insufficient when an agent can take action. The control surface must cover intent, tool selection, arguments, target systems, result verification and escalation.
This is where deterministic software returns to the centre of the architecture. Policies, schemas, budgets, rate limits, approval gates and rollback logic should sit outside the model’s probabilistic reasoning wherever possible. Evaluations then test the complete trace: did the system reach the right outcome, use the right tools, respect policy and stop at the correct boundary?
A practical production gate
Before authorising a pilot to touch a live system, leadership should be able to answer:
- What exact business outcome and acceptance threshold define success?
- Which identity does the agent use, and who can revoke it?
- Which tools can it discover, read from and write to?
- What data is retained, where, and for how long?
- Which actions require human approval?
- How are prompt injection, data exfiltration and unsafe code execution contained?
- How are latency, quality, cost and anomalous behaviour monitored?
- What happens when a model, connector or downstream system fails?
- Who owns the agent after launch?
- Can the organisation replace a model or vendor without rebuilding the workflow?
An inability to answer does not mean the project should stop. It means the work is still a prototype.
The Lexdatum view
The durable unit of enterprise AI is not the prompt. It is the controlled execution trace: goal, context, tools, permissions, actions, evidence, checks and ownership.
Organisations that standardise those primitives early can build many agents without creating many incompatible risk models. Those that optimise only for demo velocity will eventually spend more time reconciling identities, connectors and controls than building useful automation.
The fastest responsible route to production is therefore often narrower than expected: one meaningful workflow, one accountable owner, one measurable outcome and one architecture that can be extended once it has earned trust.
Sources
- Google Cloud — 20 questions for the Agentic Enterprise (and how Agent Platform can help) (2026-07-07)
Research note: This analysis is based on public information available on 31 August 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported metrics are identified as such. This is not legal, security or investment advice.