Managed Runtime vs. Self-Hosting
The discussion of managed runtime vs. self-hosting focuses on the operational responsibilities of hosting applications within Lark Services. It emphasizes the importance of defining execution boundaries that separate customer responsibilities from those delegated to platforms like Cloud Run and Google Kubernetes Engine (GKE). The text outlines the decision-making process for selecting a hosting option based on application behavior, execution hosts, inference access, state services, and customer authority. It concludes that Cloud Run is the preferred choice due to its alignment with existing operational models, while also highlighting the need for thorough testing and validation of recovery processes and private API accessibility.
Lark Services’ application team has demonstrated its maintenance-summary assistant, but nobody has accepted the restart-recovery runbook or the overnight alert. Choosing its execution host now means deciding which operational responsibilities a platform will carry and which Lark can reliably operate. The assistant’s ability to answer a request leaves those responsibilities unresolved. A defensible hosting recommendation connects customer constraints, recoverable work, and an operating team.
Choosing the boundary
An execution boundary defines which responsibilities remain with the application team and which are managed by the hosting platform. Agent Runtime, Cloud Run, and Google Kubernetes Engine (GKE) provide different options for hosting custom agents, each with distinct deployment and operational responsibilities.
Choosing a hosting platform does not automatically determine the model-serving location or API used for inference.
Document five separate architectural decisions in Lark's deployment record:
Application behavior: The assistant authorizes a maintenance-record read, obtains the record, requests a summary, and validates the result.
Execution host: A service runs the Python application and replaces failed execution instances.
Inference access: The application calls a configured Gemini managed API.
State services: Explicit integrations retain accepted tasks, conversation data where needed, and generated results.
Customer authority: Named people approve releases, respond to incidents, authorize access changes, and accept residual risk.
“Self-hosted agent” on Cloud Run or GKE describes ownership of the agent application stack. It does not necessarily mean operating physical servers: Cloud Run remains a Google-managed platform, while GKE offers several infrastructure-management boundaries. The useful question is which application and infrastructure responsibilities remain, and whether somebody can exercise them.
Lark’s actual constraints
Lark already has an approved Cloud Run delivery platform. Its platform team operates private connectivity and service telemetry; its application team owns releases and incidents. The assistant is a standard Python HTTP application, reads a private maintenance API, and uses the configured Gemini managed API. Accepted work must survive process replacement. No Kubernetes-specific requirement has been identified.
Classify these statements before comparing products:
Mandatory: Reach the private API under an approved identity; enforce access; recover accepted work; retain validated results; provide an actionable incident path.
Existing capability: Lark can already deploy and operate Cloud Run services through its approved platform.
Preference: Reuse that delivery path when it meets the mandatory requirements.
Unknown: Whether the exact application, dependencies, state integration, and telemetry contract fit Agent Runtime without significant changes.
An existing operating team is evidence of capability. “The agent should run there” is a compatibility hypothesis until the actual application is exercised. Similarly, being able to create a GKE cluster does not establish that Lark can maintain its workload configuration or respond to cluster-related incidents.
Dividing the work
Agent Runtime (formerly Vertex AI Agent Engine) delegates agent execution to a managed agent surface. Cloud Run delegates container infrastructure while Lark supplies the application and its service integrations. GKE exposes Kubernetes workload configuration, with infrastructure responsibility determined by the selected cluster and workload modes.
GKE Autopilot manages most infrastructure, including node provisioning and scaling. Standard gives the customer direct control over node infrastructure, resource allocation, placement, and scaling configuration. Standard clusters can also run selected Autopilot workloads, so “GKE Standard cluster” alone does not completely describe an individual workload’s operating burden.
Compare the five dimensions together. For Agent Runtime, treat exact supported state and telemetry integrations as verification items rather than implied features.
Across all three options, Lark retains ownership of business behavior, application authorization, release acceptance, dependency compatibility, and customer incident decisions. Delegating ...