<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Agent Infrastructure on RLGeeX</title><link>https://www.rlgeex.com/categories/agent-infrastructure/</link><description>Recent content in Agent Infrastructure on RLGeeX</description><generator>Hugo</generator><language>en-us</language><copyright>RLGeeX © 2025 - Real-Life Geeks providing expert IT consulting</copyright><lastBuildDate>Tue, 03 Nov 2026 09:00:00 -0500</lastBuildDate><atom:link href="https://www.rlgeex.com/categories/agent-infrastructure/index.xml" rel="self" type="application/rss+xml"/><item><title>Cloud Run as an Agent Runtime: Resource Type, Sandboxes and Agent Identity</title><link>https://www.rlgeex.com/news/cloud-run-as-an-agent-runtime-resource-type-sandboxes-and-agent-identity/</link><pubDate>Tue, 03 Nov 2026 09:00:00 -0500</pubDate><guid>https://www.rlgeex.com/news/cloud-run-as-an-agent-runtime-resource-type-sandboxes-and-agent-identity/</guid><description>&lt;p>If you lead a platform or infrastructure team and are wiring agents into real systems on Google Cloud, Cloud Run&amp;rsquo;s documentation now covers a lot of the agent runtime. Here is how I&amp;rsquo;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&amp;rsquo;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&amp;rsquo;t be changed or unset once you set them on a resource.&lt;/p></description></item><item><title>What MCP Actually Solves: From N Connectors to One Integration Layer</title><link>https://www.rlgeex.com/news/what-mcp-actually-solves-from-n-connectors-to-one-integration-layer/</link><pubDate>Tue, 08 Sep 2026 09:00:00 -0400</pubDate><guid>https://www.rlgeex.com/news/what-mcp-actually-solves-from-n-connectors-to-one-integration-layer/</guid><description>&lt;p>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&amp;rsquo;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&amp;rsquo;s effort.&lt;/p></description></item><item><title>Building a Multi-Tenant MCP Proxy: One Endpoint, Three Backends</title><link>https://www.rlgeex.com/news/building-a-multi-tenant-mcp-proxy-one-endpoint-three-backends/</link><pubDate>Tue, 01 Sep 2026 09:00:00 -0400</pubDate><guid>https://www.rlgeex.com/news/building-a-multi-tenant-mcp-proxy-one-endpoint-three-backends/</guid><description>&lt;p>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.&lt;/p></description></item></channel></rss>