Platform Engineering on RLGeeX

Cloud Run as an Agent Runtime: Resource Type, Sandboxes and Agent Identity

Tue, 03 Nov 2026 09:00:00 -0500

If you lead a platform or infrastructure team and are wiring agents into real systems on Google Cloud, Cloud Run’s documentation now covers a lot of the agent runtime. Here is how I’d work through it. Hosting an agent on Cloud Run is three separate decisions, made for each agent. The first is which resource type matches the agent’s loop. The second is where its untrusted tool code runs. The third is which identity it holds. Make the identity decision first, because the functional and identity types can’t be changed or unset once you set them on a resource.

What MCP Actually Solves: From N Connectors to One Integration Layer

Tue, 08 Sep 2026 09:00:00 -0400

If you lead a platform or infrastructure team that is wiring agents into real systems, this post sets out what the Model Context Protocol buys you and what it doesn’t. MCP replaces the per-pair connector with one integration layer: one server per system and one reusable client-side protocol implementation per agent application. That is the whole point. It does not remove the system-specific work, and it does not reduce the number of live connections you operate. Knowing where that boundary sits tells you where to spend your team’s effort.

Building a Multi-Tenant MCP Proxy: One Endpoint, Three Backends

Tue, 01 Sep 2026 09:00:00 -0400

This post is for platform and infrastructure leads wiring agents into real systems. You have a few MCP servers, more than one tenant who needs them, and you want a single endpoint in front of them. My position is that all of the tenancy belongs in the proxy and none of it belongs in the backends. The rest of this post covers the decisions that follow from that and the ones I would not compromise on.

Reusable Terraform modules for a GCP foundation: draw boundaries by ownership

Thu, 29 Jan 2026 09:00:00 -0500

This post is for cloud engineers building a GCP foundation with Terraform who have reached the point where the same networking or logging configuration keeps reappearing and someone suggests making it a module. My argument is about where to draw the module boundaries. Split modules by who is allowed to change the infrastructure and how often it changes. Keep each module narrow, and version it like a library. Getting the boundaries right early costs far less than refactoring a foundation that everything else sits on.