Los cuatro tiempos del agente autónomo — el trabajo despierta cómputo efímero, el cómputo piensa por un punto único, actúa dentro de jaulas independientes, lo irreversible espera veredicto sin gastar — son el patrón de la serie, y este módulo los dibuja con las piezas de Google. Sin teoría nueva: el diagrama, la tabla de decisiones, las diferencias honestas y el puente.

La tesis del módulo

La plataforma GCP del agente autónomo es el mismo patrón con tres sabores locales: la estructura trabaja para ti (proyecto por agente = aislamiento + atribución gratis), el punto único filtra para cualquier modelo (Model Armor, por API, delante del Model Garden), y la tercera jaula tiene nombre propio (VPC Service Controls). Quien entiende los cuatro tiempos arma esta plataforma en cualquier catálogo; este módulo es la prueba.

El diagrama completo

  LA PLATAFORMA DE AGENTES AUTÓNOMOS EN GCP

  correo entra        cron 2am        humano (API)
       │                 │                │
       ▼                 ▼                ▼
  ┌─────────┐    ┌──────────────┐  ┌───────────┐
  │ Pub/Sub │    │ Cloud        │  │ API GW /  │
  │ (+DLQ)  │    │ Scheduler    │  │ Apigee    │
  └────┬────┘    └──────┬───────┘  └─────┬─────┘
       │                │                │
       └────────┬───────┴────────────────┘
                ▼    proyecto por agente ·
  ┌───────────────────────────────────────────────┐
  │ AGENTE — Cloud Run (job/service, scale-a-0)   │
  │ service account propia · secretos en el borde │
  │ estado: Firestore · Cloud SQL · GCS · BigQuery│
  └───────┬───────────────────┬───────────────────┘
          │ pensar            │ acción irreversible
          ▼                   ▼
  ┌───────────────┐   ┌────────────────────┐
  │ Vertex AI     │   │ Workflows          │
  │ (Model Garden │   │ espera aprobación  │
  │ + Model Armor)│   │ (callback+timeout) │
  └───────────────┘   └────────────────────┘

  transversales: Audit Logs → proyecto seguridad ·
  VPC-SC perímetro · Command Center · presupuestos
  → Pub/Sub → freno · cuotas API · labels

La tabla de decisiones del curso de AWS se relee columna a columna con las respuestas locales — ¿dónde vive? proyecto por agente en carpetas; ¿qué puede hacer? service account mínima auditada hacia arriba; ¿dónde corre? Cloud Run job o service según peticiones-o-tareas; ¿por dónde respira? VPC global, Private Google Access, egress por SA; ¿cómo se hablan? Pub/Sub por forma de suscripción, Tasks para ritmo; ¿dónde el estado? Firestore/Cloud SQL/GCS con BigQuery recibiendo lo frío; ¿cómo consume modelos? Vertex como gateway (proxy solo con razón); ¿quién paga? la estructura + billing export + tubería de freno; ¿administrado o propio? ADK sin miedo, Agent Runtime según diferencial; ¿cómo se blinda? las traducciones + Armor + perímetro; ¿cómo se supervisa? log-based metrics + Workflows con callback.

Qué cambió de verdad: las cinco diferencias que valen el curso

De todo lo recorrido, esto es lo que un arquitecto que viene de AWS debe recablear — el resto fue traducción:

#	Diferencia	Consecuencia de diseño
1	El proyecto es liviano	Proyecto por agente: aislamiento, cuotas y FinOps vienen de la estructura, no del esfuerzo
2	La VPC es global; el firewall habla identidad	Menos plomería inter-región; reglas por service account = red e IAM nombran al mismo actor
3	Pub/Sub unifica cola y abanico; Tasks agrega ritmo	Se elige forma de suscripción, no servicio; el destino frágil se protege con un dial
4	BigQuery es protagonista	Los datos fríos, el billing y las métricas convergen en SQL; el costo por tarea real es un JOIN
5	ADK es open source; VPC-SC existe	El framework no acopla (adopción por pieza barata) y la tercera jaula es un servicio con nombre

Y una constante que vale como sexta fila: todo lo que era doctrina siguió siendo doctrina — el rol mínimo, el egress corto, la idempotencia, el freno en capas, el timeout que jamás aprueba por silencio. Las nubes compiten en catálogo; la arquitectura buena es aburridamente portable.

Las tres escalas y las cuatro piezas no diferibles

Las escalas de adopción (piloto / producción / plataforma) se trasladan con sus columnas equivalentes — y las cuatro piezas no diferibles se traducen así: service account propia por agente, suscripción con DLQ, proyecto-por-agente (que en GCP absorbe el rol de los tags) y presupuesto con alerta. Horas de trabajo, ninguna escala las excusa, misma frase: la diferencia entre incidente y anécdota.

Ojo — el examen se rinde igual: toma tu caso (o los dos de la Metodología), dibuja tu versión de este diagrama y justifica cada caja con su módulo. Si ya hiciste el ejercicio en AWS, hazlo aquí y compara: las cajas que cambiaron de nombre sin cambiar de razón son la prueba de que aprendiste arquitectura y no catálogo.

El puente a Azure

El tercer curso de la serie cierra el triángulo, y su tabla de entrada ya se puede adelantar:

Concepto	AWS	GCP	En Azure verás
Unidad de aislamiento	Cuenta	Proyecto	Suscripción + resource group (dos niveles)
Identidad de workload	Rol IAM	Service account	Managed identity (sobre Entra ID)
Cómputo efímero	Lambda/Fargate	Cloud Run	Container Apps / Functions
Colas y eventos	SQS/EventBridge	Pub/Sub/Eventarc	Service Bus / Event Grid
Modelos administrados	Bedrock	Vertex AI	Microsoft Foundry (con OpenAI en casa)
Espera de veredicto	Step Functions	Workflows	Durable Functions / Logic Apps

La fila de identidad esconde la diferencia filosófica más grande del tercer curso: en Azure, la identidad (Entra ID) no vive dentro de la nube — la nube vive dentro del directorio corporativo. Por ahí empezará.

Errores comunes (los del cruce, destilados)

Calcar AWS caja por caja. El que replica “una cuenta = un proyecto” y “SQS+SNS = dos servicios” construye una plataforma AWS con precios de GCP. Las cinco diferencias existen para explotarse.
No explotar la estructura. Proyecto-por-agente es la decisión que más regala (aislamiento, cuotas, FinOps) y la más barata. Ignorarla por inercia de mega-cuenta es dejar el diferencial de GCP en la mesa.
Saltarse las cuatro no diferibles. SA propia, DLQ, proyecto propio, presupuesto. En ninguna nube hay excusa; en esta, dos de las cuatro son casi gratis.
Tratar la referencia como dogma. Igual que en AWS: cambia piezas sabiendo qué decisión tomas — la tabla con los módulos existe para eso.
Creer que la tercera nube será igual de traducible. Azure comparte el patrón, pero su eje identidad-primero (Entra, suscripciones, el tenant) reordena el módulo 1 entero. El puente es puente, no pasarela.

La frase para llevarse

“GCP recompensa al que usa la estructura: proyecto por agente, suscripciones con forma, SQL sobre todo lo frío, y las tres jaulas con la tercera de fábrica. Los cuatro tiempos no cambiaron — y esa es la lección de la serie: el catálogo es dialecto; el patrón es el idioma.”

Qué viene

El curso de Azure cierra la serie: mismo esqueleto, tabla de equivalencias en cada módulo, y el espacio para lo que Microsoft hace distinto — la identidad como centro de gravedad (Entra ID, managed identities), Container Apps y las Durable Functions, Service Bus con sesiones, Microsoft Foundry con OpenAI como inquilino estrella, y la aprobación asíncrona con el patrón de interacción humana más maduro del mercado. El triángulo se cierra ahí — con la tabla tri-cloud final y la pregunta que todo arquitecto debe poder responder: ¿cuál nube para qué?

Arquitectura GCP — Módulo 12: la arquitectura de referencia