Building AI Agents That Run for Seven Days: Five Production Design Patterns

You spend weeks perfecting prompt engineering, fine‑tuning tool calls, and reducing response latency. Then your agent needs to stay alive for five days. Suddenly, those weeks don’t matter as much.

Real production workflows — processing thousands of insurance claims, running week‑long sales sequences, reconciling financial data across systems — don’t fit inside a single conversation turn. They take days, not seconds.

The moment you start building these long‑running agents, you hit a wall. Most agent architectures are stateless. They reconstruct context from a database on every interaction. And in doing so, they lose the reasoning chain, the soft signals, and the confidence gradients that made the agent’s previous decisions make sense.

At Cloud Next 26, Google Cloud announced that Agent Runtime now supports long‑running agents that maintain state for up to seven days. Below are five essential design patterns for building long‑running agents on Agent Runtime. These are the patterns that separate production systems from demos.

Pattern 1: Checkpoint‑and‑Resume

The most common failure mode in multi‑day workflows is context loss. Imagine your agent processes 200 documents over four hours, then hits an error on document 201. Without checkpointing, you restart from scratch.

Long‑running agents on Agent Runtime maintain persistent execution state inside a secure cloud sandbox. The agent has full access to bash commands and a sandboxed file system. That means you can write intermediate results to disk, keep processing logs, and recover from failures.

Key mindset: Treat your agent like a long‑running server process, not a request handler. The same way you build a data pipeline that processes millions of records: checkpoint progress, handle partial failures, ensure idempotency.

Here is how you structure a document‑processing agent that checkpoints after every batch, using the Google Agent Development Kit:

from google.adk import Agent, ToolContext

class DocumentProcessor(Agent):
    """Processes large document sets with checkpoint‑and‑resume."""

    async def process_batch(self, docs: list, ctx: ToolContext):
        checkpoint = self.load_checkpoint()  # Resume from last position
        start_idx = checkpoint.get("last_processed", 0)

        for i, doc in enumerate(docs[start_idx:], start=start_idx):
            result = await self.classify_and_extract(doc)
            self.results.append(result)

            # Checkpoint every 50 documents
            if (i + 1) % 50 == 0:
                self.save_checkpoint({
                    "last_processed": i + 1,
                    "partial_results": self.results,
                    "timestamp": datetime.now().isoformat()
                })

        return self.compile_final_report()

Notice the checkpoint granularity: not after every document (wasteful), not only at the end (risky). Fifty documents per batch balances durability against overhead. Your specific number depends on how expensive each unit of work is.

Common questions:

• What information should a checkpoint store?
  At minimum: the last processed position, partial results, and a timestamp. If your workflow has branches or state machines, also store the current step.

• How do you handle already‑successful items when resuming?
  Design for idempotency. Even if a few documents are processed twice after a resume, the final result should be the same as if they were processed once. Typically this is done by recording unique document IDs.

Pattern 2: Delegated Approval (Human‑in‑the‑Loop)

Every framework advertises human‑in‑the‑loop.

But in practice, most implementations work like this: serialise state to JSON, send a webhook, and hope someone checks it. Problems compound quickly. JSON serialisation loses implicit reasoning context. Notifications compete with dozens of other alerts. When the human responds hours later, the agent has to deserialise, re‑establish context, and hope nothing changed.

Long‑running agents handle this differently. When the agent hits an approval gate, it pauses in place. The full execution state stays intact: reasoning chain, working memory, tool call history, pending action.

The critical detail: hours 8 through 32 are dead time for the agent but active time for the human. The agent consumes zero compute while paused. Sub‑second cold starts mean zero latency penalty when it resumes.

Mission Control provides the inbox that makes this manageable at scale. Notifications are categorised into “Needs your input,” “Errors,” and “Completed.” If you are managing twenty long‑running agents, you don’t have to hunt through Slack channels to figure out which ones need attention.

Common questions:

• When the human responds, how does the agent know where to continue?
  The agent does not “reload” state — it resumes from where it paused. It remembers what it was doing, what reasoning it had already done, and what information it was waiting for.

• What happens if the approval is rejected?
  That depends on your business logic. Typically the agent logs the reason, reports back to a coordinator, and follows an alternative path (skip the step or terminate the workflow).

Pattern 3: Memory‑Layered Context

A seven‑day agent needs more than session state. It needs to remember things from previous sessions, user preferences from weeks ago, and organisational context that no single conversation could contain.

That is where Memory Bank and Memory Profiles work together.

Memory Bank (now generally available) dynamically generates and curates memories from conversations, organised by topic. Memory Profiles add low‑latency access to specific, high‑accuracy details. Think of Memory Bank as long‑term memory and Memory Profiles as working memory.

But here is a problem most developers don’t anticipate until production: memory drift.

Your agent’s behaviour is shaped not only by its code and prompts, but also by accumulated experience. If an agent “learns” from a few atypical interactions that a procedural shortcut is acceptable, it might start applying that shortcut broadly. And if multiple agents read and write to shared memory pools, data leakage between distinct workflows becomes a real risk.

You cannot let agents write to a vector database unchecked. You need to govern them the same way you govern microservices. That is where Agent Identity, Agent Registry, and Agent Gateway come in. They bring standard infrastructure concepts into the agent lifecycle:

For example, if an agent tries to write personally identifiable information (PII) into its long‑term Memory Bank, the Gateway blocks the transaction.

Build auditing into your memory layer from day one. The question is not just “what are my agents doing?” It is “what are my agents remembering, and how is that changing their behaviour?”

Common questions:

• What is the difference between Memory Bank and Memory Profiles?
  Memory Bank is long‑term, dynamic, and topic‑based — good for “what communication style does this user usually prefer?” Memory Profiles are short‑term, high‑precision, and low‑latency — good for “the current ticket priority is P1.” They work together.

• If multiple agents share the same Memory Bank, how do you prevent data mixing?
  Through Agent Identity and Agent Gateway. Each agent has its own identity, and the Gateway checks whether that identity has permission to read/write a given Memory Bank. Different workflows use different Memory Banks, or use namespacing inside the same Bank.

Pattern 4: Ambient Processing

Not every long‑running agent interacts with humans. Some are ambient. They watch for events, process data streams, and take action in the background without any user prompting.

Batch and event‑driven agents connect directly to BigQuery tables and Pub/Sub streams.

Here is a concrete example: a content‑moderation agent that processes user‑generated content as it arrives.

This agent runs for days. It does not wait for someone to ask it to moderate content. It processes events as they arrive, maintains its own state about trends and patterns, and escalates only when necessary.

The important architectural decision here ties back to the governance layer from Pattern 3.

Do not hardcode content policies into the agent. Define them in Agent Gateway, and the agent enforces them at runtime. When policies change, you update Gateway once and every ambient agent picks up the new rules. The agent’s identity (from Agent Identity) determines which policies apply to it, and the Registry tracks which version of the agent is running against which policy set.

This separation matters because ambient agents run unsupervised for long stretches. If you hardcode policies, every policy change requires redeploying every agent. If you externalise policies through the Gateway, you update once and the fleet adapts.

Common questions:

• How does an ambient agent know when to “wake up” and work?
  It does not need to wake up. It continuously subscribes to an event stream (e.g. a Pub/Sub topic). When a new event arrives, the agent is automatically triggered. Agent Runtime handles the mapping from events to agent instances.

• How does this kind of agent report errors?
  Through the same Gateway and Registry. Errors are recorded in Mission Control under the “Errors” category, where operations staff can review them. You can also configure alerting rules, for example “if this agent fails more than 10% of events in the last hour, send an alert.”

Pattern 5: Fleet Orchestration

The final pattern is about managing multiple long‑running agents as a coordinated fleet. In production, you rarely have a single agent working alone. You usually have a coordinator agent that delegates sub‑tasks to specialist agents, each running independently for different durations.

Consider a sales prospecting sequence:

Each specialist has its own Agent Identity (so it can access only the tools and memory it needs), its own policy enforcement through Agent Gateway (so the Outreach Agent cannot access financial data meant for the Scoring Agent), and its own entry in the Agent Registry (so you can track versions and execution state across the fleet).

The coordinator maintains global state and handles handoffs between specialists. This is the same coordinator/worker pattern used in distributed systems for decades. What is new is that ADK natively supports this with graph‑based workflows that let you define coordination logic declaratively.

The operational advantage of treating each specialist as an independent unit is that you can update them independently too.

If your Scoring Agent’s ranking logic needs improvement, you deploy the new version, monitor its performance through Agent Observability, and promote it only when the results hold up. And because each agent runs in its own container (with Bring Your Own Container support for your existing CI/CD and security requirements), a bad deployment in one specialist never cascades to the others.

Common questions:

• Doesn’t the coordinator become a single point of failure?
  The coordinator can also use checkpointing to make its own state recoverable. In addition, you can run multiple coordinator instances (active‑standby or load‑balanced) through Agent Registry. The coordinator is lightweight because it only handles task distribution and state tracking, not heavy computation.

• How do you debug a workflow that spans multiple specialists?
  Mission Control provides an end‑to‑end execution trace for the whole fleet. You can see when the coordinator gave which task to which specialist, what result came back, and any errors. This end‑to‑end observability is key for production deployments.

How to Choose the Right Pattern

These patterns compose. A compliance system might use:

• Checkpoint‑and‑Resume for document processing
• Delegated Approval for review gates
• Memory‑Layered Context for cross‑session knowledge
• Fleet Orchestration to coordinate specialists

The key question: what is the longest uninterrupted unit of work your agent needs to perform?

Frequently Asked Questions (FAQ)

How does the cost of long‑running agents compare to stateless agents?
Long‑running agents consume almost no compute while paused (e.g. waiting for human approval). Agent Runtime’s sub‑second cold start means you don’t pay for idle time. Costs are incurred only when the agent actually executes code, calls tools, or performs inference. In fact, long‑running patterns can be more cost‑efficient than repeatedly rebuilding context from scratch.

Is the 7‑day state retention a hard limit? Can I extend it?
The document states that Agent Runtime currently supports up to 7 days. If you need longer cycles, the typical pattern is to persist the final state to external storage and then start a new agent instance that loads that state. For most business scenarios (claims processing, sales sequences, reconciliation), 7 days is sufficient.

What if Agent Runtime itself restarts while my agent is running?
That is exactly what the checkpoint pattern is for. The agent’s state is persisted, and after a restart Agent Runtime can resume from the last checkpoint. It works the same way you use a database to save progress in a data‑processing job.

Can I use my existing CI/CD pipeline and container infrastructure?
Yes. The document mentions “Bring Your Own Container” support. You can use your own container images, your own CI/CD pipelines, and your own security scanning tools, as long as they meet the Agent Runtime interface specifications.

Do these patterns only work on Google Cloud?
The document focuses on Google Cloud’s Agent Runtime, ADK, and Mission Control. However, the patterns themselves (checkpointing, approval, layered memory, ambient processing, fleet orchestration) are general architectural ideas. You can implement them on other platforms or with self‑built systems.

Where can I start experimenting?
Long‑running agents are available today on the Gemini Enterprise Agent Platform. Build with ADK, deploy on Agent Runtime, monitor via Mission Control. The combination of 7‑day persistence, human‑in‑the‑loop approvals, and long‑term memory is what turns an agent from a chatbot into an autonomous worker.

Summary

Building AI agents that run for days is not about patching “stateless” architectures. It requires a different design mindset:

• Treat your agent like a server process, not a request handler (Checkpoint pattern)
• Let humans and agents work at their own best times (Delegated approval pattern)
• Separate long‑term memory from working memory, and govern writes (Layered memory pattern)
• Let agents run autonomously in the background, with externalised policies (Ambient processing pattern)
• Manage your agents like a microservices fleet (Fleet orchestration pattern)

These patterns are not for show. They solve real production problems: context loss, approval waiting, memory drift, policy‑change costs, and the need for isolation and observability when multiple agents collaborate.

Now go build agents that can truly work for you — for days at a time.