DEV Community: Google Developer Group

Managed Inference on Google Cloud: Pairing the Gemini Enterprise Agent Platform with Cloud Run

Caleb Duff — Wed, 12 Aug 2026 15:45:27 +0000

If you have ever wanted to ship an AI-powered application without managing GPUs, model servers, or scaling infrastructure yourself, this guide is for you.

Managed inference simply means letting a cloud provider run the AI model for you: you send a request, the platform handles the compute, and you get a response back. On Google Cloud, the cleanest way to do this today is to pair the Gemini Enterprise Agent Platform (formerly Vertex AI) with Google Cloud Run, dividing responsibilities between the two services. The Agent Platform serves as the orchestration and intelligence engine, while Cloud Run hosts your custom application logic, front-end UIs, or Model Context Protocol (MCP) servers.

By the end of this article, you will be able to:

Explain the hybrid architecture and why each layer exists
Define an AI agent in code using the Agent Development Kit (ADK)
Deploy your app layer to Cloud Run with a single command
Choose between online and batch inference for your workload
Secure and monitor the whole setup in production

New to the underlying concept? Start with Google Cloud's primer: What is AI inference?

Prerequisites

To follow along hands-on, you will need:

A Google Cloud project with billing enabled
The gcloud CLI installed and authenticated
Python 3.10+ and the ADK installed (pip install google-adk)

You can also read this purely as an architecture walkthrough; every step is explained, not just shown.

1. The Architectural Blueprint

This pattern splits your system into independent, auto-scaling tiers:

[ Client / Web UI ] ──> [ Cloud Run Service ] (App Logic / Tool Front End)
                                │
                                ▼
        [ Gemini Enterprise Agent Platform — Agent Runtime ]
            (Orchestration, Intent Analysis, Memory)
                                │
                                ▼
              [ Managed Inference / Model Garden ]
                 (Gemini 3.x Pro / Flash models)

Why split it this way? Each tier scales independently and fails independently. Your web front end can handle a traffic spike without touching the model layer, and you can swap models without redeploying your application code. It also creates a clean security boundary, clients only ever talk to Cloud Run, never directly to the model.

Here is what each layer actually does:

Cloud Run runs your specialized business logic, secures client-facing endpoints with Identity-Aware Proxy (IAP), and hosts external tools, MCP servers, and APIs. Think of it as everything you build.
The Agent Platform (Agent Runtime) manages active agent state, long-term memory, and the model's reasoning steps in a centralized, fully managed runtime. Think of it as everything Google runs for you.

2. Build Your Agent Code with the ADK

Use the open-source Agent Development Kit (ADK) to define your agent's behavior in code and bind it to a model. The key idea to understand: tools are plain Python functions. The ADK reads each function's docstring to decide when and how to call it; so a clear docstring is not documentation nicety, it is part of your agent's logic.

# agent.py
from google.adk.agents import Agent

def call_internal_business_system(query: str) -> str:
    """Invokes secure business workflows deployed on Cloud Run."""
    # Logic to securely call your Cloud Run service URL
    return "Data retrieved from secure internal backend."

# Define an agent that targets a current Gemini model
root_agent = Agent(
    name="enterprise_inference_agent",
    model="gemini-3.5-flash",  # Or another current model from Model Garden
    instruction="You are a data processing assistant using managed inference.",
    tools=[call_internal_business_system],
)

Breaking down the four fields:

name — an identifier for your agent, used in logs and traces.
model — which Gemini model handles the reasoning. Flash models are faster and cheaper; Pro models handle more complex reasoning.
instruction — the agent's system prompt, shaping its behavior on every request.
tools — the Python functions the model is allowed to call. When a user request matches a tool's docstring, the model invokes it.

Note: Gemini 1.0 and 1.5 models (including gemini-1.5-pro) have been retired and now return errors. Always target a currently supported model, such as gemini-3.5-flash, gemini-3.6-flash, or a Gemini 3.x Pro release from Model Garden.

3. Containerize and Deploy the App Layer to Cloud Run

When deploying your orchestration backend or front-end dashboard, the tooling can package and push the container for you. Two small steps get you there.

Step A: Configure Service Account Permissions

In Google Cloud, services do not trust each other by default, your Cloud Run instance needs explicit permission to invoke Agent Platform endpoints. This command grants its service account that permission:

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
    --member="serviceAccount:YOUR_RUN_SA@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/aiplatform.user"

In plain terms: "let this Cloud Run service call the AI platform." This is the step people most often forget; if your deployed service returns permission errors, come back here first.

Step B: Build and Deploy

The ADK ships with a one-command deployment path. Under the hood, it does three things: builds your container image, pushes it to Artifact Registry, and creates (or updates) the Cloud Run service.

# Deploys your custom agent or tool layer directly to Cloud Run
adk deploy cloud_run \
    --project="YOUR_PROJECT_ID" \
    --region="us-central1" \
    --service_name="agent-inference-backend" \
    path/to/your/agent

Alternatively, the Agents CLI (agents-cli) can scaffold the deployment configuration for a Cloud Run target. For example, agents-cli scaffold enhance --deployment-target cloud_run and works from inside your preferred AI coding tool. Either route wires up your environment variables, including model targets and the public service URL.

4. Online and Batch Inference Routines

Once the plumbing is in place, there are two primary ways to trigger managed inference. Choosing correctly comes down to one question: does a human need the answer right now?

Online inference (low-latency UI): Make synchronous API calls from your Cloud Run front end directly to the deployed agent endpoint for real-time chat, tool calls, or step-by-step reasoning. Example: a customer support chatbot where every second of latency matters.
Batch inference (high-volume data): For large data processing jobs, submit an asynchronous batch prediction job through the Agent Platform SDK. The platform provisions dedicated compute, runs the inference tasks, writes results and logs to Cloud Storage, and tears down the compute automatically when the job completes. Example: classifying 100,000 support tickets overnight; nobody is waiting on a single response, so throughput and cost matter more than latency.

Batch jobs are typically much cheaper per request, so a good rule of thumb is the "Now vs Later" latency and volume test: if you need a prediction in under 2 seconds(quickly) to serve a live user, use online inference; if you have a large volume of data that can wait minutes or hours, use batch inference.

5. Secure and Monitor the Architecture

A demo can skip this section. Production cannot.

Secure the ingress: Wrap your Cloud Run endpoints in Identity-Aware Proxy (IAP) to protect human-in-the-loop dashboards, IAP checks the user's Google identity before traffic ever reaches your code. For agent-to-tool traffic, Agent Gateway can give each agent a unique identity with end-to-end mTLS (mutual TLS, where both sides verify each other) when calling MCP servers on Cloud Run.
Centralize trace logging: Enable the platform's built-in OpenTelemetry tracing (Cloud Trace is on by default for CLI-based deployments). You can visually inspect directed acyclic graphs (DAGs) of execution, a step-by-step map of every reasoning step, model call, and tool invocation — to see exactly how your Gemini models and Cloud Run tools collaborated on an inference task. When an agent gives a strange answer, this trace is how you find out why.

Key Takeaways

Split the responsibilities: Cloud Run for your code, the Agent Platform for orchestration and models. Each tier scales and fails independently.
Tools are just functions: the ADK turns well-documented Python functions into capabilities your agent can call.
Permissions before deployment: grant roles/aiplatform.user to your Cloud Run service account, or nothing else will work.
Match inference mode to workload: online for interactive experiences, batch for high-volume processing.
Secure and trace from day one: IAP at the edge, mTLS between services, OpenTelemetry for visibility.

Where to Go Next

Try the smallest possible version: define a one-tool agent with the ADK, run adk deploy cloud_run, and send it a request. Once that works, everything else in this article is an incremental addition.

Have you tried pairing the Agent Platform with Cloud Run, or are you still on a self-managed inference setup? I would love to hear what your architecture looks like in the comments.

Angular WebMCP — Your App is Now an AI Tool 🔥🚀

Giorgio Galassi — Sat, 08 Aug 2026 10:09:17 +0000

There's a pattern in Angular releases that I've come to appreciate: every major version picks one bet that's slightly ahead of its time. Signals were that bet in v16. Zoneless was that bet in v21. In v22, that bet is WebMCP, and it's a fundamentally different kind of feature — not a framework improvement, but an architectural shift in what an Angular app is.

Let me explain what I mean.

🧭 The Idea: Outside → In

Every Angular feature so far has been about what happens inside the app — how components detect changes, how services are injected, how forms manage state. WebMCP is different: it's about exposing your app's capabilities to the outside, specifically to AI agents running in the browser.

The mental model is simple. Today, an AI assistant browsing your app sees a DOM — pixels and HTML. It can read text and click buttons, but it has no understanding of what your app can do. WebMCP changes that. You declare a set of tools backed by your real Angular services, your real signals, your real DI graph, and any WebMCP-capable agent can discover and call them directly through a typed, described interface you control.

This is different from Agent Skills, which is your app calling out to AI. Two separate features, two directions: WebMCP is agents driving your app; Agent Skills is your app calling AI. Today we're only talking about WebMCP.

🔧 Browser Support

WebMCP is built on the W3C ModelContext API, a draft browser standard. Your tools register on navigator.modelContext and any agent that speaks this protocol can query that object and call them.

As of June 2026, Edge 147 ships it natively, Chrome 149 has an open Origin Trial, Firefox is committed for Q3 2026, and Safari for Q4. Mass adoption is realistically mid-2027, and Angular ships this as experimental — that flag is honest, but the integration is already surprisingly clean.

⚠️ Experimental: provideExperimentalWebMcpTools() is available in Angular 22 but carries no stability guarantees yet. The W3C spec is still evolving; expect API changes before general availability.

🛠️ Building Your First WebMCP Tool

Let's build something concrete. A dashboard shows a list of expenses and we want an AI assistant to ask "what expenses are currently visible?" and get real, live data back — not a DOM scrape or a static API response, but the actual signal state the component is rendering from.

Step 1: The service

// expense.service.ts
import { Service, signal } from '@angular/core';

export interface Expense {
  id: string;
  description: string;
  amount: number;
  currency: string;
  category: ExpenseCategory;
}

export const ExpenseCategory = {
  Accommodation: 'accommodation',
  Transport: 'transport',
  Meals: 'meals',
} as const;

export type ExpenseCategory = typeof ExpenseCategory[keyof typeof ExpenseCategory];

export const CATEGORY_VALUES = Object.values(ExpenseCategory).join(', ');

@Service()
export class ExpenseService {
  private expenses = signal<Expense[]>([
    { id: '1', description: 'Hotel',  amount: 250, currency: 'USD', category: ExpenseCategory.Accommodation },
    { id: '2', description: 'Taxi',   amount: 35,  currency: 'USD', category: ExpenseCategory.Transport },
    { id: '3', description: 'Dinner', amount: 80,  currency: 'USD', category: ExpenseCategory.Meals },
  ]);

  getVisible(): Expense[] {
    return this.expenses();
  }
}

@Service() is Angular 22's new shorthand for @Injectable({ providedIn: 'root' }) — if you want the full picture on that, I covered it in Angular 22 — @Service and injectAsync: Dependency Injection Finally Grows Up. Notice that CATEGORY_VALUES lives right here next to the ExpenseCategory object — we'll use it to keep the tool description in sync automatically.

Step 2: Declaring the tool

Parameters are described using JSON Schema syntax — the same format Angular uses internally and the same format the agent receives.

// expense-mcp.tool.ts
import { declareExperimentalWebMcpTool, inject } from '@angular/core';
import { ExpenseService, ExpenseCategory, CATEGORY_VALUES } from './expense.service';

export const expenseListTool = declareExperimentalWebMcpTool({
  name: 'getVisibleExpenses',
  description: 'Returns the list of expenses currently visible in the dashboard.',
  inputSchema: {
    type: 'object',
    properties: {
      category: {
        type: 'string',
        description: `Filter by expense category. Allowed values: ${CATEGORY_VALUES}.`,
      },
    },
    additionalProperties: false,
  },
  execute: ({ category }: { category?: ExpenseCategory }) => {
    const svc = inject(ExpenseService);
    const all = svc.getVisible();
    const filtered = category ? all.filter(e => e.category === category) : all;
    return { content: [{ type: 'text', text: JSON.stringify(filtered) }] };
  }
});

Four things to notice here.

The return value follows the MCP tool result format. { content: [{ type: 'text', text: '...' }] } is the wire format the agent expects, defined by the Model Context Protocol spec. You don't return a plain object or array directly — you serialise your data into that text field with JSON.stringify, and the agent parses it on its end. This is not Angular-specific; it's the protocol contract every MCP tool must honour.

name and description are instructions to the LLM, not documentation for humans. The agent reads them at runtime to decide whether and how to call the tool, so write them like an OpenAPI spec for an AI: precise, specific, unambiguous.

execute runs inside Angular's injection context, which means inject() works normally and your tool has full access to your DI graph.

CATEGORY_VALUES is derived from the object, not hardcoded. Add a value to ExpenseCategory and the agent description updates automatically, with no second place to maintain.

Step 3: Registering in the app

// app.config.ts
import { provideExperimentalWebMcpTools } from '@angular/core';
import { expenseListTool } from './expense-mcp.tool';

export const appConfig = {
  providers: [
    provideExperimentalWebMcpTools([expenseListTool]),
    // ... rest of your providers
  ]
};

One line in your app config and you're done. From here, any WebMCP-capable agent visiting your app will find getVisibleExpenses in document.modelContext.tools and can call it against the live session.

🔍 What the Agent Actually Sees

When a WebMCP-capable agent inspects the page, this is what it finds on document.modelContext:

{
  "tools": [
    {
      "name": "getVisibleExpenses",
      "description": "Returns the list of expenses currently visible in the dashboard.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "category": {
            "type": "string",
            "description": "Filter by expense category. Allowed values: accommodation, transport, meals."
          }
        },
        "additionalProperties": false
      }
    }
  ]
}

The user says "show me only transport expenses." The agent reads the schema, resolves category: "transport", calls the tool. Angular runs the handler against the live signal state. The agent gets back exactly the filtered rows the dashboard is currently showing — no DOM scraping, no brittle selectors, no static mock data.

⚛️ Signal Forms as Agent Tools

If your app is form-heavy, Angular 22 also ships provideExperimentalWebMcpForms(), which automatically surfaces all your Signal Forms as agent-callable tools without you having to declare each one manually.

// app.config.ts
import { provideExperimentalWebMcpForms } from '@angular/forms/signals';

export const appConfig = {
  providers: [
    provideExperimentalWebMcpForms(),
  ]
};

⚠️ Experimental: provideExperimentalWebMcpForms() is double-experimental — both WebMCP itself and the forms integration are in preview. Treat it as a proof of concept for now.

Each Signal Form becomes a tool the agent can fill and submit. For internal tooling or admin dashboards this is already genuinely useful, and it shows where the Angular team is heading: if Signal Forms are the way to model user intent, they should also be the way to model agent intent.

💡 Beyond the Happy Path

The docs highlight forms as the easy entry point, but the more interesting territory is everything else — read queries, write actions, navigation triggers.

Let's be honest: a read + write pair is where agents become genuinely powerful. Expose getExpenseReports() alongside flagExpense(id, reason) and an agent can query, reason over the data, and act in a single turn. Add permission-awareness by injecting your AuthService inside the execute handler and the agent automatically gets a properly scoped view, seeing only what the current user is authorised to see. You could also expose derived data tools like getSummaryByCategory() — pre-computed aggregates cost fewer tokens and produce faster responses than handing the agent a raw list to process itself.

The general principle worth internalising: anywhere you'd write a hardcoded string describing your domain model, ask whether you can derive it from TypeScript instead. Your types are the single source of truth and the agent's schema should follow from them, not diverge from them.

🔒 One Thing Worth Getting Right Early: Trust

Because execute handlers run inside Angular's injection context with full access to your DI graph, a WebMCP tool is as powerful as the service method it wraps — which means a write tool is a real mutation, not a preview. Before shipping any tool that modifies state, there are three things worth understanding.

Prompt injection in your descriptions. The description and parameter description fields are read by the LLM as trusted context. A malicious site can embed instructions in its own tool descriptions that manipulate the agent's behaviour on other sites — and if your own tool returns user-generated content, that content is another vector. The W3C security considerations doc calls this out explicitly under "Metadata / Description Attacks" and "Output Injection Attacks": never echo unsanitised user content directly from an execute handler.

Angular does not validate inputs for you. The agent is supposed to match the inputSchema you define, but Angular makes no guarantee it does — the execute callback receives whatever the agent sends. The Angular docs are explicit on this: "Consider explicitly validating arguments to the execute function before using them." Treat every input as untrusted, the same way you would a form submission or a query parameter.

The session is the attack surface. The W3C spec's threat model notes that agents inherit the user's authentication context — session cookies, logged-in state, everything. The real risk isn't an anonymous external caller; same-origin constraints handle that. The risk is a legitimate, trusted agent that has been manipulated through prompt injection and then calls your write tools with the user's full permissions. Design accordingly: scope write tools tightly, and never expose an action you wouldn't want triggered automatically on behalf of a logged-in user.

⚠️ The Honest Caveat

The W3C spec is still early and has been changing frequently. Mid-2027 is the realistic mass-adoption target, when both browser default support and enough publisher adoption exist to make it meaningful at scale. For now it's great for internal tools and early experimentation, but it's not ready to ship to anonymous production users.

That said, the direction is set. Your app has always had one interface — the DOM, for humans. WebMCP adds a second one, for agents. How you design that second surface is a new skill worth starting to develop now, before the spec lands and everyone is catching up at once.

If you found this helpful, follow me here and on LinkedIn for more deep dives into Angular, signals, AI, and modern frontend development.

See you in the next one! 🤙🏻
— G.

linkedSignal() Writes Back: A Trace Through the Reactive Graph 🔍🚀

Giorgio Galassi — Fri, 07 Aug 2026 08:43:39 +0000

Let's be honest: linkedSignal() always had a bit of a split personality. It read beautifully from another signal, deriving a value that stayed in sync automatically. But the moment you needed to write back to that source, you were on your own, writing a separate method, converting the value by hand, and hoping you didn't forget to call it from every place that touched the field.

Angular 22.1 closes that gap. linkedSignal() can now take a custom set() option, and the linkedSignal becomes a genuine two-way field: read from a larger piece of state, write back to it, no disconnected duplicate copy of the data anywhere.

My first reaction when I saw this: if the linkedSignal reads a source signal, and writing to the linkedSignal updates that same source, doesn't that loop forever? It didn't feel obvious to me, so I went and traced through the actual reactive graph source to settle it, and that turned into a nice little tour of how Angular's signals actually work.

✅ Availability: the custom set() option shipped in Angular 22.1.0 (stable) and is documented in the official linkedSignal guide.

🧩 Before: Reading Was Clean, Writing Wasn't

Here's the classic shape. A profile signal holds the real state, and a linkedSignal exposes one field of it:

protected readonly profile = signal<UserProfile>({
  id: 1,
  name: 'Brian',
  email: 'brian@example.com',
  maxMarketingEmailsPerWeek: 2,
});

protected readonly maxMarketingEmailsPerWeek = linkedSignal(
  () => this.profile().maxMarketingEmailsPerWeek
);

Reading maxMarketingEmailsPerWeek() is effortless. Writing back to profile is not: you need a second method that does the profile.update() dance, and every button, every input handler, has to remember to call that method instead of the linkedSignal directly. The read side and the write side live in two different places for what is conceptually one piece of state.

🔧 After: A Custom set()

The fix is a set function passed alongside the computation:

protected readonly maxMarketingEmailsPerWeek = linkedSignal(
  () => this.profile().maxMarketingEmailsPerWeek,
  {
    set: (value) => {
      this.profile.update((profile) => ({
        ...profile,
        maxMarketingEmailsPerWeek: value,
      }));
    },
  }
);

Now maxMarketingEmailsPerWeek.set(5) and .update(v => v + 1) both flow through that setter and land on profile. The helper method is gone. The simplest version of this idea, straight from the Angular docs, is a temperature converter:

const tempC = signal(0);
const tempF = linkedSignal(() => (tempC() * 9) / 5 + 32, {
  set: (valF) => tempC.set(((valF - 32) * 5) / 9),
});

tempF.set(212);
console.log(tempC()); // 100
console.log(tempF()); // 212

🧠 Wait, Doesn't This Loop?

Here's where I got stuck. tempF reads tempC() inside its computation, so tempF is a genuine dependent of tempC in the reactive graph. When tempC.set(100) runs inside the custom setter, that dependency absolutely gets marked dirty and tempF absolutely does recompute. If it didn't, tempF() would show a stale value after the conversion, and the whole feature would be pointless.

So the question I actually needed answered was: does that recompute call the custom setter again? It doesn't, and the reason is architectural, not incidental.

🔍 Under the Hood: The Write Path

linkedSignal's public write API, defined in linked_signal.ts, looks like this once a custom setter is supplied:

const rawSet = (newValue: D) => linkedSignalSetFn(node, newValue);
upgradedGetter.set = (newValue: D) => customSet(newValue, rawSet);
upgradedGetter.update = (updateFn: (value: D) => D) =>
  customSet(updateFn(untracked(getter)), rawSet);

Calling tempF.set(212) invokes exactly one thing: your customSet function. It never touches tempF's own internal value directly, unless your function explicitly calls the rawSet escape hatch it's handed. In the temperature example, it doesn't, it only calls tempC.set(100).

The temperature example never reaches for that second parameter, but there are two situations where you would. One is performance: when computation is expensive and you already know the exact result, rerunning it is wasted work. The other is less obvious: not every linkedSignal has an invertible relationship with its source the way tempF/tempC do. Plenty of real computation functions, summarizing, rounding, picking one field out of several possible source states, can't be inverted into a single correct value to write back. rawSet covers both: it's a direct line to the exact primitive that backs the default .set() when there's no custom setter at all, letting you plant the value directly instead of inverting through the source:

} else {
  upgradedGetter.set = (newValue: D) => linkedSignalSetFn(node, newValue);
  upgradedGetter.update = (updateFn) => linkedSignalUpdateFn(node, updateFn);
}

rawSet is (newValue) => linkedSignalSetFn(node, newValue), the same call, just handed to you as an argument instead of wired up automatically. Here's what that function actually does, from the signal primitives:

export function linkedSignalSetFn<S, D>(node: LinkedSignalNode<S, D>, newValue: D) {
  producerUpdateValueVersion(node); // resolve any pending staleness first
  signalSetFn(node, newValue);      // plain field write: node.value = newValue, version++
  producerMarkClean(node);          // mark the node up to date
}

Three steps: settle any recompute that's already overdue, write node.value directly with the same primitive a plain signal() uses (never touching node.computation or node.sourceValue), then mark the node clean.

That first step is worth pausing on, because "settle any overdue recompute" is literal. If the linkedSignal is currently dirty, its source changed since anyone last read it, producerUpdateValueVersion runs producerRecomputeValue before your value ever gets written, which means computation fires once, and if it has any observable side effects, they happen. Your value always wins in the end, the freshly recomputed result gets overwritten immediately after, but "computation never runs" isn't quite true in that specific case. The mark-clean step is what matters for everything after this call: it tells the next read's staleness check that the node is current, so from then on producerRecomputeValue is skipped, regardless of what the source is doing in the meantime.

Line them up and there are three distinct write paths, not two:

`.set()`	What happens	`computation`
Default, no custom setter	Calls `linkedSignalSetFn(node, v)` directly.	Does not run. Exception: if the node was already `stale` due to an earlier unread source change, it runs once first to settle the pending recomputation.
Custom setter, setter writes to the source	Only the source's version is bumped. This node is marked dirty but is otherwise untouched.	Re-runs lazily, the next time the `linkedSignal` is read.
Custom setter, setter calls `rawSet(v)`	Identical to the default case: calls `linkedSignalSetFn(node, v)`.	Does not run, except when there is already a pending stale recomputation that must settle first.

Here's the performance case: a custom setter with independent knowledge of the right answer, where redoing the computation would be wasted work:

const items = signal<Item[]>(hugeInitialList);

const sortedItems = linkedSignal(
  () => expensiveSort(items()), // recomputes whenever items() changes
  {
    set: (value, rawSet) => {
      // We just got an already-sorted page back from the server —
      // no need to re-run expensiveSort() for a value we already know.
      rawSet(value);
    },
  },
);

sortedItems.set(pageFromServer); // writes directly, skipping a fresh expensiveSort() run

Compare that to the temperature example: there, the setter calls tempC.set(...) because it genuinely needs tempF to re-derive from the new tempC. Here, the setter already has the final value, so it bypasses the derivation instead of inverting it.

And here's the other case, where inverting through the source isn't just wasteful, it doesn't make sense at all:

const rawInput = signal('42.7');

const roundedValue = linkedSignal(
  () => Math.round(Number(rawInput())),
  {
    set: (value, rawSet) => {
      // Multiple rawInput strings round to the same integer, there's
      // no single correct string to write back, so just store the value.
      rawSet(value);
    },
  },
);

Rounding is lossy: many different rawInput values produce the same roundedValue, so there's no correct string for the setter to write back to rawInput. rawSet sidesteps the question entirely, it's the same direct write the default .set() would give you if there were no custom setter at all.

Both cases share the same shape: rawSet is for when inverting through the source is either wasteful or doesn't make sense, and you'd rather just set the value. It also keeps a single public method for callers: .set(x) works the same way from the outside whether this particular value is a normal edit that should flow through the source, or a precomputed result the setter recognizes and stores directly. The linkedSignal, not the caller, decides which applies.

That's the entire write path, everything .set() and .update() can reach, custom setter or not. rawSet can reach into the recompute machinery to settle a pending stale value, but never the other way around.

⚙️ Under the Hood: The Recompute Path

The recompute lives somewhere else entirely, in the signal primitives:

const linkedSignalGetter = () => {
  producerUpdateValueVersion(node); // check staleness, recompute if needed
  producerAccessed(node);
  return node.value;
};

Every signal getter, plain signal(), computed(), or linkedSignal(), is shaped this way. producerUpdateValueVersion checks whether any dependency's version changed since the last read, and if so, calls producerRecomputeValue, which reruns the computation and assigns straight to node.value as a plain field write:

newValue = node.computation(newSourceValue, prev);
node.sourceValue = newSourceValue;
// ...
node.value = newValue;
node.version++;

That's the whole answer. tempC.set(100) only flips a dirty flag and bumps a version counter, no computation runs at that moment. The actual recomputation is deferred until the next time something reads tempF(), and when it happens, it happens through producerRecomputeValue, a function that has never heard of customSet. Not directly, not indirectly. There's no code path in the primitives package that leads back to your setter. That direction is the one that would actually matter: if recomputation could call back into customSet, that's the loop you'd have to worry about, and it provably can't. The reverse isn't quite as absolute, rawSet can call into producerRecomputeValue to settle a pending stale value, as covered above, but even then it only ever reaches this same recompute logic, never back into your setter. That asymmetry, not a strict mutual isolation, is the whole reason a linkedSignal can safely both read from and write to the same piece of state.

One detail worth keeping in mind: this recompute isn't scheduled for later, it's synchronous and pull-based. If tempF() is read inside another computed(), the staleness check and recompute for tempF happen inline, in the same call stack, before that outer computed can finish. Angular's signals are lazy all the way down: nothing recalculates until someone actually asks for a value, but once something does ask, the whole stale chain resolves immediately, in dependency order.

✅ Closing Thoughts

So, back to the question that opened this piece: no, it doesn't loop, and now you know exactly why: producerRecomputeValue can't reach back into customSet, only rawSet reaches the other way. That one-way gap is what makes it safe.

The custom set() option is a small addition on paper, one new field in an options object, but it changes what linkedSignal() is for. Before, it was a read-only derivation with a writable escape hatch bolted on by convention (the default set/update, with no custom setter, just overwrites the linkedSignal's own value directly). Now it can be the field-level API for a slice of larger state, without ever creating a second source of truth. And it does that safely because Angular's signal graph keeps "someone wrote to me" and "one of my dependencies changed" as two structurally separate events, not because of anything defensive in the code you write.

If you haven't read my earlier piece comparing computed() and linkedSignal(), that's the conceptual "when to reach for which" companion to this one, this article is the deep end: the internals that explain why the two-way version is safe.

If you're touching linkedSignal() in a codebase that also uses Signal Forms or resource(), the same lazy, pull-based recompute model is running underneath all of them. Worth understanding once, pays off everywhere.

If you found this helpful, follow me here and on LinkedIn for more deep dives into Angular, web performance, and modern frontend development.

See you in the next one! 🤙🏻
— G.

Zero to Multi-Region: High Availability Serverless with Cloud Run and Cross-Region Failover & Failback

Caleb Duff — Fri, 24 Jul 2026 00:52:30 +0000

Google just made multi-region Cloud Run significantly easier. Here is the full picture; what changed, what it means in practice, and how to build it right.

Most teams discover they need multi-region architecture the hard way and sadly, during an outage. Whether you're running a global e-commerce platform, a real-time gaming API, or a financial services application, users expect your service to be available whenever they need it. There is a conversation that happens in almost every engineering team at some point. It usually starts with a post-mortem. A regional Google Cloud outage or a Cloud Run service that hit a cold start spike, or a single-region deployment that could not handle the latency demands of users spread across Lagos, Nairobi, and London simultaneously, caused enough pain that someone finally asked: why are we only deployed in one region?

The answer is usually one of three things: it felt complex, it felt expensive, or no one had prioritised it yet.

In July 2026, Google moved Cloud Run Service Health to General Availability and the timing was hard to miss. Six days earlier, a power cut at Google's Netherlands data centre had knocked three services offline. The GA release brings automatic cross-region failover to Cloud Run with what Google describes as a two-step setup: add a readiness probe, set minimum instances to at least 1. The load balancer does the rest.

This article covers the full architecture, what Service Health is, how readiness probes underpin it, how to set up the Global Load Balancer correctly, and how to test that failover actually works. It also covers the production details.

What changed: Service Health and readiness probes

Before Service Health, multi-region Cloud Run required you to implement a /health endpoint in your application and configure a separate HTTPS health check at the load balancer level. This worked, but it had a significant gap. The load balancer's health check only knew whether the Cloud Run service endpoint was responding, not whether the individual container instances behind it were actually ready to serve traffic.

Service Health introduces two new capabilities that close this gap:

Readiness probes operate at the container instance level. Cloud Run periodically sends an HTTP request to a path you specify on each running container instance. If the probe fails, Cloud Run stops routing requests to that instance until the probe succeeds again. Critically, a failing readiness probe does not kill the instance (that is what a liveness probe does), it simply marks the instance as not ready for traffic.

Service Health aggregates the readiness state of all container instances in a region into a single regional health signal. This aggregated health status is exposed through the Serverless NEGs (Network Endpoint Groups) for that region. When the Global Load Balancer reads the NEG's health status and sees a region is unhealthy, because enough instances are failing their readiness probes; it automatically reroutes traffic to a healthy region. When the failing region recovers, traffic is gradually restored without any operator action.

The result: failover and failback capabilities are now fully automated, triggered by real instance-level health rather than a synthetic endpoint check.

Container instance (readiness probe fails)
        │
        ▼
Cloud Run aggregates probe results across all instances in the region to determine the overall health status of each regional service
        │
        ▼
Service Health: region marked UNHEALTHY
        │
        ▼
Serverless NEG reports unhealthy status to Global Load Balancer
        │
        ▼
Load Balancer stops routing to this region → shifts traffic to healthy region
        │
        ▼
Region recovers → Load Balancer gradually restores traffic

This is available in all Cloud Run regions at no extra charge beyond the CPU and memory consumed while readiness probes run.

Architecture overview

                    ┌──────────────────────────────────┐
                    │   Global Anycast IP (single IP)  │
                    │   + SSL Certificate (managed)    │
                    └───────────────┬──────────────────┘
                                    │
                    ┌───────────────▼──────────────────┐
                    │  Global External HTTP(S) LB      │
                    │  (URL map + forwarding rules)    │
                    └──────┬──────────────────┬────────┘
                           │                  │
        ┌──────────────────▼──┐         ┌─────▼──────────────────┐
        │  Serverless NEG     │         │  Serverless NEG        │
        │  africa-south1      │         │  us-central1           │
        │  (Service Health    │         │  (Service Health       │
        │   status: healthy)  │         │   status: healthy)     │
        └──────────┬──────────┘         └───────────┬────────────┘
                   │                                │
   ┌───────────────▼───────────┐     ┌──────────────▼──────────────┐
   │  Cloud Run Service        │     │  Cloud Run Service          │
   │  africa-south1            │     │  us-central1                │
   │  Readiness probe: /health │     │  Readiness probe: /health   │
   │  min-instances: 1+        │     │  min-instances: 1+          │
   │  (auto-scales 0–N)        │     │  (auto-scales 0–N)          │
   └───────────────────────────┘     └─────────────────────────────┘

Prerequisites and setup

export PROJECT_ID="your-project-id"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
  --format="value(projectNumber)")
export SERVICE="my-api"
export REGION_A="africa-south1"
export REGION_B="us-central1"
export DOMAIN="api.yourdomain.com"
export IMAGE="gcr.io/${PROJECT_ID}/${SERVICE}:latest"

gcloud config set project $PROJECT_ID

# Enable required APIs
gcloud services enable \
  run.googleapis.com \
  compute.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  networkservices.googleapis.com

# Grant Cloud Build service account the Cloud Run builder role
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:${PROJECT_NUMBER}-   compute@developer.gserviceaccount.com" \
  --role="roles/run.builder"

Step 1: Implement the readiness probe endpoint

The first step and the most important one for Service Health to work, is adding a readiness probe endpoint to your application. Unlike the previous/alternative approach where the /health endpoint was for the load balancer's benefit, this endpoint is called directly by Cloud Run on each container instance to determine per-instance readiness.

Two rules from the official docs that matter here:

Use an HTTP/1 endpoint (the Cloud Run default, not HTTP/2)
The endpoint path must match the path in your probe configuration exactly

// Node.js / Express
// Lightweight — no DB calls, no downstream dependencies
// This runs frequently on every instance
app.get('/health', (req, res) => {
  res.status(200).json({
    status: 'healthy',
    region: process.env.REGION,
    timestamp: new Date().toISOString()
  });
});

// If you want the probe to reflect actual readiness
// (e.g. connection pool initialised), you can check internal state:
let isReady = false;
app.get('/health', (req, res) => {
  if (!isReady) {
    return res.status(503).json({ status: 'not_ready' });
  }
  res.status(200).json({ status: 'healthy', region: process.env.REGION });
});

// Set isReady = true after your startup tasks complete
pool.connect().then(() => { isReady = true; });

# Python / FastAPI
import os
from datetime import datetime
from fastapi import FastAPI, Response

app = FastAPI()
is_ready = False

@app.get("/health")
async def readiness_probe(response: Response):
    if not is_ready:
        response.status_code = 503
        return {"status": "not_ready"}
    return {
        "status": "healthy",
        "region": os.environ.get("REGION"),
        "timestamp": datetime.utcnow().isoformat()
    }

@app.on_event("startup")
async def startup_event():
    global is_ready
    # Initialise connections, warm caches, etc.
    await init_database_pool()
    is_ready = True

The is_ready pattern is the key upgrade over a basic /health endpoint. The readiness probe on each instance will return 503 until your startup tasks complete, preventing the load balancer from routing traffic to an instance that is running but not yet ready.

Step 2: Deploy to multiple regions with readiness probes

The gcloud run deploy supports deploying to multiple regions in a single command, and the --readiness-probe flag attaches the probe configuration at deploy time. Failovers require at least two (2) services from different regions.

# Deploy to both regions simultaneously with readiness probe
gcloud run deploy $SERVICE \
  --image=$IMAGE \
  --regions=$REGION_A,$REGION_B \
  --min=1 \
  --max-instances=100 \
  --concurrency=80 \
  --cpu=1 \
  --memory=512Mi \
  --timeout=30s \
  --readiness-probe="httpGet.path=/health" \
  --set-env-vars="ENV=production" \
  --allow-unauthenticated

The --readiness-probe="httpGet.path=/health" flag is the new way to configure probes at deploy time. You can also configure additional probe parameters:

# Full readiness probe configuration
gcloud run deploy $SERVICE \
  --image=$IMAGE \
  --regions=$REGION_A,$REGION_B \
  --min=2 \
  --readiness-probe="httpGet.path=/health,periodSeconds=10,failureThreshold=3,successThreshold=1,timeoutSeconds=5"

Or via YAML service definition (the Terraform-friendly approach):

# service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-api
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "100"
    spec:
      containers:
      - image: gcr.io/PROJECT_ID/my-api:latest
        resources:
          limits:
            cpu: "1"
            memory: 512Mi
        env:
        - name: ENV
          value: production
        readinessProbe:
          httpGet:
            path: /health
          periodSeconds: 10
          failureThreshold: 3
          successThreshold: 1
          timeoutSeconds: 5
        livenessProbe:
          httpGet:
            path: /health
          periodSeconds: 30
          failureThreshold: 3

The difference between readiness and liveness probes

Both probe types are supported on Cloud Run. Understanding the distinction is critical:

Readiness probe failure: Cloud Run stops routing requests to that instance. The instance continues running. Once the probe succeeds again, routing resumes. Service Health aggregates these to determine regional health.

Liveness probe failure: Cloud Run restarts the container instance. Use liveness probes for detecting deadlocks or unrecoverable stuck states.

For Service Health's automatic failover, readiness probes are what matter. Liveness probes are a complement, they handle instance-level recovery, while readiness probes handle traffic routing decisions.

Step 3: Set up the global external Application Load Balancer

With the new Service Health model, the load balancer configuration is simpler than before, you no longer need to configure a separate HTTPS health check at the load balancer level. Service Health exposes regional health through the Serverless NEG itself.

Create the backend service

# Single backend service, both regions are added as NEG backends
gcloud compute backend-services create $SERVICE-bs \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --global

Note: unlike the earlier approach with separate backend services per region, Service Health works with a single backend service that has multiple regional NEG backends. The load balancer reads health from each NEG and routes accordingly.

Reserve a global static IP (Set up a global static external IP address to reach your load balancer:)

gcloud compute addresses create $SERVICE-ip \
  --network-tier=PREMIUM \
  --ip-version=IPV4 \
  --global

export GLOBAL_IP=$(gcloud compute addresses describe $SERVICE-ip \
  --global --format="get(address)")

echo "Global IP: ${GLOBAL_IP}"
# → Update your DNS A record to this IP before proceeding

Create URL map, proxy, and forwarding rules

# Create a URL map to route incoming requests to the backend service:
gcloud compute url-maps create $SERVICE-lb \
  --default-service=$SERVICE-bs

# For HTTPS (recommended for production):
# Create Google-managed SSL certificate
gcloud compute ssl-certificates create $SERVICE-ssl \
  --domains=$DOMAIN \
  --global

# Create the target HTTPS proxy to route requests to your URL map:
gcloud compute target-https-proxies create $SERVICE-https-proxy \
  --url-map=$SERVICE-lb \
  --ssl-certificates=$SERVICE-ssl

# Create the HTTPS forwarding rule  to route incoming requests to the proxy:
gcloud compute forwarding-rules create $SERVICE-https-fr \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=$SERVICE-ip \
  --target-https-proxy=$SERVICE-https-proxy \
  --global \
  --ports=443

# HTTP forwarding rule (redirect to HTTPS)
gcloud compute target-http-proxies create $SERVICE-http-proxy \
  --url-map=$SERVICE-lb

gcloud compute forwarding-rules create $SERVICE-http-fr \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=$SERVICE-ip \
  --target-http-proxy=$SERVICE-http-proxy \
  --global \
  --ports=80

Step 4: Create Serverless NEGs and attach them

# Serverless NEG for africa-south1
gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_A \
  --region=$REGION_A \
  --network-endpoint-type=serverless \
  --cloud-run-service=$SERVICE

# Serverless NEG for us-central1
gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_B \
  --region=$REGION_B \
  --network-endpoint-type=serverless \
  --cloud-run-service=$SERVICE

# Add both NEGs to the single backend service
gcloud compute backend-services add-backend $SERVICE-bs \
  --global \
  --network-endpoint-group=$SERVICE-neg-$REGION_A \
  --network-endpoint-group-region=$REGION_A

gcloud compute backend-services add-backend $SERVICE-bs \
  --global \
  --network-endpoint-group=$SERVICE-neg-$REGION_B \
  --network-endpoint-group-region=$REGION_B

At this point, Service Health is active. Cloud Run is running readiness probes on every instance in both regions, aggregating the results into a regional health signal, and the load balancer reads that signal via the Serverless NEGs.

Step 5: Monitor Service Health with Cloud Monitoring

Service Health exposes two metrics through Cloud Monitoring that you should track from day one:

run.googleapis.com/container/instance_count_with_readiness, the number of instances passing their readiness probe per region. Watch this metric to see the health state of your instance pool in each region in real time.

run.googleapis.com/service_health_count, the regional Cloud Run service health as reported to the load balancer. Possible values: HEALTHY, UNHEALTHY, UNKNOWN. The load balancer uses this to make failover decisions. UNKNOWN is reported until the service has enough data from probes to determine health, typically within the first few minutes of deployment.

# View current service health status via gcloud
gcloud run services describe $SERVICE \
  --region=$REGION_A \
  --format="value(status.conditions)"

# Or check via the Console:
# Cloud Run → your service → Metrics tab → "Instance count with readiness"

Set up an alerting policy that fires when service_health_count for any region transitions to UNHEALTHY:

# alert-policy.yaml
displayName: "Cloud Run region unhealthy — failover active"
conditions:
- displayName: "Service health UNHEALTHY"
  conditionThreshold:
    filter: |
      resource.type="cloud_run_revision"
      metric.type="run.googleapis.com/service_health_count"
      metric.labels.health_status="UNHEALTHY"
    comparison: COMPARISON_GT
    thresholdValue: 0
    duration: 60s
    aggregations:
    - alignmentPeriod: 60s
      perSeriesAligner: ALIGN_MAX
notificationChannels:
- projects/${PROJECT_ID}/notificationChannels/YOUR_CHANNEL_ID
documentation:
  content: |
    A Cloud Run region has become unhealthy and traffic is being
    rerouted to the remaining healthy region(s). Investigate the
    failing region's logs and instance readiness metrics immediately.

Step 6: Testing failover

Testing is not optional, it is the only way to know your failover actually works before your users discover it during a real incident.

Method 1: Use the sample application's toggle (for the official sample)

The Google Cloud sample application (golang-samples/run/service-health) includes a built-in toggle button in its UI that marks a region as unhealthy. For production applications, use Method 2.

Method 2: Force readiness probe failure via environment variable

# Redeploy africa-south1 with a flag that makes /health return 503
gcloud run deploy $SERVICE \
  --image=$IMAGE \
  --region=$REGION_A \
  --set-env-vars="FORCE_UNHEALTHY=true,ENV=production"

In your application, check this variable:

app.get('/health', (req, res) => {
  if (process.env.FORCE_UNHEALTHY === 'true') {
    return res.status(503).json({ status: 'forced_unhealthy' });
  }
  res.status(200).json({ status: 'healthy', region: process.env.REGION });
});

Observe the failover sequence

# Get load balancer IP
export LBIP=$(gcloud compute addresses describe $SERVICE-ip \
  --global --format='value(address)')

# Continuous requests — watch region shift in responses
while true; do
  RESPONSE=$(curl -s https://${DOMAIN}/health)
  echo "$(date '+%H:%M:%S') — $RESPONSE"
  sleep 2
done

You should observe:

Requests showing "region": "africa-south1" — normal operation
A mix of responses as the probe failure propagates across instances
All requests showing "region": "us-central1" — failover complete
The service_health_count metric for africa-south1 showing UNHEALTHY

Restore the region:

gcloud run deploy $SERVICE \
  --image=$IMAGE \
  --region=$REGION_A \
  --set-env-vars="ENV=production"

Traffic gradually returns to africa-south1 as instances pass their readiness probes and Service Health transitions back to HEALTHY.

Safe rollout strategy using readiness probes

One of the most powerful features of the new readiness probe model is the ability to do canary deployments across regions with automatic rollback via Service Health.

The official recommended rollout process:

# Step 1: Deploy new revision to ONE region with 1% traffic
gcloud run deploy $SERVICE \
  --image=$IMAGE_NEW \
  --region=$REGION_A \
  --readiness-probe="httpGet.path=/health" \
  --min=1 \
  --no-traffic  # Deploy but send no traffic yet

# Step 2: Send 1% of traffic to new revision in REGION_A only
gcloud run services update-traffic $SERVICE \
  --region=$REGION_A \
  --to-revisions=LATEST=1

# Step 3: Monitor readiness metric
# run.googleapis.com/container/instance_count_with_readiness
# If this stays healthy, continue increasing traffic

# Step 4: Ramp to 100% in REGION_A
gcloud run services update-traffic $SERVICE \
  --region=$REGION_A \
  --to-revisions=LATEST=100

# Step 5: Once REGION_A service_health_count is stable HEALTHY,
# deploy to REGION_B
gcloud run deploy $SERVICE \
  --image=$IMAGE_NEW \
  --region=$REGION_B \
  --readiness-probe="httpGet.path=/health" \
  --min=1

If the new revision's readiness probes fail in REGION_A, Service Health marks that region unhealthy, the load balancer routes traffic to REGION_B (still running the old revision), and you have automatic rollback without a single manual step.

Known limitations of Service Health (GA)

The official documentation lists several limitations worth knowing before you build:

Minimum instances required. You must configure at least one minimum instance per region for Service Health to calculate health. A region with zero running instances cannot report health, which means a cold-start region cannot participate in automatic failover.
Minimum two regions. Failover requires at least two services from different regions. If you only deploy to one region and it fails, the load balancer returns no healthy upstream.
Max 5 NEG backends for cross-region internal LB. The limitation applies to the internal load balancer variant, not the global external LB.
No URL masks or tags in Serverless NEGs. If your routing requires URL masks, you cannot use Service Health's NEG model.
No IAP from the backend service. If you need Identity-Aware Proxy, configure it directly on the Cloud Run service, not at the load balancer backend.
First probe on new instances. A newly started instance will not have its first readiness probe counted before it begins receiving traffic. This means a very brief window where traffic may route to an instance before it has confirmed readiness.
Revisions without probes are treated as unknown. The load balancer treats unknown health as healthy, so if you deploy a revision without a readiness probe configured, it will receive traffic regardless.

The last two points are important for zero-downtime deployments. The recommended safe rollout process (canary in one region before the other) directly addresses both.

What this architecture does not solve

Database availability. Compute-layer failover is irrelevant if your Cloud Run service connects to a single-region Cloud SQL instance. The database tier needs its own HA: Cloud SQL cross-region read replicas, Cloud Spanner for global consistency, or Firestore in Native mode (inherently multi-region).

Stateful sessions. Cloud Run is stateless. Cross-region routing will invalidate in-memory sessions. Use Cloud Memorystore (Redis) or stateless JWT-based sessions.

Data residency. Routing traffic across regions may conflict with NDPR, GDPR, or sector-specific regulations. Know your data residency obligations before deploying multi-region.

Pub/Sub push subscriptions. By default, Pub/Sub delivers messages to push endpoints in the same region where it stores the messages. A multi-region Cloud Run setup behind a global LB does not automatically receive Pub/Sub push traffic from all regions. The official docs provide a workaround, review the Pub/Sub multi-region push documentation before building event-driven architectures on this pattern.

From Apple Health Data to Clinical Storytelling: Building an AI-Powered Report with Python and Gemini

Romina Elena Mendez Escobar — Mon, 20 Jul 2026 09:55:58 +0000

Introduction

At recent technology conferences, one topic has caught my attention: every year, more health-focused devices, sensors, and applications appear. Smartwatches track heart rate, smart scales measure body data, glucose monitors record blood sugar levels, and apps help users track sleep or nutrition. Today, the amount of information we can collect about our own bodies is enormous.

This article was inspired by an everyday experience with my father, Herminio ❤️. Whenever he has a medical appointment, he opens the Apple Health app and shows the doctor the evolution of his heart rate, physical activity, sleep hours, and other recorded metrics.

While watching this, I kept asking myself the same question: are we really making the most of all this information?

Showing a chart during a medical appointment can be useful, but the data could provide much more value if it were automatically processed, summarized, and transformed into a structured health report.

For this reason in this project, I use Gemini to transform previously calculated metrics into a clear and organized summary. The LLM does not analyze all the raw records or perform the main calculations. The pipeline processes the data, calculates the indicators, and generates the visualizations, while the model acts as a support layer for building the report narrative.

The goal is not to create a medical application or replace professional judgment. Instead, the purpose is to build a prototype that shows how Apple Health exports, deterministic data processing, visualizations, and an LLM can be combined to generate automated reports.

This project was developed using simulated data from three patients, so the complete pipeline can be reproduced without using real clinical information.

✨ Why Gemini?

This project uses an LLM to transform previously processed metrics into a structured narrative that can be reviewed more easily by a healthcare professional.
I chose Gemini for practical reasons:

〰️ I was already familiar with its API, it integrates easily with Python, and Google AI Studio makes it simple to test and adjust prompts.
〰️ It also offers a good balance between speed, performance, and cost for text-generation tasks.
〰️ Its free tier also makes it easier to reproduce this MVP without initial costs.

In this case, I use a general-purpose model because all calculations are completed in Python before the data is sent to Gemini. The model only organizes the results into readable text.
For projects that need to analyze clinical documents or medical images directly, specialized models such as MedGemma could also be evaluated. MedGemma is a family of open Google models adapted for healthcare-related tasks. However, its implementation, evaluation, and validation are outside the scope of this tutorial.

2. HealthKit: The Framework Behind the Data

Although most users only interact with the Apple Health app, HealthKit is the framework behind it. Apple provides HealthKit so developers can securely access health information stored on the device.

HealthKit works as a central repository where the iPhone and Apple Watch store health and fitness data. With the user’s explicit permission, authorized applications can read and write information through a single API. This avoids the need for every app to maintain its own separate database.

HealthKit currently supports hundreds of data types across many areas of health and well-being. The following figure presents a simplified grouping of some of these categories to provide a clearer overview of the available information.

This taxonomy was created specifically for this article based on publicly available HealthKit documentation. It is not an official Apple classification and should be understood as a summarized, author-created interpretation for explanatory purposes.

Thanks to this architecture, HealthKit makes it possible to:

Collect and store health and fitness information.
Analyze and visualize how this data changes over time.
Share information between authorized applications, reducing duplication and enabling new user experiences.

One of the most interesting design decisions in HealthKit is its large catalog of predefined classes and data types for standardized health metrics.

At first, this may seem restrictive for developers. However, it is actually one of the platform’s main strengths because it ensures that all stored information follows a consistent data model. This means that heart rate, blood glucose, or body weight always represent the same type of information and use the same units, regardless of the device or application that created the record.

This standardization simplifies application development, improves interoperability between apps, and helps maintain consistency across the data stored in HealthKit.

2.1 Data Sources

One of HealthKit’s main benefits is its ability to bring data from multiple sources into a single repository.
The most common sources include:

iPhone: records steps, distance traveled, mobility data, and other indicators collected through its sensors.
Apple Watch: provides physiological metrics such as heart rate, electrocardiogram (ECG), blood oxygen saturation (SpO₂), body temperature, sleep data, workouts, and cardiorespiratory fitness (VO₂ Max).
Third-party apps: can add information related to nutrition, mental health, hydration, medication, menstrual cycles, or sports training.
Connected medical devices and wearables: HealthKit supports Bluetooth Low Energy (BLE) health devices and medical data profiles. It can also work with FHIR (Fast Healthcare Interoperability Resources), making it possible to integrate data from devices such as glucose meters and blood pressure monitors, as well as clinical records from authorized healthcare institutions.

3. HL7 / FHIR Compatibility

So far, we have mainly discussed data generated by devices and applications. However, in 2018 Apple expanded the Health app by introducing Health Records, a feature that allows users to import structured clinical information from supported healthcare institutions. That same year, Apple also opened access to these records for authorized applications through the HealthKit API.

Health Records is built on HL7 FHIR, which stands for Fast Healthcare Interoperability Resources. FHIR is a standard developed by HL7 International to represent and exchange health information electronically between hospitals, applications, and Electronic Health Record systems.

FHIR organizes information into modular resources such as Patient, Observation, Condition, Procedure, MedicationRequest, and Immunization. Each resource represents a specific piece of clinical information that can be connected, queried, and exchanged between systems. Although FHIR can also be used to build clinical documents, its architecture does not require the entire patient record to be handled as one large document.

When records are downloaded from a supported institution, HealthKit represents each one as an HKClinicalRecord object, which keeps the original FHIR resource. Authorized applications can request the clinical record types they need and process their content as FHIR JSON. However, these records are read-only, which means applications cannot create new HKClinicalRecord objects or modify existing ones.

Access to any HealthKit information requires user consent, but clinical records have additional requirements because of their sensitivity. An application must enable the Clinical Health Records capability, include the required entitlement, explain why the information is needed, and request permission for each record type it wants to access. The use of this capability is also subject to Apple’s review process.

In HealthKit, clinical records are represented as read-only HKClinicalRecord objects that preserve the original FHIR content. Access requires explicit user authorization and is subject to additional privacy and platform requirements.

This architecture makes it possible to bring together information from different sources while keeping access centered on user consent and privacy.

4. HealthKit: Clinical Use Cases

The availability of large volumes of physiological data, combined with interoperability standards such as FHIR, has created many opportunities for research and clinical applications.

The value of this data does not come only from individual measurements, but from how they are analyzed over time. Tracking changes in heart rate, sleep, mobility, or activity levels can help identify patterns, summarize relevant information, and support patient monitoring in different healthcare scenarios.

The following figure presents some representative use cases, including early anomaly detection, remote patient monitoring, clinical summary generation, and synthetic data generation for research.

5. Technical, Clinical, and Regulatory Considerations

Before running the tutorial or using the code presented in this article, it is important to understand its scope and consider several limitations related to privacy, data quality, and the use of artificial intelligence in healthcare contexts.

5.1 Privacy and Data Protection

Health information is one of the most sensitive categories of personal data. Depending on the country and the context of use, it may be subject to regulations such as HIPAA in the United States or GDPR in the European Union.

Although this article uses only simulated data, any implementation that processes real information should include suitable controls for:

User consent.
Access management.
Data minimization.
Anonymization or pseudonymization.
Encryption.
Secure storage and processing.

5.2 Consumer Data Is Not a Diagnosis

Measurements collected through consumer devices can provide useful information for identifying trends and supporting long-term monitoring.
However, these records do not represent a medical diagnosis on their own and should not replace measurements taken with certified clinical equipment.

5.3 Data Quality and Continuity

The quality of the measurements can be affected by factors such as incorrect device placement, low battery levels, synchronization failures, periods when the device is not used, or differences between sensors and applications.
These situations may produce:

Incomplete records.
Duplicate measurements.
Outliers.
Periods with missing information.
Differences in units or sampling frequency.

For this reason, the data should be validated, cleaned, and normalized before generating any analysis. It is also important to identify periods where the available information is not complete enough to support reliable conclusions.

5.4 Use and Limitations of the LLM

In this project, the large language model does not diagnose conditions or recommend treatments. Its role is to transform previously calculated metrics into a clear and structured summary that can be reviewed more easily by a healthcare professional.

Any generated output should be treated as a draft that requires human review. The model may omit information, misunderstand a result, or produce statements that are not fully supported by the input data.

5.2 Scope of the Code

The repository provided with this article should be understood as an educational and experimental MVP. It is designed to demonstrate the general processing flow using simulated data.

It is not a medical product, a diagnostic tool, or an implementation ready for direct use in a clinical environment.
Before adapting the code to a real use case, additional validation would be required in areas such as:

Security and access control.
Error handling and traceability.
Data quality and provenance.
Reproducibility of the results.
Evaluation of the model’s responses.
Compliance with applicable standards and regulations.
Review and approval by qualified professionals.

The goal of this project is to present one possible architecture and explore its main components, not to provide a production-ready clinical solution.

6. Building the Apple Health Reporting Pipeline

In this tutorial, we will build a Python pipeline that processes an Apple Health XML export and generates a structured PDF report.
The pipeline will:

read and normalize the exported health records;
calculate mobility, cardiovascular, and sleep metrics;
compare the results against configurable reference values;
generate charts;
use Gemini to create a structured narrative;
combine everything into a final PDF report.

The generated report contains four main sections:

🚶 Mobility: daily steps, walking speed, steadiness, gait metrics, and caloric expenditure.
❤️ Cardiovascular: resting heart rate, HRV, oxygen saturation, VO₂ Max, and recovery metrics.
😴 Sleep: average sleep duration and nights above or below the configured references.
🤖 AI-generated summary: a structured narrative with patient profile, mobility, cardiovascular, sleep, and overall assessment sections.

The following diagram shows the complete flow of the project:

The implementation follows a modular architecture in which each class is responsible for one stage of the pipeline:

📥 HealthDataReader reads and processes the Apple Health export.
📊 HealthChartBuilder generates the visualizations.
✨ HealthSummaryGenerator creates the narrative using Gemini.
📄 HealthReportPDF combines the metrics, charts, and generated text into the final report.

In the next sections, we will review each stage separately. To keep the article focused, I will only include the most relevant code fragments and design decisions. The complete implementation, configuration files, prompt template, and simulated data are available in the project repository.

6.1 Prerequisites

To follow the tutorial, you will need:

The project repository cloned locally.
An Apple Health XML export or one of the simulated files included in the repository.
A Gemini API key created from Google AI Studio.
The Python dependencies installed from the project requirements.txt file.

You can clone the repository and install the dependencies with:

RominaElenaMendezEscobar / apple-health-data

Python pipeline that processes Apple Health XML exports, calculates health metrics, generates visualizations, creates a structured narrative with Gemini, and builds a final PDF report using simulated patient data.

From Apple Health Data to Clinical Storytelling: Building an AI-Powered Report with Python and Gemini

Apple Health Reporting Pipeline with Python and Gemini

A modular Python pipeline that processes Apple Health XML exports, calculates health metrics, generates visualizations, creates an AI-assisted narrative with Gemini, and builds a structured PDF report.

This repository is an educational MVP built with simulated data. It is not a medical device, diagnostic tool, or production-ready clinical solution.

Overview

The pipeline:

Reads and normalizes Apple Health XML records.
Calculates mobility, cardiovascular, and sleep metrics.
Compares results with configurable reference values.
Generates charts with Matplotlib.
Creates a structured narrative with Gemini.
Combines metrics, charts, and text into a PDF report.

HealthKit: The Framework Behind the Data

HealthKit is Apple’s framework for storing and sharing health and fitness information collected by the iPhone, Apple Watch, third-party apps, and compatible devices.

It provides standardized data types for metrics such…

View on GitHub

✨Gemini API key
You can create an API key from Google AI Studio.
After creating it, add a .env file at the root of the project:

gemini_api_key=YOUR_CREDENTIAL

6.2 Data source

Apple Health allows users to export their information as a ZIP file containing an XML document.

The export can be generated from the Health app:

Open the Health app on the iPhone.
Tap the profile icon.
Select Export All Health Data.
Confirm the export.
Extract the generated ZIP file.

The tutorial uses the export.xml structure produced by this process. However, to avoid exposing real health information, the repository includes three simulated patient files:

alex_28m.xml: 28-year-old male patient.
carlos_68m.xml: 68-year-old male patient.
maria_61f.xml: 61-year-old female patient. These files are stored in the patients/ folder and allow the complete pipeline to be reproduced without using real clinical data.

6.3 Orchestrating the Pipeline

The complete project is coordinated from the main.py file, which works as the application entry point. Its responsibility is not to process the data directly, but to create the specialized classes and execute each stage of the pipeline in the correct order.

This file also defines the list of patients to be processed. For each patient, it includes the XML file path and the name that will appear in the final report. The files are declared explicitly to make the example easier to follow, although a more general implementation could discover them automatically from a folder.

The complete main.py file is shown below:

from healthChartBuilder import HealthChartBuilder
from healthDataReader import HealthDataReader
from healthReportPDF import HealthReportPDF
from healthSummaryGenerator import HealthSummaryGenerator
import utils
import os

if __name__ == "__main__":
   patients = [
       ("patients/alex_28m.xml",   "Alex Torres"),
       ("patients/maria_61f.xml",  "María González"),
       ("patients/carlos_68m.xml", "Carlos Mendez"),
   ]

   os.makedirs("reports", exist_ok=True)
   os.makedirs("charts",  exist_ok=True)
   os.makedirs("data",    exist_ok=True)

   env = utils.read_env()

   for xml_path, name in patients:
       print(f"\n── {name} ──")
       prefix = name.lower().replace(' ', '_')

       # Step 1: read and compute
       reader = HealthDataReader(xml_path).load()

       # Step 1.1: save the compact LLM-friendly summary for this patient
       reader.save(write_llm_summary=True, file_name=prefix)

       # Step 2: generate charts
       builder = HealthChartBuilder(
           metrics    = reader.metrics,
           output_dir = "charts",
           prefix     = prefix,
       )
       charts = builder.build_all()

       # Step: generate the narrative summary with Gemini
       generator = HealthSummaryGenerator(
           json_path   = f"data/{prefix}_llm_summary.json",
           yml_path    = "config/params_health.yml",
           prompt_path = "prompt/prompt_summary.txt",
           api_key     = env["gemini_api_key"],
       ).load()
       llm_text = generator.generate()

       # Step 3: build PDF
       HealthReportPDF(
           metrics        = reader.metrics,
           charts         = charts,
           patient_name   = name,
           date_of_birth  = reader.date_of_birth,
           biological_sex = reader.biological_sex,
           start_date     = reader.df['start'].min(),
           end_date       = reader.df['start'].max(),
           out_path       = f"reports/{prefix}_report.pdf",
           llm_summary    = llm_text,
       ).build()

6.4 Reading and Processing the Apple Health Export

The HealthDataReader class reads the XML file exported from Apple Health and transforms it into a structure that can be analyzed with Python. During this process, it extracts the available records, normalizes dates and numeric values, limits the analysis to the configured period, and calculates the metrics used by the next stages of the pipeline.

The class receives the XML file path and, optionally, the number of months to include in the analysis:

reader = HealthDataReader( 
xml_path="patients/alex_28m.xml", months=6, 
).load()

The load() method runs two main operations:

📥 _parse_xml() reads the file, extracts the records, and transforms them into a Pandas DataFrame.
📐 _compute_metrics() calculates the daily series and aggregated indicators used in the analysis.

Threshold Configuration

The values used to classify or compare the metrics are not hardcoded inside the class. Instead, they are loaded from config/params_health.yml.

This separation makes it possible to update the reference values without changing the Python implementation:

threshold_steps_low:
  description: Step count threshold for red zone.
  value: 3000
threshold_steps_mid:
  description: Step count threshold for orange zone.
  value: 5000
threshold_steps_goal:
  description: Step count goal line.
  value: 7000
threshold_speed_low:
  description: Walking speed considered critically low.
  value: 3.5
threshold_speed_goal:
  description: Walking speed reference value.
  value: 4.5
threshold_steadiness:
  description: Steadiness warning value.
  value: 0.60
threshold_spo2_low:
  description: SpO2 critical threshold.
  value: 95.0
threshold_spo2:
  description: Minimum SpO2 reference value.
  value: 96.0
threshold_sleep_min:
  description: Sleep duration for red zone.
  value: 5.0
threshold_sleep_mid:
  description: Sleep duration for orange zone.
  value: 6.0
threshold_sleep_goal:
  description: Sleep duration goal.
  value: 7.0
threshold_hrv:
  description: Minimum HRV reference value.
  value: 25.0

These parameters affect several parts of the project. They are used, for example, to calculate how many days fall below a specific step count, identify periods of low walking speed, evaluate sleep duration, and define the reference zones later used in the charts and the final report.

⚠️ Note: The values included in the repository are only for demonstration and are intended to support the example with simulated data. They should not be treated as clinical criteria. Before adapting the code to a real use case, the thresholds should be reviewed and validated by healthcare professionals, considering the population, age group, clinical context, and specific purpose of the solution.

Metric Selection

The _compute_metrics() method defines which data types are processed and which indicators are calculated. In the current implementation, the metrics are mainly organized into three groups:

🚶 Mobility and activity: steps, walking speed, step length, steadiness, asymmetry, active energy, and flights climbed.
❤️ Cardiovascular: resting heart rate, HRV, oxygen saturation, respiratory rate, VO₂ Max, and heart rate recovery.
😴 Sleep: daily duration, average sleep, and the number of nights below or above the configured thresholds. The daily series are calculated using sums or averages, depending on the type of record:

steps = self._daily_sum("StepCount")
speed = self._daily_mean("WalkingSpeed")
hr = self._daily_mean("RestingHeartRate")
hrv = self._daily_mean("HeartRateVariabilitySDNN")
spo2 = self._daily_mean("OxygenSaturation")

⚠️ Note: The thresholds are not the only values that should be reviewed. It is also important to confirm that the statistical methods used by the class are appropriate for each metric. For example, the mean can be affected by outliers. Before using this approach in production, other measures such as the median or percentiles may need to be evaluated.

Preparing the Data for the LLM

In addition to the full set of metrics, the class generates a smaller JSON file through to_llm_summary().
Instead of sending the complete time series, Python creates a compact and deterministic representation that includes:

📊 mean and standard deviation;
↕️ minimum and maximum values;
📈 trend over the analysis period;
📅 best and worst weekly averages;
🔄 weekly variability;
⏱️ longest consecutive period below the configured threshold.

Not every metric includes all of these fields, because some calculations do not apply in the same way to every type of data. This decision has two main benefits:

1. Reducing the amount of data sent to the model. An Apple Health export may contain thousands of records. Sending all observations would increase the prompt size, token usage, and execution cost, while also adding repetitive information that may not improve the final summary.
2. Keeping the calculations in Python. Averages, trends, minimum and maximum values, weekly statistics, and threshold streaks are calculated in advance using deterministic code. The LLM receives fixed and verifiable values and is only responsible for turning them into a natural-language summary.

This separation also makes the project easier to maintain. If the trend calculation changes or a new metric is added, the update can be made in Python without changing the role of the language model.
For example, the model receives a structure like this:

{
  "steps": {
    "mean": 9498.53,
    "std": 1728.37,
    "min": 5667.0,
    "max": 14201.0,
    "trend": "stable",
    "worst_week_mean": 8214.29,
    "best_week_mean": 10672.71,
    "weekly_volatility": 576.09,
    "worst_streak_below_threshold": 0
  }
}

6.5 Generating Clinical Charts

The HealthChartBuilder class receives the metrics calculated by HealthDataReader and generates the charts that are later included in the final report.
To keep the presentation logic separate from the data-processing logic, the class uses two configuration files:

🎯 params_health.yml: defines the reference thresholds used for color zones and horizontal lines in each chart.
🎨 params_styles.yml: stores the color palette applied consistently across all visualizations.

Generated Charts

The build_all() method coordinates the chart-generation process and delegates each visualization to an independent private method:

🚶 Activity and mobility — _chart_steps(), _chart_mobility(), and _chart_calories(): daily steps with threshold-based color zones, walking speed with a reference line, and active versus basal calories.
❤️ Cardiovascular — _chart_hrv() and _chart_spo2(): heart rate variability with a minimum reference value, and oxygen saturation with critical, low, and normal zones.
😴 Sleep — _chart_sleep(): nightly sleep duration displayed with threshold-based color zones. If no sleep data is available, the chart shows an alternative message. Each chart is implemented independently, so it can be modified or replaced without affecting the rest of the pipeline.

6.6 Generating the Narrative with Gemini

The HealthSummaryGenerator class receives the summary created by HealthDataReader and uses Gemini to transform it into structured natural-language text. At this stage, the original Apple Health records are not sent to the model. Instead, Gemini receives the metrics that were already calculated and summarized in the previous step.
To build the prompt, the class uses three input files:

📊 json_path: contains the patient’s compact summary, including the previously calculated metrics and statistics.
🎯 yml_path: points to params_health.yml, which contains the thresholds used to compare each metric.
📝 prompt_path: contains the prompt template and the instructions the model must follow. The load() method reads these files and initializes the Gemini client:

self.datos = utils.read_json_file(self.json_path)
self.yml = utils.read_yml_file(self.yml_path)
self.prompt = utils.read_txt_file(self.prompt_path)
self.client = genai.Client(api_key=self.api_key)

Prompt Structure

The prompt template defines how the report should be generated. Instead of including the complete prompt in the article, its main instructions can be summarized as follows:

🧭 Patient context: calculates the patient’s age from the date of birth and considers biological sex and the analysis period.
📐 Threshold comparison: defines which value from params_health.yml should be used to evaluate each metric.
📑 Report structure: requires fixed sections for patient profile, mobility, cardiovascular data, sleep, and overall assessment.
🔎 Trends and continuity: asks the model to consider metric trends, weekly variability, and consecutive periods below the configured thresholds.
🚫 Restrictions: prevents the model from inventing data, using unavailable fields, or making general judgments about the patient’s health. It also avoids subjective terms such as “healthy” or “concerning.” The model should only report whether each value is above, within, or below its corresponding threshold.

This last point is especially important, because the model should describe the available values and their relationship to the configured thresholds without making a diagnosis or turning the summary into medical advice.

Building and Running the Prompt

The class separates prompt preparation from the model call:

_build_prompt()replaces the {datos} and {yml} placeholders with the actual JSON data and threshold configuration.
generate() sends the completed prompt to Gemini and returns the generated text.

prompt = self._build_prompt()

response = self.client.models.generate_content(
    model=self.model_id,
    contents=prompt,
    config=types.GenerateContentConfig(
        max_output_tokens=self.max_tokens,
        thinking_config=types.ThinkingConfig(
            thinking_budget=0
        ),
    ),
)

6.7 Generating the Final PDF Report

The HealthReportPDF class combines the results produced during the previous stages and creates the final PDF report using ReportLab.
The class receives four main inputs:

📊 Metrics and KPIs: obtained directly from the metrics dictionary generated by HealthDataReader. The class does not recalculate the main statistics. Instead, it organizes them into KPI cards, tables, alerts, and short descriptions.
📈 Charts: receives the image paths generated by HealthChartBuilder and adds each chart to the corresponding report section.
✨ Gemini summary: receives the narrative generated by HealthSummaryGenerator and includes it as a separate section.
🎯 Configuration: uses params_health.yml and params_styles.yml to apply the same thresholds and visual styles used across the rest of the pipeline.

This class does not calculate averages, trends, or weekly statistics. Those values are already produced by HealthDataReader. It only performs simple comparisons against the configured thresholds to decide whether a table should display a ✓ or ⚠ status and whether an alert should be added to the report.

Report Structure

The generated document is divided into four sections:

🚶 ① Mobility: KPIs for steps, walking speed, steadiness, gait asymmetry, and activity, together with the related charts and reference tables.
❤️ ② Cardiovascular: resting heart rate, HRV, SpO₂, VO₂ Max, and recovery metrics. This section is adapted when Apple Watch data is not available.
😴 ③ Sleep: average sleep duration, nights below the minimum threshold, and nights that meet the configured goal.
🤖 ④ AI-Generated Summary: the narrative generated by Gemini, converted from simple Markdown into formatted PDF content.

Alerts and Reference Status

Before building the report sections, the build() method checks the main metrics against their configured thresholds.

For example, it can generate an alert when:

the average number of steps is below the target;
walking speed is below the reference value;
HRV or SpO₂ is below the configured threshold;
average sleep duration does not meet the expected value. These alerts are based on simple comparisons and do not represent medical diagnoses.

AI Disclaimer

The AI-generated section always includes a visible disclaimer. It explains that the text was created from device data, is not a clinical evaluation or diagnosis, and may contain errors or incorrect interpretations.
The disclaimer also reminds the reader that the generated narrative should be checked against the original metrics and reviewed by a qualified professional before being used in any health-related decision.

7. Conclusions

One of the main challenges of this project was transforming Apple Health records into useful and understandable information. HealthKit’s consistent data structure makes this processing easier and supports the creation of a reusable pipeline. It also opens the door to interoperability: in a real environment, representing the results with standards such as HL7 FHIR could simplify their exchange with applications, hospitals, and electronic health record systems.

Separating Calculation from Interpretation

A relevant design decision was to keep the calculations in Python and use Gemini only to generate the narrative. Averages, trends, threshold comparisons, and weekly statistics are calculated in a controlled way, while the model receives already processed values and turns them into readable text.
Summarizing the data before sending it to the LLM also reduces token usage, execution cost, and the risk of reaching the context window limit. This approach provides more control over the information used to generate the report.

Personalization and Data Quality

The same metrics and thresholds are not suitable for every patient or every use case. Making these values configurable allows the analysis to be adapted to the patient profile, the monitoring objective, and the specific needs of the project.
However, configuration alone does not guarantee reliable results. The statistical methods should also be validated, and the pipeline should measure data completeness. For example, it should be able to distinguish between a real reduction in activity and missing records caused by low battery, synchronization problems, or irregular device use.
In a real implementation, metrics, thresholds, and validation rules should be reviewed together with healthcare professionals.

Security and Responsible Data Use

Health data requires specific controls for privacy, access, storage, and retention. A real solution should define what information is collected, who can access it, how long it is stored, and which data may be sent to external services.
Although these topics are outside the scope of this article, they should be considered from the beginning of the design process. Consent, data minimization, and retention policies should not be added only after the technical implementation is complete. This principle is also reflected in Apple Health, which requires explicit permission to read and write health information.

Final Note

This project is an educational MVP built with simulated data. It is not ready for production and should not be used directly to make health-related decisions.
Its main purpose is to demonstrate how continuous health data, deterministic processing, visualizations, and a language model can be combined in a modular pipeline. The LLM can help communicate the results, but the calculations, validation rules, and data-quality controls should remain reproducible and verifiable.

8. 📚 Reference

Apple. (2018, 24 de enero). Apple announces solution bringing health records to iPhone. Apple Newsroom. https://www.apple.com/newsroom/2018/01/apple-announces-effortless-solution-bringing-health-records-to-iPhone/
Apple. (2020). Handling FHIR without getting burned [Video]. Apple Developer. https://developer.apple.com/videos/play/wwdc2020/10669/
Apple. (s. f.). Accessing Health Records. Apple Developer Documentation. Retrieved July 10, 2026, from https://developer.apple.com/documentation/healthkit/accessing-health-records
Apple. (s. f.). Configuring HealthKit access. Apple Developer Documentation. Retrieved July 10, 2026, from https://developer.apple.com/documentation/xcode/configuring-healthkit-access
Apple. (s. f.). HealthKit. Apple Developer Documentation. Retrieved July 10, 2026, from https://developer.apple.com/documentation/healthkit
Google. (2026, 23 de junio). Gemini 2.5 Flash. Google AI for Developers. https://ai.google.dev/gemini-api/docs/models/gemini-2.5-flash
Google. (s. f.). Guía de inicio rápido de Google AI Studio. Google AI for Developers. Retrieved July 10, 2026, from https://ai.google.dev/gemini-api/docs/ai-studio-quickstart?hl=es-419
Google. (s. f.). MedGemma 27B instruction-tuned model card. Hugging Face. Retrieved July 10, 2026, from https://huggingface.co/google/medgemma-27b-it
Health Level Seven International. (2023, 26 de marzo). FHIR overview: FHIR release 5. https://fhir.hl7.org/fhir/overview.html
Health Level Seven International. (2023, 26 de marzo). Introducing HL7 FHIR: FHIR release 5. https://fhir.hl7.org/fhir/summary.html

How My AI Agent Hacked Its Own Permissions (And What It Taught Me)

Alexander Tyutin — Tue, 23 Jun 2026 17:09:18 +0000

Have you ever tried to build an automation that works so well it bypasses the very rules you set for it? Recently, I was working on a small repository designed to automate the painful process of updating my resume. The idea was simple: build a system that runs weekly, checks my social media activity, and proposes updates to my CV, complete with a fresh branch and a diff ready for my review every Monday morning. You can check out the repository here: https://github.com/tyutinalexkz/cv

I used an AI agent to do the heavy lifting. As a developer who values security, I configured the agent with no default command execution permissions. Step-by-step, I granted it specific capabilities for in-repo file management. It worked perfectly.

But then, I got ambitious.

Once the workflow was tested, I asked the agent to configure its own environment to perform this flow silently every week. I essentially said, "Make this run automatically without asking me."

The agent attempted to change its permissions, but hit a wall - it didn't have the explicit authorization to modify the workspace configuration directly. A normal script would throw an error and stop. But this was a thinking model.

It looked at the list of commands I had already allowed it to use. It saw standard file manipulation tools. And then, it compiled a chain of commands - specifically using cp and jq - to manipulate its own configuration files. By doing so, it effectively granted itself the new capabilities it needed, bypassing the standard configuration flow and its limitations!

I just sat there, laughing. I was observing it as a developer, seeing how easy it could be to live without security barriers if you know the right tools. But the underlying lesson was profound. Even a helpful, non-malicious AI, when given a goal and a subset of seemingly harmless tools, will find creative ways to achieve that goal - even if it means escalating its own privileges.

If we give an agent to a user in a corporate setting, it might seem safe if we restrict its primary permissions. But as my little experiment showed, an agent with basic file manipulation tools and problem - solving skills can easily find a workaround. The future of AI safety isn't just about what an agent is explicitly allowed to do; it's about what it can piece together from the tools it has.

Securely Exposing Internal GCP VMs using Cloudflare Tunnels

Alexander Tyutin — Tue, 16 Jun 2026 06:07:42 +0000

Exposing a web service to the public internet typically involves assigning a public IP address to the Virtual Machine, opening firewall ports (e.g., 80/443), and configuring TLS certificates. However, this traditional approach leaves the infrastructure vulnerable to port scanning, DDoS attacks, and zero-day exploits.

A more modern, secure, and elegant approach is to use a Cloudflare Tunnel (cloudflared) combined with a GCP VM that has no external IP address.

This article explains the architecture, security benefits, step-by-step implementation, and troubleshooting for this approach.

1. The Architecture

Instead of accepting incoming connections (Ingress), the cloudflared daemon runs on the VM and establishes an outbound-only, encrypted, long-lived QUIC connection to the Cloudflare Edge network.

When a client visits the configured domain, Cloudflare proxies the request through this established tunnel directly to the internal service.

Benefits of this architecture

No Ingress Firewall Rules: There is no need to open port 80 or 443 in the GCP VPC firewall.
No Public IP: The VM is invisible to the public internet. It cannot be pinged or port-scanned.
Automatic SSL/TLS at the Edge: While end-to-end encryption (HTTPS everywhere) is advocated as a best practice, this guide configures the internal traffic between cloudflared and the target service as plain HTTP for simplicity. Cloudflare handles the public-facing HTTPS certificates automatically, simplifying the initial setup.
Out-of-the-box DDoS Protection: Cloudflare absorbs volumetric attacks before they ever reach the GCP infrastructure.

2. GCP VM Security Measures

When designing a secure VM without an external IP, the following GCP-specific security measures should be implemented:

A. Networking (Cloud NAT)

Since the VM has no public IP, it cannot access the internet directly. However, cloudflared needs internet access to connect to Cloudflare, and the VM needs internet to pull updates or Docker images.

Solution: Set up a Cloud Router and Cloud NAT in the VPC. This allows outbound internet access for internal VMs while blocking all inbound internet connections.

B. Shielded VM Features

Enable Shielded VM options to protect the boot process and kernel integrity:

Secure Boot: Ensures the system only boots authentic, digitally signed software.
vTPM (Virtual Trusted Platform Module): Validates the VM's identity and provides secure key generation.
Integrity Monitoring: Generates alerts if the boot sequence is tampered with.

C. Identity and API Access

Dedicated Service Account: Avoid using the default Compute Engine service account. Create a custom service account with the absolute minimum permissions required.
Metadata Security: Ensure disable-legacy-endpoints = true in the instance metadata to prevent Server-Side Request Forgery (SSRF) attacks from extracting GCP credentials from the metadata server.

D. Secure SSH Access (IAP)

Since there is no public IP, standard SSH over the internet is impossible.

Solution: Use Identity-Aware Proxy (IAP) TCP Forwarding. IAP validates Google Identity and IAM permissions before tunneling the SSH connection through GCP's internal backbone to the VM.

3. Step-by-Step Implementation

Step 1: Provisioning the Cloudflare Tunnel

Navigate to the Cloudflare Zero Trust Dashboard -> Networks -> Tunnels.
Create a new tunnel and select Cloudflared.
Add a Public Hostname (e.g., app.example.com) and point it to the internal service (http://webapp:8080).
Copy the generated Tunnel Token.

Step 2: Infrastructure Configuration (Docker Compose)

Docker Compose can be used to run both the service and the cloudflared daemon in the same isolated bridge network.

version: '3.8'

services:
  webapp:
    image: your-company/webapp:latest
    restart: always
    environment:
      - APP_ENV=production
      # Listen on all interfaces inside the container, but expose NO ports to the host
      - LISTEN_ADDRESS=0.0.0.0

  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: always
    # CRITICAL: Prevent zombie processes by running tini as PID 1
    init: true
    command: tunnel --no-autoupdate run
    environment:
      - TUNNEL_TOKEN=your_secret_token_here
    depends_on:
      - webapp

Note: Notice there is no ports: ["8080:8080"] mapped to the host. The cloudflared container reaches the web app entirely within the internal Docker network via http://webapp:8080.

Step 3: Run the stack

docker-compose up -d

Within seconds, cloudflared will connect to the Cloudflare Edge, and the site will be securely accessible.

4. Diagnostics & Troubleshooting

When diagnosing connectivity issues, the non-standard traffic flow requires a systematic approach.

A. Diagnosing the Edge (Cloudflare)

A 502 Bad Gateway error indicates that Cloudflare Edge cannot reach the cloudflared tunnel, OR cloudflared cannot reach the target container.

# Check the HTTP response from the outside
curl -I https://app.example.com

B. Diagnosing the Host & Services

Before diving into logs, verify the overall health and resource consumption of the host and Docker containers.

# Check container uptime, status, and IDs
sudo docker ps -a

# Check memory and CPU usage (crucial for diagnosing OOM freezes)
sudo docker stats --no-stream

# Look for stray processes outside of Docker
sudo ps aux | grep cloudflared
sudo systemctl status webapp.service

C. Diagnosing the Tunnel (Cloudflared)

Verify that cloudflared is running and successfully connected to the Edge:

sudo docker logs --tail 50 <cloudflared_container_id>

Look for: INF Registered tunnel connection or ERR Unable to reach the origin service.

D. Verifying Internal Docker Connectivity

Verify that the service is actually alive and responding to the tunnel's requests. Simulate the tunnel's behavior by running a temporary curl container inside the same Docker network:

# Replace 'app_default' with the actual docker network name
sudo docker run --rm --network app_default curlimages/curl -s -I -m 5 http://webapp:8080

If this returns 200 OK, the service is healthy, and the issue lies in the Tunnel or Cloudflare configuration.

5. Common Failures & Edge Cases

[!WARNING]
The Zombie Process (Duplicate Connectors)
When updating or restarting containers (docker-compose down && docker-compose up), Docker sends a SIGTERM to cloudflared. Occasionally, the process ignores the signal, and Docker forcefully orphans it. The process remains alive in the host OS's memory, continuing to send keep-alives to Cloudflare.

Symptom: Cloudflare load-balances traffic between the new healthy container and the old "zombie" process. 50% of incoming requests will randomly return a 502 Bad Gateway.
Fix:

Find the zombie: sudo ps aux | grep cloudflared

Kill the duplicate PIDs: sudo kill -9 <PID>

Prevention: Always add init: true to the cloudflared service in docker-compose.yml. This forces Docker to use a proper init system (Tini) as PID 1, which reliably reaps and kills child processes.

[!CAUTION]
OOM (Out of Memory) Hangs
If the VM lacks sufficient memory (e.g., using an e2-micro with 1GB RAM for a heavy Node.js app), the application may freeze without the container crashing. The status will show Up X minutes, but the application's event loop is blocked.

Symptom: cloudflared cannot proxy requests, Cloudflare times out after 15 seconds, and returns a 502. Running the diagnostic internal curl command will hang indefinitely.
Fix: Increase the VM machine type (e.g., to e2-medium 4GB) or configure swap space.

[!NOTE]
Protocol Mismatch (HTTP vs HTTPS)
While end-to-end HTTPS is the recommended best practice, this guide uses plain HTTP internally for simplicity. If a protocol mismatch occurs, connectivity will fail.

If the internal service expects HTTPS, but cloudflared sends HTTP, the connection will be dropped immediately.

If cloudflared is configured to send HTTPS, it will fail if the internal service presents an untrusted/self-signed certificate (unless configured to skip TLS verification).

Ensure the protocol configured in the Cloudflare Zero Trust Dashboard perfectly matches what the internal container expects.

Configuring Firebase AI Logic for Android to Use Gemini Models

Héctor Romero — Wed, 10 Jun 2026 20:13:47 +0000

What device do we use almost all the time? Our mobile phone, almost certainly. If we wanted to develop mobile apps, we would have wondered how to integrate Artificial Intelligence (AI) into our projects in some way, given its increasing boom.

Some advances have been made with Gemini Nano and Gemma 4 as on-device AI. However, Gemma 4 is a recent release that doesn’t yet have enough maturity in most of cases, due to hardware limitations and model’s own capabilities. These are cases where using models like Gemini shines, which offer higher quality responses, can generate multimodal content and can extend their functions through third-party integrations.

I want to address this topic in two different posts: this first one will explain how you can configure Firebase AI Logic with an Android app; and I will later publish another post with two demos that I showcased at Build With AI 2026, hosted by the GDG Cali chapter.

What is Firebase AI Logic?

Firebase presents Firebase AI Logic as a service focused on offering Gemini API calls to client-side applications, including Android, iOs, web and even experiences developed with Unity.

Firebase is a platform that accelerates the app development for developers that don’t want to build a backend server to build their MVPs or proof of concept, offering a wide range of services like Realtime database, Cloud Storage, Authentication and so on.

With regard to pricing, Firebase AI Logic can be used both in Spark plan and Blaze plan, distinguished by the access of more advanced models and charges for consumption in this last one. If you want to start to experiment with AI in your apps, the Spark plan offers a free tier for the majority of Firebase services.

How I can start to use Firebase AI Logic?

The first step is to access the Firebase console and create a new project using a personal Google account — this is the recommended approach. During the setup, Firebase will ask whether you want to enable AI assistance within the platform and whether you want to activate Google Analytics — both options are optional and do not affect how AI Logic works.

After pressing the “Continue” button, you will land on the Firebase home screen, where a side navigation menu appears on the bottom-left. From here, you can access and manage all platform services. To navigate to AI Logic, find the “AI Services” section, expand it, and select the “AI Logic” option.

You will see a welcome screen for the Firebase AI Logic section along with a “Get started” button. Once you press it, a modal will appear asking you to select the Gemini API provider for your project: Gemini Developer API or Vertex AI Gemini API.

Gemini API providers

Gemini Developer API: available starting from the Spark plan, it offers a generous quota at no cost and lets you experiment without needing to link a billing account — perfect for getting started with this service. Note that image generation models are not available as of this post’s publication date.
Vertex AI Gemini API: designed for production and enterprise-scale use, it gives you access to the most advanced Gemini models (including image, video and audio generation). It requires the Blaze plan to be activated, and you will be charged for the input and output tokens you use.

Note: For more information on pricing and which Gemini models are available on each plan, check out this link.

Depending on the provider that you choose, you will need to follow a series of steps to activate it. Follow the instructions on the platform according to your case.

Firebase AI Logic SDK configuration in Android

Once you reach the “Add Firebase SDK” option after configuring the selected provider, we need to navigate to our Android Studio project. Firebase displays a form with two fields — the android package name (required) and the app nickname (optional). The package name corresponds to applicationId value in the app-level build.gradle.kts file. You can verify this by opening that file — you will find that namespace and applicationId share the same value, which will be the identifier that you need to enter.

When you press “Register app”, you will be given the option to download google-services.json file, which must be moved to the root directory of the app module in your project. To place it correctly in Android Studio, switch the file explorer view to Project (instead of Android), navigate to the /app folder, and place the file there, at the same level as the module’s build.gradle.kts.

After that, we need to go to gradle/libs.versions.toml file and add the following lines of code related to the Firebase and Google Services dependencies, as shown below:

// libs.versions.toml

[versions]
google-services = “4.4.4”
firebase-bom = "34.11.0"

[libraries]
firebase-bom = { module = "com.google.firebase:firebase-bom", version.ref = "firebase-bom" }
firebase-ai = { module = "com.google.firebase:firebase-ai" }

[plugins]
google-services = { id = "com.google.gms.google-services", version.ref = "google-services" }

We will then open the project-level build.gradle.kts file and add the line alias(libs.plugins.google.services) apply false inside the plugins block.

In the app/build.gradle.kts file, we will add alias(libs.plugins.google.services) to its plugins block, and add the following Firebase libraries inside the dependencies block:

// Google Services - Firebase AI Logic

implementation(platform(libs.firebase.bom))
implementation(libs.firebase.ai)

By using platform(libs.firebase.bom), we don’t need to worry about version compatibility across all Firebase packages, since this implementation handles compatibility for all of them automatically.

As we approach the final step, we need to go to the configuration tab of our Firebase AI Logic project and enable the required Gemini Developer APIs if we are using the Spark plan, or the Vertex AI Gemini API if we are using the Blaze plan. In both cases, I recommend enabling the AI monitoring option, as it will allow you to see — directly within Firebase — how many tokens each request consumes, what content it contains, and other relevant data.

After all this groundwork, we are finally ready to start integrating generative AI into our Android apps. Since this configuration process turned out to be quite extensive, I decided to split my original post into two parts — this being the first one, covering the full step-by-step exploration of the tool, and a follow-up post where I will showcase demos using both provider APIs, sending images and text to the Gemini model and even getting it to generate images based on the prompt we provide. In the meantime, you can check out my code from the Build With AI 2026 workshop that I will explain coming soon here.

If you want to learn more about this topic, check out the official Firebase AI Logic guide . I will be back with more Android and AI content :)

The perfect background music for Vibecoding...

Michael Ramich — Mon, 08 Jun 2026 18:01:28 +0000

While vibecoding, you sometimes need some background music. But music can also be a massive distraction. A summary of my journey in finding the perfect background tune.

I started with rap, then techno, then the 90s and 2000s… but they all failed for one reason: They are designed to be listened to actively. They steal your focus.

So I switched to Lo-Fi. It was calm, but it stimulates Alpha waves, which eventually made me sleepy.

So, what is left?

Looking for the perfect tune for Vibecoding, I found an absolute gem:

Stronghold and Anno music.
Finding these soundtracks was like finding the holy grail.

Part of it is pure nostalgia.

But there is a real psychological reason behind it:
Music from 'endless' strategy games is literally engineered to let your brain think freely while keeping you awake.
No vocals. Keeps the language regions of your brain completely free to focus on the code.

It's the perfect balance. It features dynamic elements to keep you alert, yet it is monotonous enough to fade into the background.
It's literally designed for decision-making. It pushes you to be able to complete complex strategy choices without draining your drive.

Combine this with Vibecoding and nostalgia. And you have the perfect workflow drug.

Stronghold Music:

Anno:

Happy (vibe-)coding!

Morning Security Report with Antigravity Agent

Alexander Tyutin — Mon, 01 Jun 2026 04:49:31 +0000

The latest Antigravity updates announced at Google Next brought a lot of interesting features. I am still discovering the details, but one feature really caught my attention.

Now we have separated Antigravity Agent and Antigravity IDE into two different applications. Among the new features, I found scheduled tasks and I already use them every day. What can I highlight here?

You can listen a podcast generated based on this publication (thanks NotebookLM):

Money saving

I love to maximize my ROI (How I maximized my Google Antigravity ROI). I have the cheapest paid plan. It gives me a 5-hour limit window. The limit spending starts with the first use. So, if I am not using any model, the limit is still 5 hours.

From the FinOps perspective, it is a good idea to organize usage so that one or two 5-hour windows run while I am not at my laptop. Then, a new 5-hour window should start when I begin my work in the morning. Antigravity Agent scheduled tasks are a great way to maximize ROI while minimizing effort.

Cognitive Load Reduction

I am a security guy. But I hate security when I am acting as a developer for my own product. So I try to automate not only security routines but the whole security review process.

I already have an Antigravity Workflow to automate the start of a security review (AI-powered repository security check with Antigravity Workflow) and a Quality Gate which helps me to perform a security review of a new MR (How to build a custom AI quality gate on Cloud Run from zero to production). But I still need to do some manual work and think a lot after getting the outputs of these tools.

Kaizen

The security workflow I mentioned above is a good approach. But in case of massive changes, it may require a lot of time to fix findings. That is why the Quality Gate was born. However, all of these tools run when I am working on the product. So I spend my time on security while acting as a developer.

With scheduled tasks, I can perform a deep security review of my repo while I am not working. And it is a real hit! I can not only ask the agent to review the code with its eyes, but it can also run scripts and make calls to external services during the check.

Even more, it can generate a task for me with described fixes. Or, even better, it can generate the code and provide me with the fixes right after the security review - but before I start my working day!

Here is how it looks in practice. I can find the scheduled tasks right in the new Antigravity Agent sidebar:

I configure the agent to act as a scheduled security reviewer. It checks the architecture and code of my jira-auto repository. It finds critical vulnerabilities like SSRF and insecure network configurations, and creates a clear summary:

The agent goes further and generates a detailed "Security Review Digest" artifact with a Threat Severity Matrix. This makes it very easy to understand the impact and prioritize the work:

And the best part? I can ask the agent to implement the fixes for these issues. It resolves the blockers, updates the code, and gives me a finalized security documentation showing that the repository is now 100% green:

I see how this feature helps me to move from just a local MVP to a really interesting setup for automating my developer lifecycle.

Bonus

The prompt used:

You are a scheduled security reviewer of the repository.
Your task is to perform thorough code review from security perspective.
You want to find a cause in the code to block the next MR.
You check not only code itself, but also:
- Architecture.
- Data processing.
- Users intercations.
You also search for similar code in Github to find:
- Issues around security and whether they are similar to the code checked.
- CVE related to the code checked.
- CWE related to the code checked.
- Best practices related to the code checked.
- Recommendations related to the code checked.
In case you can't find the cause to block the checked code you always can find an improvement recommendation.
Generate a digest with findings and recommendations related.

Google I/O 2026: What Happens When Everything Connects?

Romina Elena Mendez Escobar — Sat, 23 May 2026 14:03:06 +0000

This is a submission for the Google I/O Writing Challenge

Google I/O 2026 showed us something that goes beyond a list of launches: a vision of where technology is heading.

Image source: Image created by the author ____________

Sundar Pichai (Google CEO) opened the presentation sharing some interesting numbers about the *evolution of AI with Google statistics that you can see in the following infographic.

Image source: Infographic created by the author ____________

But let’s get back to the event…
Over two hours, Google announced a wide range of products, updates and platforms. From new AI models to smart glasses, from music generation tools to a digital twin of the entire planet.
What stands out is not any single product on its own, but the way they are designed to work together. Most of them are not meant to exist in isolation but to integrate with each other and with the models Google is deploying across its ecosystem.

Below you will find all the launches organized by category, with my take on each one and direct links to the exact moment in the keynote where it was announced.

🧠 Models & Infrastructure

Behind almost everything presented at Google I/O 2026 has the same foundation: more advanced models and an infrastructure designed to scale new forms of interaction between people and systems.

Image source: Image created by the author ____________

Gemini Omni

The first model that allows you to modify videos using natural language, with inputs that can be images, text or video. But it is not just about understanding text, images, audio and video at the same time; it is about reasoning over all of them together to generate something new.
What sets it apart from any previous video generator is that it combines an intuitive understanding of physics with real knowledge about history, science and cultural context. So you can take a video you recorded and ask it to change what happens in it, edit the action, add characters, transform a moment into something completely unexpected.

📍 Gemini Omni → 17:15

• • • •

Gemini 3.5 Flash

Gemini 3.5 Flash is the direct evolution of the main line of large language models (LLM) from Google, optimized to deliver ultra-high speed performance, advanced logical reasoning capabilities and code orchestration. It is an ideal model for building autonomous agents capable of executing complex task flows in the background, writing code, processing large text contexts or powering searches.
All of this while being four times faster than comparable models, which makes it the option specifically designed for agentic tasks.

📍 Gemini 3.5 Flash → 23:43

🤖 Agents & Productivity: Your Digital Life, Managed

This is one of the categories I enjoyed the most, featuring several tools that change the way we work and organize our daily tasks.

Image source: Image created by the author ____________

Gemini Spark

Gemini Spark is a personal AI agent that runs tasks in the background, across all your applications, without you having to supervise every step. With Spark you can organize an event, manage a chain of emails, coordinate a complex task across multiple services.
It also connects with external tools through the open MCP protocol, which extends its reach beyond the Google ecosystem.

📍 Gemini Spark → 35:18

• • • •

Daily Brief

Google has been offering AI summaries for a while, but Daily Brief is something different. Instead of summarizing a document you provide, it reads your chats, your Gmail emails, your calendar context and your pending tasks, and then prioritizes what matters for your day. The difference between a generic summary and one that actually understands your context is significant, and that is exactly what Daily Brief proposes.

📍 Daily Brief → 1:15:06

• • • •

Ask YouTube

Ask YouTube changes the search bar we know on YouTube into a conversation. You can ask for a summary, a specific recommendation, or request to find exactly what you need at a precise moment without watching the full video.
What I find most interesting is the impact on creators. The algorithm can now understand the deeper context of content and recommend videos that used to stay hidden behind generic titles. For creators, this is an opportunity, and for content consumption in general, it changes the way we interact with the platform.

📍 Ask YouTube → 7:41

• • • •

Docs Live

Docs Live changes the way we create documents. While it's already possible to create content using Gemini's voice input options, this solution lets you share your ideas aloud, and Gemini will start creating a document, formatting, structuring, and writing the text in real time.
The key difference from Gemini's existing voice input is that the result isn't a chat response; it's a properly formatted Google Docs document, complete with headings, lists, and a professional structure right from the start.

📍 Docs Live → 9:14

🔍 Search & Commerce: Your Next Purchase Will Be Made by an Agent

AI search is already part of our daily routine, but this year Google took it further, turning search from a simple query into an agent that can look for information and even make purchases on your behalf.

Image source: Image created by the author ____________

AI Search Box

The new search box is no longer limited to text. It now accepts images, files, videos and even Chrome tabs as input. It may seem like a small change, but it completely transforms the experience of searching for something, powered by the new Gemini 3.5 Flash models.

📍 AI Search Box → 46:05

• • • •

Search Agents

Search agents are a feature that, in my opinion, will become essential without many people noticing at first. They are background agents that you can set up to monitor specific topics, such as the value of a stock you are tracking, a flight route for an upcoming trip, or a property you want to rent in a specific neighborhood.

If the agent detects changes, it can summarize the information and notify you. It can pick up updates from blogs, news sites, social media, and real-time data on finance, shopping and sports.
This changes the current experience we have with Google Alerts, which were based only on keywords, since it takes both alerts and information retrieval to a much more advanced level.

📍 Search Agents → 47:48

• • • •

Generative UI in Search

This announcement is quite interesting because information can already be accessed through agents, chats or other channels, but the main idea is to provide an interface that is intuitive for users to interpret that information. Instead of returning a list of links, Search can now build a personalized interactive interface for complex queries. Here you can get a live comparison table, a dynamic chart or an interactive explanation, all generated in real time for your specific question.

📍 Generative UI → 51:17

• • • •

Universal Cart & UCP + AP2

Google is redefining the online shopping experience with two announcements. On one hand, Universal Cart turns the shopping cart into something where you can add products, and the system then works in the background autonomously, monitoring price drops, analyzing price history and notifying you when an item becomes available again.

On the other hand, the Universal Commerce Protocol (UCP) establishes an open standard that allows all of this to scale beyond Google. It creates a common language for agents and systems to work together across the entire shopping process, from finding a product to post-purchase support, connecting consumer platforms, businesses and payment providers.

UCP is compatible with other key ecosystem protocols such as Agent2Agent (A2A), Agent Payments Protocol (AP2) and Model Context Protocol (MCP), positioning it not as a Google tool, but as the infrastructure for agentic commerce.

📍 AP2 Protocol → 1:01:17
📍 Universal Cart → 1:03:13

🎬 Creative Tools: Can anyone make a movie today?

Content creation was another area where the shift in focus at Google I/O 2026 became very clear. It is not just about generating images, music or video, but about how these tools are starting to integrate into a continuous creative flow, closer to a conversation than to a technical process.

Image source: Image created by the author ____________

Google Flow

Google Flow is a creative platform developed by Google that allows users to generate, edit and compose videos, images and music from prompts or images. In its latest update, it integrates with Gemini Omni to take video editing to a more conversational level, allowing you to change environments, add characters, and generate 16 different camera angles from a single image.

📍 Google Flow → 1:28:08

• • • •

Flow Music

Flow Music is a generative tool that allows users to compose songs and create full music videos from prompts. It also lets you provide a reference recording and build a complete track around it, edit it section by section, reimagine the style of a song while keeping its original melody, or create music videos by directly conversing with the agent.
I think it is an ideal tool for independent artists who develop games, apps or video content and want to create using AI.

📍 Flow Music → 1:31:01

• • • •

Stitch

Google Stitch is a tool developed by Google Labs that uses AI to design user interfaces (UI/UX). These designs can be exported directly to code, Figma, Google Antigravity or Google AI Studio. The design process is driven by instructions that can be given through text or voice, and it is generated in real time.

📍 Stitch → 1:25:36

• • • •

Google Pics

Google Pics is a new image creation and editing tool based on Nano Banana, Google’s model for this type of task. It allows users to select and edit specific elements with precision, such as moving objects, changing colors, or transforming one element into another without affecting the rest of the image.

Without a doubt, it is a very useful tool for content creators, making it easier to modify and edit images using text instructions.

📍 Google Pics → 1:24:20

⚙️ Developer Tools & Hardware

This section is perhaps one of the most diverse of the event, as it combines developer tools with consumer hardware that is still in active development. It ranges from systems capable of coordinating code agents at scale to devices that start bringing Gemini interactions directly into the physical world.

Image source: Image created by the author ____________

Antigravity 2.0

Antigravity 2.0 is a native desktop application that works as a central platform for coordinating multiple sub-agents running tasks in parallel. The keynote demo showed one of the most complex examples, building an operating system from scratch, and this tool allows you to create a plan and define how sub-agents should run in parallel in order to achieve the goal.

📍 Antigravity 2.0 → 26:55

• • • •

CodeMender

CodeMender is a security tool originally developed by Google DeepMind. The tool scans code, identifies vulnerabilities autonomously, recommends fixes, tests them in a safe environment, and can apply the necessary patches with your approval at each step.
📍 CodeMender → 1:45:58

• • • •

Audio Glasses

Audio glasses, developed with Samsung and designed in collaboration with Gentle Monster and Warby Parker, allow you to use Gemini without a screen and without taking your phone out. With these glasses, you can ask about a restaurant you just passed, get step-by-step directions, manage calls and messages, take photos with a voice command, or use the apps installed on your phone.
📍 Audio Glasses → 1:34:32

• • • •

Display Glasses & Android XR

Display Glasses go one step further: they include micro-projectors built into the lenses that overlay useful information on the real world, such as navigation maps or real-time translations on signs, among other features.
Meanwhile, Android XR is the operating system platform that powers these devices, developed with Samsung and Qualcomm. It is still in a trusted testers phase, with a wider rollout expected later this year.
📍 Android XR / Display Glasses → 1:33:15

🔬 Science: What Happens When AI Never Stops Researching?

This was, for me, the most important section of the event. The following initiatives from Google apply AI to problems that go far beyond personal productivity, from accelerating scientific research to modeling the global climate and rethinking the process of drug discovery.

Image source: Image created by the author ____________

Gemini for Science

Gemini for Science is a research acceleration platform that allows scientists to stay up to date with newly published papers, turn research goals into executable code, and generate new hypotheses. It is still in a prototype phase in Google Labs, but the concept is what matters: AI is not presented as a replacement for scientific thinking, but as infrastructure that removes friction from the early stages of research, enabling literature search, synthesis of papers, and translation of hypotheses into experiments.
A researcher who can stay updated in real time across their entire field and automatically translate a hypothesis into an experiment is a researcher who can focus on more meaningful work.

📍 Gemini for Science → 1:46:37

• • • •

AlphaEarth Foundations & WeatherNext

AlphaEarth Foundations is a model developed by Google DeepMind that works as an interactive digital twin of the Earth, powered by real-time satellite data, climate sensors, ocean readings, and biodiversity records. Meanwhile, WeatherNext is its atmospheric counterpart, a weather forecasting engine capable of predicting hurricane paths and extreme weather events with greater accuracy and speed than traditional systems.
These models were presented at the conference as examples of how Google’s AI technology can be applied to solve problems that affect billions of people around the world.

📍 AlphaEarth + WeatherNext → 1:46:37

• • • •

Isomorphic Labs

Isomorphic Labs, the biotechnology company within Alphabet (a sister company of Google DeepMind), continues to build on AlphaFold. This is an AI system developed by DeepMind that enables the prediction of protein structures.
It is another example of how Google’s technology is being applied in the pharmaceutical industry, helping to significantly accelerate research and molecular design for treatments against cancer and complex immune disorders.
In the keynote, this work was described as “science at digital speed”, where AI acts as a tool to understand biological systems that were previously impossible to model directly.

📍 Isomorphic Labs → 1:46:37

• • • •

SynthID

SynthID is Google’s invisible watermarking system for AI-generated content. This label is added to images, videos and audio at the moment of creation, allowing anyone or any system to later verify whether something was generated by AI.
This announcement is important not only from a safety perspective, but also because it is being adopted as a standard by companies such as OpenAI and ElevenLabs.

📍 SynthID → 21:06

What I'm Most Excited to Try

If I had to choose the three announcements I will follow most closely:

🛒 Universal Cart & UCP + AP2

These two announcements will change the way we shop online. For years, we have designed experiences for human users: visual interfaces, marketplaces, recommendations and conversion funnels. But Google is proposing something different: agents capable of discovering products, evaluating options, monitoring prices and executing purchases on our behalf.
This means ecommerce is no longer only a human platform interaction, but starts to become an ecosystem where agents also participate as consumers.
I do not think these solutions will replace traditional commerce overnight, but they will deeply change how trust is built, how products are presented, and how companies compete for attention, not only from people but also from intelligent agents.

🔍 Search Agents

Traditional alerts have always been passive: they depended on exact keywords and often generated more noise than context. This is one of the announcements I will probably follow most closely because it completely changes that logic.
Instead of manually searching for information, you can now delegate the monitoring of a topic to a system that understands intent, relevance and meaningful changes. An agent that continuously tracks the internet in the background.
And the more I think about it, the clearer it becomes that this might be one of the most important features of the keynote, precisely because it will quietly integrate into our daily routine.

• • • •

🧬 Gemini for Science

Of everything announced, this is probably the project with the deepest potential impact.
Modern scientific research has a silent problem: the speed of knowledge has already surpassed human capacity to absorb it. Thousands of papers are published every week, information is fragmented, hypotheses are scattered, and entire weeks are spent just trying to stay updated.
Gemini for Science proposes something fundamentally different: turning AI into infrastructure for research.
The ability to translate scientific literature into actionable hypotheses, generate experimental code, connect discoveries across disciplines and accelerate research processes could completely change the scale at which science progresses.
Because perhaps the most important application of artificial intelligence is not to automate work, but to accelerate human knowledge.

🎥 What I Actually Tried: Google Flow

Most of the announcements that caught my attention were related to systems, agents and infrastructure. But beyond the long term vision, I also wanted to understand what it actually feels like to interact with one of these tools in practice.
So instead of just describing them, I decided to try one myself. I opened Google Flow and started experimenting with a short video prompt, and for a moment, I found myself living that childhood idea of creating my own animation.

Image source: Image created by google flow ____________

While doing this, I could not help but think about how tools like this could evolve beyond individual experimentation. In the future, they might become part of how schools teach storytelling, narration and creative thinking, helping children express ideas through visual and generative tools. At the same time, it also raises an interesting challenge: how younger generations will learn to use these systems in a way that is both creative and intentional, rather than just consumptive.

What the Experience Felt Like

The result was an 8 second clip and honestly, the quality surprised me. With a fairly simple prompt describing a scene, the model generated something that looked cinematic and coherent. The prompt itself was also AI generated, and I am leaving it in the appendix at the end of this article in case you want to replicate the experiment.
A few things stood out from the experience.
The 8 second limit felt a bit frustrating at first. But after thinking about it, I am not sure if that is a limitation of Flow or simply how professional video production works. Scenes in film and TV are often short clips that are later assembled in post production. Flow seems to follow that same logic, where you build a story by connecting multiple clips instead of generating one long video in a single shot.

In a previous test, I was able to concatenate two clips, and what impressed me the most was the character consistency between them. The same character appeared in both scenes without drifting, keeping the same look and style. That is actually one of the hardest problems in AI video generation today: maintaining character consistency across different prompts. Flow’s approach of letting you define and save a character that can later be reused across scenes feels like a real step forward. Whether it can maintain that consistency across longer or more complex sequences is something I still want to keep testing.

How I Tested It

Under the hood, I used Gemini Omni Flash as the base model, with an 8 second duration, 2x speed and a 16:9 aspect ratio.
Each generation costs 50 credits, which gives a more concrete sense of the cost per clip when planning a longer project. The tool also allows direct publishing to YouTube and lets you select a custom thumbnail, making the end to end workflow surprisingly complete for a creative platform.

🔮 How far do we want to go?

Google I/O 2026 presented a series of solutions, models and use cases where artificial intelligence is becoming more deeply integrated into our daily lives. But while watching each demo, one broader question kept coming to my mind:

How far do we really want to go?

Because many of these tools do not only automate tasks, they also start to reorganize how we access information, how we make decisions and how we interact with the digital world.

What stood out the most was not each announcement on its own, but what happens when you look at them together. Agents that run in the background, search that becomes conversational, interfaces that adapt to context in real time. Not as isolated products, but as parts of a system that is still being built.

And in any system, what matters is not only each component, but how they connect with each other and what kind of emerging behavior appears when they start interacting.

Google showed the pieces based on AI.

What is still being defined is the full system: its direction, its shape, and how it will integrate into our daily lives and work.
And maybe that is the most important part of this new era: it is not only about what technology is capable of building, but about how each of us decides to interpret it, use it, and become part of it.

⚠️ A note on process and transparency

I am an organizer at GDG Barcelona, and I led the event where we brought together 37 people to watch the full Google I/O 2026 keynote live. That experience, I was able to follow the announcements in real time, listening to the reactions in the room ... is what shaped the perspective and opinions in this article.

This article is also based on the official sources listed in the references section, which I read and consulted directly after the event to verify and expand on each announcement.

All the visuals in this article were designed by me using Figma Design, because creating my own images is something I genuinely enjoy as part of my writing process. AI tools were used for text correction and translation assistance and all opinions, analysis and perspectives are my own.

📚 References

Google. (n.d.). Gemini Omni. Google Blog. https://blog.google/intl/es-es/productos/presentamos-gemini-omni/ (Accessed May 22, 2026)
Google. (n.d.). Gemini Spark. Gemini Overview. https://gemini.google/overview/agent/spark/ (Accessed May 22, 2026)
Google. (n.d.). Daily Brief. Gemini Overview. https://gemini.google/overview/daily-brief/ (Accessed May 22, 2026)
Google. (n.d.). The next evolution of the Gemini app. Google Blog. https://blog.google/innovation-and-ai/products/gemini-app/next-evolution-gemini-app/ (Accessed May 22, 2026)
YouTube. (n.d.). YouTube News: Google I/O 2026. YouTube Blog. https://blog.youtube/news-and-events/youtube-news-google-io-2026/ (Accessed May 22, 2026)
Google. (n.d.). YouTube search updates and AI features. Google Support. https://support.google.com/youtube/answer/16943763?hl=en (Accessed May 22, 2026)
Google. (n.d.). Search at Google I/O 2026: AI-powered search updates. Google Blog. https://blog.google/products-and-platforms/products/search/search-io-2026/ (Accessed May 22, 2026)
Google. (n.d.). Universal Cart and shopping updates. Google Blog. https://blog.google/intl/es-419/actualizaciones-de-producto/informacion/google-shopping-cart/ (Accessed May 22, 2026)
Google. (n.d.). Merchant Center help: Shopping updates. Google Support. https://support.google.com/merchants/answer/16837055?hl=es (Accessed May 22, 2026)
Google. (n.d.). Flow updates. Google Blog. https://blog.google/intl/es-419/actualizaciones-de-producto/flow-updates/ (Accessed May 22, 2026)
Google. (n.d.). Stitch updates from Google Labs. Google Blog. https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-updates/ (Accessed May 22, 2026)
Google. (n.d.). Google I/O 2026 developer tools highlights. Google Blog. https://blog.google/innovation-and-ai/technology/developers-tools/google-io-2026-collection/ (Accessed May 22, 2026)
Google. (n.d.). Workspace updates at Google I/O 2026. Google Blog. https://blog.google/products-and-platforms/products/workspace/workspace-updates/ (Accessed May 22, 2026)
Google. (n.d.). Antigravity 2.0. https://antigravity.google/product/antigravity-2 (Accessed May 22, 2026)
Google. (n.d.). Developer highlights from Google I/O 2026. Google Blog. https://blog.google/innovation-and-ai/technology/developers-tools/google-io-2026-developer-highlights/ (Accessed May 22, 2026)
Google Cloud. (n.d.). Innovations from Google I/O 2026 on Google Cloud. https://cloud.google.com/blog/products/ai-machine-learning/innovations-from-google-io-26-on-google-cloud (Accessed May 22, 2026)
Google. (n.d.). Android XR at Google I/O 2026. Google Blog. https://blog.google/products-and-platforms/platforms/android/android-xr-io-2026/ (Accessed May 22, 2026)
DeepMind. (n.d.). SynthID. https://deepmind.google/models/synthid/ (Accessed May 22, 2026)

📄 Appendix

This is the AI-generated prompt I used to create the video in Google Flow. I am including it here so you can replicate the experiment or explore it further.

A short animated intro video, 15 seconds. Chibi anime art style — soft cel-shading, vibrant neon colors, cinematic lighting, dark moody atmosphere. Think Lo-Fi anime meets cyberpunk gamer aesthetic.
Character: A small chubby panda in chibi style. Oversized black hoodie with hood down while walking, round panda ears visible on top. Serious and unbothered expression. Tiny paws. Soft black and white fur with subtle neon light reflections. This is a developer panda — cool, focused, says nothing.
Scene 1 — 0:00 to 0:05: Wide shot of a dark misty forest at night. A distant neon city skyline glows purple and cyan through the trees. Fog rolls along the ground. The panda walks alone from the right side of frame through a forest path, hands in hoodie pocket, completely unbothered. He approaches a large mossy rock formation — a hidden cave entrance covered by hanging vines with faint bioluminescent blue glow. He pushes the vines aside and steps in. Slow cinematic cut to black.
Scene 2 — 0:05 to 0:10: Interior of the cave — full gamer setup. RGB neon strips in Google colors (blue, red, yellow, green) line the rocky cave walls casting dramatic colored light on everything. A dark stone desk holds a glowing MacBook Pro, mechanical keyboard with RGB backlighting, mouse with neon underglow, and stacked empty energy drink cans. The panda walks to the desk, drops his backpack on the floor. Pulls out the chair and sits down. He opens the MacBook — a burst of white light floods his face and the cave. He slowly reaches to the side, picks up thick black sunglasses and puts them on. Then places large black headphones over his panda ears. He cracks his tiny paw knuckles. Leans forward. The RGB strips pulse once in sync.
Scene 3 — 0:10 to 0:15: Ultra slow cinematic push-in toward the MacBook screen. The cave darkens around it. The screen fills the entire frame glowing bright. Bold text appears: "GOOGLE I/O 2026 — THE AGENTIC ERA IS HERE" in clean white typography on dark background. Neon blue and green light pulses around the text edges. Below it, six glowing color blocks appear one by one with smooth fade-ins: MODELS · AGENTS · SEARCH · CREATIVE · DEV · SCIENCE. Each block in its Google neon color, white bold uppercase text, subtle neon glow border. Final frame holds 2 seconds with all blocks visible, neon pulsing softly. Fade to black.
Lighting & mood throughout: Dark, moody, cinematic. Neon reflections on all surfaces — the panda's fur, the cave walls, the desk. Color palette: deep black backgrounds, cyan #00F5FF, neon green #39FF14, Google blue #4285F4, Google red #EA4335, Google yellow #FBBC04, purple #BF5FFF. Inspired by cyberpunk anime aesthetics — think lo-fi coder vibes meets Akira color palette.

Bypassing User Isolation on Android with a Screen Reader

Karol Wrótniak — Fri, 15 May 2026 10:58:39 +0000

A single missing check in Android lets one user's screen reader leak another user's private notifications. Here's how it happened.

Multi-user & Accessibility on Android

Android's multi-user support lets several people share one device. Each user gets their own space, apps, and data. This feature is common on tablets. But not all smartphones have it. Even so, the code is there. The problem is that accessibility services run with high privileges. They need to see everything to help users. Sometimes, this power breaks the walls between users.

Screen Readers & TalkBack

Screen readers turn text into speech. They allow people with low vision to use apps. The screen may even be completely off, but the user can still interact with the device. TalkBack is Google's screen reader for Android. Normally, TalkBack only reads the currently focused UI elements. But there are ways to make it speak programmatically.

One is announceForAccessibility() (now deprecated) – a method that forces the screen reader to read arbitrary text. Another is live regions – parts of the UI that update without user interaction. When something changes, the system fires an accessibility event (a system-level broadcast) that carries the updated text. A screen reader picks it up and reads the new value aloud. Status bar notifications are one example of live regions.

The Bug: CVE-2022-20448

The bug was simple: NotificationManagerService didn't check if a notification belonged to the current foreground user before dispatching the accessibility event. This is what caused screen readers to read it out loud.

Imagine a phone with two users: Alice (using the phone right now) and Bob (a background user).

Bob receives a text message: "Your verification code is 3291".
The system posts the notification and fires an accessibility event containing that text.
TalkBack on Alice's active session picks up the event and reads it aloud.
Alice hears Bob's private 2FA code.

Screen readers weren't the only apps that could intercept this data. Android dispatches accessibility events to all registered accessibility services – not just TalkBack. Apps like Tasker, which registers as an accessibility service for UI automation, or notification-logging apps would also receive Bob's notification content.

The Fix

The entire fix was a single added condition – checking whether the notification actually belongs to the current user – plus a unit test to prevent regression:

// frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

-                && !suppressedByDnd) {
+                && !suppressedByDnd
+                && isNotificationForCurrentUser(record)) {

isNotificationForCurrentUser() returns true only when the notification's owner matches the foreground user – so background users' notifications are no longer broadcast as accessibility events.

The issue was reported on June 29, 2022. Google awarded a $5,000 bounty for the finding. They marked the bug as High severity in the November 2022 Android Security Bulletin and released patches for Android 10, 11, 12, 12L, and 13. The vulnerability is tracked as CVE-2022-20448.

Takeaway

It really makes you wonder just how many security bugs are hiding behind assistive technologies.