One order question across ADK agents: coordinator, A2A specialists and MCP Toolbox

Flow

1The operator asks in the chat UI; Identity-Aware Proxy has already authenticated them.
2The UI calls the coordinator's ADK API server with an ID token for its Cloud Run service; the session service keeps the conversation state.
3Coordinator agent → Model Armor (screen prompt)
4The LlmAgent asks Gemini which sub-agents or tools answer the question.
5Local sub-agents run in the coordinator's process; no network hop.
6The coordinator calls the inventory agent through RemoteA2aAgent.
7Shipping is called in parallel with inventory.
8Inventory agent → MCP Toolbox (MCP: stock_by_order)
9MCP Toolbox → AlloyDB (SQL)
10Coordinator agent → Gemini (summarize answer)

Well-Architected review One order question across ADK agents: coordinator, A2A specialists and MCP Toolbox · 2026-10-02 · mode full

Coverage audit

Google Cloud Well-Architected Framework — 6 pillars, 174 recommendations, from the live documentation index, snapshot 2026-10-02 (0 days old).
Assessed 174 recommendations: 11 with diagram evidence, 163 cannot be determined.
Evidence sources: architecture diagram (services, boundaries, relationships).
Corpus read from a committed snapshot of the live documentation index (not re-fetched during this review). Re-read it with `archify-gcp wa corpus --refresh`. Statuses reflect what the diagram and spec show. Process, configuration and runtime evidence are not observable here, so those recommendations are 'Cannot Determine' rather than guessed.

Executive summary

This Google Cloud Well-Architected Framework (with its AI and ML perspective) review of One order question across ADK agents: coordinator, A2A specialists and MCP Toolbox (standard criticality) assessed the architecture diagram only. 11 of 174 framework recommendations have diagram evidence; the rest are Cannot Determine because process, configuration and runtime evidence is not in the diagram. It found 0 critical, 0 high, 3 medium and 0 low risks.

0Critical

0High

3Medium

0Low

3.0provisional maturity (1–5)

11 of 174 recommendations have diagram evidence (6%); among those, 4 implemented, 2 partial, 5 not implemented. Provisional: scores cover evidenced practices only.

Strengths. Data stores are not reached directly from clients; Managed / serverless services shown; Model safety controls shown.

Architecture overview

The reviewed architecture is the Diagram tab (9 components, sequence diagram). Hover a finding to highlight the components involved.

Pillar scorecard

Pillar	Score (1–5)	Evidenced recommendations	I · P · N · NA · CD	Strongest area	Main gap
Operational excellence	—	1/25 (4%)	0 0 1 0 24	—	No monitoring / observability shown
Security, privacy, and compliance	3.0 provisional	6/43 (14%)	2 2 2 0 37	Data stores are not reached directly from clients	Internet-facing entry has no Cloud Armor / DDoS protection shown
Reliability	—	1/35 (2.9%)	0 0 1 0 34	—	No gaps evidenced in the diagram
Cost optimization	—	0/26 (0%)	0 0 0 0 26	—	No gaps evidenced in the diagram
Performance optimization	—	1/16 (6.3%)	0 0 1 0 15	—	No gaps evidenced in the diagram
Sustainability	—	2/29 (6.9%)	2 0 0 0 27	Managed / serverless services shown	No gaps evidenced in the diagram

Score = 1 + 4 × (implemented + ½ partial) ÷ evidenced recommendations; shown only when ≥ 3 recommendations are evidenced. It reflects evidenced practices, not the whole pillar.

Framework questions

ID	Question	Pillar	Status	Risk	Recs (evidenced)	Key evidence
OE-1	Ensure operational readiness and performance using CloudOps	Operational excellence	Not Implemented	Medium	5 (1)	Diagram: No monitoring / observability shown. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometh
OE-2	Manage incidents and problems	Operational excellence	Cannot Determine	Not Applicable	5 (0)	—
OE-3	Manage and optimize cloud resources	Operational excellence	Cannot Determine	Not Applicable	5 (0)	—
OE-4	Automate and manage change	Operational excellence	Cannot Determine	Not Applicable	5 (2)	Diagram: No infrastructure-as-code or CI/CD shown. Define infrastructure as code (Terraform / Infrastructure Manager or Config Connector) and deploy through Clo
OE-5	Continuously improve and innovate	Operational excellence	Cannot Determine	Not Applicable	5 (0)	—
SEC-1	Implement security by design	Security, privacy, and compliance	Not Implemented	Medium	4 (2)	Diagram: Internet-facing entry has no Cloud Armor / DDoS protection shown. Nodes: ui. Protect public entry points (Cloud Load Balancing, Apigee, API Gateway) wi
SEC-2	Implement zero trust	Security, privacy, and compliance	Not Implemented	Medium	3 (3)	Diagram: Internet-facing entry has no Cloud Armor / DDoS protection shown. Nodes: ui. Protect public entry points (Cloud Load Balancing, Apigee, API Gateway) wi
SEC-3	Implement shift-left security	Security, privacy, and compliance	Cannot Determine	Not Applicable	6 (0)	—
SEC-4	Implement preemptive cyber defense	Security, privacy, and compliance	Cannot Determine	Not Applicable	5 (1)	Diagram: No threat detection or posture management shown. Enable Security Command Center for posture and threat detection, Cloud Audit Logs (Data Access where n
SEC-5	Use AI securely and responsibly	Security, privacy, and compliance	Partially Implemented	None	10 (5)	Diagram: Model safety controls shown. Nodes: root, gem, inv, ship. Apply Model Armor or Vertex AI safety filters to prompts and responses, screen for prompt inj
SEC-6	Use AI for security	Security, privacy, and compliance	Cannot Determine	Not Applicable	5 (0)	—
SEC-7	Meet regulatory, compliance, and privacy needs	Security, privacy, and compliance	Partially Implemented	None	10 (2)	Model Armor drawn for classification; coverage of labels and policy tags is not observable.
REL-1	Define reliability based on user-experience goals	Reliability	Cannot Determine	Not Applicable	2 (0)	—
REL-2	Set realistic targets for reliability	Reliability	Cannot Determine	Not Applicable	2 (0)	—
REL-3	Build highly available systems through resource redundancy	Reliability	Cannot Determine	Not Applicable	3 (1)	Diagram: Single-region model inference. Nodes: root, gem, inv, ship. Plan for quota and 429 errors (retries with backoff, Provisioned Throughput, the global end
REL-4	Take advantage of horizontal scalability	Reliability	Cannot Determine	Not Applicable	3 (0)	—
REL-5	Detect potential failures by using observability	Reliability	Not Implemented	Medium	4 (1)	Diagram: No monitoring / observability shown. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometh
REL-6	Design for graceful degradation	Reliability	Cannot Determine	Not Applicable	5 (2)	Diagram: Single-region model inference. Nodes: root, gem, inv, ship. Plan for quota and 429 errors (retries with backoff, Provisioned Throughput, the global end
REL-7	Perform testing for recovery from failures	Reliability	Cannot Determine	Not Applicable	7 (0)	—
REL-8	Perform testing for recovery from data loss	Reliability	Cannot Determine	Not Applicable	5 (2)	Diagram: No backup or recovery capability shown. Define RPO/RTO and protect data with Backup and DR Service, automated backups and point-in-time recovery, snaps
REL-9	Conduct thorough postmortems	Reliability	Cannot Determine	Not Applicable	4 (0)	—
COST-1	Align cloud spending with business value	Cost optimization	Cannot Determine	Not Applicable	5 (0)	—
COST-2	Foster a culture of cost awareness	Cost optimization	Cannot Determine	Not Applicable	7 (3)	Diagram: No cost visibility shown. Label resources consistently, export billing data to BigQuery and set Cloud Billing budgets and alerts so spend maps to workl
COST-3	Optimize resource usage	Cost optimization	Cannot Determine	Not Applicable	8 (2)	Diagram: Model cost controls. Nodes: root, gem, inv, ship. Choose the smallest model that meets quality targets, use context caching and batch prediction where
COST-4	Optimize continuously	Cost optimization	Cannot Determine	Not Applicable	6 (0)	—
PERF-1	Plan resource allocation	Performance optimization	Cannot Determine	Not Applicable	3 (0)	—
PERF-2	Take advantage of elasticity	Performance optimization	Cannot Determine	Not Applicable	4 (1)	Diagram: No CDN / global edge shown for end users. Serve cacheable content from Google's edge with Cloud CDN or Media CDN behind the global external Application
PERF-3	Promote modular design	Performance optimization	Cannot Determine	Not Applicable	6 (2)	Diagram: No queue / event service shown between tiers. Decouple components with Pub/Sub, Cloud Tasks or Eventarc so spikes and downstream failures do not cascad
PERF-4	Continuously monitor and improve performance	Performance optimization	Not Implemented	Medium	3 (1)	Diagram: No monitoring / observability shown. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometh
SUS-1	Use regions that consume low-carbon energy	Sustainability	Cannot Determine	Not Applicable	3 (2)	Diagram: Region choice is not tied to carbon intensity. Choose regions using Google's carbon-free energy (CFE%) data and grid carbon intensity when latency and
SUS-2	Optimize AI and ML workloads for energy efficiency	Sustainability	Cannot Determine	Not Applicable	4 (0)	—
SUS-3	Optimize resource usage for sustainability	Sustainability	Implemented	None	7 (2)	Diagram: Managed / serverless services shown. Nodes: ui, tb. Prefer managed and serverless services with automatic scaling, schedule batch work for low-carbon p
SUS-4	Develop energy-efficient software	Sustainability	Cannot Determine	Not Applicable	4 (0)	—
SUS-5	Optimize data and storage for sustainability	Sustainability	Cannot Determine	Not Applicable	3 (0)	—
SUS-6	Continuously measure and improve sustainability	Sustainability	Cannot Determine	Not Applicable	4 (0)	—
SUS-7	Promote a culture of sustainability	Sustainability	Cannot Determine	Not Applicable	4 (0)	—

Recommendation ledger 174 recommendations — nothing truncated

ID	Pillar	Best practice	Status	Evidence
OE-1.1	Operational excellence	Define SLOs and SLAs	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-1.2	Operational excellence	Implement comprehensive observability	Not Implemented	Diagram: No monitoring / observability shown. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometheus, define SLOs and alert on burn rate. Diagram: No model logging / observability shown. Nodes: root, gem, inv, ship. Log model requests and responses (Vertex AI request-response logging to BigQuery), monitor latency, errors and token usage in Cloud Monitoring, and keep an audit trail of model and agent calls.
OE-1.3	Operational excellence	Implement performance and load testing	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-1.4	Operational excellence	Plan and manage capacity	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
OE-1.5	Operational excellence	Continuously monitor and optimize	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-2.1	Operational excellence	Establish clear incident response procedures	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
OE-2.2	Operational excellence	Centralize incident management	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
OE-2.3	Operational excellence	Conduct thorough post-incident reviews	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
OE-2.4	Operational excellence	Maintain a knowledge base	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
OE-2.5	Operational excellence	Automate incident response	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
OE-3.1	Operational excellence	Right-size resources	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-3.2	Operational excellence	Use autoscaling	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-3.3	Operational excellence	Leverage cost optimization strategies	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-3.4	Operational excellence	Track resource usage and costs	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-3.5	Operational excellence	Establish cost allocation and budgeting	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
OE-4.1	Operational excellence	Adopt IaC	Cannot Determine	Diagram: No infrastructure-as-code or CI/CD shown. Define infrastructure as code (Terraform / Infrastructure Manager or Config Connector) and deploy through Cloud Build and Cloud Deploy with small, reversible changes and automated rollback.
OE-4.2	Operational excellence	Implement version control	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-4.3	Operational excellence	Build CI/CD pipelines	Cannot Determine	Diagram: No infrastructure-as-code or CI/CD shown. Define infrastructure as code (Terraform / Infrastructure Manager or Config Connector) and deploy through Cloud Build and Cloud Deploy with small, reversible changes and automated rollback.
OE-4.4	Operational excellence	Use configuration management tools	Cannot Determine	Not observable from the architecture diagram; needs IaC or configuration evidence.
OE-4.5	Operational excellence	Automate testing	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-5.1	Operational excellence	Foster a culture of learning	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
OE-5.2	Operational excellence	Conduct regular retrospectives	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-5.3	Operational excellence	Stay up-to-date with cloud technologies	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-5.4	Operational excellence	Actively seek and incorporate feedback	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
OE-5.5	Operational excellence	Measure and track progress	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-1.1	Security, privacy, and compliance	Choose system components that help to secure your workloads	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-1.2	Security, privacy, and compliance	Build a layered security approach	Not Implemented	Diagram: Internet-facing entry has no Cloud Armor / DDoS protection shown. Nodes: ui. Protect public entry points (Cloud Load Balancing, Apigee, API Gateway) with Cloud Armor security policies (WAF rules, rate limiting, DDoS protection) and restrict backends to the load balancer.
SEC-1.3	Security, privacy, and compliance	Use hardened and attested infrastructure and services	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-1.4	Security, privacy, and compliance	Encrypt data at rest and in transit	Cannot Determine	Diagram: No Cloud KMS shown for data at rest. Data is encrypted by default; use Cloud KMS customer-managed keys (CMEK, or Cloud HSM / EKM) where you need rotation, access policy or audit control, and enforce TLS in transit.
SEC-2.1	Security, privacy, and compliance	Secure your network	Not Implemented	Diagram: Internet-facing entry has no Cloud Armor / DDoS protection shown. Nodes: ui. Protect public entry points (Cloud Load Balancing, Apigee, API Gateway) with Cloud Armor security policies (WAF rules, rate limiting, DDoS protection) and restrict backends to the load balancer. Diagram: Data stores are not reached directly from clients. Least-privilege network placement for stateful services. Diagram: No private access or VPC Service Controls shown for managed data services. Reach Google APIs and managed data services privately (Private Google Access, Private Service Connect) and wrap sensitive projects in a VPC Service Controls perimeter to prevent exfiltration.
SEC-2.2	Security, privacy, and compliance	Verify every access attempt explicitly	Cannot Determine	Diagram: No identity / authentication service shown. Authenticate and authorize every request: Identity-Aware Proxy or Identity Platform for users, IAM with least privilege and dedicated service accounts (Workload Identity) for workloads. Diagram: No Secret Manager or IAM database authentication shown. Store secrets in Secret Manager or, better, use IAM database authentication and service-account identities so no credentials are embedded. Diagram: Agents and excessive agency. Nodes: gem. Give agents dedicated least-privilege service accounts and scoped tools, validate tool inputs and outputs, and require human approval for high-impact actions.
SEC-2.3	Security, privacy, and compliance	Monitor and maintain your network	Cannot Determine	Diagram: No threat detection or posture management shown. Enable Security Command Center for posture and threat detection, Cloud Audit Logs (Data Access where needed) and Cloud IDS, and route security logs to a central, access-restricted sink.
SEC-3.1	Security, privacy, and compliance	Adopt preventive security controls	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-3.2	Security, privacy, and compliance	Automate provisioning and management of cloud resources	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-3.3	Security, privacy, and compliance	Automate secure application releases	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-3.4	Security, privacy, and compliance	Ensure that application deployments follow approved processes	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SEC-3.5	Security, privacy, and compliance	Scan for known vulnerabilities before application deployment	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-3.6	Security, privacy, and compliance	Monitor your application code for known vulnerabilities	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-4.1	Security, privacy, and compliance	Integrate the functions of cyber defense	Cannot Determine	Diagram: No threat detection or posture management shown. Enable Security Command Center for posture and threat detection, Cloud Audit Logs (Data Access where needed) and Cloud IDS, and route security logs to a central, access-restricted sink.
SEC-4.2	Security, privacy, and compliance	Use the Intelligence function in all aspects of cyber defense	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-4.3	Security, privacy, and compliance	Understand and capitalize on your defender's advantage	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-4.4	Security, privacy, and compliance	Validate and improve your defenses continuously	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SEC-4.5	Security, privacy, and compliance	Manage and coordinate cyber-defense efforts	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-5.1	Security, privacy, and compliance	Define clear goals and requirements for AI usage	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SEC-5.2	Security, privacy, and compliance	Keep data secure and prevent loss or mishandling	Implemented	Diagram: Model safety controls shown. Nodes: root, gem, inv, ship. Apply Model Armor or Vertex AI safety filters to prompts and responses, screen for prompt injection and use Sensitive Data Protection to find and mask PII before it reaches the model.
SEC-5.3	Security, privacy, and compliance	Keep AI pipelines secure and robust against tampering	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-5.4	Security, privacy, and compliance	Deploy apps on secure systems using secure tools and artifacts	Partially Implemented	MCP Toolbox Cloud Run mediates access to model and tool APIs; per-API authorization is not observable in a diagram.
SEC-5.5	Security, privacy, and compliance	Protect and monitor inputs	Implemented	Diagram: Model safety controls shown. Nodes: root, gem, inv, ship. Apply Model Armor or Vertex AI safety filters to prompts and responses, screen for prompt injection and use Sensitive Data Protection to find and mask PII before it reaches the model.
SEC-5.6	Security, privacy, and compliance	Use fairness indicators	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-5.7	Security, privacy, and compliance	Use Vertex Explainable AI	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-5.8	Security, privacy, and compliance	Track data lineage	Cannot Determine	Diagram: Retrieval / grounding data shown. Nodes: db. Ground responses in enterprise data (RAG with Vertex AI Search, Vector Search or a vector-enabled database such as AlloyDB) and measure retrieval quality; version prompts, models and data sources.
SEC-5.9	Security, privacy, and compliance	Establish accountability	Cannot Determine	Diagram: Agents and excessive agency. Nodes: gem. Give agents dedicated least-privilege service accounts and scoped tools, validate tool inputs and outputs, and require human approval for high-impact actions.
SEC-5.10	Security, privacy, and compliance	Implement differential privacy	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-6.1	Security, privacy, and compliance	Enhance threat detection and response with AI	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-6.2	Security, privacy, and compliance	Simplify security for experts and non-experts	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-6.3	Security, privacy, and compliance	Automate time-consuming security tasks with AI	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-6.4	Security, privacy, and compliance	Incorporate AI into risk management and governance processes	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SEC-6.5	Security, privacy, and compliance	Implement secure development practices for AI systems	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-7.1	Security, privacy, and compliance	Identify risks to your organization	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-7.2	Security, privacy, and compliance	Mitigate your risks	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-7.3	Security, privacy, and compliance	Assess your compliance needs	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-7.4	Security, privacy, and compliance	Automate implementation of compliance requirements	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SEC-7.5	Security, privacy, and compliance	Monitor your compliance	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-7.6	Security, privacy, and compliance	Manage your operational sovereignty	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-7.7	Security, privacy, and compliance	Manage software sovereignty	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-7.8	Security, privacy, and compliance	Control data residency	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SEC-7.9	Security, privacy, and compliance	Classify your confidential data	Partially Implemented	Model Armor drawn for classification; coverage of labels and policy tags is not observable.
SEC-7.10	Security, privacy, and compliance	Lock down access to sensitive data	Cannot Determine	Diagram: No private access or VPC Service Controls shown for managed data services. Reach Google APIs and managed data services privately (Private Google Access, Private Service Connect) and wrap sensitive projects in a VPC Service Controls perimeter to prevent exfiltration. Diagram: No Secret Manager or IAM database authentication shown. Store secrets in Secret Manager or, better, use IAM database authentication and service-account identities so no credentials are embedded.
REL-1.1	Reliability	Measure user experience	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-1.2	Reliability	Analyze user journeys	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-2.1	Reliability	Accept some failure and prioritize components	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
REL-2.2	Reliability	Balance reliability and cost	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-3.1	Reliability	Identify failure domains and replicate services	Cannot Determine	Diagram: Single-region model inference. Nodes: root, gem, inv, ship. Plan for quota and 429 errors (retries with backoff, Provisioned Throughput, the global endpoint, a second region or a fallback model). No on-premises or private-link connectivity is drawn.
REL-3.2	Reliability	Detect and address issues promptly	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-3.3	Reliability	Test failover scenarios	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-4.1	Reliability	Use managed services	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-4.2	Reliability	Promote modular design	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-4.3	Reliability	Implement a stateless design	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-5.1	Reliability	Gain comprehensive insights	Not Implemented	Diagram: No monitoring / observability shown. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometheus, define SLOs and alert on burn rate.
REL-5.2	Reliability	Perform proactive troubleshooting	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-5.3	Reliability	Optimize resource utilization	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-5.4	Reliability	Prioritize alerts	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
REL-6.1	Reliability	Implement throttling	Cannot Determine	Diagram: Single-region model inference. Nodes: root, gem, inv, ship. Plan for quota and 429 errors (retries with backoff, Provisioned Throughput, the global endpoint, a second region or a fallback model).
REL-6.2	Reliability	Drop excess requests early	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-6.3	Reliability	Handle partial errors and retries	Cannot Determine	Diagram: No queue / event service shown between tiers. Decouple components with Pub/Sub, Cloud Tasks or Eventarc so spikes and downstream failures do not cascade; add retries with exponential backoff, timeouts and load shedding. Diagram: Single-region model inference. Nodes: root, gem, inv, ship. Plan for quota and 429 errors (retries with backoff, Provisioned Throughput, the global endpoint, a second region or a fallback model).
REL-6.4	Reliability	Test overload scenarios	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-6.5	Reliability	Monitor traffic spikes	Cannot Determine	Not observable from the architecture diagram; needs IaC or configuration evidence.
REL-7.1	Reliability	Define the testing objectives and scope	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-7.2	Reliability	Prepare the environment for testing	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-7.3	Reliability	Simulate failure scenarios	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-7.4	Reliability	Monitor system behavior	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-7.5	Reliability	Verify recovery against your RTO and RPO	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-7.6	Reliability	Document and analyze results	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-7.7	Reliability	Iterate and improve	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
REL-8.1	Reliability	Verify backup consistency and test restoration processes	Cannot Determine	Diagram: No backup or recovery capability shown. Define RPO/RTO and protect data with Backup and DR Service, automated backups and point-in-time recovery, snapshots, object versioning and cross-region replicas, and test restores.
REL-8.2	Reliability	Schedule regular and frequent backups	Cannot Determine	Diagram: No backup or recovery capability shown. Define RPO/RTO and protect data with Backup and DR Service, automated backups and point-in-time recovery, snapshots, object versioning and cross-region replicas, and test restores.
REL-8.3	Reliability	Define and monitor RPO	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-8.4	Reliability	Monitor backup health	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-8.5	Reliability	Plan for scenarios beyond backup	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
REL-9.1	Reliability	Conduct blameless postmortems	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-9.2	Reliability	Make the postmortem report readable by all the intended audiences	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-9.3	Reliability	Avoid complex or over-engineered solutions	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
REL-9.4	Reliability	Share the postmortem as widely as possible	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-1.1	Cost optimization	Prioritize managed services and serverless products	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
COST-1.2	Cost optimization	Balance cost efficiency with business agility	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-1.3	Cost optimization	Enable self-service optimization	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-1.4	Cost optimization	Adopt and implement FinOps	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-1.5	Cost optimization	Promote a value-driven and TCO-aware mindset	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-2.1	Cost optimization	Provide organization-wide cost visibility	Cannot Determine	Diagram: No cost visibility shown. Label resources consistently, export billing data to BigQuery and set Cloud Billing budgets and alerts so spend maps to workloads and owners.
COST-2.2	Cost optimization	Understand how cloud resources are billed	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-2.3	Cost optimization	Understand resource-based cost optimization options	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-2.4	Cost optimization	Understand discount-based cost optimization options	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-2.5	Cost optimization	Incorporate cost estimates into architecture blueprints	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-2.6	Cost optimization	Use a consistent and standard set of labels for all your resources	Cannot Determine	Diagram: No cost visibility shown. Label resources consistently, export billing data to BigQuery and set Cloud Billing budgets and alerts so spend maps to workloads and owners.
COST-2.7	Cost optimization	Share cost reports with team members	Cannot Determine	Diagram: No cost visibility shown. Label resources consistently, export billing data to BigQuery and set Cloud Billing budgets and alerts so spend maps to workloads and owners.
COST-3.1	Cost optimization	Choose environment-specific resources	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-3.2	Cost optimization	Choose workload-specific resources	Cannot Determine	Diagram: Model cost controls. Nodes: root, gem, inv, ship. Choose the smallest model that meets quality targets, use context caching and batch prediction where possible, and track tokens and cost per request.
COST-3.3	Cost optimization	Select regions based on cost requirements	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
COST-3.4	Cost optimization	Use built-in cost optimization options	Cannot Determine	Diagram: Model cost controls. Nodes: root, gem, inv, ship. Choose the smallest model that meets quality targets, use context caching and batch prediction where possible, and track tokens and cost per request.
COST-3.5	Cost optimization	Optimize resource sharing	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-3.6	Cost optimization	Develop and maintain reference architectures	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-3.7	Cost optimization	Enforce cost discipline by using organization policies	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-3.8	Cost optimization	Estimate realistic budgets and set financial boundaries	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
COST-4.1	Cost optimization	Focus on business-relevant metrics	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-4.2	Cost optimization	Use observability for resource optimization	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-4.3	Cost optimization	Balance troubleshooting needs with cost	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-4.4	Cost optimization	Tailor data collection to roles and set role-specific retention policies	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
COST-4.5	Cost optimization	Consider regulatory and compliance requirements	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
COST-4.6	Cost optimization	Implement smart alerting	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-1.1	Performance optimization	Configure and manage quotas	Cannot Determine	Not observable from the architecture diagram; needs IaC or configuration evidence.
PERF-1.2	Performance optimization	Educate and promote awareness	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-1.3	Performance optimization	Monitor performance metrics	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-2.1	Performance optimization	Plan for peak load periods	Cannot Determine	Diagram: No CDN / global edge shown for end users. Serve cacheable content from Google's edge with Cloud CDN or Media CDN behind the global external Application Load Balancer to cut latency. Diagram: Relational database with no cache / read scaling shown. Add caching (Memorystore, Cloud CDN) or read replicas for read-heavy access, and choose the data store that fits the access pattern.
PERF-2.2	Performance optimization	Use predictive scaling	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-2.3	Performance optimization	Implement serverless architectures	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-2.4	Performance optimization	Use Autopilot mode for Kubernetes	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-3.1	Performance optimization	Design for loose coupling	Cannot Determine	Diagram: No queue / event service shown between tiers. Decouple components with Pub/Sub, Cloud Tasks or Eventarc so spikes and downstream failures do not cascade; add retries with exponential backoff, timeouts and load shedding.
PERF-3.2	Performance optimization	Design for concurrency and parallelism	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-3.3	Performance optimization	Balance modularity for flexible resource allocation	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-3.4	Performance optimization	Use well-defined interfaces	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-3.5	Performance optimization	Use stateless models	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
PERF-3.6	Performance optimization	Choose complementary technologies	Cannot Determine	Diagram: Relational database with no cache / read scaling shown. Add caching (Memorystore, Cloud CDN) or read replicas for read-heavy access, and choose the data store that fits the access pattern. Diagram: Retrieval / grounding data shown. Nodes: db. Ground responses in enterprise data (RAG with Vertex AI Search, Vector Search or a vector-enabled database such as AlloyDB) and measure retrieval quality; version prompts, models and data sources.
PERF-4.1	Performance optimization	Define clear performance goals and metrics	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
PERF-4.2	Performance optimization	Monitor performance	Not Implemented	Diagram: No monitoring / observability shown. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometheus, define SLOs and alert on burn rate. Diagram: No model logging / observability shown. Nodes: root, gem, inv, ship. Log model requests and responses (Vertex AI request-response logging to BigQuery), monitor latency, errors and token usage in Cloud Monitoring, and keep an audit trail of model and agent calls.
PERF-4.3	Performance optimization	Incentivize continuous improvement	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SUS-1.1	Sustainability	Understand the carbon intensity of cloud regions	Cannot Determine	Diagram: Region choice is not tied to carbon intensity. Choose regions using Google's carbon-free energy (CFE%) data and grid carbon intensity when latency and data residency allow; use the Carbon Footprint report to track emissions.
SUS-1.2	Sustainability	Incorporate CFE in your location-selection strategy	Cannot Determine	Diagram: Region choice is not tied to carbon intensity. Choose regions using Google's carbon-free energy (CFE%) data and grid carbon intensity when latency and data residency allow; use the Carbon Footprint report to track emissions.
SUS-1.3	Sustainability	Use time-of-day scheduling	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-2.1	Sustainability	Architect for energy efficiency by using TPUs	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-2.2	Sustainability	Follow the 4Ms best practices for resource selection	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-2.3	Sustainability	Optimize AI models and algorithms for training and inference	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SUS-2.4	Sustainability	Follow best practices for AI and ML operations	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-3.1	Sustainability	Implement automated and dynamic scaling	Implemented	Diagram: Managed / serverless services shown. Nodes: ui, tb. Prefer managed and serverless services with automatic scaling, schedule batch work for low-carbon periods and right-size resources.
SUS-3.2	Sustainability	Use scheduling and batches	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-3.3	Sustainability	Match VM machine families to workload requirements	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SUS-3.4	Sustainability	Upgrade to the latest machine types	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-3.5	Sustainability	Deploy containerized applications	Implemented	Diagram: Managed / serverless services shown. Nodes: ui, tb. Prefer managed and serverless services with automatic scaling, schedule batch work for low-carbon periods and right-size resources.
SUS-3.6	Sustainability	Configure carbon-aware scheduling	Cannot Determine	Not observable from the architecture diagram; needs IaC or configuration evidence.
SUS-3.7	Sustainability	Architect energy-efficient disaster recovery	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-4.1	Sustainability	Minimize computational work	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-4.2	Sustainability	Use efficient algorithms and data structures	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-4.3	Sustainability	Optimize compute and data operations	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-4.4	Sustainability	Implement frontend optimization	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-5.1	Sustainability	Prioritize high-value data	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SUS-5.2	Sustainability	Optimize storage lifecycle management	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-5.3	Sustainability	Optimize regionality and data movement	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-6.1	Sustainability	Phase 1: Establish a baseline	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-6.2	Sustainability	Phase 2: Identify carbon hotspots	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-6.3	Sustainability	Phase 3: Implement targeted optimization	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-6.4	Sustainability	Phase 4: Institutionalize your sustainability practices and reporting	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-7.1	Sustainability	Provide business context and alignment with organizational goals	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SUS-7.2	Sustainability	Provide role-based sustainability training	Cannot Determine	Not observable from the architecture diagram; needs process or organizational evidence.
SUS-7.3	Sustainability	Advocate for sustainability and recognize success	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.
SUS-7.4	Sustainability	Incentivize sustainability efforts	Cannot Determine	Not observable from the architecture diagram; needs runtime or operational evidence.

Findings

Medium risk (3)

F-001 Medium No model logging / observability shown · Operational excellence · Generative AI Lens · OE-1.2, PERF-4.2

Evidence. Diagram: No model logging / observability shown. Nodes: root, gem, inv, ship. Log model requests and responses (Vertex AI request-response logging to BigQuery), monitor latency, errors and token usage in Cloud Monitoring, and keep an audit trail of model and agent calls.

Impact × likelihood. Moderate × Medium → Medium. Status: Not Implemented.

Recommendation. Enable Vertex AI request-response logging to BigQuery, monitor latency, errors and token usage in Cloud Monitoring, and keep an audit trail of model and agent calls.

Priority. Delegate · effort Low · owner ML platform team

F-002 Medium No monitoring / observability shown · Operational excellence · OE-1.2, REL-5.1, PERF-4.2

Evidence. Diagram: No monitoring / observability shown. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometheus, define SLOs and alert on burn rate.

Impact × likelihood. Moderate × Medium → Medium. Status: Not Implemented.

Recommendation. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging and Cloud Trace (or Managed Service for Prometheus), define SLOs and alert on error-budget burn rate.

Priority. Delegate · effort Low · owner DevOps / SRE

F-003 Medium Internet-facing entry has no Cloud Armor / DDoS protection shown · Security, privacy, and compliance · SEC-2.1, SEC-1.2

Evidence. Diagram: Internet-facing entry has no Cloud Armor / DDoS protection shown. Nodes: ui. Protect public entry points (Cloud Load Balancing, Apigee, API Gateway) with Cloud Armor security policies (WAF rules, rate limiting, DDoS protection) and restrict backends to the load balancer.

Impact × likelihood. Moderate × Medium → Medium. Status: Not Implemented.

Recommendation. Put Cloud Armor security policies (WAF rules, rate limiting, DDoS protection) in front of every internet-facing load balancer or API entry point; start in preview mode, then enforce.

Priority. Delegate · effort Low · owner Security engineering

To confirm not drawn, so not counted as gaps

No private access or VPC Service Controls shown for managed data services SEC-2.1, SEC-7.10 — Reach Google APIs and managed data services through Private Google Access or Private Service Connect and put sensitive projects inside a VPC Service Controls perimeter.
No Cloud KMS shown for data at rest SEC-1.4 — Use Cloud KMS customer-managed keys (CMEK, Cloud HSM or EKM where required) with rotation and key-access audit logging for data at rest, and enforce TLS in transit.
No identity / authentication service shown SEC-2.2 — Authenticate and authorize every request: Identity-Aware Proxy or Identity Platform for users, least-privilege IAM roles and dedicated service accounts with Workload Identity for workloads.
No threat detection or posture management shown SEC-2.3, SEC-4.1 — Enable Security Command Center (Premium where justified), Cloud Audit Logs including Data Access for sensitive services, and Cloud IDS; route security logs to a central, access-restricted sink.
No Secret Manager or IAM database authentication shown SEC-2.2, SEC-7.10 — Use IAM database authentication and service-account identities, and keep any remaining secrets in Secret Manager with rotation.
No backup or recovery capability shown REL-8.2, REL-8.1 — Protect data with Backup and DR Service or automated backups with point-in-time recovery, snapshots, object versioning and cross-region replicas, and test restores against your RPO/RTO.
No queue / event service shown between tiers REL-6.3, PERF-3.1 — Decouple tiers with Pub/Sub, Cloud Tasks or Eventarc so traffic spikes and downstream failures do not cascade; add retries with exponential backoff, timeouts and load shedding.
No infrastructure-as-code or CI/CD shown OE-4.1, OE-4.3 — Define infrastructure as code (Terraform / Infrastructure Manager or Config Connector) and deploy through Cloud Build and Cloud Deploy with small, reversible changes, environment promotion and automated rollback.
No CDN / global edge shown for end users PERF-2.1 — Serve cacheable content from Google's edge with Cloud CDN or Media CDN behind the global external Application Load Balancer to reduce latency.
Relational database with no cache / read scaling shown PERF-3.6, PERF-2.1 — Add caching (Memorystore, Cloud CDN) or read replicas for read-heavy access.
No cost visibility shown COST-2.1, COST-2.6, COST-2.7 — Apply a consistent label scheme, export billing data to BigQuery and set Cloud Billing budgets with alert thresholds so spend maps to this workload and its owner.
Region choice is not tied to carbon intensity SUS-1.1, SUS-1.2 — Compare candidate regions by carbon-free energy percentage and grid carbon intensity (Google Cloud region picker) and use the Carbon Footprint report to track emissions.
Single-region model inference REL-3.1, REL-6.1, REL-6.3 — Plan for quota and 429 errors (retries with exponential backoff, Provisioned Throughput, dynamic shared quota, the global endpoint, a second region or a fallback model).
Model cost controls COST-3.2, COST-3.4 — Select the smallest model that meets quality targets; use context caching and batch prediction where possible; track cost per request.
Agents and excessive agency SEC-5.9, SEC-2.2 — Give agents dedicated least-privilege service accounts and scoped tools, enforce policy at the tool boundary and add human approval for high-impact actions.

Eisenhower prioritization

Do First

None

Plan

None

Delegate

F-001 No model logging / observability shown
F-002 No monitoring / observability shown
F-003 Internet-facing entry has no Cloud Armor / DDoS protection shown

Defer

None

Prioritized remediation plan

ID	Risk	Quadrant	SMART goal	Owner
F-001	Medium	Delegate	By 2026-10-16 (2 weeks): Enable Vertex AI request-response logging to BigQuery, monitor latency, errors and token usage in Cloud Monitoring, and keep an audit trail of model and agent calls. Success measure: Logging on for all model endpoints; dashboards for latency, tokens and safety events	ML platform team
F-002	Medium	Delegate	By 2026-10-16 (2 weeks): Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging and Cloud Trace (or Managed Service for Prometheus), define SLOs and alert on error-budget burn rate. Success measure: Dashboards and SLO alerts for every tier; mean time to detect < 5 minutes	DevOps / SRE
F-003	Medium	Delegate	By 2026-10-16 (2 weeks): Put Cloud Armor security policies (WAF rules, rate limiting, DDoS protection) in front of every internet-facing load balancer or API entry point; start in preview mode, then enforce. Success measure: 100% of public endpoints behind a Cloud Armor policy	Security engineering

Next steps

Add the missing process, configuration and runtime evidence to turn Cannot Determine practices into assessed ones.
Re-run the review after changes, and when the architecture or documentation changes.

Impact × Likelihood matrix from the AWS well-architected-review skill, applied to the Google Cloud Well-Architected Framework (Severe+High = Critical; Severe+Medium/Low or Moderate+High = High; Moderate+Medium/Low or Minor+High = Medium; otherwise Low).