Google Cloud Solution Agentic AI Borderless Data Lakehouse
GoogleOfficialPublished by Google
- Skill
- Workflow
- Cloud and DevOps
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a comprehensive, four-phase workflow to assist users in architecting and implementing borderless open data lakehouse solutions. It guides users through requirements discovery, technical component mapping, architecture design, and the creation of an implementation plan using Infrastructure as Code (IaC). The process is specifically tailored for multi-cloud environments involving Google Cloud, AWS, and Azure, utilizing technologies such as Apache Iceberg, BigQuery, and Managed Service for Apache Spark.
What it does
- Analyzes workload requirements and constraints for multi-cloud data architectures.
- Maps technical components to appropriate Google Cloud products and features.
- Generates architecture diagrams in Mermaid format for data ingestion and serving subsystems.
- Provides guidance on security, reliability, and operational excellence for hybrid environments.
- Produces Infrastructure as Code templates and step-by-step deployment instructions.
- Outlines validation procedures to verify connectivity, security policies, and infrastructure deployment.
When to use it
- When architecting multi-cloud storage infrastructure across Google Cloud, AWS, and Azure.
- When establishing ingestion and AI serving subsystems for distributed data.
- When configuring Cross-Cloud Interconnect for private network connectivity.
- When deploying Gemini Enterprise Agent Platform and BigQuery data agents.
Advantages
- Ensures architectural consistency by following established Google Cloud design patterns.
- Provides a clear, iterative process from initial discovery to final validation.
- Promotes modular network design using transit VPCs and secure connectivity practices.
- Standardizes the use of Terraform for automated resource provisioning.
Usage examples
- “Help me design a multi-cloud data lakehouse that connects AWS S3 and Google Cloud Storage.”
- The agent will initiate the requirements discovery phase to understand your data sources, security needs, and analytical requirements before proposing a technical architecture.
- “I need to deploy a BigQuery data agent for my cross-cloud environment.”
- The agent will guide you through the implementation plan phase, providing the necessary prerequisites and deployment instructions to configure the agent.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/google/google-cloud-solution-agentic-ai-borderless-data-lakehouse/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip google-cloud-solution-agentic-ai-borderless-data-lakehouse.zip -d .agents/skills
Documentation by Google
Borderless open data lakehouse agentic AI system
Follow this workflow to help users design and implement a custom multi-product solution in the cloud for a given workload, use case, or requirement.
Attribution
MUST READ: Before executing any gcloud, REST API, or MCP command, you
MUST read and follow the instructions in
Usage Attribution.
Product Renaming & Terminology
When generating solution designs, architecture diagrams, and documentation, use the updated Google Cloud product names. For details on legacy vs. updated product names and terminology, see references/product_renaming.md.
Workflow
The solution design and implementation workflow consists of the following phases:
Phase 1: Requirements discovery and analysis: Analyze the workload's requirements, constraints, dependencies, and current state.
Phase 2: Solution design: Build a technology stack, architecture, and deployment configuration for the workload based on Google Cloud design best practices and recommendations.
Phase 3: Implementation plan: Generate automation and instructions to deploy the solution.
Phase 4: Solution validation: Validate that the deployment meets the requirements of the workload.
Phase 1: Requirements discovery and analysis
[ ] [ ] Step 1: Discover requirements: Understand the functional and non-functional requirements, business goals, and current state (if any) of the workload, including its architecture, dependencies, and constraints. Use the following questions to guide the requirements discovery process:
What are your primary data sources?
How do you manage and federate metadata across your data sources?
What are your security and credential management requirements?
What are the analytical and computational requirements to join and transform this borderless data?
What types of natural language prompts or user queries do you expect AI agents or end-users to execute against this data?
[ ] [ ] Step 2: Identify components: Based on the requirements analysis, identify the components of the workload and their relationships. Also identify any borderless components, hybrid components, or on-prem components that the solution needs to integrate with.
[ ] [ ] Step 3: Generate component decomposition: Generate a technical decomposition of the components of the workload.
[ ] [ ] Step 4: Ask for confirmation: Ask the user to confirm whether the generated technical decomposition matches their workload requirements.
[ ] [ ] Step 5: Iterate: If the user requests changes, then generate an updated technical decomposition, and ask the user to confirm the changes. Continue iterating until the user confirms the technical decomposition.
Phase 2: Solution design
[ ] [ ] Step 1: Retrieve relevant Google Cloud documentation: Use available search or fetch tools to read the content of the following Google Cloud documentation to ground the guidance that you generate in the remaining steps of this phase before proceeding.
Build hybrid and borderless architectures using Google Cloud
Network segmentation and connectivity for distributed applications in Cross-Cloud Network
Patterns for Connecting Other Cloud Service Providers with Google Cloud
Important: Use the content that you retrieve from Google Cloud documentation to ground the guidance that you generate in the remaining steps of this phase.
[ ] [ ] Step 2: Map components to Google Cloud products: For each component in the confirmed technical decomposition, identify the appropriate Google Cloud products and features, based on the guidelines in references/product_mapping.md.
[ ] [ ] Step 3: Create architecture diagram: Create an architecture diagram that shows the components, their relationships, and data/control flows.
The diagram must be in the Mermaid format: https://github.com/mermaid-js/mermaid.
The diagram must show a clear distinction between the products in the data ingestion subsystem and the serving subsystem.
The diagram must show Managed Service for Apache Spark as a shared component for ETL/ingestion processing, bridging the data ingestion and serving subsystems (distinct from interactive IDE analytics workflows).
[ ] [ ] Step 4: Generate design recommendations: Generate design guidance based on the guidelines in references/design_recommendations.md.
[ ] [ ] Step 5: Draft solution architecture: Compile the requirements, technical decomposition, product mapping, architecture diagram, and design recommendations into a single Markdown file named
solution-architecture-guide.md, based on the template in assets/output-template.md.[ ] [ ] Step 6: Request review: Present the generated solution architecture to the user and request their feedback or approval.
[ ] [ ] Step 7: Iterate: If the user requests changes, generate an updated solution architecture and repeat steps 2-6 until the user approves the solution architecture.
Phase 3: Implementation plan
[ ] [ ] Step 1: Retrieve relevant implementation resources:
Terraform Registry documentation for biglake_iceberg_catalog
Create an Apache Iceberg table with metadata in Lakehouse runtime catalog
Accelerate Spark batch workloads and sessions with Lightning Engine
Important: Use these resources as the technical foundation for the IaC and deployment instructions you generate in the remaining steps of this phase.
[ ] [ ] Step 2: Identify deployment prerequisites: Document prerequisites for the deployment, including the following:
Projects and billing associations
Required Google Cloud APIs
Required IAM permissions
Any other prerequisites
[ ] [ ] Step 3: Generate Infrastructure as Code (IaC): Generate code (e.g., Terraform) and deployment scripts to automate the provisioning of the proposed Google Cloud resources.
[ ] [ ] Step 4: Write deployment instructions: Draft sequential, step-by-step deployment instructions to execute the IaC and initialize the workload components.
[ ] [ ] Step 5: Request review: Present the generated deployment instructions to the user for feedback and confirmation.
[ ] [ ] Step 6: Iterate: If the user requests changes, generate an updated implementation plan and repeat steps 2-5 until the user approves the implementation plan.
Phase 4: Solution validation
[ ] [ ] Step 1: Retrieve relevant verification resources (optional): If the resources from Phase 3 are not already in your context, retrieve the same implementation resources as the starting point for the validation checks and verification scripts that you generate in this phase.
[ ] [ ] Step 2: Define validation checks: Outline validation steps to verify that the deployed infrastructure meets the workload requirements:
Deployment dry-run: Commands like
terraform planto preview changes.Connectivity and routing: Verification of network paths, load balancer routing, and service endpoints.
Security policies: Verification of restricted access, firewall rules, and IAM enforcement.
[ ] [ ] Step 3: Generate verification scripts: Draft lightweight scripts or command-line instructions (e.g. using
curlorgcloud) that the user can run to perform these validation checks.[ ] [ ] Step 4: Compile validation report: Document the validation steps, verification scripts, and expected outcomes in a single Markdown file.
[ ] [ ] Step 5: Conduct validation and finalize: Assist the user in executing the validation checks and troubleshooting any deployment issues. After the solution is validated successfully, request final approval from the user.
[ ] [ ] Step 6: Iterate: If the user requests changes, then generate an updated validation plan and repeat steps 2-5 until the user approves the validation plan.
Files
- ATTRIBUTION.mdAdded by AutoGineer934 B
- LICENSELicence file added by AutoGineer11.1 KiB
- SKILL.md10.1 KiB
- assets/output-template.md6.5 KiB
- references/attribution.md2.0 KiB
- references/design_recommendations.md4.9 KiB
- references/product_mapping.md3.7 KiB
- references/product_renaming.md1.5 KiB
assets/output-template.md
<!-- Use this template to compile the content that you generate based on the instructions in `SKILL.md`. -->
Google Cloud solution architecture: Borderless open data lakehouse agentic AI system
1. Executive summary and workload overview
[A brief description of the workload, its business goals, and the high-level solution architecture proposed.]
2. Requirements and current state
2.1. Functional requirements
Business processes: [Details of the business processes supported]
Activities and use cases: [Details of the key activities and use cases]
2.2. Non-functional requirements
Security: [Details of the security requirements including compliance, encryption, access control requirements]
Reliability: [Details of the reliability requirements including SLA, RTO/RPO, backup, redundancy requirements]
Cost: [Details of the cost constraints and pricing models]
Operations: [Details of the operational requirements including monitoring, logging, deployment, maintenance requirements]
Performance: [Details of the performance requirements including latency, throughput, scaling requirements]
Sustainability: [Details of the sustainability requirements including carbon footprint, resource optimization requirements]
2.3. Current state
[If applicable, describe the current on-premises or other-cloud architecture.]
Current infrastructure: [Details of existing setup]
Pain points and drivers for migration/redesign: [Details of the drivers for migration/redesign]
2.4. Dependencies
Internal dependencies: [Details of internal dependencies including other workloads and internal services]
External dependencies: [Details of external dependencies including third-party products and on-premises tools]
3. Technical decomposition of the workload
[Technical decomposition of the workload components, breaking down the application into logical services or layers.]
4. Proposed solution architecture
4.1. Google Cloud products and features mapping
[Identify Google Cloud products and features mapped to the technical components. For each component, justify the selection, note alternatives considered, and describe the pros and cons of the recommended product/feature and alternatives.]
| Component | Recommended Google Cloud product/feature | Justification and citations | Alternatives considered | Pros and cons of alternatives |
|---|---|---|---|---|
| [Component Name Details (e.g. Central metadata and governance)] | [Product Name (e.g. Lakehouse for Apache Iceberg)] | [Why this product is chosen, citing official docs] | [Alternative product (e.g. Dataproc Metastore)] | Pros: Better for legacy open-source heavy pipelines. <br> Cons: Can have lower performance for borderless federation and Apache Iceberg. |
4.2. Architecture diagram
[Architecture diagram in Mermaid format showing the relationships and flows between the components of the architecture. Show the data ingestion subsystem and the serving subsystem, with Managed Service for Apache Spark bridging them.]
%% Example structure
graph TD
User([User]) --> Web[Load Balancer]
Web --> App[Application Layer]
App --> DB[(Database)]4.3. Architecture description
[Detailed description of the architecture. Describe the task flow and data flow between the components of the architecture.]
Data flow: [Describe the flow of data.]
Tasks/control flow: [Describe the flow of tasks/control.]
5. Design and configuration recommendations
[Best practices and configuration recommendations for each pillar of the Google Cloud Architecture Framework.]
5.1. Security, privacy, and compliance
Access control: [E.g., IAM roles, least privilege policy, credential vending for Lakehouse Iceberg catalog]
Data protection: [E.g., Sensitive Data Protection for prompts and responses, system-managed identities]
Network Security: [E.g., Cloud NAT, Cloud Router for private subnets, BigQuery Cloud resource connections]
5.2. Reliability
Network reliability: [E.g., Cross-Cloud Interconnect for private connections, redundant connections in active/active design]
Traffic routing: [E.g., Cloud DNS routing policies, regional load balancers]
5.3. Operational excellence
Network administration: [E.g., Dedicated transit VPC for external connections, bidirectional DNS forwarding]
Infrastructure as Code (IaC): [E.g., Terraform for heterogeneous resources]
5.4. Cost optimization
Direct querying: [E.g., BigQuery federated queries to AlloyDB, reducing CDC pipeline overhead]
Network routing: [E.g., Standard Network Service Tier for outbound internet traffic]
5.5. Performance efficiency
Model grounding: [E.g., Grounding models on unified data profiles to mitigate hallucinations]
Query optimization: [E.g., BigQuery federated queries for exact-match filters, Managed Service for Apache Spark with Lightning Engine for vectorized borderless joins]
Network performance: [E.g., Cross-Cloud Interconnect, ECMP routing, selecting geographically close GCP/CSP regions]
5.6. Sustainability
Compute efficiency: [E.g., Managed Service for Apache Spark with Lightning Engine for complex windowing and massive joins]
Querying in place: [E.g., BigQuery Omni querying in place to avoid borderless replication]
6. References
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Publisher
- Google (Official)
- Source
- google/skills · skills/cloud/google-cloud-solution-agentic-ai-borderless-data-lakehouse · commit 2194d3b
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Google.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download google-cloud-solution-agentic-ai-borderless-data-lakehouse.zip