A long-running AI agent should be governed like a persistent production process, not treated like a chatbot left open in a browser. Google Cloud now supports agents that can operate continuously for up to seven days. That durability can cover valuable asynchronous work, but it also gives an agent more time to encounter changed data, repeat a failing tool call, accumulate cost, cross a permission boundary, or produce an output that no longer matches the original request.
Before a multi-day agent starts, leaders should approve a written run contract: one bounded workflow, named owners, stopping conditions, checkpoints, a maximum duration, a dedicated least-privilege identity, allowlisted tools and data, approval gates, per-run cost and retry ceilings, protected state, observable progress, a tested recovery path, and an acceptance test that keeps downstream systems from trusting the final output automatically. Seven days is a platform capability, not a default grant of seven days of authority.
What Google Cloud announced on July 29
Google Cloud's July 29 Gemini Enterprise Agent Platform announcement says Agent Runtime can run complex agents and reasoning tasks continuously for up to seven days. Google gives a week-long sales sequence and a multi-stage onboarding process as examples of work that can proceed asynchronously without losing context.
The same announcement places that runtime beside Memory Bank, Agent Identity, Agent Gateway, Agent Registry, Agent Observability, and Agent Evaluation. That combination matters. A seven-day loop without identity, state, policy enforcement, inventory, telemetry, or quality review would only make an uncontrolled process more durable. The platform capabilities are building blocks; the business still has to decide which workflow deserves them and what evidence makes a run acceptable.
Google's earlier Agent Executor announcement explains the durability underneath this model. Event logs and snapshots support resumption after outages or human approvals. Secure sandboxes isolate components. A single-writer model protects shared session state. Clients can reconnect and recover missed responses, while checkpoints can branch a workflow for evaluation. These are useful runtime properties. They do not define the business owner, authorized action, deadline, cost ceiling, or final approval.
Why duration changes the control problem
A short agent interaction usually fails in front of the user. A multi-day workflow can fail while everyone is doing something else. The source record may change after the agent reads it. A token can retain access after the employee who initiated the run changes roles. A retry loop can call the same paid API hundreds of times. A delayed approval can leave a process waiting with sensitive context. A recovered session can repeat a side effect unless the workflow knows which actions already completed.
Time also expands the number of decisions. A seven-day workflow is rarely one model call. It is a sequence of reads, tool calls, waits, messages, branches, checkpoints, and writes. Each transition needs a rule. The right governance unit is therefore not the prompt. It is the complete run: the outcome, identity, state, action history, budget, deadline, reviewer, and disposition of the output.
The ten-control run contract
Use this matrix as the release gate for one long-running workflow. Every row needs an accountable owner and evidence from a negative-path test. A diagram or policy statement is not proof that a stop, revocation, limit, or recovery path actually works.
| Control | Run rule | Launch evidence |
|---|---|---|
| Bounded outcome | One workflow, named inputs, accepted output, and explicit exclusions | Run contract and test cases |
| Owner and clock | Business owner, operator, checkpoints, stop rules, and maximum duration | RACI, schedule, and timeout test |
| Dedicated identity | One least-privilege identity per agent; no shared human credential | Permission map and revocation test |
| Tools and data | Allowlisted tools, approved records, field limits, and network boundaries | Tool registry and source inventory |
| Approval gates | Pause before sends, writes, purchases, deletes, or regulated decisions | Action matrix and approver test |
| Cost and retries | Per-run token, tool, retry, and spend ceilings with no infinite loops | Budget counters and forced-limit test |
| State and memory | Persist only necessary state, scope it, encrypt it, and expire it | State schema, retention rule, and deletion test |
| Observability | Track progress, errors, approvals, model calls, and every tool action | Dashboard, alerts, and trace sample |
| Recovery | Resume safely, avoid duplicate effects, compensate, and escalate | Checkpoint replay and recovery drill |
| Output acceptance | Hold final work until sources, quality, policy, and freshness pass | Acceptance rubric and human sign-off |
1. Start with one bounded workflow
Choose a recurring outcome with stable inputs, a clear finish, and a result that a reviewer can evaluate. Define what starts the run, which records it may use, what artifact it must produce, and what is explicitly outside scope. A request such as 'manage onboarding' is too broad. A request to assemble a draft onboarding packet from five approved systems, flag missing fields, and hold it for an HR reviewer is testable.
Write acceptance criteria before writing agent instructions. Specify required fields, approved sources, freshness limits, prohibited conclusions, expected exceptions, and the downstream state after success. If the organization cannot tell whether the result is correct, it is not ready to delegate the workflow for days.
2. Define owners, checkpoints, stop conditions, and maximum time
Name a business owner for the outcome, a technical owner for the runtime, a data owner for each source, an approver for high-impact actions, and an incident owner with authority to stop the run. The person who requested the agent should not be the only person who can explain or contain it. Ownership must survive nights, weekends, role changes, and leave.
Set checkpoints around risk and elapsed time. A run might report after every stage and pause at least once per business day. Define the maximum wall-clock duration independently of Google's seven-day ceiling. A three-day workflow should expire after three days, not continue because the runtime can. Stop on an expired deadline, revoked identity, missing approval, source change, policy violation, repeated error, unexpected tool, cost limit, or output that cannot be verified.
3. Give the agent a dedicated least-privilege identity
Do not let a persistent agent borrow a human administrator session or share one service account with unrelated agents. Google's current Agent Identity guidance describes a unique identity for each agent, certificate-bound credentials, IAM allow and deny policies, access revocation, and audit records that can attribute an action to both the agent and the user when it acts on someone's behalf.
Grant the identity only the resources and actions required by the bounded workflow. Separate read, draft, write, send, publish, purchase, delete, and administer. Test a denied record, a revoked role, an expired user delegation, and an attempt to use the credential outside its intended runtime. Re-run that permission test whenever the agent, tool, source, or role model changes.
4. Constrain tools, data, and destinations
Build an allowlist for every tool, operation, source, field, endpoint, and output location. An agent that needs to read approved contracts does not need unrestricted file search. An onboarding agent that drafts an account list does not need authority to create accounts. A research agent does not need a general-purpose shell merely because the framework offers one.
Treat tool output and retrieved content as untrusted input. Documents, webpages, messages, and records can contain stale facts or malicious instructions. Validate tool parameters at the boundary, enforce schemas, restrict network destinations, and prevent one tool's output from silently expanding the authority of the next. Complete a data and AI readiness audit before persistent access makes existing oversharing easier to automate.
5. Require approval before high-impact actions
Pause before the agent sends an external communication, changes a system of record, creates or revokes access, commits code, publishes content, purchases anything, moves money, deletes data, or makes a regulated or employment decision. The approval request should show the proposed action, affected records, source evidence, expected consequence, reversibility, run identity, and remaining budget.
Approval must be enforced by the tool boundary, not requested only in a system prompt. Google notes that durable execution can resume after a human-in-the-loop confirmation. Use that pause as a state transition: pending approval, approved by a named person, denied, or expired. If approval expires, the agent should stop or re-plan from current data rather than continue from an old decision.
6. Cap spend, tool calls, and retries
Give every run a budget measured in model tokens or calls, paid tool invocations, total tool calls, retry count, and wall-clock time. Use exponential backoff only for errors that are safe to retry, add jitter where appropriate, and set a hard attempt limit. Never retry an ambiguous write automatically; first determine whether the side effect already happened.
Google Cloud's current spend cap budget guidance lists Gemini Enterprise Agent Platform among eligible services, but the capability is in preview and its boundary is broader than one agent run. Caps are scoped to a project and eligible service, use gross estimated cost, allow in-flight requests to finish, and do not stop ongoing fixed-cost resources. Use a platform cap as a backstop. Enforce the tighter per-run budget inside the workflow, and alert an owner before the agent exhausts it.
7. Preserve state without preserving everything
Separate execution state from long-term memory. Execution state records what stage the run reached, which inputs and versions it used, which side effects completed, which approvals remain open, and how to resume safely. Long-term memory carries selected facts into future sessions. The first supports recovery. The second changes what the agent may remember later and needs a separate business purpose.
Google's Memory Bank documentation warns that sensitive or personal information may still be stored and that customers should not rely on filtering alone. Persist the minimum necessary fields, scope memory to the right tenant and user, encrypt it, set retention and deletion rules, and keep secrets and raw credentials out. Prefer references to governed source records over copying their full contents into an agent checkpoint.
8. Monitor progress, errors, and every tool call
A green container is not evidence that a multi-day workflow is healthy. Track the current stage, time since meaningful progress, checkpoint age, queue time, model calls, token use, tool calls by type, tool errors, retries, approvals waiting, denied actions, policy events, budget remaining, and estimated completion. Alert on stalled progress, repeated calls, unusual destinations, rising error rate, missing checkpoints, and any attempt to use an unapproved tool.
Google's Agent Runtime monitoring guidance provides built-in request, latency, CPU, and memory metrics, plus custom metrics and alerts. Its example creates a tool-call counter from logs. Add business-level telemetry because infrastructure metrics cannot tell you whether the agent is working on the right account or using current evidence. Log identifiers, decisions, and hashes where possible; do not create a second sensitive-data store by copying every prompt and response into telemetry.
9. Design recovery and escalation before the first run
Make tool actions idempotent where possible so replaying a checkpoint does not send the same email or create the same record twice. Give each side effect a unique operation ID and record its confirmed result. For reversible actions, define the compensating step. For irreversible actions, require approval and stronger preconditions before execution.
Test process restart, network loss, expired approval, unavailable tool, partial write, corrupted checkpoint, stale source, revoked permission, and a stop issued during an active call. The recovery plan should say whether to resume, roll back, start a clean run, quarantine the output, or transfer the case to a person. Pair it with a tested AI kill switch and a recovery architecture that keeps backups outside the agent's blast radius.
10. Verify the output before another system accepts it
Finish in a pending state, not an automatically trusted state. Validate required fields, source provenance, record versions, calculations, policy rules, and freshness. Compare the result to the original objective and list unresolved exceptions. A business reviewer should accept, reject, or return the output with a reason that becomes part of the run record.
Downstream systems should verify the agent identity, run ID, workflow version, approval evidence, output schema, and acceptance status before processing anything. Do not let a fluent report, a completed status, or a valid API response stand in for business acceptance. The last control in a seven-day workflow is the first control in the system that consumes its result.
An illustrative three-day workflow
Consider a mid-sized company preparing a software-renewal recommendation. This is an illustrative scenario, not a client result. The agent has three days to assemble current license counts, usage, support tickets, contract terms, and approved alternatives. Its only output is a draft decision packet. It cannot contact the vendor, cancel service, modify a contract, or create a purchase order.
The sourcing owner approves the run contract. IT owns the connected systems. Finance owns the cost evidence. The agent uses one read-only identity and five allowlisted queries. It checkpoints after source collection, discrepancy review, comparison, and packet assembly. It pauses when contract dates conflict, a record is older than the freshness limit, or a source owner has not approved access.
The run stops after three days, after two failures of the same safe read, after any attempted write, or when its model-and-tool budget is consumed. Every tool call and source version is logged. If the runtime restarts, operation IDs prevent duplicate collection jobs. The final packet remains pending until IT, finance, and the business owner verify the evidence and approve the recommendation. Only then may procurement use it as an input to its own controlled process.
This scenario is intentionally less ambitious than a fully autonomous renewal agent. That is the point. A bounded agent can prove durable execution, identity, state, checkpoints, costs, recovery, and output quality without also testing external authority. Expand one dimension only after the current run produces dependable evidence.
A practical launch sequence
During design, select one workflow and write the run contract, action matrix, source inventory, state schema, budget, acceptance rubric, and incident path. During testing, force every stop condition, denial, timeout, retry ceiling, approval expiry, and recovery path. Run with synthetic or sanitized data before approved production records.
During the pilot, keep actions read-only or draft-only, review every checkpoint, and compare the output with the prior process. Measure accepted work, elapsed time, correction rate, exception rate, tool failures, reviewer effort, and cost per accepted run. Do not measure success by how long the agent stayed active.
At the expansion gate, decide whether to increase volume, duration, data scope, tool access, or action authority. Change only one material risk dimension at a time, then repeat the tests. Update or retire this guidance if Google changes the seven-day runtime limit, Agent Identity behavior, Memory Bank safeguards, observability controls, or spend-cap availability.
Long-running agents turn persistence into a business capability. They also turn time, state, identity, and recovery into governance responsibilities. The safest organizations will not ask whether an agent can run for seven days. They will ask what the run is allowed to accomplish, what makes it stop, and what evidence a person must accept before its work moves forward.
