I want to bring you into a conversation that has reached a point where your input is critical before we proceed. Let me first give you the full picture of where we are, and then put the strategic questions to you.

Where We Are

We have been in active conversations with GCP about potentially migrating from AWS to GCP. GCP is supportive — $100k in credits is confirmed, with a realistic path to $300k–$500k over 24 months by stacking their startup, AI, and ISV programmes. This changes the economics meaningfully.

The migration question has also surfaced a bigger one: if we are moving infrastructure anyway, this is likely the natural moment to incorporate higher AI capability and scale into the architecture from the start — rather than migrating like-for-like and retrofitting intelligence later. The two questions are therefore connected: whether to migrate, and how ambitious to be about what we build when we do.

I am not asking you to design or build anything yet. I am asking whether these directions are technically sound and what we would be getting ourselves into.

The GCP Migration — Service Mapping

GCP has reviewed our current stack and provided a service-by-service assessment. The proposed mapping is:

• Aurora PostgreSQL → AlloyDB (pgvector supported — no change to vector search approach)
• Lambda → Cloud Run (better fit for long-running AI workloads, no cold start penalty on 30s+ reasoning chains)
• EventBridge → Pub/Sub + Eventarc
• DynamoDB → Firestore
• Cognito → Firebase Auth (flagged as highest-risk migration item)
• API Gateway → Cloud API Gateway
• AWS IoT Core → ClearBlade IoT Core — Google's official drop-in replacement, GCP Marketplace, maps directly to our existing JWT webhook auth pattern from the MQTT-Authorizer Lambda

Non-Negotiable: Globally Distributed Architecture

• us-central1 or us-east1 — US enterprise customers (S7, US-based corporates)
• europe-west1 or europe-west4 — EU customers + GDPR data residency enforcement
• africa-south1 (Johannesburg) — SA/African customers + POPIA compliance + sub-20ms SA latency

The AI Opportunity — Built In, Not Bolted On

If we are rebuilding on GCP, the case for going AI-native from the start is strong. The GCP services we are migrating to — Cloud Run, Pub/Sub, AlloyDB with pgvector — are exactly the right substrate for an agentic architecture. Building it in now costs significantly less than retrofitting after the fact.

The concept is to evolve Pulse Next from a passive dashboard into an autonomous duty-of-care intelligence system, built on five specialist agents coordinated by a central orchestrator:

• Risk Intelligence Agent — ingests threat feeds, advisories, and news; maintains real-time risk scores per country per org; operates on a 72-hour forward simulation horizon
• Traveller Monitor Agent — tracks each active traveller against their org's risk thresholds; flags deviations, missed check-ins, travellers in deteriorating zones; queries regional AlloyDB only
• Comms Agent — drafts and sends alerts when thresholds breach; multi-channel (push, SMS, email); tone-matched to severity
• Incident Response Agent — activates playbook steps when an incident is declared; full immutable audit log; coordinates with Comms Agent
• Playbook Agent — interprets each tenant's natural-language duty-of-care policy at runtime; no hard-coded rules per tenant; pgvector semantic policy lookup

Orchestrated by a central Duty-of-Care Orchestrator with an approval queue: AI proposes, human approves high-stakes actions (mass alerts, incident declarations, SOS escalations). Agents act autonomously below a configurable confidence threshold.

LLM strategy: Gemini Flash for high-volume routine monitoring (cost-efficient). Claude Sonnet for critical reasoning paths where quality matters.

On the regional architecture for the agent layer, two options are in play:

How Far Should We Go with AI?

The migration creates a natural forcing function. Once we are on GCP, the question is not whether to add intelligence — it's where on the spectrum to land for the initial build. Three positions:

Support Available to Us

Before asking what this costs, it's worth being clear on what support we have access to:

GTM Protection — This Cannot Delay Go-Live

Two parallel track models are in scope for Boris and Dohan's assessment:

Architecture Diagram — For Technical Review

Strategic Considerations — Where I Need Your Input

At this juncture, before any decision is made, I want your honest technical read:

1. Does the overall GCP migration direction make sense, or are there landmines in the service mapping we have not accounted for?
2. Three-region from day one — what does this realistically add to complexity and cost? Any specific gotchas with regional AlloyDB and our write-back patterns?
3. ClearBlade for MQTT — any red flags given our existing JWT webhook auth logic? Does the mapping hold in practice?
4. How far do we go with AI? Level 1 (like-for-like), Level 2 (AI-augmented), or Level 3 (fully agentic)? Is the answer different for the migration phase vs the product build phase? Your honest read on where the right risk/value trade-off sits right now.
5. If we go Level 3 — is the agentic architecture technically feasible on this foundation, and what is the order-of-magnitude effort? Not a full estimate, just a directional read.
6. Option A vs Option B on regional agent orchestration — what would you do and why?
7. GTM protection — Track A or Track B? Is running V2 (AWS) in parallel alongside a clean Pulse Next GCP build viable without compromising either? What is the minimum realistic resource requirement to do that? If Track A is not viable, what's the alternative that still honours existing go-live commitments?
8. What is the right build sequence — migration scaffolding first, then AI layer on top, or does the agentic architecture need to drive the migration decisions from the start?