Skip to content
cccskills
FreePublished on GitHub

google-cloud-solution-agentic-ai-borderless-data-lakehouse

Discovers requirements and designs a borderless open data lakehouse using Lakehouse for Apache Iceberg and BigQuery data agents. Use when architecting multi-cloud storage infrastructure (Cloud Storage, AWS S3, Azure Blob), establishing ingestion and AI serving subsystems, configuring Cross-Cloud Interconnect, or deploying Gemini Enterprise Agent Platform and BigQuery data agents. Don't use for single-cloud data warehouses, or when the focus is on Knowledge Catalog metadata governance and Spark-driven IDE analytics workflows (use google-cloud-solution-agentic-analytics-spark-knowledge-catalog instead).

The English summary is being prepared. Showing the original description.

See how to install

Files included (5)

  • SKILL.md9.9 KB
  • assets/output-template.md6.5 KB
  • references/design_recommendations.md4.9 KB
  • references/product_mapping.md3.7 KB
  • references/product_renaming.md1.5 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

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

Phase 3: 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 plan to 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 curl or gcloud) 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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Configures best-practice alerting policies for AI agents using OpenTelemetry (OTel) metrics, generating output as Terraform (.tf) configuration files. Use when analyzing, writing, or deploying alerting policies to monitor agent latency, error rates, token usage, and quality metrics. Don't use for standard infrastructure monitoring unrelated to AI agents, or when the agent is not instrumented with OpenTelemetry (for Reliability, Cost, Safety, Security alerts). NOTE: Reliability, Cost, Safety, and Security alerts use generic OTel metrics and work across runtimes (such as Cloud Run, Vertex AI). Quality alerts rely on Vertex AI Online Monitors and are strictly bound to Vertex AI deployments.

The English summary is being prepared. Showing the original description.

vaila-multimodaltoolbox/vaila21Updated Oct 20, 2026

Deploy open models or custom weights from Model Garden to Agent Platform endpoints, check the status of an in-progress deployment operation, or clean up resources by undeploying models and deleting endpoints. Use when asked to actively deploy a model, list the Model Garden CATALOG of available models, check if a specific model is deployable (`gcloud ai model-garden models list-deployment-config`), query deployment cost, troubleshoot deployment errors (like quota limits), or undeploy/clean up endpoints. Also use when copying and deploying a 1P Tuned Model. Don't use for pure listing/discovery questions of the form "is X deployed?", "list my endpoints", or "which regions have models running?" — for those use `agent-platform-endpoint-management`. Don't use for public Vertex AI deployments (use the `vertex-deploy` skill) or for running model evaluations (use the `agent-platform-eval-flywheel` skill).

The English summary is being prepared. Showing the original description.

vaila-multimodaltoolbox/vaila21Updated Oct 20, 2026

Manages Agent Platform serving endpoints. Use when you need to create, list, describe, update, or delete serving endpoints for model deployment on Agent Platform. Also use when troubleshooting endpoint permission, quota, or resource busy errors. Don't use for deploying models to endpoints or for running model evaluations.

The English summary is being prepared. Showing the original description.

vaila-multimodaltoolbox/vaila21Updated Oct 20, 2026

Measures and improves the quality of AI models and agents on Google Cloud using the Eval Quality Flywheel methodology. Use when evaluating an agent or model, building an eval dataset, picking or writing evaluation metrics, analyzing failures, comparing results before and after a fix, or when guidance is needed on Agent Platform eval methodology — including dataset schema, LLM-as-judge scoring, and common failure causes. For fine-tuning, use agent-platform-tuning. For general production deployment, use agent-platform-deploy.

The English summary is being prepared. Showing the original description.

vaila-multimodaltoolbox/vaila21Updated Oct 20, 2026

Connects to and performs inference with Google Cloud Agent Platform GenAI models, including First-Party Gemini models and Third-Party OpenMaaS models (Llama, DeepSeek, Qwen, etc.). Use when asked to perform inference, ask a model a question, run a test prompt, execute chat completions, or generate code for calling Gemini or OpenMaaS models, authenticate with GenAI SDK, OpenAI SDK, or legacy Agent Platform SDK, configure base URLs and global/regional endpoints, or troubleshoot 429 Resource Exhausted (DSQ), 400 User Validation, or 404 Not Found errors. Don't use for deploying models to endpoints or for running model evaluations.

The English summary is being prepared. Showing the original description.

vaila-multimodaltoolbox/vaila21Updated Oct 20, 2026

Guides agents and users through migrating from Gemini API in Google AI Studio to Gemini Enterprise Agent Platform (formerly Vertex AI). Use this skill when moving applications to Google Cloud, to leverage Cloud credits, or to unify inferencing with other Cloud infrastructure (IAM, billing, telemetry).

The English summary is being prepared. Showing the original description.

vaila-multimodaltoolbox/vaila21Updated Oct 20, 2026

See all skills by vaila-multimodaltoolbox

Report a problem with this skill