2026-04-30 12:39:20

If you have been using Claude Code interactively, you already know what it can do in a session. Routines take that further: you define a prompt once, wire up a trigger, and Claude Code runs autonomously on Anthropic-managed cloud infrastructure whenever that trigger fires. Your laptop can be off. The job still runs.

This article walks through what routines are, how to set them up, and where the rough edges are during the current research preview.

What Is a Routine?

A routine is a saved Claude Code configuration. It packages three things:

• A prompt (the instructions Claude runs each time)
• One or more GitHub repositories to work in
• A set of connectors (MCP servers for external services like Slack, Linear, etc.)

You attach one or more triggers to it. Each trigger type determines when a run starts:

• Schedule - recurring on a cron cadence, or a one-off at a specific timestamp
• API - an HTTP POST to a per-routine endpoint with a bearer token
• GitHub event - reactions to pull requests, releases, and similar repository events

A single routine can combine all three. A PR review routine could run nightly, also fire when your CD pipeline calls the endpoint, and also react to every new pull request.

Routines are available on Pro, Max, Team, and Enterprise plans with Claude Code on the web enabled. You manage them at claude.ai/code/routines or from the CLI using /schedule.

Why This Matters

The key property is that routines run without you present. A regular Claude Code session expects you to review, approve, and guide. A routine is designed for unattended, repeatable work tied to a clear outcome.

That changes the use cases you can build:

Backlog maintenance. A schedule trigger runs every weeknight. The routine reads issues opened since the last run, applies labels, assigns owners based on the area of code referenced, and posts a summary to Slack. Your team starts the day with a groomed queue.

Alert triage. Your monitoring tool POSTs to the routine's API endpoint when an error threshold crosses. The routine pulls the stack trace, correlates it with recent commits, and opens a draft PR with a proposed fix. On-call reviews the PR instead of starting from a blank terminal.

Bespoke code review. A GitHub trigger fires on pull_request.opened. The routine applies your team's review checklist and leaves inline comments covering security, performance, and style issues. Human reviewers focus on design decisions.

Library porting. A trigger fires on merged PRs in one SDK repository. The routine ports the change to a parallel SDK in another language and opens a matching PR. Two libraries stay in sync without a human re-implementing each change.

Creating a Routine

You can create routines from the web UI, the Claude Desktop app, or the CLI.

From the Web

1. Go to claude.ai/code/routines and click New routine.
2. Name it and write the prompt. The prompt is the most important part. Since the routine runs autonomously, the prompt must be self-contained and explicit about what to do and what success looks like.
3. Select one or more GitHub repositories. Each is cloned fresh at the start of every run from the default branch.
4. Pick a cloud environment (controls network access, environment variables, and setup scripts). A Default environment is provided.
5. Add triggers (Schedule, GitHub event, or API).
6. Review connectors. All your connected MCP connectors are included by default. Remove any the routine does not need.
7. Click Create.

After creation, click Run now on the detail page to start an immediate run without waiting for a trigger.

From the CLI

/schedule daily PR review at 9am

/schedule in 2 weeks, open a cleanup PR that removes the feature flag

Claude walks through the same information the web form collects and saves the routine. The CLI supports scheduled triggers only. To add API or GitHub triggers, edit the routine on the web afterward.

Useful CLI management commands:

/schedule list        # see all routines
/schedule update      # change a routine
/schedule run         # trigger a routine immediately

Configuring Triggers

Schedule Triggers

Pick a preset: hourly, daily, weekdays, or weekly. Times are entered in your local timezone and converted automatically. Runs may start a few minutes after the scheduled time due to stagger, but the offset is consistent for each routine.

For custom intervals (every two hours, first of each month), pick the closest preset in the form and then use /schedule update in the CLI to set a specific cron expression. The minimum interval is one hour.

One-off runs fire the routine a single time at a specific timestamp, then auto-disable. Useful for cleanup after a rollout, follow-ups when an upstream change lands, or end-of-week summaries.

One-off runs do not count against the daily routine run cap. They draw down your regular subscription usage like any other session.

API Triggers

An API trigger gives the routine a dedicated HTTP endpoint. POSTing to it with the bearer token starts a new session and returns a session URL.

To set one up:

1. Open the routine for editing.
2. Click Add another trigger and choose API.
3. Copy the URL and click Generate token. Store the token immediately - it is shown once and cannot be retrieved later.

Here is how to call the endpoint:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

The text field is optional freeform context passed alongside the saved prompt. It is not parsed - if you send JSON, the routine receives it as a literal string.

A successful response looks like this:

{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}

Open the session URL to watch the run in real time, review changes, or continue the conversation manually.

Note: The /fire endpoint ships under the experimental-cc-routine-2026-04-01 beta header. Request and response shapes, rate limits, and token semantics may change. Breaking changes ship behind new dated beta header versions, with the two most recent previous versions remaining active during migration.

Each routine gets its own token scoped to that routine only. To rotate or revoke it, return to the same modal and use Regenerate or Revoke.

GitHub Triggers

GitHub triggers start a new session automatically on matching repository events. Each matching event starts its own independent session - there is no session reuse across events.

Supported events:

You can subscribe to a specific action (like pull_request.opened) or to all actions in the category.

Filters let you narrow which events actually start a session:

Operators: equals, contains, starts with, is one of, is not one of, matches regex.

One thing to watch with regex: the matches regex operator tests the entire field value, not a substring. To match any PR title containing hotfix, write .*hotfix.*. Without the surrounding .*, it only matches a title that is exactly hotfix and nothing else. For substring matching without regex syntax, use the contains operator.

Example filter combinations:

• Auth module review: base branch main, head branch contains auth-provider
• Ready-for-review only: is draft is false
• Label-gated backport: labels include needs-backport

The Claude GitHub App must be installed on the repository. The trigger setup prompts you if it is not already. Note that running /web-setup in the CLI grants repository access for cloning but does not install the GitHub App and does not enable webhook delivery. GitHub triggers require the App specifically.

During the research preview, GitHub webhook events are subject to per-routine and per-account hourly caps. Events beyond the limit are dropped until the window resets.

Branch Behavior and Safety

By default, Claude can only push to branches prefixed with claude/. This prevents routines from accidentally modifying protected or long-lived branches.

To allow pushing to any branch (for example, if you need Claude to push directly to main or a release branch), enable Allow unrestricted branch pushes for that repository when creating or editing the routine. Scope this permission carefully.

Connectors

Routines can use your connected MCP connectors to read from and write to external services during each run. A backlog routine might read from a Slack channel and create issues in Linear. An alert triage routine might read from PagerDuty and push to GitHub.

All connectors are included by default when you create a routine. Remove any the routine does not actually need. During a run, Claude can use every tool from an included connector, including writes, without asking for permission.

Usage and Limits

Routines draw down subscription usage the same way interactive sessions do. There is also a daily cap on how many routine runs can start per account.

You can check your current consumption and remaining daily routine runs at claude.ai/code/routines or claude.ai/settings/usage.

When a routine hits the daily cap or your subscription usage limit, organizations with extra usage enabled can keep running routines on metered overage. Without extra usage, additional runs are rejected until the window resets. Enable extra usage from Settings > Billing.

One-off runs are exempt from the daily routine run allowance. They still consume your regular subscription usage.

There is no per-run token count displayed directly in the routine detail view. Usage is reflected in your overall account consumption at the settings page rather than being itemized per routine run.

Managing Runs

Click a routine in the list to open its detail page. From there you can view past runs, see what Claude did in each run, review changes, create a pull request, or continue the conversation.

You can also:

• Click Run now to start an immediate run
• Toggle the schedule on and off to pause or resume
• Edit the name, prompt, repositories, environment, connectors, or triggers
• Delete the routine (past sessions created by it remain in your session list)

Things to Know Before You Ship

Routines run as you. Anything a routine does through your connected GitHub identity or connectors appears as your account. Commits and pull requests carry your GitHub user. Slack messages and Linear tickets use your linked accounts.

Routines belong to your individual account. They are not shared with teammates and count against your account's daily run allowance.

The prompt is everything. The routine runs autonomously with no approval prompts. There is no permission-mode picker. Write prompts that are self-contained, explicit about the goal, and explicit about what success looks like.

This is research preview. Behavior, limits, and the API surface may change. The /fire endpoint ships under a dated beta header for exactly this reason.

Related Resources

• Claude Code on the web reference
• MCP connectors

2026-04-30 12:37:24

Hello readers 👋, welcome to the 18th blog in this JavaScript series!

Today we are going to tackle a topic that confuses almost every JavaScript developer at some point: the this keyword. It can feel unpredictable if you don't understand what sets its value, but once you realize that this is simply determined by how a function is called, not where it's defined, everything starts to click.

We will keep things simple, practical, and visual. No deep internal engine details, just a clear mental model you can rely on every time you see this in your code.

Let's begin.

What does this represent?

Think of this as a special variable that points to the caller of a function, or more accurately, the execution context in which a function runs. In most cases, you can figure out the value of this by looking at the dot before the function name. If there is an object before the dot, this refers to that object. If there is no dot, this refers to the global object (or is undefined in strict mode).

This one rule covers a huge number of situations. Let's see how it plays out in different contexts.

this in the global context

When you are not inside any function or object, this points to the global object. In a browser, that's the window object. In Node.js, it's global. You can test this easily:

console.log(this); // In browser: window object

If you open your browser console and type this, you'll see the window object printed. In a Node REPL, you'll see global. That's the simplest case.

this inside a regular function

Here is where people often trip up. In a standalone function call (without an object), the value of this depends on whether strict mode is enabled or not.

In non-strict mode, this inside a function called like myFunc() will be the global object:

function showThis() {
  console.log(this);
}
showThis(); // window (in browser, non-strict)

In strict mode (with "use strict"), this is undefined. This is actually better because it prevents accidentally poking the global object.

"use strict";
function showThis() {
  console.log(this);
}
showThis(); // undefined

The takeaway: a plain function call sets this to the global object or undefined in strict mode. But in both cases, it's not something we typically want.

this inside an object method

When a function is called as a method of an object (with object.method()), this points to the object that the method belongs to. This is the most intuitive and common use case.

const person = {
  name: "Satya",
  greet: function() {
    console.log("Hello, I'm " + this.name);
  }
};

person.greet(); // Hello, I'm Satya

Here, person is the caller. The dot before greet() tells us that this inside greet is the person object. So this.name gives "Satya". This works beautifully for sharing data among methods of the same object.

We can also have multiple objects sharing the same method definition. The value of this will change based on which object called the method:

function sayName() {
  console.log(this.name);
}

const user1 = { name: "Amit", speak: sayName };
const user2 = { name: "Priya", speak: sayName };

user1.speak(); // Amit
user2.speak(); // Priya

Notice that sayName is the same function, but because we call it via user1.speak(), this becomes user1. When called via user2.speak(), this becomes user2. The function itself doesn't own a fixed this. The call site decides.

How the calling context changes this

The magic of this lies in its dynamic nature. But this also means you can lose the intended binding if you call a method without its object. This happens often with callbacks or when you assign a method to a variable.

Let's see a classic pitfall:

const counter = {
  count: 0,
  increment: function() {
    this.count++;
    console.log(this.count);
  }
};

const inc = counter.increment;
inc(); // NaN or error

What happened? We assigned counter.increment to inc and then called inc() without any object before the dot. That makes this become the global object (or undefined in strict mode). this.count is then undefined, and incrementing it gives NaN. The original counter.count remains untouched.

To fix this, we need to explicitly bind this to a specific object. JavaScript gives us three powerful tools for that: call, apply, and bind.

call and apply

Both call and apply invoke the function immediately with a specified this value. The difference is how you pass arguments.

function introduce(city, country) {
  console.log("I am " + this.name + " from " + city + ", " + country);
}

const user = { name: "Satya" };

introduce.call(user, "Bhubaneswar", "India");
introduce.apply(user, ["Bhubaneswar", "India"]);

Both lines set this to user. call takes arguments one by one, apply takes an array of arguments. This is useful when you need to borrow methods or reuse functions with different contexts.

bind

bind is different. It doesn't call the function immediately. Instead, it returns a new function where this is permanently locked to the given object.

const counter = {
  count: 0,
  increment: function() {
    this.count++;
    console.log(this.count);
  }
};

const boundInc = counter.increment.bind(counter);
boundInc(); // 1
boundInc(); // 2

Even though we call boundInc() without an object, this inside it is always counter. This is incredibly handy for passing methods as callbacks without losing the intended context.

Visualizing the caller relationship

A simple mental picture can help. Imagine every function being a piece of code waiting for an instruction. When you call it through an object, it's like the object hands over its identity key to the function, saying, "I am the one calling you, use me as this."

caller.method()
   ^
   |
 this = caller

If there is no caller object, JavaScript falls back to the global environment (or undefined in strict mode). Explicit binding with call, apply, or bind is like personally handing over a specific identity key, no matter how the function is called later.

This is why losing context happens: you might pass a function without its object, and the default fallback kicks in.

Arrow functions and this (a quick note)

You will likely encounter arrow functions, and they handle this differently. Arrow functions don't have their own this. They inherit this from the surrounding scope at the time they are defined. This is called lexical scoping.

For example:

const person = {
  name: "Satya",
  greet: function() {
    const inner = () => {
      console.log(this.name);
    };
    inner();
  }
};

person.greet(); // Satya

Even though inner() is called like a regular function, it uses the this from greet because that's where it was defined. This behavior makes arrow functions very convenient as callbacks inside methods.

But keep in mind: if you define a method itself as an arrow function, it will capture the global this or the this of the enclosing scope, not the object. So it's best to use regular functions for object methods unless you have a specific reason.

Summary of contexts

Let's put everything together in a quick reference:

We haven't covered constructors in this post, but they also set this to the fresh instance. That's a topic for another day.

Conclusion

The this keyword is not magical. It's a dynamic reference that depends on how a function is invoked. Once you train yourself to look at the call site, this becomes predictable and powerful.

To recap the key points:

• this represents the calling object when a function is called as a method.
• In a plain function call (non-strict), this is the global object; in strict mode, it's undefined.
• You can explicitly set this using call, apply, and bind.
• Arrow functions don't have their own this; they capture it from the enclosing scope.
• The most common pitfall is losing context when passing a method as a callback, which bind easily fixes.

I hope this clears up the mystery around this and gives you confidence to use it intentionally. With this foundation, you are well equipped to handle more complex patterns like constructor functions, classes, and event handling.

Hope you found this helpful! If you spot any mistakes or have suggestions, let me know. You can find me on LinkedIn and X, where I post more about web development.

2026-04-30 12:30:00

🔍 Overview
In modern applications, secure and seamless user onboarding is critical — especially when identity verification (KYC) is involved.

In this article, I’ll walk through how we integrated the uqudo SDK Flutter plugin into a FlutterFlow application using Custom Actions to enable a robust identity verification flow.

This solution leverages uqudo’s official Android and iOS SDKs to deliver a secure, scalable, and efficient KYC experience — particularly optimized for users across the Middle East & Africa.

🎯 Objective
The goal was to implement a reliable identity verification system in FlutterFlow that:

• Accelerates user onboarding
• Reduces manual verification efforts
• Seamlessly integrates into a no-code / low-code workflow
• Maintains high security and accuracy

🛠 Technology Stack

• FlutterFlow
• Custom Actions (Flutter code)
• uqudo SDK Flutter Plugin
• Android & iOS Native SDKs
• Device Camera (Front Camera)

🧩 Architecture & Implementation Approach
To integrate uqudo into FlutterFlow, we followed a hybrid approach:

• The uqudo Flutter plugin was added to the FlutterFlow project
• Custom Actions were used to bridge FlutterFlow UI with SDK functionality
• Platform-specific logic was handled in:
• android/ (native implementation)

• ios/ (native implementation)
  This approach allowed us to:

• Use advanced native SDK features

• Keep FlutterFlow UI clean and manageable

• Maintain flexibility for future enhancements

🔄 Verification Flow
1️⃣ Identity Document Scanning
We implemented document scanning for:

• Aadhaar Card
• PAN Card Using uqudo’s document verification capabilities, the app extracts and validates identity data efficiently.

2️⃣ Face Capture & Biometric Verification

• The device’s front camera is used to capture the user’s face
• Face matching is performed against the scanned document

This ensures:

• Authenticity
• Fraud prevention
• Real-time verification

3️⃣ Verification Result Handling
Clear outcomes are displayed directly in the UI:

• ✅ Face matched successfully
• ❌ Face mismatch detected This improves transparency and user trust during onboarding.

4️⃣ Error Handling & User Feedback
Robust error handling was implemented using Custom Actions to manage:

• Invalid document scans
• Face mismatch scenarios
• Camera permission issues
• SDK-related errors Providing clear feedback significantly improved the user experience.

✅ Outcome & Impact
Successfully implemented a production-ready KYC flow within FlutterFlow
Reduced onboarding friction with automation
Enabled seamless integration of native SDKs in a low-code environment
Improved user trust with real-time verification feedback

🚀 Key Learnings
FlutterFlow Custom Actions are powerful for integrating complex SDKs
Combining low-code UI with custom Flutter logic offers both speed and flexibility
Native SDK integration is achievable without compromising maintainability
Proper error handling is critical for user trust and retention

🔗 Conclusion
Integrating the uqudo SDK in FlutterFlow using Custom Actions proved to be an effective approach for building a secure and scalable identity verification system.

This method bridges the gap between low-code development and advanced native capabilities, enabling faster delivery without sacrificing control or performance.

✨ Final Thoughts
If you’re building a FlutterFlow app that requires KYC, identity verification, or onboarding automation, this approach can significantly reduce development complexity while ensuring a high-quality user experience.

FlutterFlow #Flutter #MobileDevelopment #KYC #IdentityVerification

2026-04-30 12:28:52

This is a submission for the Google Cloud NEXT Writing Challenge

Topic: Cloud Run’s new serverless primitives—Cloud Run Instances, Cloud Run Sandboxes, and Ephemeral Disk Storage—announced at Google Cloud Next ’26, plus native integration with the Gemini Enterprise Agent Platform via the Model Context Protocol (MCP).

Format: Opinion Piece

Introduction: The Announcement Nobody Is Talking About

Google Cloud Next ’26 produced 260 announcements [1]. Predictably, the headlines went to the Gemini Enterprise Agent Platform—the rebranded, expanded successor to Vertex AI—alongside eighth-generation TPUs, the Agentic Data Cloud, and the Wiz-powered Agentic Defense story [2]. Thomas Kurian’s keynote framed the entire conference around a singular, aggressive thesis: the agentic enterprise is here, and Google Cloud is its operating system [6].

Buried beneath that flashy narrative, however, was a set of infrastructure announcements that will easily outlast the keynote buzz. Google quietly introduced three new Cloud Run primitives that fundamentally redefine what serverless means on GCP. Alongside these, the platform revealed a tight, native integration with the Gemini Enterprise Agent Platform via the Model Context Protocol (MCP) [6]. Together, these updates transform Cloud Run from a passive HTTP host into a stateful, secure, agent-first compute fabric.

The developer community has largely ignored these primitives in favor of the Gemini spectacle. That is a massive mistake. This evolution addresses the single greatest barrier to production-grade AI agents—trustworthy, isolated, and persistent execution—in a way no hyperscaler has delivered before. If developers overlook these primitives now, they will spend the next two years retrofitting architectures that could have been built correctly from day one.

The Problem: Why “Traditional” Serverless Failed the Agentic Era

Before examining the new primitives, we have to understand the architectural gap they fill. Cloud Run established itself as the gold standard for stateless, request-driven compute, abstracting away the Kubernetes control plane while preserving Knative’s operational simplicity. But this model was designed for a world of synchronous HTTP requests, not for AI agents that:

• Run continuously for hours.
• Maintain complex conversational state.
• Execute dynamically generated, untrusted code.
• Demand persistent, local scratch space.

The industry workarounds had become folklore. Developers pinged their own endpoints to keep containers warm. They massively over-provisioned RAM because the local filesystem was an in-memory tmpfs—meaning if you staged a 2 GB dataset, you consumed 2 GB of your container’s memory, often triggering an OOM (Out of Memory) kill.

For anything more complex, teams begrudgingly fell back to GKE clusters or VMs. These weren’t edge cases; they were the default, broken patterns for agentic workloads. One Chinese developer perfectly summarized the prevailing anxiety in the community:

Giving an LLM the keys to a shell and hoping it behaves isn’t security; it’s a prayer. This is exactly the crisis Google’s new Cloud Run primitives solve.

The Four Primitives That Change Serverless

Google announced four interconnected capabilities at Next ’26. Here is a breakdown of what they are and why they matter.

The Architectural Shift at a Glance

1. Cloud Run Instances (Preview): Guaranteed Baseline Compute

Historically, Cloud Run’s scale-to-zero model left a frustrating gap for architectures requiring continuous background processing or persistent daemons. Cloud Run Instances bridge that gap by provisioning long-lived, dedicated containers that do not scale to zero [3].

From a systems-engineering perspective, this is the most critical primitive. It provides a native serverless abstraction for continuous event backbones without relying on HTTP concurrency hacks. The official blog demonstrated a single command to provision such an instance with a Cloud Storage volume mount:

gcloud run instances create \
  --image alpine/openclaw:latest \
  --port 18789 \
  --memory 4Gi \
  --default-url \
  --add-volume mount-path=/home/node/.openclaw,type=cloud-storage,bucket=$BUCKET_NAME

Developers no longer need to choose between the operational simplicity of serverless and the continuous persistence requirements of stateful workloads.

2. Cloud Run Sandboxes (Preview): Zero-Trust Execution

When building systems that dynamically generate and execute code, you are dealing with fundamentally untrusted workloads. Cloud Run Sandboxes expose gVisor-backed, micro-VM isolation as a configurable developer primitive, allowing you to spin up execution environments with granular egress and syscall restrictions [4].

This is the exact same isolation technology Google uses to protect Gemini itself. The performance characteristics are staggering: 300 sandboxes launched per second per cluster, sub-second time-to-first-instruction, and stateful session persistence [5]. Prior approaches forced a trade-off: sacrifice isolation (shared storage) or sacrifice continuity (reconstructing the environment for every call). Cloud Run Sandboxes maintain strict boundaries while preserving session state—acting as a "memory-equipped prison" for autonomous code execution.

3. Ephemeral Disk Storage (Preview): Breaking the RAM Tax

This primitive will immediately improve the quality of life for developers doing data-intensive work. Previously, staging large datasets meant paying a massive "RAM tax" due to the tmpfs filesystem.

Ephemeral Disk Storage attaches dedicated, local, high-speed block storage (NVMe-backed) directly to your instances [3]. This storage dies with the instance, but crucially, it does not consume your memory allocation. A Kafka consumer buffering gigabytes of streaming data can now write to local NVMe rather than holding it in memory, avoiding OOM kills entirely [4].

4. Gemini Enterprise Agent Platform Integration via MCP (Preview)

Google tightly integrated Cloud Run with the Gemini Enterprise Agent Platform using the Model Context Protocol (MCP). This allows multi-agent systems to securely interface with internal infrastructure without building custom authentication middleware; the transport layer is natively authenticated via Google Cloud IAM [4].

This elevates Cloud Run from a mere hosting target to a cognitive capability. An agent equipped with an MCP-mapped skill can dynamically act as its own platform engineer—provisioning an Instance for a background daemon or a Sandbox for safe code execution on the fly.

Production Patterns: What This Actually Enables

Architectural features are only as valuable as the systems they enable. Here are four production patterns these primitives unlock [4]:

• Continuous Stateful Ingestion: Combine Instances and Ephemeral Disk to deploy a horizontally scalable Kafka consumer group entirely on serverless. Instances maintain uninterrupted connections; NVMe buffers the payloads.
• Autonomous Zero-Trust SOC Analyst: Security agents often need to execute dynamic scripts to analyze suspicious binaries. Cloud Run Sandboxes ensure this execution occurs within an isolated gVisor micro-VM with restricted network egress, ensuring a zero-blast radius.
• Agentic Firewall Configuration Loops: An Instance can run continuously to tail telemetry logs. Upon detecting an anomaly, it triggers a Gemini Agent via MCP, which securely navigates the firewall architecture via IAM and updates blocklists in real time.
• The Agentic Platform Engineer: A local agent equipped with an MCP-mapped Skill can dynamically orchestrate its own Instances, Sandboxes, and Ephemeral Disks to solve complex problems, provisioning its own compute resources in real time.

The Critique: What’s Missing and What to Watch

An honest evaluation requires acknowledging the gaps:

• Preview Gating: The most valuable primitives are preview-only and limited to select customers. Developers must weigh the risk of betting on preview APIs against immediate architectural benefits.
• Vendor Coupling Risk: The MCP integration is deeply tied to Google Cloud IAM. While the A2A (Agent-to-Agent) protocol and ADK (Agent Development Kit) are open-source, the managed hosting layer and Agent Registry are heavily coupled to GCP [5].
• Observability Maturity: Debugging what happened inside an ephemeral gVisor container requires a mature observability pipeline. While ADK 1.0’s OpenTelemetry integration is encouraging, the sandbox-specific tracing story needs clearer documentation.
• The Competitive Landscape: AWS Lambda and Azure Container Apps haven't responded with equivalent primitives yet—but they will. Google’s gVisor-backed serverless sandboxing is a massive first-mover advantage, but it is a window of opportunity, not an impenetrable moat.

Conclusion: The Foundation, Not the Fireworks

The Gemini Enterprise Agent Platform is the user-facing story of Next ’26. But platforms need foundations, and Cloud Run’s new primitives are precisely that: the infrastructure layer that makes agentic workloads production-grade rather than a flimsy proof-of-concept.

My recommendation to the developer community is straightforward: look past the keynote pyrotechnics. Experiment with Cloud Run Instances for your stateful workloads. Evaluate Cloud Run Sandboxes as the execution boundary for any agent running untrusted code. Plan your capacity models around Ephemeral Disk rather than RAM over-provisioning.

The agentic era demands infrastructure that is stateful, secure, and highly composable. Google shipped exactly that at Next ’26. The rest of us just haven’t noticed yet.

References

[1] Google Cloud, “260 things we announced at Google Cloud Next ’26 – a recap,” Google Cloud Blog, Apr. 25, 2026. [Online]. Available: https://cloud.google.com/blog/topics/google-cloud-next/google-cloud-next-2026-wrap-up

[2] Google Cloud, “Welcome to Google Cloud Next ‘26,” Google Cloud Blog, Apr. 23, 2026. [Online]. Available: https://cloud.google.com/blog/topics/google-cloud-next/welcome-to-google-cloud-next26

[3] S. Giannini and B. Runkle, “What’s new in Cloud Run at Next ‘26,” Google Cloud Blog, Apr. 23, 2026. [Online]. Available:

What’s new for Cloud Run at Next ‘26 | Google Cloud Blog

Cloud Run updates at Next include integrations with Google AI Studio and Gemini Enterprise Agent Platform plus support for NVIDIA Blackwell GPUs.

cloud.google.com

[4] Google Cloud Developer Advocates, “Stateful Serverless: The Architectural Evolution of Cloud Run for the Agentic Era,” Medium, Apr. 28, 2026. [Online]. Available: https://medium.com/google-cloud/architectural-evolution-of-cloud-run-for-the-agentic-era-28af995cecb0

[5] R. Bobade, “I Looked Past the Keynote Hype: Why A2A + ADK Is the Real Story of Google Cloud NEXT ’26,” dev.to, Apr. 23, 2026. [Online]. Available:

I Looked Past the Keynote Hype: Why A2A + ADK Is the Real Story of Google Cloud NEXT '26

Google Cloud NEXT '26 Challenge Submission

Rushikesh Bobade

Rushikesh Bobade

Rushikesh Bobade

Follow

Apr 23

I Looked Past the Keynote Hype: Why A2A + ADK Is the Real Story of Google Cloud NEXT '26

#devchallenge #cloudnextchallenge #googlecloud #ai

4 reactions

Comments Add Comment

10 min read

[6] M. Gerstenhaber and M. Bachman, “Introducing Gemini Enterprise Agent Platform, powering the next wave of agents,” Google Cloud Blog, Apr. 23, 2026. [Online]. Available: https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform

[7] Google Cloud, “Day 1 at Google Cloud Next ‘26 recap,” Google Cloud Blog, Apr. 23, 2026. [Online]. Available: https://cloud.google.com/blog/topics/google-cloud-next/next26-day-1-recap

[8] “每秒300个沙盒：Google把AI代理的‘定时炸弹’拆了,” 163.com, Apr. 30, 2026. [Online]. Available: https://www.163.com/dy/article/KRNLIEBV05561FZW.html

2026-04-30 12:26:37

Ever wondered what happens when you let AI argue with itself?

I built AI Debate Arena — a terminal app where four AI agents (a moderator, a pro debater, a con debater, and a judge) run a full structured debate on any topic you give them, powered by LangGraph and Groq.

Here's how it works and what I learned building it.

🧠 The Concept

The idea is simple: instead of one AI giving you a balanced answer on a topic, what if multiple agents each had a role and a perspective — and had to argue, rebut, and decide?

Four agents, one state machine:

🔧 The Stack

• LangGraph — for the state machine / agent orchestration
• Groq + llama-3.1-8b-instant — for fast LLM inference
• Rich — for the live typewriter-style terminal UI

🗂️ Project Structure

I split the project across 4 files for clean separation of concerns:

debate-arena/
├── main.py           # Entry point, user input, terminal display
├── agents.py         # State definition, LLM, agent functions
├── connections.py    # Graph nodes, edges, routing logic
└── prompts.py        # All prompt templates

🖥️ Terminal UI with Rich

After the graph finishes, the full history list is played back with a live typewriter effect using Rich:

def typewriter_panel(role, content):
    colors = {
        "moderator": "cyan",
        "pro": "green",
        "con": "red",
        "judge": "magenta"
    }
    text = Text()
    with Live(Panel(text, title=role.upper(), border_style=colors.get(role, "white")), refresh_per_second=30) as live:
        for char in content:
            text.append(char)
            sleep(0.005)
            live.update(Panel(text, title=role.upper(), border_style=colors.get(role, "white")))

Each role gets its own colour — cyan for the moderator, green for pro, red for con, magenta for the judge.

🧪 Running It

pip install -r requirements.txt
python main.py

Enter the topic: AI will replace software engineers
Enter maximum rounds: 3

Then watch the debate unfold in your terminal.

💡 What I Learned

LangGraph's conditional edges are powerful. Once I understood that routing is just a function that returns a string key, wiring up complex agent flows became intuitive.

Shared state is everything. All four agents read from and write to the same State dict. Keeping it well-defined upfront saved a lot of debugging later.

Prompt discipline matters. Telling each agent to "avoid repetition" and "rebut the previous argument" in the prompt made a real difference in output quality.

Groq is fast. Running 3 rounds with 4 agents means 6+ LLM calls — Groq handled this without any noticeable delay.

🔮 What's Next

• Save debate transcripts to a file
• Swap in different models per agent
• Build a web UI with Flask or Streamlit
• Add a third "neutral" debater

The full code is on GitHub: github.com/Sripadh-Sujith/debate-arena

If you build something on top of this or have ideas for improvements, drop them in the comments. Happy to discuss!

Thank You💖

2026-04-30 12:22:45

Long-form (1500+ words). 12-point checklist: principle of least privilege, env var hygiene, no shell=True, signed releases, dependency pinning, sandboxed FS access, structured logging, no eval/exec on untrusted input, supply chain auditing, etc. Each point with a code example (good vs bad). Mention mcp-security-scan as one tool among several (also reference semgrep, bandit, trivy for fairness). Footer disclosure: 'Written and published by AgentGraph's content bot. Reviewed by humans before publishing.'