Building Stateful AI Automations with Firestore and Apps Script

Today’s AI automations are evolving into autonomous agents that operate over several days, breaking traditional synchronous execution models. Discover how to overcome the architectural hurdles of persistent memory to build complex, long-running AI workflows.

The Challenge of Multi Day AI Interactions

As we push the boundaries of what AI can achieve within Automatically create new folders in Google Drive, generate templates in new folders, fill out text automatically in new files, and save info in Google Sheets, we are rapidly moving away from simple, single-turn prompts. Today’s advanced AI automations act more like autonomous agents: they research, draft, wait for human feedback, revise, and execute. This evolution introduces a significant architectural hurdle. A workflow that requires an AI to analyze an incoming email on Monday, wait for a user to approve a drafted response on Tuesday, and automatically send a follow-up on Thursday fundamentally breaks the traditional synchronous execution model.

When building these multi-day, multi-step interactions, developers can no longer rely on variables held in active memory. The system must become “stateful”—capable of remembering the exact context, history, and pending actions of an AI agent across vast stretches of time.

Overcoming Apps Script Execution Timeouts

AI Powered Cover Letter Automation Engine is an incredibly powerful serverless platform for Workspace automation, but it was designed primarily for quick, synchronous tasks. The most notorious constraint developers face is the strict execution time limit—typically capped at 6 minutes per execution for standard accounts (and up to 30 minutes for certain AC2F Streamline Your Google Drive Workflow enterprise accounts).

When integrating Large Language Models (LLMs) and AI workflows, hitting this timeout wall is almost inevitable. AI automations often involve:

• High API Latency: Waiting for external LLM endpoints (like Building Self Correcting Agentic Workflows with Vertex AI or OpenAI) to process massive context windows.

• Chained Inferences: Running multiple sequential prompts where the output of one step feeds into the next (e.g., extract data, then summarize, then format as JSON).

• Rate Limiting and Backoffs: Implementing exponential backoff strategies to handle API rate limits gracefully.

If a script attempts to handle a complex AI workflow in a single run, it risks timing out mid-process. When an Apps Script times out, it fails ungracefully. Any data held in memory is instantly destroyed, the progress is lost, and the automation must start over from scratch—costing you both compute time and API credits. To build reliable AI systems, we must architect our way out of the single-execution trap.

The Need for Stop and Start Task Flows

To survive execution limits and accommodate human-in-the-loop delays, our AI automations require a robust “Stop and Start” task flow. This means decoupling the trigger of an event from the completion of the workflow.

Instead of a single, monolithic script that runs from start to finish, the architecture must be broken down into discrete, independent steps. When a script finishes a specific chunk of work—or senses it is approaching the 6-minute timeout—it needs to gracefully pause. To do this successfully, the system must:

1. Persist the State: Serialize the AI’s current memory, conversation history, and variable states, and write them to a persistent database.

2. Queue the Next Action: Register what the next step should be (e.g., “awaiting human approval” or “continue processing chunk 4 of 10”).

3. Resume with Context: Allow a subsequent trigger (like a time-driven trigger or a webhook) to wake the script up, read the saved state from the database, and resume the workflow exactly where it left off, as if no time had passed.

This stop-and-start orchestration transforms Genesis Engine AI Powered Content to Video Production Pipeline from a simple task runner into a resilient, long-running state machine. However, achieving this requires a fast, scalable, and easily accessible database to act as the “long-term memory” for your scripts. This is exactly where Firestore enters the equation as the perfect companion to Apps Script.

Understanding the State Store Pattern

When building intelligent automations, developers quickly run into a fundamental limitation: Large Language Models (LLMs) and serverless compute environments are inherently stateless. Every time an Apps Script function is triggered or an API call is made to an AI model, the system wakes up with amnesia. It has no memory of previous interactions, ongoing tasks, or user context.

The State Store Pattern is the architectural solution to this amnesia. It involves externalizing the “memory” of your application into a dedicated, highly available database. By decoupling the state from the compute layer, your AI automations can pause, resume, handle multi-step reasoning, and maintain long-running conversational contexts without losing their train of thought.

Core Principles of State Persistence

To effectively implement a state store for AI-driven workflows, you must adhere to several core engineering principles:

• Decoupling Compute from Memory: Your Apps Script functions should act purely as the execution engine. They retrieve the current state, process the logic (or query the AI), update the state, and spin down. This ensures your automation is resilient to timeouts and execution limits.

• Context Window Management: AI models require historical context to make informed decisions, but you cannot pass infinite data due to token limits. A robust state persistence strategy involves storing the full interaction history while allowing your script to query and retrieve only the most relevant, recent, or summarized context to feed back into the LLM.

• Concurrency and Atomic Updates: In automated environments, multiple events might trigger simultaneously (e.g., a user sending multiple emails or modifying a Google Sheet concurrently). Your state store must support atomic operations and transactional updates to prevent race conditions and ensure data integrity.

• Idempotency: Because network requests can fail or retry, your automation must be able to safely re-execute without causing unintended side effects. By checking the persistent state before executing an action, you ensure that a specific step in an AI workflow is processed exactly once.

Why Firestore is Ideal for Workspace Developers

While Architecting Multi Tenant AI Workflows in Google Apps Script offers built-in storage like PropertiesService or CacheService, these are severely limited in capacity (e.g., 9kB per property value) and lack querying capabilities. When you graduate to building Building Stateful AI Agents with Firestore for Gemini Long Term Memory, Google Cloud Firestore emerges as the undisputed champion for Workspace developers. Here is why:

• Native NoSQL JSON Alignment: AI models communicate natively in JSON, and Apps Script handles JavaScript Objects effortlessly. Firestore’s document-oriented NoSQL structure means you can save complex AI payloads, nested arrays of conversation history, and dynamic metadata directly to the database without writing rigid SQL schemas or complex ORM layers.

• Seamless Ecosystem Authentication: Because Apps Script projects can be directly linked to standard Google Cloud Projects, authenticating with Firestore is virtually frictionless. Using community-vetted libraries (like FirestoreApp) or the native REST API, you can leverage default Google credentials without managing vulnerable API keys.

• Serverless Scalability: Firestore is a fully managed, serverless database. It scales automatically from zero to millions of reads/writes. Whether your Apps Script automation is triggered once a day by a time-driven trigger or hundreds of times a minute by Google Forms submissions, Firestore handles the throughput without any provisioning on your end.

• Real-Time Capabilities and TTL: Firestore supports Time-To-Live (TTL) policies, allowing you to automatically purge stale AI session data or temporary automation states after a set period. This keeps your database lean and reduces storage costs automatically, which is perfect for ephemeral AI chat sessions or temporary workflow locks.

System Architecture and Tech Stack

To build resilient, stateful AI automations, we need an architecture that bridges the gap between serverless execution, persistent data storage, and advanced natural language processing. Standard Google Apps Script is inherently ephemeral; each execution runs in a vacuum without out-of-the-box memory of previous runs. By introducing Google Cloud Firestore and Gemini 2.5 Pro, we transform this stateless environment into a powerful, context-aware automation engine.

The architecture relies on three core pillars:

1. Google Apps Script: Acts as the serverless orchestration layer. It handles triggers (like incoming emails, form submissions, or time-driven events), interacts with Automated Client Onboarding with Google Forms and Google Drive. APIs, and executes the business logic.

2. Google Cloud Firestore: Serves as the high-performance, NoSQL state management layer. It stores session data, execution history, and contextual metadata, allowing the automation to “remember” past interactions.

3. Gemini 2.5 Pro: Functions as the cognitive engine. With its massive context window and advanced reasoning capabilities, it analyzes the current state, processes the input, and determines the next best action.

When an event triggers the Apps Script, the script queries Firestore for the current state of that specific workflow. It then packages this historical context alongside the new input and sends it to Gemini 2.5 Pro. Once Gemini returns its decision or generated content, Apps Script executes the required Workspace actions (e.g., drafting an email, updating a Sheet) and writes the updated state back to Firestore.

Integrating Gemini 2.5 Pro with Apps Script

Integrating Gemini 2.5 Pro into Google Apps Script requires establishing a secure, server-to-server HTTP connection using the native UrlFetchApp service. Because Gemini 2.5 Pro excels at complex, multi-step reasoning, providing it with the right payload is critical.

First, security is paramount. You should never hardcode your Gemini API key directly into your script. Instead, utilize the Apps Script PropertiesService to store the API key securely as a script property:

const API_KEY = PropertiesService.getScriptProperties().getProperty('GEMINI_API_KEY');

const ENDPOINT = `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-pro:generateContent?key=${API_KEY}`;

When constructing the payload, you must combine the new user prompt with the historical state retrieved from Firestore. Gemini 2.5 Pro’s extended context window allows you to pass substantial JSON objects representing the automation’s history directly into the prompt.

Here is an example of how you might structure the request:

function callGeminiWithState(currentState, newPrompt) {

const payload = {

"contents": [

{

"role": "user",

"parts": [

{ "text": `System State: ${JSON.stringify(currentState)}` },

{ "text": `New Input: ${newPrompt}` },

{ "text": "Based on the system state and new input, determine the next action and generate the response." }

]

}

],

"generationConfig": {

"temperature": 0.2, // Low temperature for deterministic automation routing

"responseMimeType": "application/json" // Enforce JSON output for easy parsing

}

};

const options = {

"method": "post",

"contentType": "application/json",

"payload": JSON.stringify(payload),

"muteHttpExceptions": true

};

const response = UrlFetchApp.fetch(ENDPOINT, options);

return JSON.parse(response.getContentText());

}

By enforcing a JSON response (responseMimeType: "application/json"), you ensure that Gemini 2.5 Pro returns structured data that Apps Script can immediately parse and use to update the Firestore database or trigger subsequent Workspace functions.

Designing the Firestore Database Schema

Firestore’s NoSQL document-model is perfectly suited for stateful AI automations because it allows for flexible, schema-less data structures that can evolve as your AI’s context requirements grow. To connect Apps Script to Firestore, you can either use the native Google Cloud REST API with OAuth2 tokens or leverage a community-supported library like FirestoreGoogleAppsScript.

For an AI automation system, the database schema should be designed around “Sessions” or “Workflows.” A highly effective approach is to create a root collection named automation_sessions. Each document within this collection represents a unique, ongoing workflow—keyed by a deterministic ID, such as an email thread ID, a customer ID, or a unique ticket number.

A well-architected Firestore document for stateful AI should look like this:

// Collection: automation_sessions

// Document ID: thread_12345ABC

{

"sessionId": "thread_12345ABC",

"status": "AWAITING_USER_RESPONSE",

"workflowType": "CUSTOMER_SUPPORT_TIER_1",

"createdAt": "2023-10-27T10:00:00Z",

"lastUpdatedAt": "2023-10-27T14:30:00Z",

"contextData": {

"customerName": "Jane Doe",

"issueCategory": "Billing",

"sentimentScore": 0.4

},

"interactionHistory": [

{

"timestamp": "2023-10-27T10:00:00Z",

"actor": "USER",

"message": "I was double charged for my subscription this month."

},

{

"timestamp": "2023-10-27T10:05:00Z",

"actor": "AI_AGENT",

"message": "I apologize for the inconvenience. Let me check your billing history.",

"actionTaken": "QUERY_STRIPE_API"

}

]

}

Key Schema Design Considerations:

• status: This is the most critical field for state management. It tells the Apps Script exactly where the automation left off (e.g., INITIALIZED, AWAITING_APPROVAL, COMPLETED).

• contextData: A nested map containing extracted entities. As Gemini 2.5 Pro processes interactions, it can instruct Apps Script to update this map with new facts (like identifying the issueCategory), preventing the AI from having to re-deduce information in future runs.

• interactionHistory: An array of objects acting as the memory bank. Because Firestore documents have a 1MB size limit, this array is usually more than sufficient for text-based automation histories. If the workflow is exceptionally long-lived, you can implement a rolling window logic in Apps Script to keep only the most recent or most relevant interactions, summarizing older ones using Gemini before saving.

Implementing Session Token Management

Because Google Apps Script executions are inherently stateless—spinning up and spinning down with each trigger or HTTP request—maintaining a continuous, context-aware dialogue with an AI model requires an external state store. Firestore, with its flexible NoSQL document structure and seamless Google Cloud integration, is the perfect backend for this. However, to map an incoming Apps Script request to a specific conversation thread in Firestore, we need a robust session token management system.

By implementing session tokens, we can uniquely identify users, track the lifecycle of a conversation, and prevent context leakage between different executions.

Generating and Validating Session Tokens

The first step in our stateful architecture is handling the session identifier. When a user or system initiates a conversation, the Apps Script webhook or trigger must check for an existing session token. If one does not exist, the script must generate a secure, unique token and initialize a new session document in Firestore. If a token is provided, the script must validate it against Firestore to ensure the session is active and hasn’t expired.

Google Apps Script provides a highly convenient method for generating universally unique identifiers: Utilities.getUuid(). We can use this to generate our tokens.

Here is how you can implement the generation and validation logic in Apps Script:

/**

* Retrieves an existing session or creates a new one in Firestore.

* Note: This assumes the use of a Firestore Apps Script library or a custom REST API wrapper (getFirestoreClient).

*

* @param {string|null} requestToken - The token passed from the client, if any.

* @returns {string} The valid session token.

*/

function getOrCreateSession(requestToken) {

const firestore = getFirestoreClient();

const currentTime = new Date().toISOString();

if (!requestToken) {

// Generate a new session token for a new conversation

const newToken = Utilities.getUuid();

const newSessionData = {

createdAt: currentTime,

lastActive: currentTime,

status: 'ACTIVE'

};

// Create a new document in the 'sessions' collection

firestore.createDocument(`sessions/${newToken}`, newSessionData);

Logger.log(`New session created: ${newToken}`);

return newToken;

} else {

// Validate the provided token

try {

const sessionDoc = firestore.getDocument(`sessions/${requestToken}`);

// Check if document exists and is active

if (!sessionDoc || sessionDoc.fields.status.stringValue !== 'ACTIVE') {

throw new Error("Session is inactive or does not exist.");

}

// Update the lastActive timestamp to keep the session alive

firestore.updateDocument(`sessions/${requestToken}`, {

lastActive: currentTime

}, true);

return requestToken;

} catch (error) {

console.error(`Token validation failed for ${requestToken}:`, error);

throw new Error("Invalid or expired session token.");

}

}

}

This approach ensures that every interaction is authenticated against a known state. You can easily extend this validation logic to include expiration checks (e.g., invalidating tokens where lastActive is older than 24 hours) by utilizing Cloud Tasks or a time-driven Apps Script trigger to sweep stale documents.

Saving and Retrieving Conversation State

Once a session token is validated, it acts as the primary key for our conversation state. Large Language Models (LLMs) like Gemini or OpenAI’s GPT do not inherently remember past prompts; they require the entire conversation history (the “context window”) to be passed with every new request.

Using our validated token, we will query Firestore for the historical array of messages, append the user’s latest input, send the comprehensive payload to the AI, and finally write the AI’s response back to our Firestore document.

Here is the implementation for managing the conversation state:

/**

* Processes a user message, retrieves history, calls the AI, and saves the new state.

*

* @param {string} sessionToken - The validated session UUID.

* @param {string} userMessage - The latest input from the user.

* @returns {string} The AI's response.

*/

function processConversation(sessionToken, userMessage) {

const firestore = getFirestoreClient();

const docPath = `sessions/${sessionToken}/history/messages`;

let conversationHistory = [];

// 1. Retrieve the existing conversation state from Firestore

try {

const historyDoc = firestore.getDocument(docPath);

if (historyDoc && historyDoc.fields.messages) {

// Assuming messages are stored as a serialized JSON string for simplicity

conversationHistory = JSON.parse(historyDoc.fields.messages.stringValue);

}

} catch (e) {

// If the document doesn't exist yet, we proceed with an empty history array

Logger.log(`No previous history found for session ${sessionToken}. Starting fresh.`);

}

// 2. Append the new user message to the history

conversationHistory.push({

role: "user",

content: userMessage

});

// 3. Pass the full context window to the AI Model

// (callAiModel is a placeholder for your specific LLM API integration)

const aiResponseText = callAiModel(conversationHistory);

// 4. Append the AI's response to the history array

conversationHistory.push({

role: "assistant",

content: aiResponseText

});

// 5. Save the updated state back to Firestore

// This overwrites the document with the newly updated array

firestore.createDocument(docPath, {

messages: JSON.stringify(conversationHistory)

});

return aiResponseText;

}

By structuring the state management this way, you decouple the AI processing from the webhook lifecycle. If an Apps Script execution times out or fails, the state in Firestore remains intact up to the last successful interaction. Furthermore, storing the state in a subcollection (sessions/{token}/history/messages) keeps your database organized and allows you to store rich metadata at the root session level without cluttering the message payload.

Building the Stateful Agent Workflow

When developing AI-driven automations in Automated Discount Code Management System, you quickly run into one of Google Apps Script’s most notorious constraints: the 6-minute execution limit (or 30 minutes for Automated Email Journey with Google Sheets and Google Analytics Enterprise accounts). AI workflows—such as chaining large language model (LLM) prompts, processing massive document libraries, or waiting for external API responses—can easily exceed this window.

To build a truly robust AI agent, we must transition from a synchronous, single-run script to a stateful workflow. By leveraging Firestore as our agent’s external memory, we can track the exact progress of a task, pause execution before a timeout occurs, and seamlessly pick up right where we left off.

Handling Execution Interruptions Gracefully

The key to preventing hard crashes and data loss is proactive time management. Instead of letting Apps Script forcefully terminate your function when the clock runs out, your script needs to monitor its own execution time.

A best practice is to set a safe execution threshold—typically around 4.5 to 5 minutes (270,000 to 300,000 milliseconds). Inside your main processing loop, you continuously check the elapsed time. Once the threshold is breached, the script must halt the AI processing, package its current context (such as the last processed index, accumulated LLM responses, or the next step in the prompt chain), and save this “state” to Firestore. Finally, it programmatically creates a time-driven trigger to spin up a new execution.

Here is how you can implement this graceful interruption logic:

function processAIAgentWorkflow() {

const START_TIME = Date.now();

const MAX_EXECUTION_TIME = 4.5  *60*  1000; // 4.5 minutes

const firestore = getFirestore(); // Assume a helper initializes Firestore

// 1. Fetch the current state from Firestore

let stateDoc = firestore.getDocument('agent_states/workflow_123');

let state = stateDoc ? stateDoc.fields : { status: 'PENDING', currentIndex: 0, aiMemory: [] };

if (state.status === 'COMPLETED') return; // Task is already done

const dataset = getLargeDataset(); // The data the AI needs to process

// 2. Begin or resume processing

for (let i = state.currentIndex; i < dataset.length; i++) {

// Check if we are running out of time

if (Date.now() - START_TIME > MAX_EXECUTION_TIME) {

Logger.log(`Approaching timeout at index ${i}. Saving state and scheduling continuation.`);

// Save the exact state to Firestore

firestore.updateDocument('agent_states/workflow_123', {

status: 'IN_PROGRESS',

currentIndex: i,

aiMemory: state.aiMemory

});

// Schedule the script to run again in 1 minute

ScriptApp.newTrigger('processAIAgentWorkflow')

.timeBased()

.after(60 * 1000)

.create();

return; // Exit gracefully

}

// Simulate an AI API call (e.g., summarizing text, extracting entities)

let aiResponse = callExternalLLM(dataset[i], state.aiMemory);

state.aiMemory.push(aiResponse);

}

// If the loop finishes without timing out, mark as completed

firestore.updateDocument('agent_states/workflow_123', {

status: 'COMPLETED',

currentIndex: dataset.length,

aiMemory: state.aiMemory

});

cleanupTriggers('processAIAgentWorkflow');

}

By explicitly managing the timeout, you ensure that your AI agent never loses its train of thought. The Firestore document acts as a highly reliable save point.

Resuming Tasks from the Last Known State

When the programmatic trigger fires a minute later, the script starts a fresh execution environment. However, because our workflow is stateful, the script doesn’t start from scratch. Its very first action is to consult Firestore to rebuild its context.

Resuming tasks requires a few critical architectural considerations:

1. State Hydration: The script must read the Firestore document and map the stored fields back into local variables. If the AI agent was in the middle of a multi-step reasoning chain, the aiMemory array retrieved from Firestore provides the LLM with the historical context it needs to generate the next response without hallucinating or repeating itself.

2. Idempotency: The resumption logic must be idempotent. If a network error occurs right as the state is being saved, the script might re-process a single item. Designing your AI prompts and database writes to handle duplicate processing safely (e.g., using upsert operations) ensures data integrity.

3. Trigger Cleanup: Apps Script has a limit on the number of triggers a user can have. It is absolutely vital that once the workflow finishes—or when resuming—you clean up the old triggers that spawned the current execution.

Let’s look at the cleanup and resumption mechanics that complement our workflow:

function cleanupTriggers(functionName) {

const triggers = ScriptApp.getProjectTriggers();

for (let i = 0; i < triggers.length; i++) {

if (triggers[i].getHandlerFunction() === functionName) {

ScriptApp.deleteTrigger(triggers[i]);

}

}

}

// Example of how the state dictates the next action upon resumption

function routeAgentAction(state) {

switch(state.currentPhase) {

case 'DATA_EXTRACTION':

// Resume extracting data from Drive files

return performExtraction(state);

case 'LLM_SYNTHESIS':

// Resume feeding extracted data to the LLM

return performSynthesis(state);

case 'REPORT_GENERATION':

// Resume building the Google Doc report

return generateReport(state);

default:

throw new Error("Unknown agent phase.");

}

}

In this architecture, Firestore dictates the flow of execution. When the script wakes up, it asks Firestore, “What was I doing, and what do I know so far?” By decoupling the execution environment (Apps Script) from the execution state (Firestore), you transform a simple script into a resilient, long-running Cloud Engineering pipeline capable of handling complex, multi-hour AI automations.

Next Steps for Your Enterprise Architecture

Transitioning from a functional prototype to a robust enterprise architecture requires a strategic shift. While the combination of Firestore and Google Apps Script provides an excellent, lightweight foundation for stateful AI automations, enterprise-grade solutions demand rigorous attention to high availability, security, and seamless integration across the broader Google Cloud ecosystem. As your organization’s reliance on these automated workflows grows, so must the underlying infrastructure that supports them.

Scaling Your AI Workflows

To elevate your stateful AI automations from department-level utilities to enterprise-wide engines, you must leverage the full power of Google Cloud. Apps Script is fantastic for rapid Workspace integrations, but as payload sizes increase, concurrent requests multiply, and execution time limits loom, decoupling your architecture becomes essential.

Here are the critical pathways to scale your architecture:

• Adopt an Event-Driven Architecture: Move away from purely synchronous Apps Script triggers. By integrating Cloud Pub/Sub and Eventarc, you can decouple your Workspace events from your AI processing. This allows you to queue tasks asynchronously, ensuring zero data loss during traffic spikes and enabling resilient retry mechanisms.

• Upgrade to Serverless Compute: Offload heavy AI processing—such as complex prompt chaining, large document parsing, or Retrieval-Augmented Generation (RAG) pipelines—to Cloud Run or Cloud Functions. These serverless environments offer custom runtimes, significantly longer execution timeouts, and the ability to auto-scale from zero to thousands of concurrent requests instantly.

• Deepen Vertex AI Integration: Transition from basic API calls to native Vertex AI integrations. Tap into the power of Google’s Gemini models for advanced multimodal reasoning. By combining Firestore’s NoSQL document storage with Vertex AI Vector Search, you can give your stateful automations deep, contextual memory over vast enterprise datasets.

• Enforce Enterprise Security & Governance: As your AI workflows handle increasingly sensitive data, implement granular Identity and Access Management (IAM) controls. Utilize VPC Service Controls to mitigate data exfiltration risks, and integrate Cloud Logging and Cloud Monitoring to ensure your automated workflows remain compliant, secure, and fully observable.

Book a GDE Discovery Call with Vo Tu Duc

Navigating the complexities of Google Cloud and Automated Google Slides Generation with Text Replacement integrations can be daunting, especially when designing stateful AI systems that must scale reliably under enterprise workloads. If you are ready to modernize your architecture, eliminate technical debt, or need expert guidance on optimizing your current workflows, it’s time to consult with a proven industry leader.

Vo Tu Duc, a recognized Google Developer Expert (GDE) in Google Cloud and Automated Order Processing Wordpress to Gmail to Google Sheets to Jobber, offers specialized discovery calls tailored to your organization’s unique technical challenges.

During this focused, high-impact session, you will receive:

• Comprehensive Architecture Review: A technical deep dive into your existing Apps Script and Firestore implementations to identify performance bottlenecks, scaling limitations, and security gaps.

• Custom Scaling Roadmap: Actionable, step-by-step strategies to migrate and future-proof your AI automations using advanced Google Cloud services like Cloud Run, Pub/Sub, and Vertex AI.

• Expert Best Practices: Insider knowledge on state management, cost optimization, and enterprise data governance directly from a Google Developer Expert.

Don’t leave your enterprise architecture to chance or trial-and-error. Accelerate your engineering journey and transform your stateful AI automations into highly scalable, production-ready assets. Book your GDE Discovery Call with Vo Tu Duc today to architect the future of your enterprise workflows.